For users with their own provider and subscription who encounter node timeouts or can’t access websites after connecting in Shadowrocket. First distinguish a failed test from a protocol handshake failure or traffic taking an unexpected route, then check your existing connection details and device time. Change one thing at a time and keep a record of each test to identify whether the issue lies with the local network, remote endpoint, or app configuration.
1. Distinguish the connection switch, node test, and website access
When the connection switch is on in Shadowrocket, the system VPN tunnel is established. That does not mean the remote node has authenticated successfully or that every website is reachable. A latency value beside a node only indicates that a particular test completed under specific conditions; it doesn’t prove that all destinations or transport methods are working.
Start on Home and note the selected node, Global Routing mode, and network in use. While troubleshooting, go to Settings → On Demand and turn off On Demand to prevent automatic connection behavior from changing when the network switches. Restore the original setting when you’re done. Don’t change the node, update the configuration, and modify DNS at the same time; even if access returns, you won’t know which change fixed it.
- Check the local network: Turn off the connection switch temporarily and confirm that the current Wi-Fi or cellular network can access the internet. If public Wi-Fi requires a sign-in page, complete authentication first.
- Record test conditions: Note the network type, node name, test method, whether it succeeded or timed out, and the exact error text. Hide server addresses, account details, and credentials before sharing your notes.
- Determine the scope: Check whether all existing nodes fail, only one node fails, or just one website is inaccessible. Each pattern points to different checks.
2. Run a Connectivity Test and understand what it tells you
On Home, run Connectivity Test for an existing node and note the test method. Different methods check different layers: a successful TCP connection only shows that the specified endpoint accepted a TCP connection. A test that sends a request through the proxy also depends on authentication, proxy egress, DNS, and the test destination itself. These results aren’t directly comparable.
-
Keep conditions consistent
Select one existing node on Home and run the same test three times on the same network. Record each result; a single low latency reading doesn’t show that the connection is stable.
-
Check the routing mode
Go to Home → Global Routing. To troubleshoot the proxy path, temporarily select Proxy and confirm that the intended node is selected. Note the original Config, Direct, or Scene setting, then restore it when you’re done.
-
Test access
Turn on the connection and visit two HTTPS websites you regularly use and know to be working. Don’t rely on the test destination alone: a problem with that destination can also cause a test timeout.
-
Try another network
Keep the node and its settings unchanged. Switch between Wi-Fi and cellular, then repeat the same test. Check cellular data permissions and whether the current network allows the required transport.
| Observed result | What it may indicate | Next step |
|---|---|---|
| The same node times out on all three tests | The test didn’t complete within the time limit under these conditions; this alone doesn’t confirm that the credentials are wrong. | Repeat the test on another network, then check the address, port, and transport type. |
| TCP test succeeds, but the proxy request fails | The endpoint may be reachable, but authentication, TLS, or a later request could still fail. | Check protocol settings and the recorded error, one item at a time. |
| Fails on Wi-Fi, succeeds on cellular | The issue is more likely related to the network path, DNS resolution, or network restrictions. | Check Wi-Fi authentication, DNS, and UDP availability. |
| Proxy works, but Config does not | Check the rules, policy selection, and DNS path first. | In Config, check which configuration is enabled and which rule matches. |
Takeaway: Use comparisons to narrow down the cause
If the same node fails on only one network, leave the protocol settings unchanged and investigate that network path first. If it fails on both networks, check the address, port, and handshake settings next. This avoids repeatedly changing settings that may already be correct.
3. Check the address, port, authentication, and transport in order
On Home, open the selected node’s edit screen and compare each field with your original connection details. The server address must not include a link scheme, path, or trailing spaces. Port must match the port the remote server actually listens on. For example, if your details specify 443, don’t change it to 8443 just because the connection fails. A matching port number doesn’t mean both TCP and UDP are available.
Subscription updates and node connections use two separate request paths. A successful subscription update only confirms that the configuration data was retrieved; a working node doesn’t guarantee that the subscription URL is currently accessible. If your provider has explicitly announced a connection setting change, update your existing subscription first, then check the selected entry again so you don’t keep testing an old address. Record the original values before editing manually; a later subscription update may overwrite your changes.
| Protocol | Check first | Common misconception |
|---|---|---|
| Shadowsocks | Address, port, encryption method, password, and any plugin settings specified in your original details | A reachable port doesn’t mean the encryption method and password match. |
| VMess | UUID, encryption settings, transport, TLS, and device time | Checking only the UUID and overlooking transport settings or a time discrepancy |
| VLESS | UUID, transport, TLS, and parameters such as flow if specified in your original details | Applying another transport configuration for the same address without checking the original settings |
| Trojan | Password, TLS, server name, and port | Assuming the connection address and TLS server name must always be the same |
| Hysteria2 | Authentication details, TLS, UDP path, and any obfuscation settings in your original details | Treating a TCP test as proof that a QUIC-based connection works |
| WireGuard | Local private key, peer public key, Endpoint, tunnel address, and Allowed IPs | Checking only that the switch is on, without confirming a valid handshake and traffic |
For connections using TLS, also check the server name. For WebSocket connections, check Host and Path. Uppercase and lowercase letters and slashes in Path can affect routing, so don’t rewrite it based on habit. Parameters aren’t interchangeable between protocols. Use your original connection details to determine whether a field is required, and don’t disable certificate verification just to clear an error.
4. Match the error to the stage where the connection failed
Error details are more useful for troubleshooting than simply saying “it won’t connect.” The examples below are common English error messages that may appear during a connection. The actual message may include an address, protocol prefix, or more context. Keep the surrounding stage information too; don’t infer the remote server’s status from a single keyword.
Error: i/o timeout
What it means: A connection, read, handshake, or other operation didn’t complete within the time limit. This does not by itself mean the password is wrong.
What to do: Retest the same node on another network, then check the address, port, and TCP or UDP transport requirements.
Error: connection refused
What it means: The connection request was rejected. The destination port may have no service listening, or an intermediate device may have actively refused the connection.
What to do: Confirm that the port in your original details hasn’t changed. If the issue persists, send your provider the time and error details with sensitive information removed so they can check the endpoint.
Error: no such host
What it means: DNS didn’t return a usable result. Possible causes include a typo in the address, a DNS resolver issue, or a problem with the domain itself.
What to do: Check the node address for typos and extra spaces, then compare DNS resolution on another network. Don’t replace the TLS server name without a specific reason.
Error: x509: certificate has expired or is not yet valid
What it means: The certificate’s validity period doesn’t match the time used for verification. The device time may be wrong, or the remote certificate may have expired.
What to do: Correct the system time first. If the same error persists, ask your provider to check the certificate rather than bypassing verification.
5. Check the date, time, and time zone to avoid authentication and certificate errors
Device time is used to check TLS certificate validity and can affect time-based authentication in protocols such as VMess. Don’t check only the hour in the status bar: an incorrect date, year, or absolute time can also cause a handshake to fail. The time zone mainly affects local display; a different displayed time zone doesn’t necessarily mean the device’s absolute time is wrong.
- On your iPhone or iPad, open Settings → General → Date & Time and check Set Automatically. If available, turn it on and wait for the device to sync.
- Check the displayed date, year, and time zone, and confirm that the current network is working. Don’t change the date manually to bypass a certificate error.
- Return to Shadowrocket, turn off the connection, then reconnect. Run Connectivity Test on the same node as before, without changing any other settings.
- If Set Automatically can’t be changed, check for device management restrictions. If the time is correct but the certificate error continues, record the error and ask your provider to check the remote certificate.
6. If the test passes but websites don’t load, check Global Routing and Config
In Global Routing, Direct sends requests over a direct path, Proxy uses the proxy path, Config applies the rules in the current configuration, and Scene applies the selected scene. A node test and an app’s actual requests may follow different decision paths. If latency looks normal but websites won’t load, check routing and the destination instead of immediately rebuilding the node.
- Compare routing modes first: Temporarily select Proxy and test the same website, then restore the original mode. If the issue occurs only in Config, check the configuration currently enabled in Config—not an inactive file.
- Check rule order next: Rules are generally matched in order.
DOMAIN-SUFFIXmatches domain suffixes,IP-CIDRmatches IP ranges,GEOIPmatches an address using a geolocation database, andFINALhandles requests that didn’t match an earlier rule. - Check DNS clues: If domain requests fail but the endpoint connection works, review the DNS settings in the current configuration and the error details. Don’t simply replace a domain with an IP address to test an HTTPS website: the certificate or virtual host may require the original domain.
- Check whether it’s one destination: If other commonly used websites work and only one destination fails, note the destination and time. Then check whether the issue is with the destination itself, DNS resolution, or the relevant rule.
For example, if the configuration ends with FINAL,DIRECT, requests that didn’t match a proxy policy above it will use Direct. That’s configuration behavior, not evidence of a node timeout. Back up the current configuration before editing, confirm which policy the destination should use, and adjust the specific rule. Clearing the entire rule set isn’t a routine troubleshooting step.
7. Common questions and what to include in a report
Why can’t I open websites after getting a latency reading?
First check which method Connectivity Test used. Then go to Home → Global Routing, temporarily select Proxy, and test the same website. A reachable endpoint doesn’t confirm that authentication, DNS, rules, and access to the destination are all working.
All nodes are timing out. Should I add them all again?
Turn off the connection and confirm that the local network works. Then keep one existing node unchanged and retest on Wi-Fi and cellular. Shared issues with the network path, DNS, or device time are more likely to be worth checking first than re-adding every entry.
Only Hysteria2 fails, but the TCP test succeeds?
Hysteria2 is based on QUIC and relies on UDP. First check the port and authentication details in your original connection information, then test on another network. A TCP port test can’t replace a UDP test or a full protocol handshake check.
Why does the old node still fail after a successful subscription update?
A successful update only means the subscription content was retrieved. Return to Home and confirm whether the selected entry is still the old one, then compare its address, port, and protocol with the latest details. Don’t treat a successful subscription request as a node health check.
What should I send my provider?
Include the time of the failure and your time zone, whether you were on Wi-Fi or cellular, the protocol, test method, results from all three tests, and the error with sensitive details removed. Don’t send a full subscription URL, password, UUID, private key, or screenshots containing credentials.
After troubleshooting, restore the original Global Routing and On Demand settings, then test your usual apps. Keep a record of the conditions before the change, the single item you changed, and the result afterward. If the same issue comes up again, you can reuse the checks that worked instead of changing the entire configuration again.