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

Check your server source and test conditions first

Servers in Shadowrocket are connection configurations that typically include a server address, port, protocol, and authentication details. A subscription imports these configurations in one place and can sync changes when updated. A server name is only a label; it doesn’t prove the server’s location, exit IP, or current load. Even a configuration with the same name may have changed after an update.

Before comparing servers, go to Home and confirm that your existing subscription has loaded and the servers you want to test are still listed. If your provider has announced a configuration change, update the relevant subscription and check the results. Don’t update it midway through a test run: the before-and-after results may reflect different server settings.

1. Check the configuration

   View your existing servers in Home. To import a subscription for the first time, tap “+” in the upper-right corner of Home → Type → Subscribe, enter your own subscription URL, and save. After importing, make sure the servers appear in the list.

2. Keep the network consistent

   Use either Wi-Fi or cellular data throughout the test, and pause large file transfers. Open Settings → On Demand and note the current setting to avoid automatic connection changes if network conditions shift during testing.

3. Use the same test method

   Go to Home → Connectivity Test and check the current test method. Use the same method for every candidate. If the interface lets you choose a test target, keep that target the same as well.

4. Repeat and record

   Test a small number of candidates one at a time, recording each result and the time of the test at least three times. Include timeouts in your notes; don’t record only the lowest result.

Testing a server doesn’t route your traffic through it. After testing, select the candidate in Home and check the connection status. Existing long-lived connections may not switch to the new route immediately, so reopen the target app or start a new request when verifying performance.

What latency tells you—and what it doesn’t

Latency is usually measured in ms. A lower number means that particular test took less time. But different test methods cover different parts of the connection: a TCP handshake mainly checks whether a connection to the server port can be established, while a test that accesses a target through a proxy also depends on the protocol handshake, the target’s response, and related resolution steps. Don’t compare results from these two methods directly.

For example, suppose one set of results is 42, 190, and a timeout, while another is 86, 89, and 91. The first has a lower single result; the second is more consistent across these three tests. These hypothetical figures illustrate how to record results. They aren’t measurements of any actual service and don’t indicate long-term performance.

Latency isn’t throughput. A short test request may complete quickly, while sustained transfers are still affected by bandwidth, congestion, packet loss, and server capacity. A route with slightly higher latency may deliver steadier loading. Don’t treat ms as a download speed or use a single short test to predict whether video will play continuously.

Filter by location: focus on the destination, not just distance

Location can help narrow down candidates, but geographic distance isn’t the same as network path length. The connection from your device to the entry server, any internal routing by the service, and the route from the exit server to the destination website are separate parts. A location in a server name may refer to its exit point, not the server your device connects to first.

A destination service may also consider your account region, device location, payment details, or existing session. Switching servers changes only some network conditions and doesn’t guarantee access to a different set of services. If the page still shows the same status, first confirm that the request actually went through the new server, then check the service’s rules. Avoid switching repeatedly, which can make the results harder to interpret.

Filter by protocol: check compatibility first

A protocol name describes how a connection is established; it isn’t a performance rating. The same protocol can run on different servers and network routes, and one server may offer multiple protocols. Keep other variables as consistent as possible when comparing. You can’t attribute the full difference to the protocol if the location and server changed, too.

A port number is just one connection parameter. For example, 443 alone doesn’t prove which protocol a server uses, whether TLS is enabled, or whether it can be reached on your current network. Don’t change the original port to 443 just to make a test pass; the server must actually provide the matching service on that port.

Low latency, but pages won’t load? Check Global Routing

A successful server test only means that the specific test completed. Real-world access also depends on Global Routing, the active configuration rules, DNS, and the destination service. If the request uses Direct or a rule selects another policy, the tested server’s latency won’t explain what happened during that request.

If you use Scene, check its settings and confirm which ones are active. Don’t mistake a scene change for a change in the server itself. Keep the same Global Routing mode throughout the comparison, and note which settings to restore afterward.

• DOMAIN-SUFFIX,example.com,PROXY: Requests matching the example domain suffix use the PROXY policy.
• IP-CIDR,192.168.0.0/16,DIRECT: The example private IP range uses DIRECT.
• GEOIP,CN,DIRECT: Matches based on the GEOIP result; this is not the same as identifying a region from a server name.
• FINAL,PROXY: Uses PROXY when no earlier rule matches. Check the rules in order.

These examples explain how rules work; they aren’t instructions to replace your existing configuration. If only one domain fails, first check the policy and resolution result for that request. If every candidate fails for the same destination, check the destination itself before assuming all servers are unavailable.

Use test results to choose a primary and backup

After the initial screening, keep a few candidates and test them in the order you’d actually use them: open the target page, navigate to the next level of content, and continue using it for a few minutes. For video or file transfers, keep the quality or file conditions consistent, and remember that testing uses data. Cached content may load much faster on a second visit, so don’t assume a server improved based only on the second load.

1. Choose a primary: On your usual network and during your usual usage hours, favor a candidate that loads the full destination reliably across repeated tests. Don’t chase the lowest single ms result.
2. Keep a backup: Retain another candidate from your existing subscription that passes the same checks. Different names don’t necessarily mean different network paths; use your existing service information to determine whether the paths are independent.
3. Retest on a different network: Results on Wi-Fi don’t necessarily apply to cellular data. After switching networks, repeat a brief test and check the actual destination.
4. Recheck after changes: After a subscription update, configuration change, or service parameter change, confirm the selected server and Global Routing setting again.

Keep your notes simple: network type, time, server name, protocol, three latency results, and whether the actual destination loaded completely. If a candidate fails often only in the evening, recording that condition is more useful than simply marking it “good” or “bad.”