Shadowrocket Latency Test: Choose Existing Servers by Region and Protocol

In this guide

Shadowrocket latency figures are useful for screening servers you already have, but they don’t measure bandwidth or the full browsing experience. Assuming you already have a service provider and subscription, this guide walks through controlling test conditions, checking regions and protocols, repeating measurements, and verifying real-world access—so you can distinguish fast responses, stable connections, and fast downloads.

What latency tells you: start with what’s being measured

Latency is usually shown in milliseconds (ms). A lower figure means less time was taken by the interactions included in that test. First, check what the test measures: TCP connection time and the time for an HTTP request through a proxy cover different steps. ICMP round-trip time is not a direct measure of proxy request time, either. Until you know the test method, don’t refer to every figure in the list as “ping.”

A successful TCP connection only shows that a connection to the address and port could be established at that moment. It doesn’t guarantee successful protocol authentication, a TLS handshake, or a complete request to the destination website. HTTP tests also depend on the test URL, DNS, TLS, and the server’s response. Tests that more closely resemble real requests are more informative, but each result still represents only that particular request.

Latency: How long a single interaction takes—useful for assessing initial response time.
Throughput: The amount of data transferred over time, usually measured in Mbps or MB/s. It can’t be calculated directly from ms.
Variation: How consistent results are under the same conditions. Repeated measurements are more useful than a single lowest value.
Timeout: The test didn’t finish within the allotted time. Possible causes include the network, port, protocol settings, or test target; it doesn’t necessarily mean the server is down.

Keep conditions consistent, then test existing servers from Home

For a meaningful comparison, change only the server whenever possible. Use the same iPhone or iPad, network connection, test target, and test method. Wi-Fi and cellular connections can take very different routes. Retest after switching networks instead of relying on the previous ranking.

Check your existing configuration

View your existing servers in Home. To add one manually, tap “+” in the upper-right corner of Home to open Add Server, then enter the Type, address, and port from your existing service details. Update your subscription before comparing servers so you don’t test an address that has since changed.
Keep the connection environment consistent

Choose either Wi-Fi or cellular, and pause other bandwidth-intensive activity. Check Settings → On Demand and note its current state. If you need to temporarily turn it off to prevent automatic reconnections from changing test conditions, record the original setting and restore it afterward.
Test candidates one at a time

Go to Home, select each candidate server in turn, and use Connectivity Test to check connectivity. Record the displayed result, test method, and time. A successful connectivity check doesn’t prove that every website is accessible.
Run three tests

Test each candidate three times using the same method, for example at intervals of about 10 seconds. Keep every result instead of recording only the lowest value. Record timeouts too; don’t silently exclude them from an average.
Verify real-world requests

Check the current routing mode in Home → Global Routing. To temporarily isolate the effect of rules, select Proxy to test the chosen server, then visit the same page. When finished, restore the original Config or other setting, and confirm that the request actually went through that server.

Direct in Global Routing isn’t suitable for checking a proxy server’s real-world access because requests connect directly. Config processes requests according to the active configuration and may match DIRECT. Scene follows its configured conditions, which you should also check. So “the page loaded quickly” doesn’t necessarily mean “the selected server is fast.”

Choosing a region and protocol: check the route before comparing results

A region label can help organize candidates, but it usually comes from the service details. It doesn’t verify the server’s physical location or reveal the route from ingress to egress. Shorter geographic distances can reduce propagation time, but carrier peering, detours, and congestion may erase that advantage. Compare results on your current network rather than sorting by region label alone.

Keep separate test records for each network

Wi-Fi

Test on the same Wi-Fi network in the same location to minimize changes in wireless signal.
Choose two or three candidates from different regions in your existing list and use the same test target.
Run one set of tests during the day and another in the evening to check for changes during busy periods.

Cellular

Compare servers while stationary with a stable signal, so you don’t change cell sites while moving.
Retest your existing candidates instead of assuming the Wi-Fi top pick will also be best on cellular.
Record the network conditions for each test. Retest if your signal or location changes.

Keep separate rankings for each network. This makes it easier to pinpoint problems than trying to use one server for every connection.

Protocol names describe connection methods, not fixed speed tiers. The performance of Shadowsocks, VMess, VLESS, and Trojan also depends on transport, encryption, TLS, and server settings; the name alone can’t tell you which will be faster. Hysteria2 uses QUIC and depends on UDP reachability. WireGuard also uses UDP, but its tunnel works differently, so the two aren’t equivalent test cases.

Check the type first: The Type in Add Server must match your existing service details. Don’t change the protocol just to chase a lower number.
Then check the settings: The port, authentication details, and TLS settings must match. Port 443 is just a port number; it doesn’t mean the protocol is necessarily Trojan or guarantee a successful connection.
Distinguish the transport: For configurations that use UDP, probing the TCP port at the same address doesn’t prove the actual protocol works. Check the protocol connection and a real request as well.
Keep variables in mind: Results from servers in different regions using different protocols can help you choose between them, but they don’t show that one protocol is inherently faster.

How to read three test results: consistency matters more than the lowest value

These hypothetical figures illustrate how to record results. They aren’t measurements from this site and don’t represent the performance of any region or protocol. Compare success first, then the median and variation. Finally, verify real-world page loads and sustained transfers.

Existing candidate	Three results	How to interpret
A, same test method	72 / 180 / 95 ms	Median: 95 ms. High variation; check performance during busy periods.
B, same test method	104 / 108 / 106 ms	Median: 106 ms. Consistent across all three tests; proceed to verify real-world access.
C, same test method	60 ms / timeout / 65 ms	Despite the low result, one test failed. Don’t rank it first based on 60 ms alone.

Three samples are enough for an initial comparison, but not to calculate a reliable long-term packet loss rate. If A is occasionally fast while B is consistently stable, interactive pages may feel smoother on B. If real-world results show otherwise, trust repeatable results from the task you actually care about. Don’t treat a single fixed millisecond threshold as a pass mark for every network.

Latency log

Network: Same Wi-Fi throughout testing; no network switching
Test conditions: Same test method and test target
Number of tests: 3 per candidate, about 10 seconds apart
Record: Every ms result, timeout, and test time

Make sure conditions are comparable before ranking results. Record figures from different test methods separately.

Real-world access checklist

Routing mode: Home → Global Routing → Proxy; restore the original setting after testing
Page load: Open the same page three times; distinguish the first load from cached loads
Sustained transfer: Use the same file you’re authorized to access and observe the sustained transfer rate
Overall assessment: Consider success rate, wait time, and sustained transfer performance together

A request can only assess a connection if it actually passes through the server being tested.

Low latency but slow pages: troubleshoot the request path

Loading a webpage takes more than one round trip. DNS lookups, connection setup, TLS handshakes, the main document, and requests for multiple subresources all add time. Some resources may come from different domains. A fast latency probe doesn’t mean the website’s DNS resolution, egress route, or server response will be equally fast. Large downloads are more sensitive to sustained bandwidth, congestion, and packet loss.

Confirm the request route. Check the current mode in Home → Global Routing. When using Config, check the active file in Config rather than relying on which server appears selected in Home.
Check which rules match. For example, DOMAIN-SUFFIX,example.com,DIRECT sends the matching domain through DIRECT; FINAL,PROXY applies only to requests that haven’t matched an earlier rule. Rules are evaluated from top to bottom. Changing the selected server won’t override a matching DIRECT policy.
Separate first loads from cached loads. The first load may include DNS and TLS setup; a later visit may use cached data or a reused connection. Record these separately so you don’t compare a first load on one connection with a cache hit on another.
Change the task, not multiple settings at once. Check the same page first, then another destination you’re authorized to access. If only one site has problems, investigate its route and response before changing the port, DNS, and protocol all at once.
Check different times of day. If a short test looks fine but sustained transfers slow down, retest later under the same conditions and note whether the issue occurs only during busy periods.

GEOIP and IP-CIDR rules route traffic based on IP conditions; they don’t measure server distance or speed. A region condition in a configuration also doesn’t prove where the selected server’s egress is located. When troubleshooting, separate how rules determine the route from the actual quality of the connection.

FAQ: timeouts, updates, and automatic switching

Does a timeout mean the server is definitely unusable?

First, make sure your Wi-Fi or cellular connection is working, then run the test again from Home. Check the existing server’s Type, address, and port in Add Server, then verify the actual connection. If only one test target fails while real pages work, check the test method and target before drawing conclusions from the timeout.

Why are my old low-latency results no longer accurate after a subscription update?

An update may change addresses, ports, or server entries; the same name doesn’t guarantee the same route. Go to Home, check the updated candidates, and test each three times on the same network with the same target. Don’t apply old rankings to new entries or restore outdated settings just to preserve a low number.

The connection turns itself back on during testing. How can I keep conditions consistent?

Go to Settings → On Demand and check your existing on-demand settings. Note the original state, then temporarily turn them off if needed and return to Home to confirm the connection state. Restore the original settings after testing. On Demand connects according to conditions; it doesn’t automatically choose a server with the lowest latency.

Should the server with the lowest number always be my first choice?

Verify real-world page loads and sustained transfers before choosing a primary server, and keep another verified candidate available. Retest after switching from Wi-Fi to cellular, updating your subscription, or noticing a significant change in performance. If your configuration uses an automatic policy group, check its selection criteria too: the entry you select manually may not be the server the group ultimately uses.

A practical selection order is: confirm the settings, verify that the connection works, check for consistent results across repeated tests, and assess performance for your actual task. Only then compare differences of a few milliseconds. This guide covers testing and using configurations you already have. Check client purchases and the terms of your existing service separately.