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

At a Glance

When choosing a server in Shadowrocket, first confirm that the connection works, then compare results under the same network and test conditions, and finally verify them with the page you actually need to access. Assuming you already have a provider and subscription, this guide explains how latency, location, protocol, and rules affect the outcome—and why a low test result doesn’t necessarily mean your task will succeed.

Keep Test Conditions Consistent Before Choosing a Server

Don’t assume the lowest millisecond value in the list tells the whole story. A single test reflects one connection attempt at one point in time; it can’t replace testing a webpage, a sustained download, or an app sign-in. Keep your network and test method consistent, then compare two or three servers from your existing subscription. This makes it easier to pinpoint the cause than switching through every entry.

Check Your Subscription

In Home, confirm that your subscription and its servers have loaded. To add it again, go to Home → + → Type → Subscribe, enter the subscription URL from your provider, save it, and update the subscription. Don’t enter a subscription URL as a server address.
Keep the Network Constant

Use the Wi-Fi or cellular network you actually rely on, and pause bandwidth-heavy tasks on other devices. During comparisons, don’t change the network, test target, and server at the same time; otherwise, you won’t know which change affected the result.
Check Routing

Open Home → Global Routing and note the current mode. To temporarily test the selected proxy connection, use Proxy; check everyday rule behavior under Config. While troubleshooting, first check Settings → On Demand so automatic connection conditions don’t interfere with manual testing.
Repeat the Test

Run Connectivity Test from Home using the same method, and record three consecutive results for each candidate. Select a candidate and connect, then open the same target page to confirm that the request actually succeeds.
Restore Your Settings

When you finish comparing, restore your original Global Routing and On Demand settings. If you normally use Config, return to the selected configuration and check its rules. Don’t leave temporary troubleshooting settings in place.

What Does a Latency Test Measure?

Latency is usually measured in ms, but what it means depends on the test method. A TCP connection test focuses on whether a connection can be established to the server address and port. A test that accesses a URL through the proxy may also involve the proxy handshake, DNS, TLS, and the target’s response. These methods measure different parts of the connection, so their results aren’t directly comparable. Check which method Connectivity Test is using before interpreting the result.

Connection-Level Test

What it measures: The server address and port in the configuration
What it tells you: Whether a connection could be established and how long it took
What it doesn’t prove: That proxy authentication succeeded or the target webpage is accessible
Example port: 443 is one possible configuration value, not a protocol default

Use the port specified in your subscription. Don’t change it to 443 just for testing.

Request-Level Test

What it measures: A request sent through the proxy to a test target
What it tells you: Whether the relevant handshakes and the target’s response completed
What it doesn’t prove: Sustained download speed or access to other websites
For a fair comparison: Use the same target, test method, and network

A problem with the test target itself can cause multiple servers to time out.

For example, suppose one candidate returns 68, 72, and 70 ms across three tests, while another returns 45, 310, and a timeout. The first has more consistent results in this sample; the second has a lower reading just once. This illustrates how to interpret results—it isn’t a real-world route measurement or a recommendation. Three tests are still only a short sample. If problems usually occur in the evening, repeat the test at the same time you typically use the connection.

Low latency: Often helps with short-request response times, but it can’t be converted directly to MB/s.
Timeout: Means this test didn’t complete within the time limit. It doesn’t prove the server is permanently unavailable.
Variability: May be caused by a weak wireless signal, network congestion, server load, or the target service’s status. Check each factor in turn.

Distinguish Server Labels from the Actual Exit Location

A location in a server name is a label supplied by the provider, not independent geographic verification by the client. It may refer to an entry point, an exit point, or a product group. The actual exit is the address seen by the target service after connecting. IP geolocation databases can also be out of date, so a location label doesn’t guarantee that every website will identify the same region.

Choose How to Verify Location Based on Your Task

For everyday browsing and request-response checks

Use the same target page and record whether it opens and refreshes successfully.
Compare whether repeated requests succeed, not just how close the server appears to be.
For downloads, check sustained transfer speed separately; the initial response time isn’t throughput.

If the target service has regional requirements

Check the target service’s own terms and regional requirements first.
Confirm that the target’s traffic actually goes through the selected proxy exit.
Check account region, location permissions, and cached data too—not just the IP location label.

Use location as a filtering criterion, then verify that the task works under the same settings.

A shorter geographic distance doesn’t necessarily mean a shorter network route. Traffic can pass through different carrier interconnections, entry relays, and exit links. The destination IP returned by DNS can also affect the route. If two servers with the same location label behave differently on the same page, record the test conditions and error rather than guessing based on their names.

Check Protocol Compatibility—Don’t Rank by Name

A protocol defines how the client and server establish and carry a connection; it doesn’t determine speed by itself. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard have different configuration requirements and can’t be converted into one another by changing Type alone. If your subscription provides the full configuration, start with those settings. Ask your provider for any missing parameters.

Protocol	Configuration to verify	What to check
Shadowsocks	Server, port, encryption method, and password	The encryption method and password must match the server.
VMess / VLESS	User ID, transport method, and related security parameters	Check fields such as TLS, Server Name, and path against the actual configuration. Don’t mix authentication settings from different protocols.
Trojan	Password, port, and TLS settings	Check Server Name and certificate verification requirements. Disabling verification isn’t a fix.
Hysteria2	Authentication details, TLS, and other parameters provided by the server	Uses QUIC; check whether UDP is reachable on your current network.
WireGuard	Keys, peer address, port, and tunnel settings	Uses UDP; both the handshake and routing configuration can affect access.

A successful TCP connection to a port doesn’t prove that a UDP-based protocol will work. Likewise, a protocol failing on your current Wi-Fi doesn’t mean it will behave the same way on cellular. Compare correctly configured entries from your subscription, changing only the network or the candidate—not both at once. Two servers using the same protocol can still behave differently because of their exit locations, server load, and transport settings.

If the Test Looks Good but the Page Fails, Check Rules and Routing

The selected server may not carry traffic for the target page. Under Global Routing, Proxy is useful for temporarily checking the proxy route, Direct lets you compare a direct connection, and Config applies the selected configuration. Scene follows its configured conditions; it isn’t simply another fixed proxy switch. If you use a policy group, the target rule may point to a different server within that group, so check which option actually matched.

Rules in Config are evaluated from top to bottom. The examples below explain the syntax only; they aren’t a complete configuration for every network. example.com is an example domain, not a subscription or test service. The documentation-only address 192.0.2.0/24 doesn’t correspond to a real service endpoint.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX matches the specified domain suffix; this example routes that domain and its subdomains through PROXY.
IP-CIDR matches a destination IP range; no-resolve means this rule won’t trigger an extra domain lookup for matching.
GEOIP matches based on the destination IP’s geolocation database entry, not the server name.
FINAL handles requests that didn’t match any preceding rule and belongs in the fallback position.

If a page works under Proxy but fails under Config, first check the selected file in Config, rule order, and policy targets instead of switching servers based on latency. Conversely, if multiple candidates fail only for the same domain, check that target’s DNS, TLS, and service status. Review the request log for the target domain, matched rule, and error details, then continue troubleshooting in Troubleshooting.

Four Common Questions About Choosing a Server

Why are downloads still slow when latency is only 30 ms?

30 ms is the response time for one test, not your bandwidth. Keep the file, server, and network the same, then check whether the transfer remains steady. Also check whether your device or other devices are using bandwidth. Don’t compare speeds across different download sites.

Everything times out. Should I add the subscription again?

First, confirm that your device can access the internet. Then check the test method and target in Home → Connectivity Test. If the test sends a request through the proxy, an unavailable target can also cause every candidate to time out. Update the subscription only after confirming that its contents have expired or its parameters have changed; don’t delete your existing configuration without a reason.

Why does the same server work on Wi-Fi but not cellular?

Keep the server the same and switch only the network to compare results. Record the protocol, error, and time. Check whether Settings → On Demand changes connection behavior based on the network. For Hysteria2 or WireGuard, distinguish UDP reachability from a standard TCP connection test.

Why did the entry I used disappear after updating the subscription?

Return to Home and check the updated list. See whether your provider changed the name or server parameters, then select an entry that still exists and check any policy groups referenced in Config. Don’t try to fix the new entry by copying an old address or password; ask your provider for the correct parameters.

Keep Simple Notes to Avoid Switching Based on Memory

After a comparison, record the network, time, protocol, test method, three latency results, and whether the target request succeeded. Don’t share a full subscription URL, password, user ID, or private key in notes or support screenshots. A token in a subscription URL can grant access, so fully redact it before sharing.

Example: Home Wi-Fi, candidate A, Trojan, same request-level test, 68 / 72 / 70 ms, target page opened successfully three times. This is just an example of how to record results.
Keep the comparison consistent: If an issue occurs, repeat the test under the same conditions, then change the network or candidate one at a time. Don’t change protocol parameters and rules simultaneously.
Stop switching: If an existing entry reliably completes the task, there’s no need to keep switching just to shave a few milliseconds off a single test.