This guide is for users who have imported servers into Home in Shadowrocket but aren't sure which one to choose. First, check what the test measures. Then keep your network and Global Routing settings consistent while comparing latency, location, protocol settings, and real-world page loading. Get subscription links from your service provider. This guide explains how to evaluate servers you already have; it does not provide server sources.
1. Check latency in Home: a result reflects one test
Open Home and make sure the listed servers are from your current subscription. Then use Connectivity Test to check the connection. Before reading the results, confirm the test method and target: different methods cover different parts of the connection, so an ms value doesn't necessarily mean “how long a web page takes to load.”
A TCP connection test mainly checks whether a connection can be established to a specified server port; it does not confirm that a full proxy request will succeed. A test that accesses a target through the proxy is also affected by the proxy handshake, the target's response, and related resolution steps. A successful test does not guarantee that other websites will work, and a timeout does not necessarily mean the server is permanently unavailable.
Latency and bandwidth measure different things. A short test request completing quickly doesn't prove that throughput will be sufficient for a sustained download, and a single test may not reveal congestion during peak hours. Treat test results as clues for troubleshooting, then verify them with real tasks. Don't choose a server for long-term use based on the lowest result from a single test.
2. Keep Global Routing consistent when comparing servers
Check Global Routing in Home. With Config, requests are routed according to the active configuration: a website may go DIRECT or be assigned to another policy. In that case, changing the current server in Home may not change the route the website actually takes. To compare servers, keep routing conditions consistent before comparing performance.
-
Choose candidates
Keep two or three existing candidates in Home and note their names, location labels, and protocols. Update the subscription if needed before testing so the server list and settings don't change mid-test.
-
Keep the network consistent
Test on the same Wi-Fi or cellular network, and pause large file transfers. Don't compare results from home Wi-Fi directly with results from cellular data while you're out.
-
Check routing
In Home → Global Routing, confirm the current mode. For a brief comparison of proxy routes, you can use Proxy; check the policy selection in your configuration, then restore the original mode when you're done.
-
Select a server
In Home, tap the circle next to a candidate server to make it current, then turn on the connection switch at the top. The first time you connect, follow the system prompt to allow adding a VPN configuration.
-
Repeat the checks
Review the results in Connectivity Test and test the same target three times. Then open the same web page and note when content first appears, when images finish loading, and whether any errors occur.
Proxy, Direct, Config, and Scene in Global Routing are routing modes, not four speed levels. Direct can't verify how a proxy server performs for real requests. With Config, check which configuration is active and which policy matches the request. Scene involves scene selection, so confirm which route is in use before testing. Don't assume every request goes through the current server just because the switch at the top is on.
3. Choose a location: distinguish the access point, exit location, and destination website
Location names in Home usually come from the service provider and don't, by themselves, confirm where the entry and exit points are. Where your device first connects and where traffic ultimately reaches the destination website are two different things. Servers with the same location label may also use different network routes.
A nearby location can be a useful first filter, but network traffic doesn't always take the geographically shortest route. Peering between networks, congestion at different times, and the route from the server to the destination website all affect performance. When accessing a website in a particular region, the exit location can also affect which content server the site assigns to you. So don't compare only the connection between your device and the server.
Device to server
- Check the location
- The current server and its connection settings in Home
- Keep conditions consistent
- The same Wi-Fi or cellular network
- What to observe
- Connection time, timeouts, and variation across repeat tests
- Location evidence
- Check your provider's information; don't infer the route from the name alone
Even if this leg performs well, check the route from the server to the destination website too.
Server to website
- Keep the target consistent
- The same web page and the same real-world task
- Check the route
- Confirm the request uses the expected proxy policy
- What to observe
- Whether page content appears, resources load, and transfers remain uninterrupted
- Retest at another time
- Test again during a time when you commonly use the service
Judge performance against the destinations you use regularly; don't treat one test target as representative of every website.
If a website is sensitive to account region or exit location, switching regions frequently may trigger additional verification. Keep your access environment consistent and in line with the website's requirements. Don't keep switching between regions just to chase a lower latency result.
4. Evaluate protocols: match the settings, then check how they perform on your network
In Home, open the server's edit screen and check Type against the settings supplied by your service provider. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different connection methods and settings; the protocol name alone doesn't indicate performance. For imported subscription entries, use the settings provided by your service provider. Changing Type alone cannot convert a server to a different protocol.
| Protocol | Check first | What to watch for during testing |
|---|---|---|
| Shadowsocks | Server address, port, encryption method, and password | A reachable port doesn't mean the encryption method and password are correct; verify a proxy request too. |
| VMess / VLESS | User ID, transport method, and related security settings | If the configuration uses TLS or a specific transport route, those settings must match as well. |
| Trojan | Password, port, and TLS settings | Troubleshoot connection timeouts and certificate validation failures separately. Disabling validation is not a routine fix. |
| Hysteria2 | Authentication, port, and TLS settings | This protocol uses QUIC for transport, so check whether UDP connectivity is available on your current network. |
| WireGuard | Settings such as the key, peer address, and tunnel address | Uses UDP; a TCP port test alone can't determine whether its tunnel is working. |
The server port isn't necessarily 443. Don't change the proxy port just because websites commonly use HTTPS. If one protocol fails on your current network but other existing entries work, note the error and check the settings and network restrictions. That doesn't mean the protocol is unavailable on every network.
- Different protocols and different servers: results are affected by both the route and the server load, so don't attribute every difference to the protocol.
- Same protocol, different time: peak congestion can change results, so compare tests taken at similar times.
- Unclear or outdated settings: check with your service provider and update the subscription if needed. Don't change authentication details at random.
5. Test real web pages: distinguish the initial load from continued use
After selecting a server, test it with websites or app tasks you use regularly. The first page load involves resolution, connection setup, and resource requests. A later refresh may reuse connections or local cache. So a faster second load doesn't necessarily mean the server has improved; the browser may simply be doing less work.
This is a method for recording results, not measured performance data. For each candidate, record three test results, any timeouts, and how the same task performs. Don't keep only the best-looking result: if two out of three tests fail, an occasional low latency reading doesn't make up for the reliability problem.
- Text pages: Check whether the text appears, whether loading stalls repeatedly, or whether a connection error occurs.
- Image-heavy pages: Check whether images finish loading. If a single resource domain fails, routing rules may be involved.
- Sustained transfers: Observe whether content you're authorized to access frequently stalls. Don't use a short test request to estimate long-term throughput.
- Switching networks: Record results separately for Wi-Fi and cellular. The same server may perform differently on each network.
6. FAQ: low latency, timeouts, and no change after switching
Why is the page still slow when latency is only a few dozen milliseconds?
First, check Global Routing and the current server in Home, then verify the connection with Connectivity Test. The test may cover only connection setup or a single target; a web page can load resources from other domains too. If the text appears but images stall, check the policies used by the actual requests, resource availability, and sustained transfer performance rather than just reordering servers by latency.
Should I delete a server if the test times out?
Keep the entry for now and repeat the test on the same network, then compare it with another existing entry. If everything times out, check your local network and the test target. If only one entry fails, verify its address, port, and authentication settings. If an update is needed, use the subscription from your service provider, then check which entry is selected after updating.
Why does the page look exactly the same after I switch servers?
In Home, confirm the circle is next to the new entry and check the connection status. Then check Global Routing: a rule or policy group under Config may not use the current entry in Home. Existing connections may not have switched yet either. Send a new request and check again; don't judge the switch based on a single page refresh.
How can I compare results if switching to cellular triggers an automatic connection?
Go to Settings → On Demand and check the automatic connection conditions already in place. Keep the network unchanged during testing so automatic connections don't get mixed up with manual switching. If you temporarily change On Demand, note the original settings and restore them after testing. On Demand controls when connections are triggered; it doesn't automatically find the lowest-latency route.
Choose in this order: confirm the settings and connection work, verify that your target websites load, check for consistent performance during the times you usually connect, and compare latency last. Keep one other existing candidate that passed the same checks as a backup. There's no need to rank every entry in the list, and a single test result isn't a long-term guarantee.