Latency figures in Shadowrocket are results from a specific test, not a speed ranking. This guide assumes you already have a provider and subscription. It explains how to keep test conditions consistent, check regions and protocols, confirm the route actually used, and choose primary and backup options from your existing servers. First check whether requests work, then whether the connection is stable, and only then compare latency.
1. What Latency Tests Measure—and What They Don’t
Latency is usually shown in milliseconds and represents the time taken by a specific probe. Start by checking the test method. A TCP connection test mainly reflects how quickly a connection to the server port is established. A test that accesses a URL through the proxy is also affected by the proxy handshake, DNS resolution for the test URL, and the destination’s response time. Results from these two methods aren’t directly comparable in a single ranking.
Before running a latency test on a server in Home, go to Settings and check the current test method. If it uses a test URL, keep that URL consistent too. The available methods and menu locations may vary; follow what the app currently displays. A successful test only confirms that this particular probe met its conditions. It doesn’t replace testing websites, sustained transfers, or real-time calls.
| Result | What it tells you | What it doesn’t tell you |
|---|---|---|
| Low TCP connection time | The connection to the tested port was established quickly at that moment | That proxy authentication is correct or the destination website will definitely load |
| Proxy request test succeeded | That the test request completed over the specified route | That other websites or UDP apps will also work |
| A single timeout | The probe didn’t complete within the time limit | That the server is permanently down or the password is definitely wrong |
| Results vary significantly across tests | The test route or endpoint may be unstable and needs further investigation | That you can choose a primary server based solely on its single lowest result |
Throughput measures how much data can be transferred over time; latency measures how long one interaction takes. They’re different metrics. A connection that responds quickly to a small request may still struggle with sustained transfers because of limited bandwidth, congestion, packet loss, or server load. Conversely, a connection with a slightly slower handshake may transfer data steadily once established.
2. Set Global Routing Before Comparing Existing Servers
Changing the selected server in Home doesn’t mean every request will use it. The Global Routing mode, rules in the current Config, and policy-group selection all affect the route. If a rule sends the test website through Direct, its load time can’t be used to judge the selected proxy server.
Config: Test with Your Everyday Rules
RecommendedConnections are handled according to the rules and policies in the current configuration. First check which policy matches the test destination, then confirm which server that policy actually uses. Don’t assume that every domestic address uses Direct or every other address uses Proxy.
Best for: Keeping your usual routing in place while testing real-world use
Proxy: Temporarily Isolate Rule Effects
Routes connections handled by Shadowrocket through the proxy, making it easier to check whether an issue comes from Config routing. This doesn’t guarantee that the network or destination is reachable. Restore your previous mode after testing.
Best for: Comparing the same website briefly to troubleshoot rules or policy selection
Direct: Direct-Connection Baseline
Routes connections handled by the app directly. Website performance in this mode doesn’t reflect the selected proxy server; use it only as a reference for your current direct connection.
Best for: Checking whether the same issue occurs when connecting directly
If you use Scene, first confirm which routing mode it actually applies under the current network conditions. Don’t mistake a Scene name for a separate latency test method. During troubleshooting, also check Settings → On Demand so automatic connection rules don’t change a state you just set manually.
- Note the current selection under Home → Global Routing and the configuration active in Config.
- Choose an existing server and run the same test three times. Record timeouts as well as successful results.
- After connecting, open a fixed destination and check the request log to confirm the rule, policy, and server used match your expectations.
- When testing the next server, change only the server selection. Keep the network, destination, and routing mode the same.
- If you temporarily switch to Proxy for comparison, restore the original Config or Scene setting when you’re done.
3. Region Labels Narrow the Search, but Don’t Verify the Route
Region names in server lists are usually labels entered by the configuration provider, not independent verification of a server’s physical location by the client. The locations of the entry address, final exit address, and region detected by the destination website may all differ. A server labeled “nearby” doesn’t necessarily have a short network route; carrier peering and routing detours can affect actual latency.
Choose a region based on what you need to do. For everyday browsing, prioritize requests that complete reliably. For content with regional restrictions, check the exit region the destination actually detects. A name, latency figure, or result from a single geolocation database can’t guarantee that a service will accept the exit address.
Test Wi-Fi and Cellular Separately
Wi-Fi
- Test on the same access point and pause bandwidth-heavy tasks.
- Test one frequently used destination, then another unrelated one.
- Record timeouts and interruptions during the hours you normally use the connection.
Cellular
- Make sure you’re no longer connected to Wi-Fi to avoid recording the wrong network.
- Repeat the same tests from a relatively fixed location.
- After switching networks, establish a new test connection instead of reusing an old request.
Keep results for the same server on Wi-Fi and cellular separate. Choose a primary option for your usual network, then keep a verified backup from your existing list.
Keep test times consistent too. If a connection works in the morning but repeatedly drops in the evening, peak congestion or server load may be involved; a region label can’t explain that. Retest when issues usually occur before changing your selection. Don’t switch servers repeatedly just to chase a one-off low latency result.
4. Protocol Type Determines Connection Requirements, Not a Fixed Speed Ranking
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard identify protocol types, not service quality tiers. The server must support the corresponding protocol and parameters. Changing the protocol type in an existing configuration won’t make the server support it and may cause the handshake to fail.
| Protocol | What to check | Troubleshooting notes |
|---|---|---|
| Shadowsocks | Address, port, encryption method, and password; match any plugin settings too | A working TCP connection doesn’t mean UDP forwarding is configured correctly |
| VMess / VLESS | User ID, transport method, and any required TLS, Host, path, or other parameters | Checking only the address and port isn’t enough to confirm the handshake is fully configured |
| Trojan | The password, TLS, server name, and other parameters used by the configuration | A successful port connection doesn’t mean TLS and authentication succeeded |
| Hysteria2 | QUIC-based UDP reachability, authentication, and TLS parameters | If the network restricts UDP, a TCP probe can’t replace a test using the actual protocol |
| WireGuard | Configuration details such as keys, Peer, Endpoint, and tunnel addresses | Uses UDP; an Endpoint address alone isn’t enough to establish the tunnel correctly |
For example, with TCP 443, the port may be reachable while the connection still fails during TLS or authentication. With UDP 443, a successful TCP 443 test doesn’t prove the UDP connection works. The same port number doesn’t mean the same transport. Check the existing configuration; don’t change every server to port 443 or disable certificate verification just to get one successful test.
Bottom Line: Verify Protocol Connectivity Before Comparing Real-World Performance
If an existing configuration fails only on cellular, first check whether that transport is reachable on that network and review the handshake logs. Don’t conclude that the protocol itself is slow. Once authentication and destination requests succeed, compare response times, stalls, and sustained stability under the same conditions.
5. Troubleshoot Latency, Rules, DNS, and Subscriptions Separately
“The server returns a latency result, but websites won’t load” often means the test and actual request cover different things. A probe may only connect to a port; loading a website also requires resolving its domain, completing proxy authentication, matching the right policy, and reaching the destination. Check each step along the request path instead of repeatedly switching servers and stopping there.
- Check the rules first: In the configuration used by Config, check the order of
DOMAIN-SUFFIX,GEOIP,IP-CIDR, andFINAL, along with their target policies. Rules are matched in order;FINALhandles connections that didn’t match earlier rules. - Then check the policy: A matching rule may use Direct or another policy group. The item selected in Home isn’t necessarily the server ultimately used for the request.
- Check DNS: If an address is reachable but requests to its domain fail, check the DNS settings in the current Config and review the request log. Don’t change DNS, the protocol, and the server all at once, or you won’t know which change made a difference.
- Check the subscription: If the address, port, or credentials for an existing service have changed, update the corresponding subscription in Home first, then make sure you’re testing the updated entry. A successful list update doesn’t mean every entry is usable.
- Start a fresh connection: After switching configurations, close the old test page and make a new request. Existing long-lived connections may temporarily keep using the previous route, affecting your comparison.
When recording troubleshooting results, include only the server’s locally recognizable name, access network, test method, and observed behavior. Subscription URLs, passwords, user IDs, and keys are sensitive and shouldn’t appear in public screenshots or test notes. For instructions on importing and maintaining an existing subscription, see the subscription manual.
6. FAQs and Choosing Primary and Backup Servers
Why does video keep buffering when latency is only a few dozen milliseconds?
First confirm that video requests actually use the selected server, then test the same content at the same resolution while monitoring sustained playback. A latency probe transfers very little data and can’t show bandwidth, congestion, or the route to the content delivery network. Note when buffering occurs and compare an existing backup under the same conditions.
The list shows a timeout, but websites load. Can I still use the server?
First check the test method and test URL in Settings, then review the website’s request log to confirm it actually used that server. If real requests are stable but the probe fails, check whether the probe URL or method is suitable. Don’t remove an existing configuration based on a timeout label alone.
If there are several servers in the same region, should I always pick the one with the lowest latency?
No. Test each one three times under the same conditions, then check a frequently used website and one sustained task. Flag options that repeatedly time out or disconnect. Among the candidates that complete tasks reliably, choose a primary server based on latency and regional requirements for your current network.
A configuration that worked on Wi-Fi stops working after I switch networks. Should I import the subscription again?
First make sure you’ve completed any login required by the network, then check automatic connection rules under Settings → On Demand. Reconnect and test the existing configuration. If it works again when you return to the original network, investigate reachability on the new one first. Update or reimport the relevant subscription only if its existing parameters have actually changed or are missing.
Keep a short record of your primary and backup servers, the networks they work on, the test method, and whether common destinations work reliably. Verify the backup in practice; don’t pick a low-latency name at random from the list. Retest only if problems persist, the access network changes, or the existing configuration is updated. Don’t treat an occasional fluctuation as a reason to change servers.
Shadowrocket is a paid client for Apple platforms, primarily iPhone and iPad, and is available exclusively on the App Store. The one-time app purchase does not include a network service plan. This guide covers verifying and choosing servers you already have; it does not provide, sell, or recommend servers or subscription services. Check the App Store page for system requirements and device compatibility.