When choosing a server in Shadowrocket, first rule out entries that won't connect, then compare consistency across repeated tests, performance on the sites you use, and protocol compatibility. Assuming you already have a provider and subscription, this guide walks through a consistent testing setup, how to interpret location details, and how to check protocol settings. By the end, you can pick a regular server and a backup from your existing list instead of sorting by the lowest latency alone.
Set consistent test conditions before comparing servers
Takeaway: Change one variable at a time to get useful results. A server entry typically includes a name, address, port, and protocol settings. Location, traffic multiplier, or routing details in the name come from your provider and don't confirm the actual exit location. Before testing, make sure your subscription is still valid and check the selected entry to avoid comparing an outdated address or a different configuration.
Server tests and web browsing may also take different routes. A successful list test doesn't guarantee that a particular site will use that server. If the current rules send the destination domain through DIRECT, switching servers won't affect that direct connection. Start with a controlled connection test, then check again using your usual routing mode.
-
Check your subscription
In Home, review your existing subscription and entries. To import it again, go to Home → + → Type → Subscribe, enter your own subscription URL, and save it. Treat the URL as a credential; don't include it in full in a public screenshot. Use the update option provided by your subscription, then confirm that the entries are still there.
-
Keep the network consistent
Stay on the same Wi-Fi network or cellular connection; don't switch back and forth. Pause bandwidth-heavy tasks on other devices and note the test time. A weak Wi-Fi signal or saturated local upload can affect the whole set of results.
-
Check routing
In Home → Global Routing, check the current mode. To isolate the effect of rules, you can temporarily select Proxy and test the same destination. When you're done, restore your original Config or other everyday settings. Don't switch configuration files in Config during the test.
-
Repeat the tests
In Home, run Connectivity Test on each candidate three times and note timeouts and fluctuations. Then connect using each candidate and retest with the same webpage, file, or call scenario. One successful test isn't enough to establish reliability.
-
Check automatic connections
If the connection state changes on its own during testing, go to Settings → On Demand and review the connection conditions. Check whether a network change triggered an automatic connection or disconnection. Note the original settings, and restore them after testing if you temporarily turn the feature off.
Low latency means a fast response—not high throughput
Takeaway: Check that tests complete reliably first, then compare response times, and finally evaluate the tasks you actually do. Latency is usually shown in milliseconds and measures the time taken for a test response. It isn't bandwidth and can't be converted directly into download speed. Results depend on the test method and target, DNS, handshake, and current network conditions, so keep these factors consistent when comparing servers.
These figures are examples to explain how to read results, not measurements by this site. One entry returns 48, 51, and 49 ms across three tests; another returns 24 ms, 280 ms, and a timeout. The second has a lower minimum, but more variation and failures. The first may be worth further testing for interactive browsing or calls. For large file transfers, compare sustained speed separately—latency alone can't tell you which is faster.
- Response time: Check whether results stay close across multiple tests. A single low reading may reflect a brief lull; repeated timeouts call for checking the connection and settings first.
- Sustained throughput: Use the same file you’re authorized to access, or the same task, and observe performance over time. A short-lived peak doesn't show sustained capacity. Don't mix up MB/s and Mbps.
- Failures and retries: Note whether pages repeatedly reload or connections drop. A small number of tests can't establish an accurate packet-loss rate, so don't present timeout counts as complete network statistics.
- Real-world performance: Check page load, video buffering, and call continuity separately. Reaching one test destination doesn't mean all destinations will perform the same way.
Choose a location based on the destination and actual exit—not distance alone
Takeaway: Location helps narrow your options; it isn't a speed ranking. The route from your device to the server and the route from the server to the destination are different. A shorter geographic distance doesn't guarantee better peering between networks. A subscription entry's name may describe its exit location, or it may include information about an entry point or relay. Refer to your provider's details when interpreting it.
| Use case | What to check first | How to verify |
|---|---|---|
| General web browsing | Consistency across repeated responses and complete page loads | Test the same page in alternating order and distinguish first loads from cached loads. |
| Services with location requirements | The service's regional policies and the location it identifies for your current exit | Check the result in the service itself; matching location labels don't guarantee access. |
| Long file transfers | Sustained throughput, dropped connections, and changes over time | Use the same file and test duration; don't record only the peak from the first few seconds. |
| Real-time calls | Audio continuity, response variation, and UDP reachability | Test within the same service, and confirm that its traffic actually follows the expected policy. |
To check your exit location, you can use information shown by the destination service itself, such as account activity or connection location. Treat it only as a clue, not proof of the route's topology. Don't change your account region, app settings, and server at the same time, or it will be hard to tell what caused a difference. For services with regional access requirements, follow their terms; a server's location doesn't guarantee access.
Check protocol settings first, then network compatibility
Takeaway: Protocol names aren't speed ratings. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard differ in configuration and transport characteristics. Performance also depends on the server implementation, route, local network, and settings. If each protocol is deployed on a different server, your test changes multiple variables at once; it can't prove that one protocol is always faster.
Credentials and connection settings
- Shadowsocks
- Check the address, port, encryption method, and password; copying the server address alone isn't enough.
- VMess / VLESS
- Check the UUID, transport method, and the relevant TLS and transport settings.
- Trojan
- Check the password and TLS settings; the server name must match the server's requirements.
- Port
- Use the port in the original configuration. Port 443 isn't the default for every entry and doesn't guarantee a working connection.
Open the entry's edit screen in Home to check its settings. Don't change authentication or TLS verification settings just to lower latency.
UDP and transport conditions
- Hysteria2
- Check authentication, TLS, and any other settings required by your provider. The network you're using must allow the relevant UDP traffic.
- WireGuard
- Check the complete configuration, including the keys, peer address, port, and tunnel addresses. These aren't ordinary password-based entries.
- Network restrictions
- If UDP is restricted, UDP-based connections may fail even when regular HTTPS websites open directly.
- How to test
- Keep the original settings and retest the same entry on Wi-Fi and cellular to distinguish a configuration issue from a network restriction.
Packet loss alone doesn't mean Hysteria2 will be faster. You still need to verify congestion-control performance with the tasks you actually use.
Connected, but performance hasn't changed? Check routing and your subscription first
Takeaway: First confirm that traffic is using the selected server; only then compare servers. In Home → Global Routing, Proxy, Direct, Config, and Scene are different routing modes. Direct won't switch to a proxy just because an entry is selected in the list. With Config, check the active configuration and policy in Config. With Scene, check the relevant scene settings too; it doesn't guarantee that all traffic will use one fixed server.
The rule DOMAIN-SUFFIX,example.com,DIRECT sends matching domain suffixes through DIRECT; FINAL,PROXY sets the final policy when no earlier rule matches. These examples explain the syntax; they aren't recommendations to overwrite your current configuration. If a PROXY policy uses additional selection logic, check which entry it actually selects instead of relying only on the selected indicator in Home.
Why is browsing still slow when latency is low?
First, check the mode in Home → Global Routing. Temporarily test the same webpage with Proxy, then restore the original mode. If it's slow only in Config, check the domain's rule and policy in Config. If both modes are slow, compare other existing entries and your local network.
Why do all entries time out?
First, confirm that your local network can reach the websites you normally use. Then update your own subscription in Home and check that the address, port, and credentials are still valid. Retest on another local network, and check whether the test destination is restricted. A timeout to one test destination alone doesn't prove that all servers are down.
Why does the same entry work on Wi-Fi but fail on cellular?
Keep the entry's settings unchanged and record the results on each network. For Hysteria2 and WireGuard, check UDP reachability in particular, and review the connection conditions in Settings → On Demand. Don't change the password or port first; that would mix up network differences and configuration errors.
Why can't I find my previous selection after updating the subscription?
In Home, check the updated list and identify candidates again using their address, protocol, and existing details. Entries may have been renamed or removed, so don't rely on the old name alone. If the entry is no longer in your subscription, check with your provider instead of guessing new connection settings.
Keep a tested regular server and a backup
Takeaway: Your final choice should be reproducible with the same steps. For your regular server, note at least the local network, test destination, time, protocol, and routing mode. For a backup, prioritize an option you've confirmed works under different network conditions. Two entries with different names don't necessarily use different routes; check your provider's details to find out whether they do.
- Everyday choice: Keep entries that perform consistently in repeated tests, work for your actual tasks, and have clearly sourced settings—not simply the entry with the lowest latency in a single test.
- Backup check: Confirm that it works on both Wi-Fi and cellular. After switching, check Global Routing and the current policy again; selecting an entry in the list doesn't mean all traffic has switched to it.
- When to retest: Repeat the same process when subscription details change, timeouts become frequent, or you switch local networks. If everything is working normally, there's no need to keep testing every entry; doing so can use extra data.
- Keep records safe: It's enough to save the entry name and what happened. Don't expose subscription URLs, passwords, UUIDs, or keys in public records.