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

Understand what the test measures—not just the latency number

Servers in the Home list are often called nodes. The millisecond value beside each entry is the result of a specific test, not an overall score for the entire route. A lower value only means less time was spent on the interactions covered by that test; it does not measure available bandwidth, long-term packet loss, or how quickly a destination website responds.

First, check which method Connectivity Test uses. If it only checks whether a connection to the server port can be established, the result mainly reflects handshake time between your device and the server entry point. If it sends a request to a test URL through the proxy, the result may also include proxy negotiation, DNS resolution, the server's exit route, and the destination's response. An ICMP (Internet Control Message Protocol) probe is not a proxy handshake. Results from different methods should not be ranked together.

For example, an HTTPS (Hypertext Transfer Protocol Secure) test URL typically uses port 443, while your proxy server may use a different port specified by your provider. If a test fails, check the destination URL and server port separately; don't change both to 443. This guide does not list live test results or use a fixed millisecond threshold to determine whether a route is usable.

Test under consistent conditions, then set a default server

Before testing, pause other high-bandwidth activity. Use the same Wi-Fi or cellular network, test method, and destination URL throughout. Change only one variable at a time so you can tell whether a difference comes from the server or your local network. If your existing subscription has changed, update it before comparing servers in the list.

1. Check your existing configuration

   Open Home and confirm that your subscription group and servers appear. To add an existing subscription again, tap “+” in the upper-right corner, select Subscribe under Type, enter your own subscription URL, and save. Don't share subscription URLs in public posts.

2. Keep test conditions consistent

   On Home, open the Connectivity Test method settings and note the current selection. If you can set a test URL, note that too. Use the same settings for the entire comparison; don't combine results from different methods in one ranking.

3. Repeat the tests

   Run a latency test on the server list and test each candidate at least three times. Note whether you get a result every time and whether timeouts recur. Don't keep only the lowest value: a server that occasionally reports a low latency but times out on other attempts cannot be considered stable on that basis.

4. Choose a default server

   Return to Home and tap the selection dot to the left of a candidate server. Confirm that the selected indicator moves to it. Turn on the connection toggle; the first time you connect, follow the system prompt to allow a VPN configuration. Simply opening a server's edit screen does not select it as the default.

5. Verify access to your destination

   On Home, check the current mode under Global Routing, then open the website you need and reload it several times. Also try a brief sustained playback or download. After testing, restore your previous routing mode so diagnostic settings don't become your everyday configuration.

Choose a region based on where you need to exit—not the server name

A region in a server name is a description supplied by the provider; it does not, by itself, confirm the entry point, exit location, or actual route. The entry point your device connects to and the exit point used to reach a website may be in different regions. A shorter geographic distance can still involve a longer network route, so it does not guarantee lower latency.

If a website requires a particular region, check the exit region in your provider's documentation, then verify the website's actual availability. Account region, location permissions, cached data, and the site's own policies may also affect the result. A region in a server name does not guarantee that content will be accessible.

Check protocol type against configuration and network conditions

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are different protocol types, not a ranking from slowest to fastest. Even with the same protocol, results can vary with server load, the entry link, exit routing, and transport settings. Keep the type and associated fields supplied by your provider, then test whether your current network allows the required transport.

Don't change Type directly from one protocol to another to “speed things up.” The server must support the protocol, and its authentication fields must match. Use the original configuration for the domain, port, password, UUID (Universally Unique Identifier), TLS (Transport Layer Security), and transport path—don't guess from the server name.

For connections that use UDP (User Datagram Protocol), a network that can load ordinary webpages may still block the required UDP traffic. Conversely, an unresponsive port probe does not necessarily mean the full proxy connection will fail. Check the protocol connection, destination access, and error messages together.

Check Global Routing to make sure traffic is taking the expected route

Even after you select a default server, requests to a destination may not use it. Home → Global Routing controls how traffic is routed. In Config mode in particular, rules can send a website directly or route it through a specified policy. If changing servers makes no difference to a webpage, first check which route the request actually matched.

• Proxy: Handles traffic in proxy mode. When troubleshooting, also check the selected server and related settings; the connection toggle alone isn't enough.
• Direct: Connects directly to the destination. If ordinary webpages load in this mode, that doesn't prove the selected proxy server works.
• Config: Matches traffic against rules in the currently enabled configuration. Rules are processed from top to bottom; the first match determines the policy.
• Scene: Applies routing settings based on the configured scene conditions. Before retesting, check the current scene so you don't attribute a scene change's effects to the server.

The snippet below illustrates routing; it is not a replacement for your full configuration. DOMAIN-SUFFIX routes the example domain through PROXY, while FINAL sends all other unmatched requests through DIRECT. The example domain is for illustration only.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

If your configuration also contains GEOIP or IP-CIDR, check their position and policy too. Once a test website matches an earlier rule, later rules won't change the result for that request. When troubleshooting, check the mode first, then the enabled Config file, and finally the rule that applies to the destination.

Track response time, variation, and sustained transfers separately

A slow webpage doesn't necessarily mean a slow handshake with the server. A single visit may also involve DNS (Domain Name System) resolution, a TLS handshake, redirects, and multiple resource requests. Video playback depends more on sustained throughput and buffering. A successful small-data probe doesn't prove that large transfers won't become congested.

• Track response time: Use the same test method and record three results for each candidate. Frequent timeouts call for checking connection stability—not just comparing the lowest millisecond value.
• Track destination access: Open the same page and compare the first and subsequent loads. A later load may use cached data, so it isn't proof that the route got faster.
• Track consistency: Use the same content for a brief, sustained session and note any repeated pauses, reconnects, or interruptions. Don't treat a momentary speed reading as the average for the entire session.
• Track conditions: Record whether you used Wi-Fi or cellular, the test time, server name, and routing mode. After switching networks, start a separate set of results rather than mixing them with the previous set.

Common issues: what to check first

Keep a final test record without credentials: current network, selected server name, protocol type, test method, whether it timed out, and whether the destination was accessible. Sharing these details with your provider is more useful for troubleshooting than simply reporting “high latency.” Don't share subscription URLs, passwords, UUIDs, or keys publicly.