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

1. Latency, throughput, and real-world availability are different

Low latency means a response arrived quickly in a particular test; it does not guarantee fast, sustained data transfer. Throughput measures how much data is transferred over time. Availability also depends on whether a connection succeeds, the target service can be reached, and long-lived connections remain stable. These factors are related, but they are not interchangeable. When choosing a server, the lowest number in the SERVER list is not necessarily the best choice.

Open Connectivity Test from Home to find the testing options. Before interpreting results, check which test method and target are being used. A TCP connection test mainly measures the connection to a server's specified port. A test that accesses an HTTP or HTTPS target through a proxy may also involve the proxy handshake, name resolution, and the target site's response. These methods cover different parts of the connection path, so their results should not be compared as if they were equivalent. Available options may vary; refer to the app's English interface.

The server port must match the settings provided by your service provider. For example, if the original settings specify port 8443, do not change it to 443 to try to make the connection “faster.” A port number is not a speed setting. A successful test only confirms that the parts covered by that test worked at that moment; it does not prove that video playback, uploads, or every website will work properly.

2. Test in a consistent order so network changes aren't mistaken for server differences

Change one condition at a time. Keep the device, current network, test method, and target consistent before switching servers. Do not compare results on Wi-Fi directly with results on a cellular network, and do not judge connection quality while large files are downloading. Batch tests can help narrow the options; once you have candidates, retesting them individually makes occasional fluctuations easier to spot.

1. Confirm the list source. Find the existing subscription entries in the SERVER section on Home, and check their names and groups. If your provider has changed the settings, update the relevant subscription before comparing servers.
2. Keep test conditions consistent. Use the same test method in Home → Connectivity Test. Stay on the same Wi-Fi or cellular network throughout testing, and pause high-volume transfers on other devices.
3. Record three rounds. For each round, note the response time, whether it timed out, the time of the test, and the network type. Leave a short gap between rounds, and don't record only the best result.
4. Select a candidate before connecting. Confirm which entry is selected, then check Home → Global Routing. If you use a policy group, also verify the active selection within that group. Otherwise, you may change the selected list entry while the target traffic continues to use a different route.
5. Test real-world tasks. Use the same webpage to check its initial load and a refresh. For video, use the same fixed quality and observe startup, seeking, and uninterrupted playback. Disconnect existing test connections first to avoid results being affected by connection reuse.

The following is a hypothetical example of how to record results, not a measured test or performance guarantee: Candidate A returns 42 / 260 / timeout over three rounds; Candidate B returns 88 / 91 / 89 ms. A has the lower best result, but varies considerably; B is a stronger candidate for real-world testing. Three samples are enough only for an initial comparison: they cannot establish a long-term packet loss rate or guarantee the same performance at other times.

3. Treat location labels as clues; consider the entire connection path

Physical distance affects propagation delay, but the path from your device to the entry server, from entry to exit, and from exit to the target website consists of separate segments. Location text in a server name is usually a label supplied by its source; it does not, by itself, establish the actual entry or exit location or the route in between. A nearby server may still be slow because of routing detours, peering congestion, or server load.

When comparing locations, start with the task you need to perform. Web browsing and interactive tasks make response delays easier to notice, while long video streams depend more on sustained data delivery. A target service may also select a content delivery server based on the exit IP, so the same candidate can perform differently across websites. A fast connection to the server does not necessarily mean a fast connection to the target website.

Changing Wi-Fi networks, switching to cellular, or moving to another city can change the ranking. You don't need to reconsider every candidate every day; retest using the same process only if performance changes persist. Keeping one verified backup is more useful for troubleshooting than constantly chasing the lowest momentary result.

4. Choose protocols based on compatibility, not a speed ranking

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different connection methods and settings. Whether a protocol works depends first on matching client and server configurations, and then on whether the current network supports the relevant transport. A protocol name alone does not guarantee “high speed” or “low latency.” Changing the Type of an existing entry does not turn it into a different protocol.

For example, if a Wi-Fi network restricts UDP, candidates that rely on UDP may fail to connect. That does not mean the protocol is slow on every network. Conversely, a successful TCP connection test does not prove that UDP traffic will work. Verify performance with the target task instead of judging every protocol by one test result.

• When comparing protocols, keep the exit location, test target, and test time as similar as possible. Differences between servers may be greater than differences between protocols.
• Keep the original settings provided with the subscription; don't disable certificate verification just to make a test pass.
• When sharing troubleshooting notes, hide passwords, keys, identity parameters, and full subscription URLs. Include only the protocol name and relevant symptoms.

5. Check Global Routing to make sure the test uses the selected server

If the webpage behaves exactly the same after switching servers, check routing first. Home → Global Routing controls how traffic is handled overall; it is not a speed setting. Rules and policies on the Config page can also determine which route a request actually takes. Comparisons are valid only after confirming that the target traffic is going through the candidate you're testing.

If you use Scene, check the settings for the active scene; don't assume a scene name means a fixed exit route. If Settings → On Demand is enabled, check whether on-demand connections change the connection state during testing. The goal is to keep conditions consistent, not to permanently change your everyday configuration for a speed test.

6. If latency is low but browsing or video is slow, troubleshoot by symptom

When test results don't match the real-world experience, first distinguish between “slow from the start” and “slows down after transferring data for a while.” The first may involve name resolution, handshakes, the target site's response, or routing. The second points more toward sustained throughput, congestion, or connection stability. The steps below help avoid unnecessary changes.

1. Tests are fast, but every real-world target is slow: First check whether the test only measures the connection to the server. Then verify Global Routing and the actual exit route. Pause background transfers and compare with another verified candidate.
2. Only one website is slow: Test another target to rule out the site's own response, content delivery route, or access restrictions. A problem with one site doesn't mean the entire server is unavailable.
3. Video starts quickly, then buffers repeatedly: Keep the video quality fixed and continue observing. A quick initial handshake doesn't guarantee sufficient sustained throughput. Comparing a backup candidate at around the same time is more useful.
4. Slow in the evening, normal at other times: Record results for the same target at different times and consider congestion on shared links or changes in server load. Don't change protocol settings based on a single peak-hour result.
5. All candidates time out at once: First check that the device's current network is working, then confirm that the subscription is up to date and the service settings haven't changed. If all candidates fail, look for a cause they have in common.

When reporting a problem, include the device's network type, protocol, test method, time of occurrence, whether only one target is affected, and what happened after switching candidates. Don't share real credentials. These details make it easier to distinguish a local network issue from a service configuration or target-site problem than a screenshot showing only the lowest latency.