How to Choose a Shadowrocket Server: Latency Tests, Regions, Protocols, and Why Low Latency Does Not Always Feel Faster

First, understand what the latency number measures

The latency value in Shadowrocket’s server list is mainly useful for quickly checking whether a connection can be established and roughly how long one round trip takes. It is useful for an initial filter, but it does not by itself represent download speed, video buffering, total page-load time, or long-connection stability. The test target, current network, DNS resolution, protocol handshake, and server load all affect the result.

Latency is usually shown in ms. A smaller number means that particular test completed faster. For example, 40 ms is about 0.04 seconds, while 180 ms is about 0.18 seconds. Opening a page, however, involves more than one round trip: DNS lookup, TCP connection setup, TLS handshake, request delivery, and resource downloads may require multiple exchanges. As a result, a difference of a few dozen milliseconds between two servers may not produce a consistent noticeable difference.

The most useful data is not the single lowest value, but how close the results are across multiple tests. Suppose server A shows 42, 47, and 190 ms, while server B shows 71, 74, and 79 ms. A has the lower minimum, but its variation is substantial; B is more likely to feel consistent during interactive use. These figures illustrate the method only and do not represent fixed performance for any region or protocol.

Filter existing servers with a consistent process

Control the variables during testing. Use the same device and the same Wi-Fi or cellular network, and test at roughly the same time whenever possible. If half the data comes from home Wi-Fi and the other half from a cellular network, access method, signal strength, and carrier routing differences will be mixed into the results, making a fair comparison impossible.

1. Confirm the configuration source

   In Home, check that the existing servers come from your own configuration. To maintain a subscription, use Home’s top-right “+” → Type → Subscribe. An example address is https://example.com/sub?token=xxxx. Save it, then update it according to the configuration method.

2. Keep the local network fixed

   Stop any large file transfers in progress. Keep the device on the same Wi-Fi access point or the same cellular network, and avoid switching connections during testing.

3. Complete three rounds of testing

   In the server list on Home, use the latency test function and test each candidate for at least three consecutive rounds. Record successful tests, timeout, minimum values, and maximum values.

4. Remove obvious outliers

   First remove candidates that repeatedly fail to complete the test. Then flag entries whose results vary by several times, such as frequent jumps from a few dozen milliseconds to several hundred milliseconds.

5. Verify with real-world use

   Select the remaining candidates one at a time. After connecting, use the same webpage, video segment, or controlled file for a short verification. Do not change Global Routing at the same time.

6. Retest at different times

   Run another test during your usual usage period. Stability during the day does not guarantee stability in the evening; results across different time periods are more useful than a single minimum latency.

There is no need for elaborate tools. A table with columns such as “Server name, region, protocol, three latency rounds, timeout status, initial page load, and sustained transfer” is enough. When latency is similar, keep the entries with stable multi-round results and fewer errors during actual tasks.

Geographic distance is only one variable

When other conditions are similar, a shorter geographic distance usually suggests a shorter transmission path. However, a region label in a server name cannot fully describe the actual route. Packets may pass through different international exits, transit networks, and congestion points, and two servers labeled as nearby regions may follow completely different paths.

When choosing a region, first consider whether the task is sensitive to response time. Web browsing, remote interaction, and real-time requests depend more on round-trip latency and jitter. Continuous viewing or large-file transfers depend more on sustained throughput, loss recovery, and long-connection stability. The former often reveals larger latency differences, while the latter may perform better on a server with slightly higher latency but steadier throughput.

If your main task requires content provided for a specific region, also consider the service’s regional access policy. The region with the lowest latency may not meet the target service’s access requirements, while a server that meets the regional requirement may not have the lowest latency. First identify the necessary region, then compare stability among the existing candidates in that region.

• Nearby regions: Suitable as low-latency candidates, but still check evening variation.
• More distant regions: Baseline latency is usually higher, so focus on stability and whether the result matches your actual use case.
• Multiple servers in the same region: Do not keep only the lowest value; record three-round variation and actual success rate for each.
• Servers with similar names: Similar names do not prove that the underlying routes are identical, so record their test results separately.

Protocol type changes test behavior

Shadowrocket supports multiple protocols and transport combinations. A protocol name describes part of the encapsulation and connection method, but it does not determine speed on its own. The same protocol can perform very differently across servers, ports, and network paths; different protocols on the same good-quality path may all be suitable for everyday use.

Shadowsocks has a relatively straightforward structure. VMess and VLESS are also affected by their underlying transport and encryption settings. Trojan is commonly used with TLS. Hysteria2 focuses on UDP-based transport characteristics, while WireGuard is also a UDP-based tunneling protocol. UDP can perform well on some networks, but may be affected by restrictions or significant packet loss. HTTPS traffic commonly uses TCP 443, while HTTP/3 and some UDP-based solutions often involve UDP 443; the actual port is determined by your existing configuration.

Protocol filtering should not rely on a fixed conclusion that one protocol is always fastest. Instead, choose candidates with similar regions and comparable load conditions from your existing configuration, then run latency and real-task tests for each. If a UDP protocol is stable on Wi-Fi but frequently fails on a cellular network, record it as a network-environment difference rather than generalizing one result.

Test record example
Network: same Wi-Fi
Global Routing：Config
Candidate A: VLESS, 68 / 72 / 70 ms, stable initial page load
Candidate B: Trojan, 55 / 160 / 59 ms, occasional pauses
Candidate C: Hysteria2, 83 / 81 / 85 ms, stable sustained transfer

Conclusion: Keep A and C for their respective use cases; retest B at other times.

Inconsistent Global Routing can distort the results

Keep Global Routing consistent when testing servers. Config matches rules one by one, Proxy sends traffic through the current proxy, Direct connects directly, and Scene follows the configured scene. If test A uses Config while test B switches to Proxy, the two results may follow different processing paths and cannot be compared directly.

When using Config, also check whether the rules send the test target to DIRECT. Rules typically match in configuration order: DOMAIN-SUFFIX targets domain suffixes, GEOIP targets the region associated with an IP, IP-CIDR targets address ranges, and FINAL handles traffic that matched none of the preceding rules. If the test resource matches DIRECT, the result does not represent the selected server.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

In the example above, example.com matches PROXY first; local network ranges use DIRECT; GEOIP then handles addresses that meet its conditions; all remaining traffic goes to FINAL. Rules match from top to bottom, so more specific rules should generally appear before broad rules that could override them.

Why low latency can still feel slow

A latency test covers only part of the connection experience. Real-world access is also affected by bandwidth limits, concurrent server load, packet loss along the route, jitter, retransmissions, DNS response time, and the target service’s processing time. One server may respond quickly during a short test but slow down during sustained transfer because of congestion; another may have higher baseline latency but steadier throughput.

Common examples include a server showing 50 ms in the list while video buffers repeatedly after playback starts; latency around 100 ms while pages continue loading steadily; a normal first test followed by several-hundred-millisecond fluctuations in the evening; or normal Wi-Fi performance that changes after switching to cellular. These cases all require a layered diagnosis.

DNS can also create the impression that a server is slow. Domain resolution happens before content transfer. If resolution times out or returns an unsuitable route, the initial page load will be slow even though the latency value may look normal. During troubleshooting, keep DNS settings unchanged and compare several candidates first. If all candidates show similar domain-loading problems at the same time, inspect the DNS settings in the configuration separately.

The local network is another fundamental variable. Weak Wi-Fi, a busy access point, cellular signal switching, or background synchronization consuming bandwidth can slow every server at once. When multiple regions and protocols show high latency simultaneously, test the Direct baseline and local network first instead of changing server parameters one by one.

• Use a single lowest-latency result only for initial filtering, not as the final decision.
• Variation across three to five rounds matters more than one result.
• Verify webpages, video, and sustained transfers separately.
• When every candidate is abnormal, check the local network and DNS first.
• Only when one protocol fails on a specific network should you investigate TCP, UDP, and port conditions.

Review after On Demand and subscription updates

Settings → On Demand determines connection behavior based on network conditions. Once enabled, the Wi-Fi name, network type, or other conditions may trigger a connection or disconnection. If the network state changes during testing and triggers On Demand, the current connection may be re-established, meaning the before-and-after data was collected under different conditions.

Before formal testing, review the existing rules in Settings → On Demand and confirm what actions are triggered by the current Wi-Fi and cellular networks. During testing, either keep the conditions completely unchanged or temporarily use a clearly defined fixed set of conditions. After choosing a server, restore the settings and verify that automatic connection behaves as expected.

A subscription update may add, remove, or adjust servers, and may also change their names or underlying parameters. Even if a name appears unchanged after an update, repeat connectivity and latency tests. If you maintain multiple configurations, also confirm which Config is currently active so that you do not choose a server from the wrong configuration.

Shadowrocket is a paid commercial application for Apple platforms, with iPhone and iPad as its primary devices. The App Store compatibility section may also list Mac, Apple TV, and Apple Vision; system requirements are subject to the App Store listing. The official source is the App Store, the developer is Shadow Launch Technology Limited, and the app ID is 932747118. The one-time purchase covers the client itself.

Build a repeatable selection process

A single test describes only the conditions at that moment. A more reliable approach is to keep a small set of candidates with simple notes such as “usual region, backup region, TCP candidate, and UDP candidate.” When the network or usage location changes, retest from the relevant group instead of scanning the entire list again.

If two servers are similar across three latency rounds, initial page loading, and sustained transfer, there is no need to chase a difference of a few milliseconds. Choose the one with a clear name, stable performance, and an identity that is easy to recognize after updates. Switching too often changes DNS caching, connection reuse, and test timing, which can reduce comparison quality.

1. Keep the device, network, Global Routing, and test resources fixed.
2. Run at least three latency tests on the existing candidates.
3. Remove candidates with repeated timeout or obvious instability.
4. Narrow the list by required region and protocol conditions.
5. Retest interactive web use and sustained transfer separately.
6. Verify once more during your usual usage period and record backup candidates.

After completing this process, you will not have one permanently “fastest server,” but a set of choices that better fit the current network and use case. Routes and load change, so when performance noticeably changes, start with the local network baseline and then check rules, DNS, protocol, and server status in order.