Latency results, the VPN connection status, and whether a webpage loads each tell you something different about Shadowrocket. This guide is for users who already have their own service and configuration and are seeing timeout or connection failures. Keep the configuration and repeat the test, check the protocol, port, and routing, then compare system time and network conditions to narrow down the cause instead of assuming every failure is server-related.
1. Identify whether the failure is a test timeout, tunnel connection, or webpage request
First identify where the failure occurs, then adjust the relevant setting. A timeout shown for an item in Home only means that test did not finish within the allotted time. A VPN icon in the system status bar does not confirm that the remote service authenticated successfully or that every website is reachable. Note the test method, selected item, current Global Routing mode, and destination.
This flow helps separate troubleshooting stages; it does not mean every request follows the exact same sequence. A domain may be resolved on the device or remotely, and routing rules may choose an outbound route based on the domain, IP address, or other conditions. A single latency result cannot tell you what happened at every stage.
- Only the test times out: Repeat the same test, then try an actual request. Don’t delete the configuration right away.
- The connection switch won’t stay on: Check system VPN permissions, other VPN connections, and On Demand before reviewing remote settings.
- The connection is on, but every destination fails: Check the selected item, Global Routing, authentication, and DNS.
- Only one domain fails: Start by checking that domain’s rules, resolution results, and current status.
2. Repeat the latency test in Home under the same conditions
In Home, confirm which item in the existing configuration you’re testing, and note its name and protocol. Run the same test on the same item three times over the same network, about 10 seconds apart. Use the test option and method shown in the app. A TCP test mainly shows whether a TCP connection can be established; it does not confirm that a UDP-based protocol path is working.
- Make sure Wi-Fi has completed any required network sign-in, or that cellular data is available. Temporarily disconnect Shadowrocket, then use a browser to open a page you can normally access directly. This gives you a baseline for the network.
- Return to Home and test the same item three times using the same method. Don’t change the port, DNS, and routing mode all at once between tests.
- Select the item, connect, and open a fixed destination. Note whether it fails immediately, keeps loading, or loads with some resources missing.
- If you have another working item, compare it using the same network and destination. Don’t directly compare results from different test methods.
| Example results | What you can conclude | Next step |
|---|---|---|
| Timeout on all three attempts | The test is consistently failing, but the cause is not yet known | Check the address, port, and network reachability |
| 120 ms、timeout、135 ms | Inconsistent results; these numbers are examples for record-keeping only | Repeat the same test on a different network |
| TCP test succeeds, but the webpage fails | A successful port connection does not confirm authentication | Check protocol settings, TLS, and routing |
| The webpage loads, but one test method times out | The test path does not match real-world traffic | Verify the test method; don’t change the configuration based on this result alone |
Takeaway: Keep variables constant before narrowing down the failure
If the same item fails on Wi-Fi but works on cellular, first investigate the Wi-Fi connection and any access restrictions. Don’t change the password and DNS at the same time, or you won’t know which change affected the result.
3. Check the protocol, server address, and port one by one
From Home, open the existing item’s edit screen and compare each field with your saved original configuration. The display name is just a label; it does not confirm that the server address or protocol is correct. The port must match the remote listener. If the original uses 443, keep 443; don’t copy 8443 from a different configuration. Port 443 does not automatically mean the item uses TLS.
| Protocol | Check first | Common mix-up |
|---|---|---|
| Shadowsocks | Server address, port, encryption method, and password | The encryption method must match the remote server; checking only the password isn’t enough |
| VMess / VLESS | UUID, transport, and any TLS settings required by the original configuration | The WebSocket Host and Path are not the server address |
| Trojan | Password, port, TLS Server Name | If you switch to an IP address, the domain required for the certificate must still be correct |
| Hysteria2 | Authentication details, TLS settings, and UDP path | A TCP port test does not verify the UDP path |
| WireGuard | PrivateKey, peer PublicKey, Endpoint, address, and AllowedIPs | Check key roles, UDP reachability, and routing scope separately |
The domain, TLS Server Name, and WebSocket Host may happen to match, or the original configuration may specify different values. Don’t replace them all just to make them “consistent.” Preserve slashes and query strings in the Path. When copying settings, check for leading or trailing spaces, line breaks, and truncated credentials. Don’t post private keys, passwords, or full subscription links in public records.
4. Use the exact error message to narrow down the cause
Keep the exact error text and timestamp for the request in question from the connection history or logs available in the app. The following are common network error snippets; exact wording may vary by protocol, underlying error, and app interface. If the corresponding text isn’t present, don’t assume that type of failure occurred.
Error: timeout
Cause and next step: An operation did not complete within the allotted time; the issue may involve resolution, connection, or handshake. Use the log stage to narrow it down, then retest on a different network without changing the settings.
Error: connection refused
Cause and next step: The destination or an intermediate device actively refused the connection. Check the address and port, then ask your service provider to confirm that the service is listening.
Error: no such host
Cause and next step: The domain did not resolve to a usable result. Check the spelling, current DNS, and basic network connection, then confirm that the domain is still valid.
Error: certificate has expired or is not yet valid
Cause and next step: The certificate’s validity period does not match the current time. Correct the system date and time first; if the error persists, check the remote certificate’s validity period.
A single log entry may show connection retries before ending with a timeout. Keep the surrounding errors instead of copying only the final line. If a subscription update fails but an already saved item still works, record these as separate issues: a failed subscription fetch does not mean the existing remote connection is no longer valid.
5. Check Global Routing, Config, and DNS
Global Routing in Home determines the current routing mode. Proxy, Direct, Config, and Scene are not interchangeable switches: Direct connects directly; Config routes according to the active configuration rules; Scene also depends on the current scene settings. Note the original value first. If needed, briefly use Proxy to test a fixed destination, then restore the original setting.
- In Home, confirm the selected item and note the original Global Routing value. Make sure the app isn’t still set to Direct during the test.
- If you’re using Config, open Config and confirm which configuration file is active. Check which rule matches the destination domain or IP address and whether its policy is valid.
- If you’re using Scene, check the route and policy the scene actually applies. Don’t infer where a request goes from the scene name alone.
- Distinguish between a remote server domain that won’t resolve and a destination website domain that won’t resolve. The former may fail before a proxy connection is established; the latter needs to be checked against the configuration’s DNS settings and actual connection records.
The following is an example of rule syntax, not a fix file to overwrite your existing configuration with. Rules are generally matched in order, so an earlier match may prevent later rules from being considered for a request. DOMAIN-SUFFIX matches domain suffixes; IP-CIDR and GEOIP apply to IP-based conditions; FINAL is the fallback policy when no earlier rule matches.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYno-resolve means this IP rule won’t trigger a DNS lookup to try to match a domain; it does not turn off DNS for the entire configuration. If a fixed destination works in Proxy but fails in Config, check the rules and policies first instead of changing the remote password again. Don’t delete every rule to fix a problem with one domain.
6. Finally, check system time, network path, and On Demand
An incorrect clock can affect certificate validity checks and authentication that depends on time validation. On your iPhone or iPad, go to Settings → General → Date & Time and check Set Automatically, along with the displayed date, time, and time zone. The key is an accurate system clock; a different time zone alone is not necessarily a problem. If device management restricts these options, follow the device’s management requirements.
- Compare Wi-Fi and cellular: Keep the same item, destination, and routing mode, and test once on each network. If only one network fails, check its DNS, access restrictions, and UDP reachability first.
- Network sign-in: Hotel, campus, or public Wi-Fi may require you to sign in through a webpage first. Changing protocol settings usually won’t help until the network allows basic access.
- On Demand: In Settings → On Demand, check the connection conditions. If the connection turns back on right after you disconnect manually, or its status changes automatically when you switch networks, temporarily disable the relevant conditions. Restore them after your manual test.
- System VPN status: Check whether another VPN connection is routing traffic. Don’t remove a device management configuration unless you know what it does; first confirm which connection is actually active.
- Subscription updates: Keep existing working items and a configuration backup. Update only after confirming that the original subscription content has changed, so you don’t conflate connection troubleshooting with replacing the configuration.
Takeaway: Share the minimum details needed to reproduce the issue
If the issue persists, give your service provider the time it occurred, network type, protocol, port, results from all three tests, and redacted error snippets. Don’t include passwords, PrivateKey, full UUIDs, or subscription tokens in public screenshots.
7. Common questions and what to check after reconnecting
Why can I get a latency result but still not open a webpage?
First, confirm the test method. A successful TCP test only means that a TCP connection to the port succeeded. In Home, check the selected item and Global Routing, then see whether the actual request failed during authentication, TLS, DNS, or rule matching.
It times out on Wi-Fi but works on cellular. Should I reinstall?
Not yet. Use the same configuration to confirm that the difference is reproducible, then check Wi-Fi sign-in, DNS, and network restrictions. Reinstalling won’t directly fix a network that restricts a particular port or UDP path.
The connection failed after a subscription update. Can I delete all the original items?
Keep the original configuration and compare the address, port, and protocol settings before and after the update. If the list is empty or content is missing, address the subscription fetch issue first. Deleting the original items without a backup removes the records you need for comparison.
What should I change after the connection is restored?
Restore the Global Routing mode and On Demand conditions you had before troubleshooting, then test a destination you normally use. Keep changes that proved effective, undo temporary test settings, and note the specific field or network condition that caused the issue.
A thorough troubleshooting process ends with a repeatable link between a change and a result—not just a switch turning on. If every existing item fails on both networks while basic connectivity works, focus on settings shared across configurations, system time, and remote status. If only one destination fails, narrow the issue down to its DNS resolution and rules.