How to Choose a Shadowrocket Server: Latency Tests, Regions, and Protocols

1. What a latency reading tells you

A test result in Home is the time taken for one probe, not an overall score for the entire route. What the reading tells you depends on the test method: a TCP probe typically measures how long it takes to establish a connection to a specified address and port. An HTTP probe is also affected by the test URL, request path, and connection method. Before comparing results, make sure both tests use the same method and target. Don’t rank readings from different test methods together.

Loading a webpage involves several stages: DNS lookup, connection establishment, TLS handshake, request transmission, server processing, and content transfer. A page may also load images, scripts, and other resources from multiple domains. A fast response from the server entry point only means that one part of the route was short or uncongested at that moment. It doesn’t guarantee a fast response from the destination website or enough bandwidth for sustained transfers.

A failed test doesn’t mean the server is unusable in every situation. A failed DNS lookup, unreachable test target, or unresponsive port can all cause a probe to fail. Conversely, a reachable port doesn’t confirm that the password, TLS settings, or protocol parameters are correct. Check these as two separate things: whether the entry point responds and whether a proxy request completes successfully.

2. Set up a repeatable comparison in Home

Choose a small number of candidates from your existing list. Don’t change DNS, rules, protocol parameters, and network settings all at once. Change only one variable at a time so you can identify what caused the difference. When verifying real-world access, make sure requests actually go through the selected server. A successful page load under Direct doesn’t prove that a proxy server works.

1. Check the details

   In Home, review your existing server entries and the results of any subscription updates. Compare the address, port, and Type with your own service details. If a subscription needs updating, update it first, then review the candidate entries again to avoid comparing settings that changed midway.

2. Keep the network consistent

   Stay on the same Wi-Fi or cellular network, and pause large downloads or uploads. Go to Settings → On Demand and check the automatic connection conditions to make sure the connection won’t disconnect or reconnect automatically during testing because the network conditions changed.

3. Check the routing mode

   Go to Home → Global Routing. For a temporary proxy test, select Proxy, then choose a candidate server in Home and connect. Restore your usual settings when the test is done. If you use a policy group, also check which member is actually selected.

4. Repeat the tests

   Run a latency test for each candidate in Home, using the same method and target every time. Test each candidate at least three times and record every result, including timeouts. Don’t keep only the lowest reading.

5. Verify real-world access

   Select each candidate in turn, open the same webpage, and test the same video segment. Record how long it takes for content to first appear and whether playback stalls. Then restore your usual Global Routing settings.

In Global Routing, Proxy routes traffic through a proxy, Direct connects directly, Config applies the rules in the active configuration, and Scene follows the selected scene settings. These are not four different speed-test methods. If you normally use Config, switch back to Config for your final check. Go to Config to confirm which configuration is active, then check whether the relevant domains match a policy that routes through the server you just tested.

3. Assess region labels separately from the actual exit location

A region name in the server list usually comes from the entry’s label; it isn’t an independent verification of physical location by the app. An entry labeled for one region may have an entry point elsewhere, then route through another server before reaching its exit. A website’s detected region may also depend on its IP geolocation database, account region, and content licensing. Don’t infer the route or assume a website will work based on the name alone.

Physical distance often affects propagation time, but internet routes don’t follow straight lines on a map. Peering between networks, carrier routing, congestion, and the location of the entry point can all affect performance. Different results for the same server on home Wi-Fi and cellular data aren’t contradictory; they show that at least part of the route has changed.

If you need access to content for a specific region, first check the exit region against your legitimate use and actual access results, then compare performance. For general web browsing, there’s no need to rank regions in advance. Choose an existing entry that responds consistently and completes requests over the network you use most.

4. Protocol type is not a speed rating

A protocol determines how the client and server exchange data, authenticate, and establish a connection. Speed also depends on server resources, link quality, and server-side settings. There’s no universal speed ranking for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard across all networks. Changing Type alone also can’t convert an existing server to another protocol.

Two servers in the same region but using different protocols may have different entry points, exit points, and resources, so their performance difference may not be caused by the protocol. To assess a protocol’s effect on your current network, keep other conditions as consistent as possible. If you can’t confirm that they match, conclude that “this entry was more stable in this test,” not that “this protocol is always faster.”

5. Use your test records to distinguish low latency from smooth performance

The figures below are hypothetical examples to show how to record results; they are not real-world measurements or a performance guarantee. Suppose candidate A returns 42, 45, and 180 ms across three probes, while candidate B returns 68, 70, and 72 ms. A has the lower minimum, but its results vary more. If A repeatedly stalls during video playback and B doesn’t, factor in real-world performance instead of ranking them solely by 42 being lower than 68.

For three test results, start by comparing the median and the range. Record timeouts separately instead of removing them to calculate a more flattering average. A short sample can’t establish all-day stability. For candidates that matter to everyday use, test again during your usual hours and record the network type and test time.

• Webpages: Distinguish when content first appears, when images finish loading, and when the page becomes interactive. A cache hit can make repeat visits faster.
• Video: Keep the resolution and segment fixed. Automatic resolution changes can hide insufficient throughput, so don’t record only whether playback started.
• Large files: Check sustained transfer speed, not just the initial burst. Avoid running multiple transfers that compete for bandwidth.
• Interactive apps: Watch request response times and interruptions. When average latency is similar, jitter and packet loss may have a greater impact.

6. Check rules and updates after choosing a server

After testing with Proxy temporarily enabled, restore your usual configuration. If a website works under Proxy but fails after switching back to Config, check the rules and policy references first instead of assuming the server has failed. Config applies the rules in the active configuration file. Requests to different domains on the same webpage may also be routed separately through DIRECT and PROXY.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

The snippet above illustrates match order; it isn’t a complete configuration for every use case. Go to Config to check the active file and its Rule section, then confirm which server or policy group PROXY actually points to. If an earlier rule matches, a later FINAL rule won’t select a different route.

1. [Rule] marks the start of a rules section.
2. DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains, then routes them through PROXY.
3. IP-CIDR,192.168.0.0/16,DIRECT,no-resolve routes this private IP range through DIRECT; no-resolve means this IP rule won’t trigger a DNS lookup.
4. GEOIP,CN,DIRECT matches CN using an IP geolocation database, then routes through DIRECT. It doesn’t use the region label on a server entry.
5. FINAL,PROXY sets the final policy for requests that didn’t match an earlier rule.

After an existing subscription is updated, entry names, addresses, ports, or policy group members may change. Check the selected server in Home, the policy references in Config, and real-world access again. A matching name in the selected entry isn’t a substitute for checking its settings. When troubleshooting, share only the error details needed; don’t disclose subscription links, passwords, UUIDs, or keys.