This guide is for users with their own service subscription who are experiencing node timeouts or connection failures in Shadowrocket. Check the local network, Connectivity Test, protocol settings, system time, and actual requests in that order. This helps distinguish an unreachable port, authentication failure, or a rule that isn’t using the expected policy. Change one setting at a time and keep results you can verify.
1. Identify where the connection is failing
Turning on the connection switch in Home doesn’t mean the remote node has authenticated successfully, or that web requests are going through it. The system can establish a local VPN tunnel before a specific request triggers a remote connection. So a VPN indicator, a latency value for a node, and a page loading successfully are three different observations.
Before you start, note whether you’re on Wi-Fi or cellular, which node is selected, the Global Routing mode, and when the failure occurred. Don’t delete the subscription, reset all settings, or change multiple parameters at once; otherwise, it’s hard to tell what affected the result. The table below explains how to interpret symptoms; it isn’t a field report for any particular service.
| What you observe | What it may indicate | Next step |
|---|---|---|
| Regular websites won’t load even after disconnecting Shadowrocket | The local network may not have working internet access | Complete Wi-Fi sign-in, or test again over cellular |
| TCP test returns a value, but the actual request fails | The destination port may be reachable, but authentication and TLS haven’t been confirmed | Check the password, UUID, SNI, and transport settings |
| The test times out, but websites load normally | The test method or target may differ from the actual request | Check the test method and the policy used by the actual request |
| Only Wi-Fi fails; cellular works | The issue is more likely related to the current network path | Check Wi-Fi sign-in, DNS, and network access restrictions |
| Only one existing node fails; others work | Don’t assume the client as a whole is at fault | Check that node’s settings and ask your service provider to confirm its status |
Takeaway: keep one repeatable comparison
Choose one failing node and one test target. Keep the settings unchanged and test once over Wi-Fi and once over cellular. If the result changes with the network, troubleshoot the network path first. If it keeps failing, check the node settings next.
2. Run latency and connection tests in a consistent order
A latency test only answers a question under specific test conditions. A TCP test checks whether a TCP connection can be established; a result in milliseconds doesn’t confirm protocol authentication or a successful real-world request. For connections that use UDP, a TCP result is especially insufficient on its own. Don’t compare numbers from different test methods as if they were equivalent.
-
Check the local network
Turn off the connection switch in Home, then use Safari to open a page you can normally access directly. If Wi-Fi requires a web sign-in, complete it first. If the page still won’t load, troubleshoot the device’s internet connection before changing the node password.
-
Select the node to test
Return to Home, select the node you’re troubleshooting, and note its name and protocol. Don’t rely on the latency shown for one item in the list if a different item is selected when you connect.
-
Run a connection test
Run Connectivity Test in Home and record the selected test method, result, and network type. Repeat three times using the same method and keep every result—not just the fastest one.
-
Rule out routing rules
Temporarily switch Home → Global Routing to Proxy, make sure the node under test is selected, then turn on the connection and send the same web request. When you’re done, restore the original Config or Scene so the troubleshooting setup doesn’t become your everyday configuration.
-
Test on another network
Keep the node, test method, and target unchanged, then repeat the test on another available network. If you’re diagnosing automatic reconnection, temporarily pause it under Settings → On Demand, then restore your original setting afterward.
If the request works in Proxy but fails after you restore Config, check the matching rules, policy targets, and DNS in Config before changing protocol settings. With Global Routing set to Direct, requests connect directly, so that mode can’t confirm whether a proxy node works. When using Scene, check which routing configuration the current scene actually applies.
3. Check protocol settings against your subscription
A node name is only a label; nodes with the same name may have different addresses, ports, or authentication details. Open the node’s edit screen in Home and compare it with the current information from your service provider. If you already have a subscription, update it first and check again. Don’t guess passwords, UUIDs, or transport paths based on online articles.
| Item | What to check | Common mistake |
|---|---|---|
| Address / Port | Don’t include a web page path in the address; make sure the port matches your provider’s details | Changing the original port to 443 just because TLS is enabled; 443 is common, not mandatory |
| Shadowsocks | Check the encryption method and password, along with any plugin settings required by your provider | Assuming every other field is correct because the password is right |
| VMess / VLESS | Check the UUID, TLS setting, and transport; if using WebSocket, verify Host and Path | Assuming the WebSocket Host, TLS SNI, and connection address must all match |
| Trojan | Check the password, SNI, port, and certificate verification settings | Turning off certificate verification instead of correcting the server name |
| Hysteria2 | Check authentication details and TLS settings, and confirm that the current network allows the required UDP traffic | Assuming a successful TCP test means the UDP path is working too |
| WireGuard | Check the key, Endpoint, tunnel address, and Allowed IPs | Checking only the Endpoint and overlooking the tunnel address or routing range |
SNI specifies the server name during the TLS handshake. Certificate validation also depends on the name, trust chain, and validity period. If the connection address is an IP, that doesn’t mean the SNI should be set to the same IP. If your provider gives you a separate domain name, use it as specified. Don’t treat Allow Insecure as a routine fix.
4. Use the exact error message to choose what to check next
“Timeout” means a step didn’t finish within the allotted time; it doesn’t identify the cause by itself. If the log contains one of the English messages below, use it to narrow down what to check. Exact wording can vary by protocol, underlying connection library, and failure stage. When saving the full context, hide authentication details and don’t copy just the last word.
Error: i/o timeout
What it means and what to do: A read or write operation didn’t complete in time. Possible causes include packet loss, filtering, or no response from the remote end. Test the same node on another network, then check the address and port. This message alone doesn’t mean the password is wrong.
Error: connection refused
What it means and what to do: The destination or an intermediate device actively refused the connection. This can happen when nothing is listening on the port or a policy blocks the connection. Check the Port in your subscription and ask your service provider to confirm the port’s status. Don’t try random ports one by one.
Error: TLS handshake timeout
What it means and what to do: The TLS handshake didn’t complete in time. The network path, TLS settings, or server response may be involved. Check the SNI, TLS setting, and port, then compare results on another network. This error alone doesn’t prove that the certificate has expired.
Error: certificate has expired or is not yet valid
What it means and what to do: The certificate’s validity check failed. The device time may be wrong, or there may be an issue with the server certificate. First correct the time on your iPhone and try again. If the time is correct and the error persists, ask your service provider to check the certificate’s validity period.
If the error only appears when you open a particular website, distinguish between the connection to the proxy server and the connection from the proxy server to the destination website. The same TLS message can come from different connection stages. Check the destination host, port, and time of the error to avoid mistaking a certificate issue on the destination website for a problem with the node.
5. Check your iPhone’s system time and automatic reconnection
TLS certificates have start and expiration dates, and authentication for some protocols also depends on the time. If the device clock is significantly off, connections may fail even when the network and password are correct. Changing the displayed time zone doesn’t necessarily correct the clock. Set the correct date and time, then establish a new connection.
- On your iPhone, open “Settings → General → Date & Time.” Check that “Set Automatically” is enabled and that the date, time, and time zone are correct. If device management or another restriction prevents you from changing this setting, first find out where the restriction comes from.
- Return to Shadowrocket → Home, disconnect, and reconnect. Then test the same node and target again. Don’t rely on a result left over from before you corrected the time.
- If the connection comes back on as soon as you turn it off, check Settings → On Demand. To get a clear manual test result, temporarily turn it off, then restore it when you’re done.
- If only one node continues to report a certificate validity error while other existing nodes work, note when it happened and save the relevant error message. Ask your service provider to check the server time and certificate chain.
On Demand starts connections when its conditions are met; it won’t fix a remote password, an expired certificate, or an unreachable port. Temporarily turning it off during troubleshooting helps prevent automatic changes in connection state from affecting your tests. It doesn’t mean you need to leave it off for everyday use.
6. Common questions and what to include in a support request
Why can’t I open websites when the latency test shows a value?
First check the Connectivity Test method. Then go to Home → Global Routing, temporarily select Proxy, and use the node under test to open the same target. A successful TCP connection doesn’t rule out protocol authentication, TLS, or destination access failures. If Proxy works but Config doesn’t, check your rules and policies.
All my nodes are timing out. Do I need to buy the app again?
Turn off the connection and check whether regular websites load, then test again on Wi-Fi and cellular. The app’s purchase status doesn’t tell you whether a service connection is working. The app purchase and the service subscription are separate; ask your service provider whether your existing subscription is active.
Why does an old node still fail after the subscription updates successfully?
Check the updated entries in Home and make sure you’ve selected the node you want to test. Verify that its current Address, Port, and authentication settings match the latest details. Access to the subscription resource and availability of the node service are separate things. Don’t keep deleting and re-adding nodes instead of checking their settings.
What should I include when contacting my service provider?
Include when the failure occurred and the time zone, whether you were on Wi-Fi or cellular, the protocol, the test method, three consecutive results, and the relevant error text with sensitive fields hidden. Say whether the node works on another network. Don’t send the full subscription link, password, UUID, or private key.
When you’re done troubleshooting, restore your original Global Routing and On Demand settings, then verify that a regular website loads as expected. A repeatable test that changes one variable at a time is more useful for diagnosing a problem than a screenshot showing that the connection is on. If you’ve confirmed the device time, settings, and local internet access, but the same node still fails on different networks, send your notes to your service provider so they can check the remote service.