Shadowrocket’s latency readings help you shortlist connections; they aren’t a speed ranking. Assuming you already have a service and subscription, this guide explains how to keep test conditions consistent, compare regions and protocols, check browsing and video performance, and troubleshoot connections that show low latency but won’t load pages. Steps use the iPhone / iPad interface; on other platforms, look for the corresponding features.
1. Latency, throughput, and availability are different
Latency, usually measured in ms, is how long a test request takes along a particular route. Throughput is the amount of data transferred over time. A quick response to a small request only means that route responded quickly at that moment; it doesn’t show whether there’s enough bandwidth for a sustained download. Video playback also depends on the destination, cache location, congestion at the exit, and stability over time.
Different tests cover different parts of the connection. A TCP connection test mainly measures how long it takes to connect to a destination port; it may not complete proxy authentication or reach the target website. An HTTP request sent through a proxy covers more steps, but only for that test URL. Before comparing results, check that the test methods and targets match. Don’t rank numbers from different kinds of tests together.
2. Run a repeatable comparison from Home
First, make sure the subscription imported successfully and that Home shows the list of servers you already have. If your provider has changed any settings, update the relevant subscription before comparing; don’t judge a protocol using outdated parameters. Subscription URLs contain credentials, so hide the full link, passwords, and tokens in screenshots or notes.
-
Keep the network consistent
Stay on the same Wi-Fi or cellular network, and pause large downloads and system updates. Open Settings → On Demand and note the current setting. If it could switch connections automatically during testing, temporarily turn it off and restore it afterward.
-
Check the settings
From Home, open a candidate server’s edit screen and confirm that Type, server address, and port match the details from your existing provider. Don’t change the port, TLS, or authentication fields just to get a lower reading.
-
Repeat the test
From Home, run Connectivity Test on each candidate using the same method for three rounds, leaving a short pause between rounds. Record how many tests succeed, typical response times, and any timeouts—not just the lowest reading.
-
Check real-world use
From Home → Global Routing, temporarily select Proxy. Choose a candidate server, connect, and open the same target page in the same browser. After switching servers, start a new connection before testing so you don’t reuse an existing session.
-
Restore your settings
When you’re done comparing, restore Home → Global Routing to its original Config or other existing setting, and restore On Demand. Reopen the target and confirm that your everyday rules still select the expected policy.
Proxy is useful for briefly ruling out differences in traffic routing; it doesn’t mean all system traffic necessarily takes the same route. Browser cache, existing persistent connections, and exclusions in your configuration can all affect the results. Change one condition at a time to tell whether switching servers helped or the issue just cleared after a refresh. Tests use data, so follow the limits of your existing service.
3. Use region labels to shortlist, not to predict the full route
A region in a server name is usually a label supplied by the provider. It may describe the exit location or simply name a route. The entry address, actual exit, and IP location seen by a target website may all differ. Physical distance is only one factor; peering between carriers, routing detours, and exit load can matter more than distance in a straight line.
Keep separate results for each network
On Wi-Fi
- Test on the same router under similar signal conditions.
- Note the difference between daytime and your usual evening hours.
- Prioritize the target website’s response and sustained transfers.
On cellular
- Turn off Wi-Fi and test again; don’t reuse the previous ranking.
- Stay in roughly the same location to avoid handoffs between cell sites.
- Watch for UDP path issues and reconnection behavior after a network switch.
The same server can perform differently on Wi-Fi and cellular. Keep separate shortlists for each instead of treating a region as permanently fast or slow.
If a service requires an exit in a particular region, first confirm that your existing connection actually exits there, then compare performance. Matching the region doesn’t guarantee that a website will allow access; account region, site policies, and IP detection can all affect the response. Don’t assume access restrictions, failed sign-ins, or more frequent CAPTCHAs are caused by latency.
4. Check protocol compatibility before comparing performance
You can’t rank Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard by name alone. Overhead depends on the transport, encryption, TLS, server implementation, and network conditions. Use a protocol explicitly supported by a service you already have, and keep all required fields intact. Changing Type to another protocol won’t make the original server support it.
TCP connection checks
- Common configurations
- Shadowsocks, VMess, VLESS using TCP transport, and typical Trojan configurations.
- Example port
- Port 443 is a common example for TLS. Use the actual value specified by your existing server.
- Authentication fields
- Check the password, UUID, encryption method, and other fields required by the protocol. They aren’t interchangeable.
- TLS settings
- If TLS is required, check the server name and certificate requirements. A reachable port doesn’t mean TLS has succeeded.
A successful TCP connection test alone doesn’t confirm proxy authentication or access to the target afterward.
UDP path checks
- Hysteria2
- Based on QUIC, this requires a working UDP path and correctly configured authentication and TLS parameters.
- WireGuard
- Uses UDP; check settings such as the key, endpoint, and tunnel address.
- Network restrictions
- Your current Wi-Fi or carrier may restrict or drop UDP traffic, or make it less reliable.
- What to test
- Verify with an actual handshake and real traffic. A TCP test on the same port is not a substitute.
UDP isn’t automatically faster. Test protocol behavior on your current network with your server’s implementation.
If a protocol works at home but repeatedly times out on another network, first check the network differences and the status of your existing server. Then consider other compatible candidates you already have configured. Don’t disable certificate verification to clear an error. Check the server name, device time, and server certificate instead of masking certificate issues by weakening verification.
5. Use real tasks to diagnose low latency with poor performance
Loading a webpage takes more than one round trip: it usually involves DNS, connection setup, TLS negotiation, and requests for multiple resources. A successful test URL doesn’t guarantee that every domain referenced by a webpage will work. Video depends more on sustained throughput and consistency. Slow or interrupted playback after a quick start is a different issue from a timeout on the first request; record them separately.
- Web browsing: Compare how long the same page takes to show its main content, and check whether images and scripts finish loading. Cache affects results. A fresh private browsing session can help, but keep other conditions the same.
- Video: Watch the same content at the same resolution for several minutes. Note startup time, recovery after seeking, and buffering. Auto quality can hide bandwidth problems, so playback alone isn’t proof of good performance.
- Downloads: Compare sustained transfers from the same source; don’t treat the peak speed in the first few seconds as the long-term rate. Server-side limits and load on the source site can also be bottlenecks.
- Reliability: Record successes and timeouts across multiple rounds. A candidate that is occasionally fast but often fails shouldn’t rank first based only on its lowest latency reading.
When troubleshooting routing, Direct in Home → Global Routing means traffic goes direct; it can’t verify how the selected proxy performs for real tasks. Config follows the current configuration, while Scene follows the selected scene. Under Config, also check the configuration currently in use: earlier DOMAIN-SUFFIX, GEOIP, or IP-CIDR rules may already match, and FINAL applies only if no earlier rule does. Identify the policy actually being used before explaining a speed difference.
6. Common questions and criteria for keeping candidates
Why won’t the webpage load on the server with the lowest latency?
First, check the Connectivity Test method. Then go to Home → Global Routing, temporarily select Proxy, select that server, and establish a fresh browser connection. If it still fails, check authentication, TLS, and DNS resolution for the target domain. If it works with Proxy but not Config, return to Config and check the matching rule and policy.
The list shows a timeout. Do I have to delete the server?
No need to delete it right away. Test other candidates you already have on the same network, then check whether the test method suits that protocol. For UDP-based configurations in particular, a failed TCP probe alone doesn’t prove the service is unavailable. Update the relevant subscription, confirm the endpoint settings, and retest with an actual connection and target website.
It’s fast on Wi-Fi. Do I need to choose again when I go out?
After switching to cellular, run the same tests again under consistent conditions. First, check Settings → On Demand to see whether automatic connection settings changed the connection state. Then check the selected server and Global Routing in Home. Don’t rely only on the latency readings left over from the previous test.
What if my previous choice disappears after updating the subscription?
First, make sure you updated the original subscription group rather than deleting it and importing it again by mistake. The provider may have renamed or removed a server. Recheck the new address, region details, and protocol fields; contact your existing provider if anything is unclear. Don’t try to reconstruct passwords or other authentication fields based on a similar server name.
You can keep one candidate for everyday use and one verified backup, noting the networks, test methods, and real-world performance each suits. Choose in this order: correct settings and a successful connection, working target services, stable sustained transfers, then latency readings. Retest when network conditions or subscription contents change. There’s no need to keep changing your entire configuration to chase a slightly lower ms reading.
This guide does not provide, sell, or recommend servers or subscriptions; all comparisons are for connections you already have. For initial setup, read Getting Started to review importing, connecting, and how Global Routing works, then use the steps above to compare your candidates.