This guide is for users who have already imported their own subscription into Shadowrocket. To choose a server, use the same test method to rule out unreachable options, then compare regions, protocol settings, and real-world results for your intended service. You’ll learn to keep repeatable test records instead of switching based only on the lowest latency value. This guide assumes you already have your own provider and subscription; it does not cover how to choose a service.
1. Make sure your test matches the connection you’re evaluating
The selected server in Home, the current mode in Global Routing, and the rules in Config all affect where requests go. A successful test for a server in the list doesn’t mean a webpage is using that server. In Config mode, for example, the destination domain may match DIRECT. In that case, using page load speed to evaluate the server won’t test what you think it does.
Before testing, pause large file transfers and stay on the same Wi-Fi or cellular network. Don’t switch networks while comparing two servers; wireless signal, carrier routing, and server performance can otherwise affect the results at the same time.
-
Check the list
Open Home and confirm your subscription is expanded and the server list isn’t empty. If you’ve just updated the subscription, check the entry names and settings again; don’t assume an old entry still points to the same server.
-
Set the routing mode
Go to Home → Global Routing. To isolate the effect of rules, temporarily select Proxy, then restore your usual mode, such as Config, when testing is done. Direct won’t test how a proxy server handles webpages; for Scene, check how the selected scene behaves.
-
Run a test
Return to Home and run Connectivity Test. Record the test method: ICMP, TCP, and HTTP results mean different things. Don’t rank latency values from different test methods together.
-
Test each option
Select a candidate server, connect, and visit the same target webpage. Repeat the same steps for other candidates, recording whether the page loads, times out, how long the first screen takes to appear, and whether loading stalls.
-
Restore your settings
When you’re done comparing, restore your usual Global Routing mode and open the target service again. If the result changes, check the matched rules and routing policy first instead of continuing to switch servers blindly.
2. What latency does—and doesn’t—tell you
Latency measures how long a specific probe takes at a specific moment. It isn’t bandwidth or the time needed to load a whole webpage. ICMP mainly measures network-layer probe responses, which servers may restrict. TCP probes mainly check connection setup on a specified port. HTTP tests also depend on the test URL, application-layer response, and route used. Latency values are comparable only when you know how they were measured.
Server probe log
- Network
- Use the same Wi-Fi throughout; don’t switch to cellular during testing
- Test method
- Use one method throughout; don’t mix results
- Number of tests
- Run each candidate 3 times in a row and record failures
- What to look for
- Whether tests succeed consistently and results fluctuate significantly
Three tests is a practical recommendation, not a fixed app setting.
Real-world access log
- Routing mode
- Temporarily use Proxy to isolate the effect of DIRECT rules
- Target
- Use the same webpage or resource in every round
- What to observe
- Initial load, ongoing loading, and any mid-load stalls
- Retest time
- Run another round during your usual usage hours
Browser cache and connection reuse affect results, so don’t compare only the speed of the second visit.
For example, suppose one set of test results shows candidate A with TCP latencies of 45, 48, and 210 ms, and candidate B with 85, 88, and 86 ms. This only shows that B’s probe results were more consistent in that round; it doesn’t mean B will necessarily download faster. These are sample readings, not measurements of any server by this site. If webpages also stall frequently with A, that’s stronger evidence for temporarily removing it from your shortlist.
- Low latency, slow webpages: Check DNS resolution, the TLS handshake, the target site’s response, and server egress load. A single latency value can’t pinpoint the problem.
- Occasional timeouts: Keep a record of timeouts. Choosing only the lowest successful result can hide intermittent connectivity problems.
- Slow sustained transfers: Latency probes transfer very little data and can’t replace a sustained transfer test. Check bandwidth limits and congestion separately.
3. Choose a region based on where you need to connect, not just distance
A region in a server name is a configuration label, not independent verification of where traffic exits. The locations of the entry address, the route taken, and the egress IP region identified by a destination website may all differ. Shorter physical distance can reduce propagation time, but detours, interconnection between networks, and congestion may cancel out that advantage.
If your target service has regional requirements, rely on the region it actually detects and your access results. Account region, location permissions, previous sessions, and the target site’s database can also affect page content. A change in the homepage language alone doesn’t confirm that your network egress region has changed.
- Everyday browsing: Among candidates that meet your access requirements, compare reliability and actual time to first screen. Don’t assume one region is always faster.
- Region-dependent services: Identify the required egress region first, then compare candidates within that region. A low-latency entry that doesn’t meet your needs isn’t useful to compare.
- On the go: A server that works well on home Wi-Fi may behave differently on cellular. After switching networks, run the same test again.
- Long sessions: Avoid switching egress servers repeatedly during a login, call, or sustained transfer; a disrupted session can be mistaken for an unavailable server.
4. Choose protocols for compatibility, not by name or assumed speed
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different connection methods and require different settings. The protocol name alone doesn’t determine speed. Server setup, transport, whether your network allows the relevant traffic, and whether all settings are correct are often more important for connectivity. Existing subscriptions usually include these settings; leave them unchanged while testing.
Trojan commonly uses TLS. Check the configuration to see how VMess and VLESS are transported and whether TLS is enabled; don’t infer these details from the protocol name. Hysteria2 depends on the UDP path, while WireGuard also requires the correct keys, peer, and address settings. A TCP probe can’t fully confirm that a UDP-based session works, nor can it replace protocol authentication.
- Port: Port 443 isn’t a universal fix. If your server listens on a different port, changing it to 443 will cause the connection to fail.
- TLS: Check the server name and certificate requirements in your configuration. Disabling certificate verification isn’t a routine troubleshooting step.
- Authentication: The password, UUID, or key must match your own server. A reachable port doesn’t mean authentication succeeded.
- Transport: Changing Type doesn’t convert the server to a different protocol. The protocol and its associated settings must match.
5. Troubleshoot common symptoms layer by layer
Start by checking your network, then server reachability, protocol connectivity, and finally the target service. Change one variable at a time and retest the same target. If you change the region, protocol, subscription, and rules all at once, you won’t know what fixed access—even if it starts working again.
Why does a webpage keep spinning when latency is low?
In Home → Global Routing, temporarily select Proxy, choose the server, and retry the same webpage. If it still fails, check protocol authentication, TLS settings, and access to the target service. If it works, return to Config and check the rules and routing policy. Restore your usual routing mode when testing is complete.
Why does the same server work at home but not on cellular?
Run the same test over Wi-Fi and cellular, and note the protocol. If you’re using Hysteria2 or WireGuard, check whether the UDP path is restricted. Also make sure your system allows Shadowrocket to use cellular data; don’t conclude that the server is faulty based on a single timeout.
Why did my selected server change after updating the subscription?
Return to Home, check the updated list, select a candidate again, and confirm its Type, server address, and port. A subscription update may rename entries or replace servers, so old test results may no longer apply. Don’t include your full subscription URL or authentication details in public troubleshooting records.
Why does the target website look unchanged after switching servers?
First check that Global Routing isn’t set to Direct, then check whether Config routes the target through DIRECT. Close the existing webpage session and try again. If the connection restores automatically or is affected by switching, check your existing automatic connection conditions under Settings → On Demand. This helps distinguish automatic behavior from a manual test.
6. Keep reusable server selection records
Your final choice should meet three criteria: the target service works, access is reliable, and results are repeatable on your usual network. The lowest latency can help narrow down the options, but it shouldn’t be the only criterion. Keep one server for everyday use and one tested backup. When a problem occurs, retest before switching; don’t treat a brief fluctuation as a permanent result.
- Record the network, test time, test method, candidate, and results from all three probes, including failures.
- Note whether the egress region meets your needs, whether the same webpage loads, and whether loading stalls. Don’t record passwords, keys, or your full subscription URL.
- Retest after a subscription update or network change; don’t rely on speed rankings for old entries.
- After temporary testing, restore everyday settings such as Config and confirm that requests to the target still follow the expected policy.