How to Choose a Shadowrocket Server: Latency Tests, Regions, Protocols, and Why Low Latency Doesn't Guarantee a Better Connection

At a glance

This guide is for users who have already imported a configuration from a provider they use into Shadowrocket. Start by distinguishing latency from throughput and stability, then control your network, test method, and routing mode before comparing the regions and protocols of your existing configurations. Choose based on whether your actual apps work and on repeatable test results—not the lowest number in the list. This guide does not provide, sell, or recommend servers or subscriptions.

1. What a latency reading actually measures

Latency is usually shown in milliseconds (ms) and measures how long a particular probe takes to complete. It describes a brief exchange, not how much data can be transferred per second. Interpret Shadowrocket's test results in light of the method used: the same configuration can produce different readings depending on the test method, target, or current network. Don't treat results from different tests as directly comparable rankings.

For example, a TCP probe mainly measures the time needed to establish a TCP connection to a specified server port. A reachable port doesn't mean protocol authentication succeeded, or that the remote server can access the target website. An HTTP probe through a proxy covers more of the path, but its timing also depends on the test URL, DNS, the TLS handshake, and how the server responds. Don't assume a test covers the entire path used by your app just from its name.

Test method	What it can tell you	What it can't prove on its own
ICMP probe	Whether the target host is reachable over ICMP and its round-trip time	That the proxy port, authentication, and target website all work; the server may also restrict ICMP
TCP probe	Whether a TCP connection can be established to the specified host and port	That the proxy protocol works, sustained transfer speeds are high, or the UDP path is working
HTTP probe through a proxy	Whether a request to a specified test URL completes, and how long it takes	That other domains, content in other regions, or long-lived connections will work normally
Testing the app itself	How the target page, video, or call performs with the current configuration	That performance will stay the same at different times or on different networks

A timeout doesn't necessarily mean the server is offline. The test target may be unreachable, the port may be wrong, the current network may restrict a transport, or the test method may not suit the protocol. Likewise, a low latency reading only means that particular probe completed quickly. It doesn't replace testing the apps you actually use after connecting.

2. Hold test conditions steady before comparing configurations

First, confirm that your existing subscription imported successfully into Home and that the server address, port, and protocol fields are complete. Updating a subscription syncs configuration records; it doesn't increase server bandwidth or automatically resolve restrictions on a target website. If your provider changed the address or authentication details, update them before comparing. Don't update subscriptions, switch networks, and change rules all between tests.

Use the same network

Choose one Wi-Fi or cellular network and pause bandwidth-heavy sync tasks. Don't switch networks during testing, and note the time of each test.
Check the configuration

Select an existing configuration in Home, open its details, and check Type, the address, and the port. For example, if the server requires TCP 443, don't guess and change it to 8443. Use the parameters provided for your server.
Keep routing consistent

Go to Home → Global Routing and note whether the current mode is Config or Proxy. To isolate the effect of rules, you can temporarily compare using Proxy, then restore the original setting. Also check Settings → On Demand so automatic connection conditions don't change the test state.
Repeat the tests

In Home, run Connectivity Test with the same method and target for each candidate, repeating each test three to five times. Record timeouts, typical results, and the highest latency—not just the lowest reading.
Test your actual use case

After connecting, visit the same target and check the initial load, continued loading, and recovery after a brief idle period. Give each candidate the same observation window—for example, five minutes—before testing the next one.

The figures below are hypothetical and illustrate a logging format. They are not product measurements and don't correspond to any available service. Count timeouts separately; don't treat them as 0 ms when calculating an average. The median of successful results reduces the influence of an outlier, but failures still need to be recorded.

Candidate A: sample log

Test network: Same Wi-Fi, same location
Five test results: 38, 41, timeout, 210, 43 ms
Median of successful results: 42 ms, plus 1 timeout
App performance: Two loading stalls in five minutes

The 38 ms minimum doesn't account for the timeout and significant variation.

Candidate B: sample log

Test network: Same conditions as Candidate A
Five test results: 72、75、73、74、76 ms
Median of successful results: 74 ms, no timeouts
App performance: Loading remained smooth for five minutes

For sustained interactive tasks, consistent results may matter more than a single low latency reading.

3. A region label doesn't reveal the actual route or egress performance

The region in a connection name is usually supplied by the configuration provider. It may refer to an entry point, an egress location, or a service group; it isn't an independent confirmation of physical location by the client. The path may include your local network, access provider, entry server, relay, egress, and target website. A server that's geographically closer isn't necessarily on a shorter route; detours and congestion between networks can erase the distance advantage.

If a target app determines your region from your egress IP, rely on the egress it actually sees and the app's own service rules—not just the name shown in Home. Websites may also consider your account region, location permissions, or previous sessions. If a website still shows the old region after you switch configurations, that doesn't immediately mean the latency test is wrong: these are entirely different observations.

Interactive use: Focus on how quickly pages load, searches run, forms submit, and repeated taps respond. Don't rely on a geographic label alone.
Sustained transfers: Check whether transfers continue smoothly or stall often. A quick response to a short probe doesn't mean a long-lived connection has enough throughput.
Real-time apps: Check jitter, packet loss, and UDP reachability as well as round-trip time. If UDP is unavailable, a successful TCP probe doesn't establish that the app will work.
Region-specific services: Check the target service's availability and account requirements, and confirm that requests actually use the expected egress.

4. Protocols affect connection requirements, not speed rankings

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different connection mechanisms, but the protocol name alone can't tell you which configuration will be faster. Server location and load, transport settings, your local network, and the route to the target all play a part. First make sure the imported fields match the server settings. Changing Type alone won't turn an existing server into a different protocol.

Protocol	Requirements to check	Testing limitations
Shadowsocks	Encryption method, password, port, and UDP settings supported by the server	A successful TCP test doesn't prove that UDP forwarding works
VMess / VLESS	Identity fields, transport method, and the corresponding TLS, Host, and path settings	A reachable port doesn't mean authentication and application-layer transport settings are correct
Trojan	Password, server port, TLS, server name, and related settings	A successful TCP connection may still fail at TLS or authentication
Hysteria2	UDP reachability, authentication, TLS, and server-specific settings	Uses QUIC; a TCP port probe alone can't confirm that the complete connection works
WireGuard	Keys, Endpoint, tunnel addresses, AllowedIPs, and other settings	Uses UDP; check the handshake and actual traffic through the tunnel

A port number doesn't identify what a protocol can do. TCP 443 and UDP 443 use different transport protocols; despite sharing a number, they aren't the same connectivity requirement. A network that allows TCP 443 may not allow UDP 443. If a configuration works on Wi-Fi but not cellular, keep its original settings and check the network and transport conditions separately rather than changing ports at random or disabling TLS verification.

5. Check Global Routing and rules before drawing conclusions

Selecting a configuration doesn't mean every request uses it. Global Routing sets the overall routing mode; under Config, the active configuration file, matched rules, and the policy specified by those rules also matter. If a domain matches DIRECT, switching proxy configurations usually won't change the route that domain takes.

Config

Recommended

Routes requests according to the rules in the current configuration. Use it when your existing rules are set up correctly and you want to keep your usual routing. It doesn't guarantee that every target will use the currently selected proxy.

Best for: Everyday use and testing actual traffic after confirming which rule matches

Proxy

Uses a proxy as the overall routing direction and can help you compare with the effect of Config rules. System traffic, routing exclusions, and traffic not captured by the proxy still need to be considered; this mode doesn't mean every connection on the device uses the proxy.

Best for: Temporarily isolating rule effects, then restoring the previous mode

Direct

Uses direct connections as the overall routing direction, so you can check access to a target over your local network. Performance in this mode doesn't tell you how the selected proxy configuration performs.

Best for: Establishing a local-network baseline and separating target-side issues from proxy-path issues

Scene

Uses the routing setup associated with the configured scene conditions. Before testing, check which settings the current scene actually applies so that changes in your environment don't send two rounds of tests over different paths.

Best for: Environments where scene conditions have been configured deliberately

For example, in the sample rule snippet below, example.com and its subdomains match DIRECT first; other requests then fall through to PROXY, as specified by FINAL. The example domain illustrates the syntax only. It isn't a test service or a usable connection configuration.

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

In Config, check which file is active and review request logs to confirm the policy in effect. Rules are evaluated in order. Besides DOMAIN-SUFFIX, conditions such as GEOIP and IP-CIDR can also affect the route; FINAL is the fallback when no earlier rule matches. Check whether a policy refers to another specified configuration or policy group, too, rather than assuming a request always uses the item currently selected in Home.

6. Common issues and what to check next

Why does video keep buffering when latency is only a few dozen milliseconds?

First, check the routing mode in Home → Global Routing and review the policy for the target request. Then watch the same video for five minutes, distinguishing the initial wait from stalls during playback. The initial wait may involve DNS, the handshake, or the target's response; playback stalls call for closer checks of sustained throughput, packet loss, and congestion. A brief probe can't account for these conditions.

The list test timed out, but websites load. Should I delete the configuration?

Don't delete it yet. In Home, check the Connectivity Test method and target, then confirm that the website is actually using that configuration. A timeout may not indicate an app failure if, for example, the protocol uses UDP but the test checks only a TCP port, or the test URL itself is unreachable. Repeat the test under the same conditions and keep a record of actual request results.

Why does a website still show the same location after I switch regions?

First, make sure Global Routing isn't set to Direct. Then check whether the domain matches DIRECT in Config or uses another policy. The actual egress may differ from the region label in the list. Even if the egress has changed, the website may still use your account region or previous session. Check the target service's rules instead of repeatedly switching connections.

Results change whenever I switch networks. How can I keep a backup?

Repeat the same tests on your usual Wi-Fi and cellular networks, and record success rates, variation, and actual app performance. Check whether conditions in Settings → On Demand have changed the connection state. Keep one of your existing configurations that you've verified works on your backup network, and confirm that the switch succeeds when you need it. There's no need to keep changing protocol settings to chase the lowest number.

A useful order for comparing configurations is: the target app works → the connection is stable on your usual network → results are repeatable at the times you use it → latency and throughput meet your needs. When troubleshooting, record the network type, time, protocol, routing mode, test method, and error. Then check server status with your own service provider. Hide passwords, keys, identity fields, and full subscription URLs; don't expose authentication details in troubleshooting screenshots.