This guide is for users who have already imported their own subscription into Shadowrocket. Start with Connectivity Test to rule out entries that cannot connect, then repeat tests on the same network and compare candidates against your destination, exit region, and protocol requirements. Finally, verify performance with real browsing and sustained transfers instead of simply picking the lowest number in the list. This guide covers using existing configurations only; it does not provide, sell, or recommend servers or subscriptions.
1. Check the test setup and current routing first
A server is a connection endpoint in an existing configuration, typically defined by a server address, port, protocol, and authentication details. A subscription is the source used to update those entries. Region, multiplier, or purpose labels in a server name are just labels, not results measured by the app. Addresses or parameters may change when a subscription is refreshed, so make sure the list has finished updating before comparing entries, and keep a working configuration as a fallback.
The steps below refer to the Home, Config, and Settings screens on iPhone / iPad. Other platforms may look different, so don't rely on matching button positions. Before testing, distinguish the selected server from the route actually used by a request: with Global Routing set to Direct, browsing generally won't use the selected proxy server. With Config, requests follow the rules in the active configuration.
- Proxy: Use this for a consistent proxy-routing test. Make sure the selected policy points to the server being tested, not another automatically selected entry.
- Direct: Connect over the current network without a proxy. This cannot show how the selected proxy server performs for real-world access.
- Config: Route traffic according to the active Config. Its DIRECT, REJECT, or other policies may change where requests to the test site go.
- Scene: Use the configured scene. Check its actual routing and configuration before comparing results.
2. How to interpret Connectivity Test results
Connectivity Test is neither a full webpage load test nor a sustained download speed test. Results depend on the test method, destination, and current network. A TCP test mainly reflects connection setup time; an HTTP test may also involve proxy negotiation, TLS, and the destination's response. “Handshake time” is shorthand for this brief connectivity check, not the total time a page takes to load in an app.
A low millisecond reading means only that a particular probe completed quickly. It can't be converted directly to Mbps or prove that video playback, file downloads, or long-lived connections will remain stable. A Timeout means the probe did not finish within the time limit. The cause could be the test destination, network path, port, or configuration parameters; it doesn't by itself prove the server is permanently unavailable.
- Use the same test method and destination for every comparison. Don't rank TCP and HTTP results together.
- Run at least 3 tests per candidate. Record the typical result, variation, and number of timeouts—not just the fastest reading.
- Pause system updates, cloud syncing, and large transfers to avoid saturating your connection with background traffic.
- Note whether you tested on Wi-Fi or cellular. After switching networks, treat the previous ranking as historical only.
3. Five steps to shortlist candidates from your existing list
Filter for connectivity first, then test your actual use case. Don't change DNS, rules, and protocol parameters at the same time as switching servers; otherwise, you won't know which change affected the result. Keep two candidates for further testing—you don't need to run lengthy downloads through every entry in the subscription.
-
Check the list
Open Home and make sure your subscription has finished refreshing. Check that each candidate has a complete server address, port, and protocol. If names are duplicated, compare connection parameters instead of assuming the routes are identical based on their names.
-
Keep conditions consistent
Stay on the same Wi-Fi or cellular network and note the current selection under Home → Global Routing. Don't change Config during testing. If Settings → On Demand is enabled, make sure its connection rules won't change the connection state partway through a test.
-
Repeat the test
Run Connectivity Test from Home using the same method for 3 rounds. Favor candidates that return consistent results with little variation, and record any timeouts. Don't remove an entry based on a single failed test.
-
Check real-world access
Select a candidate on Home and turn on the connection, then test the same website. If needed, temporarily set Global Routing → Proxy and confirm the policy points to that candidate. Check the initial page load, subsequent pages, and whether your actual task works.
-
Restore your routing
When testing is complete, restore your original Global Routing and On Demand settings. Keep a backup candidate verified on the current network, then recheck it after changing networks or refreshing the subscription. Today's results are not a long-term ranking.
4. Choose a region based on the service and network
Geographic distance is only one factor affecting the route. Traffic from your device to a server may pass through different carrier interconnections, relay points, or congested links, so a server labeled as closer isn't necessarily lower-latency. The region in a server name may also differ from the location associated with its exit IP. A destination service may determine region using IP databases, account region, and device settings.
If your use case requires a specific region, start by filtering your existing entries for that region, then compare stability. Don't ignore the region your service requires just to get a lower test reading. For services tied to an account, avoid frequent region changes, which may trigger additional verification during testing.
Test the same candidate on both types of network
Wi-Fi
- First make sure Wi-Fi can reach basic network services.
- Stay on the same access point; don't move between rooms and change signal conditions during testing.
- Record performance at your usual times to distinguish local congestion from fluctuations farther along the route.
Cellular
- Test where the signal is relatively stable; don't compare results while moving.
- Run Connectivity Test again. Don't reuse the Wi-Fi ranking.
- Sustained transfers use data, so keep verification tests limited in duration and data volume.
You can keep different candidates for different networks. There's no need to designate one server as the “fastest” for every connection.
5. What protocol types do—and don't—tell you
Protocol names describe connection and transport mechanisms, not speed tiers. First make sure the protocol and parameters meet the requirements of your existing server, then check that the current network allows the relevant transport. Changing the type name in the client won't make the server compatible. Authentication details, TLS, transport settings, and server port must match the existing configuration.
| Protocol | Check before using | What you can't infer |
|---|---|---|
| Shadowsocks | Match the server address, port, encryption method, and password. UDP support depends on both endpoints and the network. | A shorter name doesn't mean faster processing. |
| VMess | Match the UUID, transport, and TLS settings. If authentication fails, check the system clock too. | A successful handshake doesn't mean every destination service will work. |
| VLESS | The UUID and transport and security-layer parameters must match. The protocol name alone doesn't tell you how the connection is protected. | Differences in protocol names don't create a speed ranking. |
| Trojan | Check the password, TLS certificate verification, and Server Name settings. | Using TLS doesn't mean every network restriction can be bypassed. |
| Hysteria2 | Based on QUIC; check that the UDP path is available and that authentication and certificate parameters are correct. | It doesn't guarantee a fixed bandwidth on high-latency networks. |
| WireGuard | Check the keys, Peer, Endpoint, tunnel address, and routing scope. Transport depends on UDP. | An established tunnel doesn't guarantee that DNS and all routes are configured correctly. |
A port number doesn't identify a protocol. For example, TCP 443 and UDP 443 are different transport endpoints. Seeing “443” doesn't prove the connection uses Trojan or that the network allows it. Use the port in your existing configuration. Don't change it just to chase lower latency, and never disable certificate verification to get past a certificate error.
6. Avoid misreading results caused by rules or automatic connections
A common source of confusion is “I changed servers, but the webpage looks the same.” This may be expected in Config mode: the domain may match DIRECT, or a rule may assign it to another policy group. Rules are typically matched in configuration order. DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an address range, GEOIP relies on IP geolocation, and FINAL is the fallback. Selecting a server does not override every rule.
Routing check log
- Entry
- Home → Global Routing
- Configuration
- The configuration currently active in Config
- Check the rule keyword
- DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL
- What to verify
- Whether the request is using the policy that contains the candidate server
Check where the rule routes traffic before attributing webpage behavior to a server.
Connection status check
- Entry
- Settings → On Demand
- Purpose
- Trigger connection behavior under the configured conditions
- Where to check
- The Home connection toggle and current network
- After testing
- Restore the original automatic connection settings
On Demand controls when connections are triggered; it doesn't test server speed or rank server quality.
If only one website fails, first check its matching policy, DNS results, and the service itself. If all candidates fail, check the local network, subscription parameters, and current connection status. Don't reset everything at once. Change one setting at a time and record the result to keep troubleshooting reproducible. For more steps, see the connection troubleshooting guide.
7. Frequently asked questions about latency tests and real-world performance
Why is a webpage slow to load when the latency is lowest?
First check where Global Routing is actually sending traffic, then compare two candidates on the same page. Loading a page also involves DNS, TLS, multiple resource requests, and content transfer—none of which are covered by a brief probe. Browser caching can affect repeat visits, so don't compare a cached page with one being loaded for the first time.
The test shows Timeout, but webpages open. Should I remove the server?
Not right away. Keep the server and network unchanged, check the Connectivity Test method and destination, and run it again. A test destination being unreachable doesn't mean every service is unreachable. Also confirm that webpage requests actually use this server, not DIRECT or another policy.
The same server slows down in the evening. Should I change protocols?
First compare your backup candidates at the same time and check for congestion on your local network. You can compare protocols only if the server already provides configurations for them; don't change Type at random. Recording “tests are stable but sustained transfers are slow” or “handshakes frequently time out too” is more useful for troubleshooting than simply noting “slow.”
What if all candidates are unstable on cellular?
First make sure cellular service itself is working, then rerun Connectivity Test from Home. If the issue is limited to existing configurations that rely on UDP, check whether UDP is reachable on the current network. If your subscription already includes another transport type, use it for comparison. Don't assume a restriction on one network makes a protocol unusable everywhere.
Use this order: the candidate meets your requirements, connects successfully, gives consistent repeat results, and works for your actual use case. Latency is one screening measure, not the final verdict.