This guide is for users who have already imported their own subscription on an iPad or iPhone. When choosing a Shadowrocket server, first confirm the test method and routing, then compare consistency across repeated tests, responses from the sites you use, and exit region. Finally, check the protocol settings. The steps below explain how to compare candidates under consistent conditions, understand protocol differences, and troubleshoot timeouts—without choosing a server based on a single lowest-latency result.
1. What latency tells you
Connectivity Test in Home checks the connection, but results depend on the selected test method. A TCP connection test mainly measures the time needed to connect to the test endpoint. An HTTP test sent through a proxy may also include proxy negotiation, DNS lookup, and part of the destination's response time. These methods measure different paths, so their results shouldn't be ranked side by side.
Latency is usually shown in ms and measures time, not download speed. A server that connects quickly may still load slowly because of exit congestion, throughput limits, or packet loss. One with slightly higher latency but steady data transfer may work better for long reading sessions or file transfers. A successful test also doesn't mean every website will be reachable.
A timeout means the test didn't finish within the allotted time; it doesn't mean the server is permanently down. A network change, unreachable server port or test endpoint, or incorrect protocol settings can all cause a timeout. Repeat the test using the same method, then check actual access to distinguish a temporary issue from a persistent failure.
2. Run a consistent comparison in Home
Before comparing servers, stay on the same Wi-Fi or cellular network, pause other bandwidth-heavy tasks, and note your current configuration. If automatic connection is enabled, go to Settings → On Demand to check; you can turn it off temporarily while troubleshooting, then restore it afterward. This prevents automatic reconnection from disrupting your checks after a manual disconnect.
-
Check the list
Go to Home → SERVER and confirm your subscription is imported. To update it, pull down on Home to refresh and wait for the update to finish before choosing candidates. Don't record test results while the list is updating.
-
Use one test method
Open Home → Connectivity Test and note the current test method. For an HTTP test, keep the test endpoint the same as well. Choose three to five candidates and test each one three times using the same method.
-
Check routing
Go to Home → Global Routing. To isolate the effects of rules, you can temporarily select Proxy, choose the server you want to test in Home → SERVER, and connect. Actual traffic under Proxy may still be affected by existing exclusions or system network behavior.
-
Verify access
Open the same destination page for each candidate, then repeat the same task you normally do. Note the time to first content, interruptions during loading, and repeated reconnects. Change only the server between tests; keep all other conditions the same.
-
Restore your settings
Return to Home → Global Routing and restore your original settings, such as Config or Scene, along with On Demand. Visit the destination again to confirm your everyday rules use the expected server.
3. Check the region label and exit region separately
Region names in a server list are usually supplied by the subscription provider and are only a clue for filtering. The connection entry point, actual exit, and destination website's region may differ: a nearby entry point doesn't guarantee a shorter exit route, and an exit in the region you need won't necessarily make every destination faster. Start with your own access needs, then compare relevant candidates in your existing list.
Location-sensitive services may also use account region, device location, cached data, and past sessions to determine your location. Don't rely on a server name alone. To check the exit region, use location information provided by the service you're accessing or a diagnostic tool you already have. Make sure you don't mistake a direct connection from your device for the proxy's exit.
Comparison criteria
- Network connection
- Use the same Wi-Fi; retest after switching to cellular
- Test endpoint
- Keep the same address and test method
- Candidate servers
- Choose three to five from your own list
- What to record
- Three latency results, timeouts, and actual loading behavior
Change only the selected server each time to reduce interference from other variables.
Checking the region
- Name label
- From the subscription description; not proof of the exit region
- Actual exit
- Check the information shown by a request sent through the proxy
- Destination service
- Check sign-in, pages, and feature responses
- Retest time
- Test again at a time you usually use the service
Once the region meets your needs, compare stability and actual response.
For example, if two servers both meet your region requirements, favor the one with consistent repeated test results and pages that load smoothly. Don't switch frequently over a difference of a few milliseconds; changing exits can trigger session revalidation and make comparisons less reliable.
4. Protocols aren't a speed ranking
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are different protocols and configuration methods, not a fixed ranking from fastest to slowest. Performance can vary significantly across routes using the same protocol. Different protocols in the same region may also use entirely different entry and exit paths.
| Protocol | Settings to check | What to consider |
|---|---|---|
| Shadowsocks | Server, port, encryption method, password, and plugin settings | The encryption method and plugin settings must match the server. Changing the display name alone won't do it. |
| VMess | UUID, transport method, TLS, and related transport settings | Check the device's clock. Incorrect authentication or transport settings can cause connection failures. |
| VLESS | UUID, transport method, and related security settings | The protocol name alone doesn't describe the full security configuration. Keep the settings from your existing subscription. |
| Trojan | Password, port, TLS, and server name | If the TLS handshake fails, first check that the server name matches the certificate configuration. |
| Hysteria2 | Authentication, TLS, port, and related bandwidth settings | Based on QUIC and requires UDP to be reachable; a successful TCP test alone doesn't confirm it will work. |
| WireGuard | Keys, Endpoint, interface address, and routing scope | Uses UDP. Check the handshake and actual traffic; don't rely on the Endpoint name alone. |
A port number doesn't define a protocol's capabilities. A server using port 443 doesn't mean every protocol can connect, nor does it prove the traffic is HTTPS. If your existing configuration uses example.com:443, also check the transport protocol, authentication, TLS, and other settings. This address is only an example of the format, not a working server.
- Start with the settings provided in your subscription. Avoid changing the protocol, port, and transport method all at once.
- If a protocol fails on one Wi-Fi network only, test again on another network you can use and check for transport restrictions such as blocked UDP.
- Don't disable certificate verification just to make a test pass. Correct the configuration or check the settings with your service provider.
5. Consider latency, variation, and actual loading together
The hypothetical data below illustrates how to record results; it isn't a measurement from this site and doesn't indicate service quality. Three test results help show variation, while actual loading behavior shows whether the task works. Record these separately.
| Candidate | Three test results | Behavior on the same page | Next step |
|---|---|---|---|
| A | 48 / 240 / timeout | Opens quickly at first, but later resources occasionally stall | Check for variation; don't favor it based on a single 48 ms result |
| B | 85 / 89 / 87 ms | Loads continuously; repeat visits work normally | Keep it and retest during your usual usage hours |
| C | 65 / 68 / 66 ms | Test succeeds, but the destination service applies a region restriction | Check the actual exit region and service requirements |
For web browsing, check the time to first content and whether all resources load. For sustained transfers, check whether speeds remain stable. Real-time communication also depends on jitter, packet loss, and UDP support. A single Connectivity Test can't replace testing these tasks directly, and shouldn't be taken as a guarantee that a particular app will work.
If performance changes after restoring Config, check the current configuration and matching rules in Config. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches IP geolocation, and FINAL handles traffic that didn't match earlier rules. A rule may route traffic to DIRECT, a policy group, or a specific server; the selected server indicator in Home alone doesn't reveal the actual route.
- First find which rule matches the destination domain, then check the policy that rule points to.
- Check that the policy group has selected the candidate server you expect.
- If only one destination fails, check its rules, DNS, and exit response first rather than deleting the entire subscription.
6. Common questions about choosing a server
Why does the server with the lowest latency load web pages more slowly?
In Home, check which SERVER is selected, then review Global Routing. Temporarily select Proxy and test the same destination for comparison. If it's still slow, compare loading continuity and timeouts. A quick response from the test endpoint doesn't mean the destination website, exit bandwidth, or DNS lookup is working just as well.
Every server times out. Does that mean my subscription no longer works?
First make sure the device itself can access the internet. Then refresh your existing subscription and check whether the account status or settings have changed. Retest using the same method and try another network you can use. If only the test fails while actual access works, check the test endpoint instead of assuming all servers are down.
If I choose a server on my iPad, should I choose the same one on my iPhone?
You can start with the same candidates, but test them again on the network your iPhone is currently using. The iPad's Wi-Fi and the iPhone's cellular connection take different paths, so results may differ. Even on the same Wi-Fi, check that both devices use the same configuration, test method, and Global Routing setting.
What should I do if my selected server disappears after a subscription update?
Go to Home → SERVER and check the updated list to see whether the entry was renamed or removed, then select an available server. Next, check Config for rules or policies that still refer to the old name. Updates change the available candidates, so treat your earlier latency results as historical reference only.
Verify the App Store listing and check configuration steps
Shadowrocket is a closed-source commercial app for Apple platforms, primarily iPhone and iPad, and is available exclusively on the App Store. Before purchasing, verify the developer, Shadow Launch Technology Limited, and app ID 932747118. Check the App Store listing for the current one-time purchase price and system requirements. Buying the app does not include a network service; use your own existing subscription or configuration.
Open the App Store verification page View the guide