A timeout in Shadowrocket does not mean every request is unable to connect. A latency reading does not prove that protocol authentication or web access is working either. This guide is for users who already have their own server or subscription and are experiencing connection failures. First distinguish between your network, server tests, and actual requests; then check protocol settings, TLS, and system time. Finally, retest the same destination, changing only one variable at a time.
1. Distinguish latency tests, VPN status, and actual requests
Keep your current server and configuration unchanged at first. Do not change the port, DNS, and rules all at once. Server latency on Home, the system VPN status, Connectivity Test, and browser access each reflect a different stage. A VPN-connected status only means the device-side tunnel is established; it does not prove that the remote server has authenticated successfully or that the destination website is reachable.
Checking these stages in order helps avoid misdiagnosis. For example, a TCP connection to the server port may succeed, while a later handshake fails because the password is wrong. A test destination that does not respond also does not prove that every website is unavailable. Different tests cover different stages, so record both the test method and destination along with the result.
| Where to check | What it tells you | What to check next |
|---|---|---|
| Server latency on Home | Response under the current test method | Protocol settings and whether actual requests succeed |
| System VPN status | Device-side tunnel status | Default server and Global Routing |
| Connectivity Test | Whether the test destination was reachable under the conditions at the time | Other destinations and actual app access |
| Browser result | End-to-end request result for that destination | Whether the issue affects just one domain or app |
2. Reproduce the timeout step by step without changing multiple settings
First make sure your basic network works, then check the Shadowrocket connection. If Settings → On Demand is enabled, manually disconnecting may trigger another connection. You can temporarily turn off On Demand for baseline testing, then restore the original setting. Test with a destination you know is reachable rather than switching among unfamiliar addresses.
-
Check your basic network
Disconnect Shadowrocket and use a browser to open a website you know works. If the Wi-Fi network requires sign-in, complete that first. If the network itself is unavailable, resolve the network access issue before continuing.
-
Confirm the selected server
Return to Home, tap the server you want to test, and confirm that its selection indicator is shown. Opening the edit screen alone does not change the selected server. Also note the current Global Routing option.
-
Record latency results
Run the server latency test on Home and record whether it succeeds or times out, along with the selected test method. Run it three times to check for consistency; one response does not prove that the server is reliably available.
-
Test the actual connection
Turn on the connection switch and approve the VPN configuration when prompted by the system. Then run Connectivity Test on Home. Visit the same known destination and record the test result and webpage result separately.
-
Switch networks
If possible, switch from Wi-Fi to cellular data only, keeping the server, configuration, and destination unchanged, then test again. If the result changes with the network, investigate network restrictions, DNS resolution, and whether the relevant transport is reachable.
3. Check the address, port, authentication, and transport settings one by one
If your basic network works but one server keeps failing, open that server’s edit screen on Home and compare it with the original settings from your provider or server. First confirm that Type matches, then check the address and port, followed by authentication, transport, and TLS. The display name is only a label and is not used for protocol authentication; matching names do not mean the underlying settings match.
| Item to check | What to verify | Common point of confusion |
|---|---|---|
| Address and port | Make sure the address has no extra spaces and the port matches the server’s listening port | Port 443 does not automatically mean TLS is enabled or that the service is available |
| Shadowsocks | Check the encryption method, password, and any plugin settings required by the server | Do not try to substitute a different encryption method for the original settings |
| VMess / VLESS | Check the UUID, transport type, and any other fields required by the server | The same UUID does not mean two protocols are interchangeable |
| Trojan | Check the password and TLS-related settings | A reachable address does not mean the password is correct or certificate validation has succeeded |
| Hysteria2 | Check authentication, TLS, server-specific settings, and UDP reachability | A basic TCP port test cannot verify the full connection path |
| WireGuard | Check the key, peer, Endpoint, address, and other settings | It does not use TLS certificates, so TLS troubleshooting steps do not apply |
If the original configuration uses WebSocket, also check Path and Host. For example, if the server requires /ws, do not change it to / on the client. This example illustrates that the field must match exactly; it is not a server setting you can apply as-is. For other transports, check the corresponding fields against the original configuration and do not copy WebSocket fields into them.
- The port is part of the server configuration. Do not change the original port from 8443 to 443 just because 443 is common.
- Check that passwords, UUIDs, and keys were not truncated or copied with line breaks. Do not post these values in public forums.
- If you use a subscription, first confirm that it updated successfully, then check whether the selected item is still the server you expect. Updating the list and connecting successfully are two separate things.
- A subscription-managed entry may be overwritten the next time it updates. Save the original settings before testing changes, and do not mistake a temporary edit for a permanent fix.
4. Use the exact error text to identify the failing stage
The following are common network error snippets; the exact wording may vary by screen. Follow a troubleshooting path only when the corresponding text appears in the actual error details or connection log. A timeout alone does not indicate an authentication failure. When recording an error, note whether it occurred during a subscription update, server test, or webpage request.
Error: i/o timeout
What it means: An operation did not complete before its deadline. This message alone cannot tell you whether the timeout occurred during DNS resolution, connection, or a later read.
What to do: Check the surrounding log entries for the destination and operation stage. Retest the same address and port first, then compare using a different network connection. Do not change every setting at once.
Error: connection refused
What it means: The connection was explicitly refused, commonly because nothing is listening on the destination port or a network device actively rejected it.
What to do: Check the port and protocol first, then ask your provider whether the relevant service is running. Repeatedly changing the password usually will not resolve a port refusal.
Error: certificate has expired or is not yet valid
What it means: The certificate’s validity period does not match the time used for verification. The certificate may actually be expired, or the device clock may be wrong.
What to do: Check the system date and time first, then reconnect. If the error persists with the correct time, ask your provider to check the certificate’s validity period.
When reporting an issue, the exact error text is more useful than simply saying “it doesn’t work.” Include the network type, test time, protocol, stage where the error occurred, and any individual changes you tried. Do not share a full subscription URL, password, UUID, or private key as public diagnostic information.
5. Check TLS and system time without bypassing certificate validation
TLS depends on the server configuration, certificate identity, device time, and other conditions all being correct. The server address, TLS Server Name (SNI), and WebSocket Host serve different purposes. They may sometimes have the same value, but do not assume that they must. If you connect using an IP address, that does not mean you should change the Server Name required by the server to the IP address.
- Open the server edit screen on Home and check whether TLS is enabled and whether Server Name matches the server configuration. Check this only when the protocol and transport actually use TLS.
- On your iPhone or iPad, open Settings → General → Date & Time and check Set Automatically, the current date, time zone, and time. These are system settings, not Shadowrocket Settings.
- If Set Automatically is unavailable, first check for device management or system restrictions. Make sure the time is accurate before testing again. Do not set the system date back to hide an expired certificate.
- If certificate errors continue despite the correct time, ask your provider to verify that the certificate has not expired, the domain matches, and the certificate chain is complete. Do not routinely bypass certificate validation as a fix.
6. Latency looks normal, but sites still won’t load: check Global Routing and rules
If the actual request still fails despite normal latency, check whether it is taking the expected route. Under Home → Global Routing, Proxy, Direct, Config, and Scene represent different routing modes: Proxy uses a proxy route, Direct connects directly, Config routes according to the active configuration, and Scene follows the selected scene. These options change the route; they do not fix incorrect protocol credentials.
- When using Config, confirm which configuration is selected under Config, then check the matching rule and outbound policy. Do not judge routing results solely by server latency in the list.
DOMAIN-SUFFIXmatches domain suffixes;IP-CIDRmatches IP ranges;GEOIPuses IP geolocation categories. Domain rules and IP rules use different matching conditions.FINALis the fallback when none of the preceding rules match. Check the rule order and final policy to make sure the destination is not unexpectedly routed through Direct or another unintended path.- After temporarily using Proxy to compare results for the same destination, restore the original routing mode. If the issue occurs only with Config, check the rules and DNS resolution instead of continuing to change a password you have already verified.
DNS resolution is also part of an actual request. Failure to resolve the server’s address is different from reaching the server successfully but failing to resolve the destination domain. Do not change all DNS settings at once. First identify which domain fails and on which route, then compare results before and after changing one setting.
7. Common questions and when troubleshooting is complete
Why does the connection fail even though there’s a latency reading?
A latency reading covers only the stages included in that test method. Return to Home and confirm the selected server, connect, run Connectivity Test, then check authentication and transport settings. A response from the port does not prove that the full protocol handshake succeeded.
What if it times out only on Wi-Fi but works on cellular?
Keep the same server and destination. Complete Wi-Fi sign-in first, then check that network’s DNS resolution, port access, and UDP reachability. Tell your provider that the same configuration works differently on different network connections, rather than immediately asking to change protocols.
Why can the subscription update if the server won’t connect?
A successful subscription update only means the list was retrieved; it does not mean every server in it can authenticate successfully. After updating, confirm the selected server on Home and test it separately. Ask your provider to confirm that the service is running and the credentials are still valid.
The VPN says it’s connected, but one website won’t open. What should I check?
First compare with another destination you know works, then check Home → Global Routing and the matching rules in Config. If other destinations work, investigate DNS resolution, rules, and the response from the affected domain. Do not rebuild the entire configuration straight away.
Troubleshooting is complete when the expected server is selected, its protocol settings match the original configuration, the system time is correct, requests follow the expected route, and repeated tests under the same conditions produce consistent results. Keep a record of the settings before and after changes, and restore On Demand and Global Routing if you changed them temporarily. If the problem persists, give your provider the smallest set of steps needed to reproduce it.