How to Choose Shadowrocket Servers: Latency Tests, Regions & Protocols

1. Latency measures response time, not bandwidth

A latency test measures how long a probe takes to receive a response, usually in ms. Different test methods cover different network paths. A TCP handshake test focuses on whether the server address and port respond promptly. A probe routed through a proxy to a test destination is also affected by proxy negotiation, destination address resolution, and the destination server’s response. Check which method was used before comparing results; don’t rank results from different methods as if they were directly comparable.

When you use Connectivity Test on Home, test each candidate with the same method and destination. If the interface lets you choose a test method, keep it unchanged. A result is one probe, not a guarantee about every future request. A timeout means only that this probe did not finish within the time limit; one timeout alone doesn’t prove the subscription has stopped working.

Low latency may make short interactions feel faster, but sustained downloads also depend on available bandwidth, packet loss, congestion, server load, and destination throttling. For example, a candidate may respond quickly while a congested shared exit keeps a large download at a low rate. Another candidate with a slightly slower response but steadier throughput may work better for video buffering or file transfers.

2. Keep test conditions consistent before choosing candidates on Home

Keep your current working configuration in place. Don’t update the subscription, change rules, and switch networks all at once just to compare latency. Home is where you select a server and connect; Config manages configuration files; Settings contains related options. Keeping these layers separate makes it easier to tell whether a change came from your server choice, routing rules, or automatic connection conditions.

1. Check your subscription

   On Home, check your existing subscription group and server entries. If you haven’t added one yet, go to Home → + in the upper-right corner → Type → Subscribe, enter the subscription URL from your provider, and save it. Update once before testing, then avoid repeatedly refreshing the group during your comparisons.

2. Keep the network consistent

   Run the first round on the same Wi-Fi network, and pause heavy transfers on other devices. Check your existing triggers under Settings → On Demand. If they interfere with manually disconnecting and reconnecting, note the original settings and pause them during testing, then restore them afterward.

3. Keep routing consistent

   Note the original setting under Home → Global Routing. For a short, controlled comparison, you can select Proxy to reduce interference from direct-connection rules in Config; restore the original setting when you’re done. With Direct selected, don’t attribute the speed of a direct connection to the chosen server.

4. Repeat the tests

   Use the same method to test candidates under Home → Connectivity Test. Repeat each test three times, with a short pause between runs. Record the number of successful tests and the range of results, then shortlist two or three entries that respond consistently. You don’t need to test the entire subscription every time.

5. Check real-world requests

   Select a candidate on Home, connect, and retest using the same websites and files. Re-establish the test connection after switching. If needed, reconnect Shadowrocket so existing long-lived connections don’t keep using the previous route. Finally, return to Config and check performance with your everyday rules.

3. Choose a region based on your needs, then verify the actual exit

Regions in server names are usually assigned by the subscription provider. They might describe an entry point, an exit point, or the intended use of a route; they don’t necessarily show the path your device takes to a destination website. Shorter physical distance often helps reduce propagation delay, but peering, detours, and congestion can change the results. Two routes in the same region can perform very differently.

Websites usually see the request’s exit address, but region detection may also use account details, device permissions, session history, and address databases. Switching servers doesn’t guarantee that a website will immediately recognize a different region. If a site detects your region incorrectly, first confirm that the request is using the intended policy. Then distinguish the exit address from the site’s own detection logic instead of switching repeatedly without identifying the cause.

4. Choose a protocol for your network conditions, not by name or speed

A protocol defines how the client and server communicate, but it doesn’t determine route quality on its own. How Shadowsocks, VMess, and VLESS perform depends in part on their transport and related settings. Trojan commonly uses TLS; Hysteria2 is based on QUIC and relies on a UDP path; WireGuard tunnels traffic over UDP. Results from different servers, regions, and load conditions can’t establish that one protocol is inherently better than another.

The port must match the server’s settings. For example, if the configuration specifies TCP 443, test that port rather than changing it because it’s commonly used for TLS. UDP 443 and TCP 443 are different transport endpoints; connectivity on one doesn’t prove the other works. Don’t try random ports, disable certificate verification, or change identity settings just to get a lower test result.

If entries with different protocols from the same provider don’t share the same entry point, exit, and load conditions, compare them as separate candidates. To assess the effect of transport, keep the server, destination, time, and network as consistent as possible. Protocol support means a connection is possible; it doesn’t guarantee route performance.

5. Use a fixed log to distinguish latency, variation, and throughput

Compare two or three candidates at a time. Start with consecutive tests, then retest during your usual hours. The configuration card below is a manual logging template, not a file you can import into Shadowrocket. Its time and test count are consistent conditions for this process, not product limits.

For example, suppose candidate A returns 42, 45, and 310 ms across three tests, while candidate B returns 78, 81, and 80 ms. These figures illustrate how to assess results; they are not measured route data. A has the lower minimum, but its results vary more in this round. B is more consistent. Next, check real-world requests. Three probes can’t establish all-day stability, and response times can’t be converted into download speeds.

• Web browsing: Check whether initial loads, repeat visits, and image loading all slow down together. Cached content can mask differences.
• Video: Compare buffering and interruptions at the same resolution. Smooth playback after the player automatically lowers quality isn’t an equivalent comparison.
• File transfers: Use the same file and source, and distinguish MB/s from Mbps. In decimal units, 1 MB/s equals 8 Mbps.
• Interactive apps: Watch for fluctuations and intermittent lag. If the service uses UDP, verify the UDP path in practice as well.

6. Check the route before switching servers

If everything works under Proxy but fails again under Config, check the rule path before trying more servers. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP matches geographic IP classifications, and FINAL handles requests that didn’t match earlier rules. Rule order, DNS results, and policy group selection can all affect the exit. In Config, check which configuration is active and use request logs to identify the matching rule.

7. Keep a primary and a backup, and retest under consistent conditions

The goal isn’t to find a permanently lowest ms value; it’s to keep a route you can verify repeatedly in your own environment. Your primary candidate should reach the websites you use, provide stable interactions, and support adequate sustained transfers. Choose a backup with a different route where possible. Two entries with different names but the same exit may not provide a useful alternative.

• For everyday use, restore your original Global Routing and On Demand settings. Don’t leave temporary test settings in place.
• Retest when performance changes persist, subscription entries are updated, or your network environment changes. Don’t switch immediately because of one higher latency result.
• Record candidate names, protocols, network, and test times so you can compare results later.
• When something goes wrong, change one variable at a time: check the network first, then the candidate, then protocol settings and rules.

For more details on where to find settings and how to use them, see the User Guide. For unfamiliar terms, consult the Glossary. Confirm the route used by real requests before investigating latency, region, or protocol; this is usually more effective than repeatedly refreshing the entire list.