When choosing from servers in a subscription you already have, first rule out those that fail to connect. Then compare latency on the same network using the same test method, and check whether the location and protocol suit your needs by trying your actual destinations. This guide covers selecting a server in Shadowrocket, checking Global Routing, running Connectivity Test, and troubleshooting slow loading despite low latency. Latency is one measurement—not a guarantee of bandwidth, exit location, or a stable connection over time.
1. What latency numbers tell you
The milliseconds shown in a list measure how long a test takes. What that means depends on the test method and destination. A test that checks whether a connection can be established does not cover the same route as one that sends a request to a destination through a proxy. Before comparing results, check which method Connectivity Test is using. Numbers from different methods or destinations should not be ranked directly against each other.
A successful connection test alone doesn’t prove that subsequent authentication, DNS resolution, or access to the destination website will work. Even when a test goes through a proxy, it only shows how that route to that test destination performed at that moment. A webpage may request resources from multiple domains, open multiple connections, and download many files. Video playback depends more on sustained throughput and buffering.
For example, if one test reports 40 ms and another reports 90 ms, you can only conclude that the first took less time in that test run. These figures are hypothetical and illustrate how to read results; they are not measured performance data. They don’t show that the first server downloads faster, and a single timeout doesn’t mean a server is permanently unavailable.
2. Set consistent conditions before choosing a default server
Keep your current working configuration before you start, and make sure the subscription is from a service provider you already use. Updating a subscription may change the server list or its settings. After an update, check that the previously selected entry is still there instead of comparing by its old name. Don’t change a server address, port, or authentication details just to lower a latency reading.
-
Keep the network consistent
Run tests on the same Wi-Fi network or the same cellular connection without switching networks. Pause other bandwidth-heavy activity and note the test method. If the cellular signal or Wi-Fi access point changes, start a new set of results.
-
Check the routing mode
Go to Home → Global Routing and check whether the current mode is Config, Proxy, Direct, or Scene. If you’re using Config, also check the active configuration under Config; its rules may route the destination through a different policy.
-
Select an entry
Return to Home, select a candidate from your existing server list, and check that the selection indicator appears on the left. If a policy group in the configuration selects a different server, changing the default server on Home may not change the route used by your traffic.
-
Run a test
Use Connectivity Test on Home. Keep the test conditions the same, run it three separate times, and record successes, timeouts, and elapsed time. Three runs are a troubleshooting step—not a fixed number of tests required by the app, and not a packet-loss measurement.
-
Test your actual destination
Turn on the connection switch. The first time you connect, follow the system prompt to allow adding a VPN configuration. Visit the website or service you actually plan to use, and note whether it opens, whether the initial page load is sluggish, and whether the connection drops during use. Repeat the same steps with the next candidate.
If the test result doesn’t match your browsing experience after selecting a server, first check whether your traffic is actually using it. The connection switch, Global Routing selection, and rules and policy groups in Config all affect the route. The selection indicator beside an entry doesn’t prove that every request uses that server.
3. How Global Routing changes the comparison
Before comparing servers, identify the routing mode. Config, Proxy, and Direct handle traffic differently. Scene needs to be checked against the active scene settings; it doesn’t represent one fixed exit route. The comparisons below cover Shadowrocket’s own settings only.
Config
RecommendedWith Config, traffic may use DIRECT, a proxy, or a specified policy, depending on the matching rules. To compare everyday performance, keep the configuration you’ve already checked and confirm that the test destination matches the expected policy. If no earlier rule matches, behavior depends on the FINAL rule.
Best for: Checking real-world access with your everyday rules
Proxy
Routes traffic within its scope through the proxy. This is useful for isolating the effects of rules once you’ve confirmed which proxy is selected. It won’t fix problems on the route between the server and destination website, or replace checking whether the destination service is available.
Best for: Temporarily isolating rule-based routing and checking the proxy route
Direct
Uses a direct connection. Results from browsing in this mode aren’t evidence of the selected proxy server’s performance. They can help you check whether your local network can access a destination that allows direct connections.
Best for: Establishing a direct-connection baseline—not ranking proxy servers
Bottom line: Check the route before interpreting the numbers
If results differ noticeably between Config and Proxy, first check the rule matched by the destination and the policy it uses. Don’t switch protocols right away. The comparison is meaningful only after confirming both requests use the same server.
4. A server’s listed location may not match the location a website detects
Locations in subscription entries usually come from names provided by the service provider. They’re clues for choosing a server, not independently verified geographic information from the app. The location of the entry address, the final exit address, and the location database used by a destination service may all differ. With multi-hop routing, low latency to the entry point doesn’t mean the final exit is closer to the destination.
- Start with your goal. If you want reliable page loads, compare the actual websites you use rather than choosing by location labels alone. A shorter distance often reduces transmission time, but peering and congestion can still affect performance.
- Check the exit location. Use the location shown by the destination service itself and consider the service provider’s information about the exit. Don’t treat a city or country in a subscription name as verified exit-location data.
- Separate location from account requirements. Some services also check account region, content licensing, and other conditions. Changing to a server with a different location label doesn’t guarantee access to particular content or features.
- Keep the destination consistent. A candidate that works better with one website may not work as well with another. Compare the same page at similar times and under consistent cache conditions.
A server working on Wi-Fi but behaving differently on cellular doesn’t necessarily mean you chose the wrong location. A network change can affect DNS, routing, and UDP reachability. Treat cellular as a separate set of test conditions and run Connectivity Test again instead of mixing the results into one ranking.
5. Use protocol type to check compatibility, not to rank servers
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are different protocols with different configuration requirements—not speed tiers. A connection first depends on the server and client settings matching. Even when a protocol works, the network, server load, and route to the destination still affect performance.
| Protocol | Check first | What you can’t infer |
|---|---|---|
| Shadowsocks | Server address, port, encryption method, and password. If UDP is involved, confirm that both ends support it. | Actual throughput based only on the encryption method’s name. |
| VMess / VLESS | Identity parameters, transport method, and TLS settings must match the server. | That the protocol name means one specific transport route. |
| Trojan | Password and TLS parameters, including the server name required by the server and certificate verification requirements. | That entering 443 will always establish a connection. |
| Hysteria2 | Based on QUIC and requires UDP reachability. Check authentication and TLS parameters. | That it will always be faster than a TCP-based route on every network. |
| WireGuard | Keys, peer address, port, tunnel addresses, and other settings. Its transport uses UDP. | That a working connection with another protocol means UDP is reachable on the current network. |
If a subscription you already have includes entries using different protocols in the same listed location, test them one at a time as candidates. Similar names don’t prove that entries use the same server, exit, or workload. This comparison can help you choose an entry that works for you now, but it isn’t a controlled performance test of the protocols themselves.
Don’t change an entry’s Type to another protocol in an attempt to make it faster. Changing the type in the client doesn’t switch the server’s protocol, and the existing port and identity settings may not apply. If you need a different protocol, use the corresponding configuration actually provided by your existing service provider.
6. Troubleshoot low latency but poor performance by symptom
It’s more useful to note which step fails than to keep refreshing the latency test. Establishing a connection, resolving a domain, loading the first screen, downloading resources, and streaming for an extended period are different stages. If a test succeeds but a page doesn’t load, narrow down the problem instead of describing every failure as a slow server.
Latency is low, so why does the webpage keep loading?
First check the connection switch on Home and Global Routing, then run Connectivity Test. If the test succeeds but one website fails, check its rule and policy under Config, along with the DNS settings in the current configuration. If the rules include DOMAIN-SUFFIX, GEOIP, or IP-CIDR, check the matching order as well; don’t look at FINAL alone.
The list shows a timeout. Should I try anyway?
Check your local network first, then test the same entry again. A timeout may be caused by the test destination or a specific test route. If you’ve confirmed the settings are correct, select the entry and try the destination you actually need. If both the test and actual access fail, check whether the subscription has been updated and whether the address and port are still valid.
Video starts playing, then starts buffering. Why?
Note whether this happens only on a particular network or at certain times, then try another existing candidate at the same video quality. Sustained video transfer and short-term latency measure different things. Initial buffering, the content delivery route, and server load can all affect playback. A single low millisecond reading doesn’t prove that sustained throughput is sufficient.
Why does the connection reconnect after I switch networks?
Check the existing triggers under Settings → On Demand and confirm whether Wi-Fi, cellular, or domain conditions are active. Record these conditions before troubleshooting. If needed, temporarily disable the relevant triggers and connect manually. Restore the original settings after testing so automatic connection behavior isn’t mistaken for an unexpected server switch.
Keep the entry that meets your needs, works across repeated tests, and provides stable real-world access—not necessarily the one with the lowest latency in a single test run. Keep a simple record of the network, candidate name, protocol, Global Routing mode, test method, and actual results. Repeat the same steps after a subscription update or a network change.