Shadowrocket Latency Test: Choose Existing Nodes by Region and Protocol

1. What latency numbers measure

Latency is usually shown in ms (milliseconds), but what the number means depends on the test method. A TCP connection test measures roughly how long it takes to connect to a server address and port. An HTTP or HTTPS test through a proxy also involves proxy negotiation, connecting to the target, and waiting for its response. These tests cover different parts of the route, so their results aren’t directly comparable.

Before comparing nodes, check which test method and target the app is using. If a test only checks the server port, a low result means that connection responded quickly—it doesn’t prove the target website is accessible. Even a test that reaches a specified target through a proxy only reflects that target’s performance at that moment, not every site or time of day.

A timeout doesn’t necessarily mean a node is down. The test target may be unreachable, name resolution may fail, the server port may be restricted, or the protocol handshake may fail. Check separately whether the port accepts connections, the proxy connects, and the target returns content. One red result can’t identify every kind of failure.

2. Set consistent conditions before testing your subscription

Update your subscription before comparing nodes, and note which network you’re using. An update can change addresses, ports, or the node list. If some results come from before the update and others from after, you’re no longer comparing the same configuration. Treat subscription links as credentials; don’t include them in screenshots, public notes, or support requests.

1. Check your subscription

   Find your subscription group in Home. To import a subscription for the first time, go to Home → “+” → Type → Subscribe, enter a link you already have, and save it. There’s no need to add an imported subscription again.

2. Update the subscription

   Update the existing subscription from Home and make sure the list refreshes. If the update fails, resolve the link or credential issue first. Don’t treat test results from an outdated list as current.

3. Keep conditions consistent

   Use the same Wi-Fi or cellular network throughout, and pause any high-bandwidth transfers. Check Settings → On Demand to review automatic connection conditions and avoid connection changes if the network switches during testing.

4. Repeat each test

   Run latency tests on candidate nodes from Home, keeping the method and target consistent. Test each node three times, with a short pause between runs, and note any timeouts. Use batch results to narrow the list, then retest a few candidates individually.

5. Verify actual access

   Select and connect to a candidate, then check the mode used in Global Routing before opening the same target page. Observe whether the page loads promptly, stays responsive as you browse, and handles longer requests reliably.

Three readings aren’t a statistical guarantee, but they make occasional fluctuations easier to spot than a single result. For example, 48 / 51 / 49 ms is a stronger candidate for further testing than 25 / timeout / 180 ms. These figures are illustrative only—not measurements of any node or pass/fail thresholds.

3. Filter by region: names are only clues

Start with the region your use case requires. If the destination needs an exit in a particular region, confirm the exit region first, then compare candidates from that group. If there’s no regional requirement, focus on consistency and real-world access. Region names, flags, and abbreviations come from the subscription and don’t prove where a server is located or where traffic exits.

Two nodes in the same region can use different entry points, transit routes, or exit points. Conversely, nodes labeled with different regions may share part of a route. So neither “closer is always faster” nor “same region means same performance” is a reliable rule. Record the specific node, network, and test time—not just the region name.

4. Filter by protocol: check connection requirements first

Existing nodes in Shadowrocket may use Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard. A protocol name describes how a connection works; it doesn’t tell you how latency or bandwidth will rank. Performance can vary widely with the server, port, and network route, even for the same protocol. Don’t change subscription parameters just to use a particular protocol.

Hysteria2, for example, uses QUIC. If the current network restricts UDP, switching to a similarly named node in the same region may not help. WireGuard also relies on UDP, but its handshake and tunnel work differently, so TCP connection time can’t explain its connection status. For VMess or VLESS, checking Type alone isn’t enough; transport method and server configuration matter too.

• When comparing protocols in the same region, choose candidates tested at similar times and against the same target to limit changes in conditions.
• If a protocol connection fails, first check for a subscription update and verify the address, port, and authentication parameters. Don’t weaken verification just to get one successful connection.
• If a connection type fails only on one Wi-Fi network but works over cellular, first check for transport restrictions on that network.
• Don’t batch-edit ports, TLS, or transport settings on subscription nodes. These settings need to match the server configuration.

5. Low latency but no access? Check Global Routing and rules

A successful latency test doesn’t mean your browsing request is using the node you just tested. In Home → Global Routing, Proxy, Direct, Config, and Scene determine how traffic is routed. For everyday use, follow the existing Config rules. When troubleshooting, identify the route the request actually takes.

Scene provides scenario-based routing, and its behavior depends on the existing scene settings. The name alone doesn’t show which route is in use. If Scene is enabled, check its configuration before testing, or note the original settings before switching to a troubleshooting mode.

• In Config, check which configuration is active—not just a file that isn’t enabled.
• DOMAIN-SUFFIX matches domain suffixes; GEOIP matches against IP geolocation data; IP-CIDR matches IP ranges.
• FINAL determines where traffic goes when no earlier rule matches. Rule order and the policies they reference both affect the result.
• Check connection logs for the destination, matching rule, and route. If the destination is routed to DIRECT, that page’s performance doesn’t tell you how the proxy node performs.

6. Distinguish a quick response from a stable transfer

Low latency can help with frequent small requests, but sustained transfers also depend on available bandwidth, packet loss, congestion, and target server load. A node may complete the handshake quickly but repeatedly stall while transferring content. Another may respond a little more slowly at first, yet handle later requests reliably. Evaluate each based on your actual use; don’t reduce both to one number.

Browser caching and connection reuse can affect how fast a connection feels. If the same page opens faster the second time, it may be a cache hit—not an improvement in the node. Compare the same content under similar request conditions. Don’t judge a node by latency while streaming video or syncing large files. Testing itself uses network traffic, so account for any limits on your existing service.

7. Keep results you can reproduce

Your final choice should be one that’s been verified for a particular network and use case—not a permanent ranking. Subscription updates, server changes, and local network conditions can all make old results outdated. There’s no need to test the entire list often; recheck a few frequently used candidates after an issue, a network change, or a subscription update.

1. Record the conditions: Note whether you used Wi-Fi or cellular, the test method, target, and time. Don’t share subscription credentials.
2. Record the candidates: Keep the node name, region label, Type, and update status to distinguish similarly named entries.
3. Record the results: Note latency, timeouts, and actual request performance separately instead of keeping only the lowest reading.
4. Record the routing: Note the Global Routing mode and the policy actually used so you can repeat the test.
5. Keep a backup: Retain a tested alternative from your existing options, and verify access again after switching.