When choosing a server in Shadowrocket, first identify responsive candidates under the same network and test conditions, then connect and check how they perform for your actual tasks. This guide explains what latency figures can and can’t tell you, how to use location labels, which protocol settings to verify, and how to avoid mistaking routing rules for server performance. It assumes you already have a provider and subscription. This site does not provide, sell, or recommend servers or subscriptions.
1. Use Latency Tests to Check Reachability, Not Rank Speed
Latency is usually shown in ms and measures how long a test takes to receive a response. It is not download speed or the full time it takes a page to load. A test that only establishes a TCP connection mainly reflects the connection setup phase. When a test accesses an HTTP target through a proxy, the result can also depend on the proxy handshake and the target’s response. Latency can help show how quickly a connection is established, but it does not measure bandwidth or replace checking how the test works.
First, check the active test settings in Settings → Connectivity Test, then return to Home and run Connectivity Test. Results are comparable only when the test method, target, and local network are the same. Don’t rank a Wi-Fi result against a cellular result, or average figures from different test methods.
- A result is shown: The test received a response under those conditions. This doesn’t mean every website or protocol will work.
- Timed out: The server may be unreachable, the port may be blocked, the test target may not respond, or the settings may not match. A timeout alone doesn’t prove the entire subscription is unusable.
- Results vary widely: Test the same candidate more than once and note repeated timeouts; don’t keep only its lowest result.
For example, if your notes show “Candidate A: 80, 82, 450 ms; Candidate B: 110, 115, 112 ms,” pay attention to A’s variability, then test both for your actual use. These figures illustrate a way to record results; they weren’t measured by this site and aren’t a performance guarantee. Even if A has the lowest result, that doesn’t prove it will sustain a smoother connection.
2. Run a Repeatable Comparison from Home
Change one factor at a time so you can tell what caused a result to change. Before testing, pause heavy traffic on your device and stay on the same Wi-Fi or cellular network. Your network doesn’t need to be completely idle, but avoid comparing differences of a few dozen milliseconds while downloading a large file.
-
Check the server list
In Home, confirm the server entries are present. If you’ve just updated a subscription, check that the entries are still there. Open an entry to verify Type, address, and port so you don’t compare a server entry that’s no longer valid.
-
Use the same test settings
Go to Settings → Connectivity Test and check the test method and target. Keep these settings unchanged, return to Home, and run Connectivity Test. Record which candidates respond and which time out.
-
Repeat the test
Test a small set of candidates in three rounds, leaving a short interval between rounds. Keep the original results and timeout counts instead of recording only the lowest figure. Don’t switch local networks during testing.
-
Check the routing mode
In Home → Global Routing, check the mode. Use Proxy to assess the selected server’s actual performance. If you use Config, also check which policy the active Config rules ultimately select.
-
Test your actual task
Select a candidate and turn on the connection switch, then visit the same webpage or play the same video. Record whether the page opens, all resources load, and playback continues. Repeat with the next candidate.
Using Proxy helps isolate variables; it doesn’t mean you need to use that mode every day. When you’re done testing, restore your preferred Global Routing setting. If an existing webpage doesn’t change immediately after switching servers, close and reopen it. Long-lived connections and cached content aren’t reliable evidence of the route used by a new connection.
3. Use Location Labels to Filter, Then Check the Actual Route
Location labels in server names are usually set by the provider of the service you already use. A name doesn’t independently verify the server’s physical location, exit location, or access permissions. The entry address, final exit, and target website’s network may all be in different regions. A city name or flag alone can’t tell you which route traffic to a destination takes.
A closer location may mean a shorter transmission distance, but total time also depends on carrier peering, routing, server load, and the destination’s response. Narrow down locations based on your actual task, then test reachability and consistency. This is easier to verify than ranking servers by map distance alone.
Choose what to check based on your task
Webpages and interactive requests
- Use the same target page and check both the initial load and subsequent interactions.
- Check that images, scripts, and other resources load—not just that the page title appears.
- Rule out candidates that repeatedly time out before comparing response times.
Continuous playback and transfers
- Use the same content and resolution, then check whether playback or transfers are interrupted.
- Distinguish buffering at startup from buffering during playback.
- Repeat the test at different times; don’t treat one quiet period as a long-term performance measure.
Location is a filter, but the result for your specific task is what matters. A server name doesn’t guarantee how a target service will determine your location or whether it will be available.
4. Verify Protocol Settings Before Comparing Performance
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different connection methods and settings. Protocol names don’t have a universal speed ranking, and the same protocol can use different transport options. Use the settings supplied for the service you already have. Changing the name in Type alone won’t make a server support another protocol.
Don’t guess the port based on the protocol name. Some configurations use 443, but it isn’t a standard port for every service, nor does it prove the connection uses the same transport. For TLS-related settings, verify parameters such as the server name required by the service. Don’t hide a configuration error by turning off certificate verification.
Check the protocol and transport settings
- Shadowsocks
- Verify the server, port, encryption method, and password. A mismatch in any of these can cause the connection to fail.
- VMess / VLESS
- Verify the user ID, transport method, and any TLS settings required by the service. An address and port alone usually aren’t enough to recreate a configuration.
- Trojan
- Verify the password and TLS-related settings. The server name must match the service configuration.
Confirm all settings are correct before comparing latency. Different transport configurations aren’t equivalent test conditions just because they share the same Type.
Check network requirements
- Hysteria2
- Hysteria2 is based on QUIC and relies on a UDP path. Testing a TCP port alone can’t determine whether the connection is fully usable.
- WireGuard
- WireGuard uses UDP and requires the correct key, Endpoint, and tunnel settings. A responsive port doesn’t mean the tunnel is configured correctly.
- Port example
- Port 443 is only one possible option. Use the port in your existing configuration; don’t replace it with a guess.
Wi-Fi and cellular networks may handle UDP differently. Retest after switching networks instead of relying on old rankings.
If a candidate fails on Wi-Fi but works on cellular, investigate the local network path before concluding that the protocol is “faster” or “slower.” Recording Type, transport method, port, and the network where the failure occurred is usually more useful than repeatedly changing the protocol name.
5. Avoid Misreading Global Routing and Rules
The server selected in Home may not handle requests from the current webpage. With Global Routing set to Direct, traffic uses a direct connection; Proxy uses the proxy route; Config routes traffic according to the active rules; and Scene uses the settings for the selected scene. Before comparing candidates, identify which policy is handling the request.
In Config mode, DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an IP range, GEOIP matches IP geolocation, and FINAL handles traffic that hasn’t matched earlier rules. Rules are evaluated from top to bottom. If an earlier rule matches DIRECT or REJECT, changing a later FINAL rule won’t affect that request.
- The webpage is always fast: Check whether it matches DIRECT. A page loaded directly can’t tell you how fast the selected proxy server is.
- Only one domain fails: Check whether it matches REJECT or uses a policy other than the currently selected server.
- Switching servers makes no difference: Check whether the active Config selects a different policy, and rule out page caching and existing long-lived connections.
- The connection switch turns itself back on: Check the conditions in Settings → On Demand so automatic connection behavior doesn’t interfere with a manual comparison.
If the test gets a response but the webpage won’t open, also check DNS resolution and the destination itself. A reachable port doesn’t prove the domain resolves correctly or that the destination allows access from the current exit. For help with rule syntax, see the protocol guide. Avoid changing the entire Config just to choose a server.
6. Common Questions and What to Record
Why does the server with the lowest latency still buffer during video playback?
Return to Home, select that candidate, and confirm Global Routing. Then use a fixed video resolution and observe playback. Fast connection setup and sustained throughput are different measures; congestion, packet loss, and the content delivery route can all affect playback. Recording whether buffering happens at startup or mid-playback is more useful than noting a single ms figure.
The test timed out, but webpages load after connecting. Should I delete the server?
First check the test target and method in Settings → Connectivity Test, then compare with actual browsing. The test target may be unreachable on its own, or the test may not cover the protocol path used by your traffic. Don’t delete an entry based on one timeout. If it came from a subscription, a later update may sync the list again.
Why do servers in the same region using the same protocol perform so differently?
In Home, open each server entry and check its address, port, and transport settings. The same location label doesn’t mean the servers share an entry point, exit, or route; the same protocol doesn’t mean they have the same load. Retest on the same network and compare them using the same task.
Should I choose a server again after updating a subscription?
Check the entries first. An update may change addresses, ports, settings, or the list of entries, so old results may no longer apply. Return to Home, confirm the current entries, and run Connectivity Test. Repeat the full comparison only if the subscription has changed or performance is noticeably different.
Keep two or three candidates that you’ve verified with your actual tasks. Record the test time, local network, entry name, Type, test method, results from all three rounds, and what happened during actual use. Retest after your network or subscription changes. You don’t need to record passwords, keys, or full subscription links; redact them when sharing a problem with someone else.