This guide is for users who already have their own service provider and subscription but are experiencing timeouts or connection failures in Shadowrocket. First, distinguish local internet access, test results, and actual proxy requests. Then check the address, port, authentication, TLS, and device date and time. Finally, compare routing rules and network conditions to narrow down the issue and keep a record you can review.
1. Distinguish Test Timeouts from Connection Failures
A latency test returning a number only shows that the path covered by that test responded. It does not prove that every website, authentication step, or transport method will work. Likewise, one timed-out test does not prove that the server is down. The test method, destination, network conditions, and server-side restrictions can all affect the result.
When Shadowrocket’s connection switch is on, the system VPN tunnel has been established or is being established. This does not mean the remote server has finished authenticating. Track these separately during troubleshooting: whether the switch stays on, whether the test gets a response, and whether the actual request succeeds. Don’t lump all three together as “can’t connect.”
- Basic internet access fails: Turn off Shadowrocket and try opening a website you know is directly accessible. If it still won’t load, check Wi-Fi, cellular data, or a network sign-in page first.
- Test fails: A test in Home times out, but actual access has not been checked. At this point, the only conclusion is that the test failed.
- Proxy request fails: Basic internet access works, but a request still fails with the selected server. Continue by checking settings and logs.
- Only one destination fails: Other destinations work, but one domain does not. Check that destination, DNS, and routing rules first.
2. Keep Test Conditions Consistent Before Comparing Latency
For the first round of troubleshooting, don’t change any settings. Select the same existing server entry and use the same test method. Run a few tests close together in time. Comparing numbers without noting how they were measured can lead you to treat results with different meanings as equivalent.
-
Confirm internet access
Turn off the connection switch in Home, then open a website you know is directly accessible in Safari. If public Wi-Fi requires a sign-in page, complete sign-in before returning to Shadowrocket.
-
Select the same entry
Return to Home and select the server you want to check. Note whether you’re on Wi-Fi or cellular data, and make sure you haven’t selected another entry with a similar name.
-
Repeat the latency test
Run Connectivity Test in Home and check which test method is selected. Test three times under the same conditions and record each response or timeout. Don’t replace spaced-out retests with rapid, repeated taps.
-
Check an actual request
Turn on the connection and use the same destination page to verify access. Record the test result and page result separately. If they differ, keep track of the discrepancy rather than deleting the configuration right away.
-
Retest on another network
If your device and plan allow it, switch between Wi-Fi and cellular data and repeat the tests. Change nothing except the network, so the results remain comparable.
Takeaway: Check whether the problem changes with the network
If the same entry fails on only one network, first check that network’s DNS, sign-in status, and transport restrictions. If it fails on both, focus on the server settings and service status. Neither result alone identifies the root cause based on latency.
3. Check Protocol Settings: Address, Port, Authentication, and Transport
In Home, open the edit screen for the relevant entry and compare it with the original details from your service provider. Confirm Type first, then check the remaining fields. Protocols require different settings; you can’t simply copy a server address and password into a different Type. Keep a recoverable copy before editing, especially if the entry still works.
| What to check | Details to verify | Common misjudgment |
|---|---|---|
| Address and port | Check that the server address is complete and the port matches the original details. Valid port numbers range from 1 to 65535. | Assuming 443 is a universal answer. A port of 443 does not work with every protocol and does not necessarily mean TLS is in use. |
| Shadowsocks | Check the encryption method and password. If the server uses a plugin, verify the plugin and its related settings as well. | Assuming the address and port are correct means an encryption method mismatch can be ignored. |
| VMess / VLESS | Check the UUID, transport method, and security options enabled for that entry. If VLESS uses flow, make sure it matches the server. | Assuming that two protocols can use the same UUID means their Type settings are interchangeable. |
| Trojan | Check the password, TLS settings, Server Name, and configured transport method. | Updating only the password and missing a server-side change to the domain or transport settings. |
| Hysteria2 | Check authentication, TLS, port, and any enabled obfuscation settings. Confirm that the current network allows the relevant UDP traffic. | Using a single TCP port test to conclude that the UDP connection is working. |
| WireGuard | Check that the keys match, along with Endpoint, tunnel addresses, and settings such as AllowedIPs. | Treating key, routing, and handshake issues as if they were all password errors. |
| WS / gRPC | Check the WS Path and Host, or the gRPC Service Name, only if the entry uses that transport. | Treating Path, Host, and Server Name as the same field. |
Server Name usually affects the name sent during the TLS handshake and certificate validation. WS Host is part of the HTTP request, while Path is the request path. Even if the values look similar, don’t merge these fields. Check the path’s capitalization, leading slash, and any extra spaces in the UUID against the original details exactly.
4. Check the System Time and TLS; Don’t Skip Certificate Validation
Certificates are valid only within a specific time range. If the device date is significantly wrong, TLS can fail even when the network and password are correct. Some protocols also rely on time for authentication. Check the time after reviewing the settings, but don’t wait until every other attempt has failed.
- On your iPhone or iPad, open system Settings → General → Date & Time. Check Set Automatically and make sure the displayed date and time are reasonable.
- If device management or another restriction prevents automatic time setting, resolve the restriction first. Don’t set the date back to bypass an expired certificate.
- After correcting the time, disconnect and reconnect, then retest with the same entry and destination. Don’t rely on an already-open page that may be cached.
- If the time is correct but you still see a certificate error, check the server address, Server Name, and the domains covered by the certificate. Then ask your service provider to confirm the certificate’s validity period and chain.
Disabling certificate validation is not a routine fix. It changes the security boundary and can conceal problems such as connecting to the wrong server or using an incorrect domain. Correct device time and a valid certificate are separate requirements; check both.
5. Use the Original Log Message to Identify the Failure Stage
After a failure, check the connection log and note when the error occurred, the destination address, and the relevant lines. The examples below may appear in network or TLS logs. The actual message may include surrounding context, and different protocols may use different wording. Errors can help identify the stage of failure, but they don’t prove who is responsible on their own.
Error: i/o timeout
Possible cause: A read or write operation did not complete before its deadline. Possible factors include packet loss, no response from the remote end, or restrictions along the network path.
What to do: Use the surrounding log lines to confirm the address being contacted. Retest the same configuration on another network, then check the port and remote service status.
Error: connection refused
Possible cause: The connection was actively rejected. This often means nothing is listening on the destination port, but an intermediary device may also have returned the rejection.
What to do: Check the server address and port first. Send your service provider the time of the error and the message so they can confirm whether the port is listening. Don’t try random ports.
Error: x509: certificate has expired or is not yet valid
Possible cause: The certificate’s validity period does not match the current time. The device clock may be wrong, or the remote certificate may have an issue.
What to do: Check system Date & Time first, then confirm the remote certificate’s validity period. Leave certificate validation enabled.
Error: EOF
Possible cause: The data stream ended prematurely. This can happen at different stages, including a protocol mismatch, failed authentication, or a remote disconnect.
What to do: Use the preceding handshake details to check Type, authentication, and transport settings. This line alone does not prove the password is wrong.
6. Check Routing and On Demand After the Connection Is Established
If a test gets a response but webpages still won’t load, check whether requests are actually going through the selected server. In Home → Global Routing, Proxy, Direct, Config, and Scene represent different routing modes, not connection quality levels. A successful direct connection does not verify the proxy server, and Config must be assessed against the configuration currently in use.
- Quick comparison: To check a particular request, temporarily use Proxy to rule out the effects of routing rules. Restore the previous Global Routing setting when you’re done. Note the original mode to avoid leaving the wrong setting in place.
- Check the configuration: If you’re using Config, open Config to confirm which file is active, then check the rule order and policy names. For Scene, verify the settings that are actually in effect rather than relying on the scene name alone.
- Identify the rule:
DOMAIN-SUFFIXmatches a domain and its subdomains;IP-CIDRmatches an IP range;GEOIPmatches based on the IP’s geographic information;FINALis the fallback when no earlier rule matches. DNS resolution and rule order can both affect the final policy. - Rule out automatic triggers: Check the on-demand connection settings under Settings → On Demand. For a manual retest, you can temporarily turn off On Demand and control the connection yourself. Restore the original settings when you’re done.
On Demand starts connections when its conditions are met; it won’t fix a wrong password, an expired certificate, or a port with no listener. If the connection turns back on after you disconnect manually, check its trigger conditions instead of repeatedly deleting the system VPN configuration. System VPN authorization issues and remote server timeouts occur at different stages.
7. Common Questions and What to Include in a Troubleshooting Report
Why won’t webpages load even though latency is low?
First, check which stage the current test covers, then verify the selected entry and Global Routing in Home. Temporarily use Proxy for comparison and review the failed request in the logs. If only certain domains fail, check DNS, routing rules, and the destination site’s status instead of simply reordering servers by latency.
Why does it time out on Wi-Fi but work on cellular data? Should I change the protocol?
Keep the configuration unchanged first. Confirm that you’ve signed in to Wi-Fi and retest the same destination. If the difference persists, note the protocol’s transport method and ask the network administrator or your service provider about possible restrictions. For UDP-related issues in particular, TCP access alone doesn’t rule out network restrictions.
Everything timed out after I updated my subscription. Did the update fail?
First, distinguish an update failure from connection failures after an update. In Home, check whether the new entries appeared and whether the correct one is selected. Then compare Type, address, and port with your service provider’s details. A subscription can be retrieved successfully even if some remote services in it are unavailable. Repeatedly updating is no substitute for checking protocol settings.
Do I need to send someone my entire configuration and subscription link?
No. Start by recording the exact error, when it occurred and the time zone, your current network, protocol type, test method, and comparison results. Redact passwords, UUIDs, private keys, and subscription tokens. For server-side checks, use the private support channel provided by your service provider.
Takeaway: Change One Condition at a Time
For each retest, change only one factor: the network, settings, time, or routing. Record the result. Telling your service provider which step failed, which network reproduced the issue, and what error appeared is more useful than simply saying “the server doesn’t work.”
After troubleshooting, restore any temporary changes to Global Routing and On Demand, and keep a copy of a configuration you’ve confirmed works. Shadowrocket is a closed-source commercial client for Apple platforms. A one-time purchase of the app is not a service subscription; getting the app and troubleshooting a remote service are separate matters. Buying the app again won’t fix remote settings.