This guide is for users who have already added their own subscription to Shadowrocket. First confirm that the connection and rules are working as expected, then compare latency variation on the same network, the region required by your target service, and protocol compatibility. You’ll learn a repeatable way to compare options instead of simply keeping the one with the lowest latency. Get subscription links from your service provider.
1. Keep test conditions consistent before comparing existing nodes
Node names often include a region, protocol, or provider-defined label, but a name doesn’t prove performance. Before comparing options, make sure the subscription is up to date and the selected entry has all the required parameters. Then keep your network and test website consistent. Switching between Wi-Fi and cellular or testing different pages makes it hard to tell whether a result is caused by the node or your local network.
-
Check the subscription
Find your existing subscription in Home and check its entries and expiration date. To add it again, go to Home → + → Type → Subscribe, enter the link provided by your service provider, and save it. Update the subscription before testing, and leave expired entries out of the comparison.
-
Keep the network consistent
Stay on the same Wi-Fi or cellular network, and pause bandwidth-heavy transfers on other devices. In Settings → On Demand, check the conditions for connecting on demand so a change in network conditions doesn’t alter the connection state during testing.
-
Check the routing mode
In Home → Global Routing, check whether the current mode is Proxy, Direct, Config, or Scene. Note the original setting. If you temporarily use Proxy for comparison, restore the original setting afterward so your everyday routing behavior remains unchanged.
-
Retest each option
In Home, select a candidate, connect, and run Connectivity Test before visiting the same target page. Test each candidate three times in a row. Note whether it connects, how long the first screen takes to load, and whether loading stalls—not just a single millisecond reading.
Updating an existing subscription can change the number of entries, addresses, or parameters. Record the selected entry before and after an update so you don’t carry forward a conclusion based on a different option. A token in a subscription URL is an access credential; never include it in public screenshots, shared logs, or test notes.
2. Ping, connection latency, and page loading are different measures
People often use “Ping” as a catch-all for latency, but different tests measure different network paths. ICMP probes, TCP handshakes, and tests that access a test address through a proxy each cover different steps. Before comparing results, check the test method and target address. Numbers in the same list are directly comparable only when the test conditions match.
Latency measures how long a probe round trip or connection process takes; throughput measures sustained data transfer. Loading a webpage also involves DNS, connection setup, the TLS handshake, server response, and multiple resource requests. Lower latency can reduce some waits, but it doesn’t prove that large files will transfer faster or that a target website will accept the exit address.
| What you observe | What it may indicate | What to check next |
|---|---|---|
| The probe returns low latency | The test path responded quickly this time | Open a site you actually use and check the initial load and ongoing browsing |
| The probe times out, but the webpage works | The test method or target may not be suitable | Check the test method and compare again using the same target |
| The connection succeeds, but transfers keep stalling | A completed handshake doesn’t guarantee stable data transfer | Rule out local network congestion, then compare packet loss and server load |
| Most websites work, but one specific site fails | The issue may involve the target site, DNS, or routing rules | Check which rule matched the request and which exit it used |
For example, suppose candidate A returns 45, 260, and a timeout across three tests, while candidate B returns 85, 88, and 91 ms. In this illustrative set, B varies less, but you still need to test the target service. These aren’t measured performance rankings, and they don’t mean any region or protocol is always faster. Base your choice on repeatable results, not an occasional low reading.
3. Choose a region by considering the entry, exit, and target service
A region label may describe the exit location, or it may simply be a name chosen by the provider. Traffic travels from your device to an entry point, through the provider’s network to an exit, and then to the target service; geographic distance explains only part of the route. A location that looks closer on a map doesn’t guarantee a shorter network path, and a region in the name doesn’t confirm the actual exit location. Check with your provider.
Choosing a region: general browsing vs. region-specific services
General browsing
- Choose two candidates with different exit locations from your existing subscription.
- Visit the same set of pages on the same network and at similar times.
- Prioritize ongoing availability and latency consistency—not distance on a map.
Region-specific services
- Check the service’s region requirements and terms of use first.
- Ask your service provider to confirm the entry’s actual exit region.
- Check that requests to the target really use that exit, and judge by the service’s actual response.
Region is a selection criterion, not a guarantee of access. Different routes in the same region still need to be tested individually.
Region detection can also depend on account details, device location, existing sessions, and the service’s own policies. If a service still shows the previous region after you switch, that doesn’t by itself mean Shadowrocket failed to connect. Check routing and the exit first, then start a new session using the service’s normal process. Repeatedly switching entries won’t identify the cause.
4. Choose a protocol based on server settings and network conditions
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are different protocol options, not speed tiers. A client configuration is useful only if the server supports that protocol and provides all the required parameters. Changing Type to another option won’t make the existing server support a different protocol, and a port number alone doesn’t identify the protocol.
| Protocol | Parameters to check first | What to keep in mind when comparing |
|---|---|---|
| Shadowsocks | Server, port, encryption method, password | Parameters must match the server; confirming that the address resolves isn’t enough |
| VMess / VLESS | UUID, transport, TLS, and related transport parameters | They use different authentication methods; you can’t simply switch Type between them |
| Trojan | Password, port, TLS, SNI | SNI must match the certificate and server configuration; disabling verification isn’t a fix for incorrect parameters |
| Hysteria2 | Authentication details, TLS, and any other parameters required by the server | Uses QUIC over UDP; network restrictions on UDP can affect the connection |
| WireGuard | PrivateKey、PublicKey、Endpoint、Address、MTU | Requires UDP; the key, address, and routing conditions must all be correct |
For example, if an entry’s server port is set to 8443, use the 8443 provided by your service provider. Don’t replace it with 443 just because that’s a common HTTPS port. Hysteria2 and WireGuard both use UDP, but that doesn’t mean they’ll perform the same on the same network: server location, implementation, network load, and configuration parameters still differ.
- If only some entries using the same protocol fail, first check that entry’s address, port, credentials, and service status.
- If multiple UDP entries fail on the same network, retest on another network you’re authorized to use and check for UDP restrictions.
- If no protocols can access the internet, check your local network, system time, connection permissions, and current routing first. Don’t immediately conclude that the protocols are unsuitable.
5. Check Global Routing to make sure the selected node is actually being used
Selecting an entry in Home doesn’t mean every request will use it. Global Routing determines how requests are handled; under Config, rules may also assign a policy or policy group. Before comparing nodes, confirm where the target request is actually routed. Otherwise, you may be testing a direct connection the whole time.
Config
RecommendedRequests are routed according to the rules in the current configuration. First check the active configuration in Config, then see which rule and policy match the target domain. Not every unmatched request necessarily goes direct.
Best for: everyday use with correctly configured routing rules
Proxy
Requests covered by proxy routing are handled in proxy mode. This can help reduce variables introduced by rule-based routing, but exclusions in the system and configuration may still apply. It doesn’t prove that all device traffic goes through the proxy.
Best for: temporarily comparing proxy routes; restore the original setting afterward
Direct
Uses a direct connection. Even with a node selected in Home, you can’t use this result to assess that node’s performance. It can serve as a baseline for your local network.
Best for: checking whether the target is reachable without a proxy
Scene
Applies settings according to the configured scene conditions. Check which scene currently matches before testing; don’t assume the same routing conditions remain in effect after you switch networks.
Best for: setups with defined scenes that switch behavior based on the environment
Rules are generally matched from top to bottom. FINAL handles requests that didn’t match an earlier rule. The example below explains the syntax only; don’t replace your existing configuration with it as a whole. Check your current configuration to confirm what PROXY actually targets.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIn this example, DOMAIN-SUFFIX matches example.com and its subdomains first. IP-CIDR matches the specified address range, while no-resolve means the rule won’t actively resolve a domain name. GEOIP is checked afterward, and FINAL handles anything still unmatched. If an earlier DIRECT rule matches the target, changing the node in Home usually won’t change its route.
6. Common issues and how to retest
Why does the node with the lowest latency still buffer video?
Low latency reflects only the response time of the test step. Use the same video, resolution, and network to compare two candidates, checking playback over time and how quickly buffering recovers. Pause bandwidth-heavy background tasks as well. If buffering happens only during peak hours, note the time and compare again. A single probe can’t replace a sustained transfer test.
Home shows a timeout. Does that mean the node is no longer working?
Check the test method and target first. Then select the entry, connect, run Home → Connectivity Test, and try the actual target. If the test fails but the service works, investigate the probe conditions. If both fail, check for subscription updates and verify the address, port, and authentication parameters.
I switched nodes, but the webpage speed and region haven’t changed. Why?
First check whether Home → Global Routing is set to Direct. If it’s set to Config, check in Config whether the target matches a DIRECT rule or a fixed policy group. Have the target establish a new connection, then test again; existing long-lived connections may not be recreated immediately when you select another entry. A highlighted entry in the list doesn’t prove which exit is being used.
Wi-Fi works, but the same entry fails on cellular. What should I do?
First confirm that cellular data itself is working. Then check network conditions in Settings → On Demand and review the current Global Routing mode and scene. If the same parameters work on one network but fail on another, note the protocol, time, and error, then ask your service provider whether it’s reachable on that network. Don’t repeatedly change passwords or keys.
7. Keep retest notes instead of chasing the lowest number
You can keep one entry for everyday use and one verified backup. This is simply a way to organize an existing subscription, not a recommendation of any service provider. Record the network, test time, protocol, stated exit region, repeated test results, and actual app performance. Don’t record full subscription URLs, passwords, PrivateKey values, or other authentication details.
- Connection: Does the connection succeed, and does Connectivity Test pass consistently?
- Real-world performance: Does the same webpage load reliably, and does ongoing use stay uninterrupted?
- Routing: Do Global Routing, the active configuration, and the policy matching the target agree?
- When to retest: Compare again after switching networks, updating a subscription, or noticing a persistent issue. One temporary fluctuation doesn’t require an immediate switch.
Use this order: connection works → routing is correct → target is accessible → performance is stable → compare latency. This separates parameter errors and rule issues from network performance, so not every access problem gets blamed on node speed.