This guide is for users who already have their own service provider and subscription but encounter node timeouts or can’t access websites after connecting in Shadowrocket. Run repeat tests on the same node and compare networks first, then check the address, port, authentication, and transport settings one by one. Finally, verify the device time and subscription status. The goal is to identify where the connection fails—not to assume every problem means the node is down.
1. Distinguish a Latency Test Timeout from a Connection Failure
A latency test result in Shadowrocket is not the same as a website access result. A timeout means that a particular test did not finish within the allotted time. By itself, it does not prove that your account is invalid or that all websites are unreachable. Conversely, a result in milliseconds only means that the test completed; it does not guarantee that authentication, the TLS handshake, and access to the destination will all succeed.
In Home, check which node is selected, then run Connectivity Test. Note the test method and use the same method for comparisons; results from different methods are not directly comparable. A TCP connection test covers different steps from a test that accesses a destination through the proxy. In particular, a basic TCP result cannot establish that UDP-based transport is working.
| What you observe | What you can conclude so far | Next step |
|---|---|---|
| Repeated timeouts on the same node | The test path is consistently failing to complete; the cause is not yet identified | Keep the settings unchanged and compare Wi-Fi with cellular |
| The test returns a time in milliseconds, but websites still fail | The test completed, but that does not mean application requests will succeed | Check authentication, TLS, Global Routing, and DNS |
| Only one node fails | The problem is more likely with that node or its settings | Compare it with another node you already have |
| All nodes fail on the same network | A shared network or configuration issue may be involved | Confirm that your local network works, then test on another network |
Don’t treat any particular millisecond value as a universal pass mark. Latency depends on your network, the server’s location, and the test destination. Rather than comparing values from different conditions, record results for the same node and test method across different networks to narrow down the cause.
2. Build a Repeatable Test Record in Five Steps
Change only one condition at a time. If you update the subscription, switch protocols, change DNS, and restart the device all at once, even a successful result won’t tell you which step helped. Keep the existing configuration intact while troubleshooting so you don’t overwrite settings that may still work. You can keep notes locally; there’s no need to share your full configuration.
-
Check the network
Temporarily turn off the connection switch in Home and confirm that your current Wi-Fi or cellular network can access websites you normally visit directly. If public Wi-Fi requires sign-in, complete that step before continuing.
-
Choose one node
In Home, select one of your existing nodes and run Connectivity Test three times using the same method. Record whether all attempts time out, some succeed, or every attempt returns a value. Don’t treat three tests as a measure of long-term availability.
-
Switch networks
Keep the node and its settings unchanged. In iPhone Settings, switch between Wi-Fi and cellular, then repeat the same test. If it fails only on one network, first check that network’s access restrictions and UDP reachability.
-
Test actual access
Turn on the connection switch in Home, confirm the selected node, and try to access the same destination. To temporarily isolate the effect of rules, switch Global Routing to Proxy for comparison. When testing is complete, restore the Config you normally use.
-
Rule out automatic connections
If the connection starts again after you manually disconnect, check Settings → On Demand. Note the current setting, temporarily turn off On Demand, then repeat the manual connection test. Restore the setting afterward to suit your usual needs.
Takeaway: First determine whether the problem follows the network
If the same node times out on Wi-Fi but the test completes over cellular, keep the node settings as they are and investigate the Wi-Fi network path first. Don’t immediately rebuild the entire configuration or change authentication details.
3. Verify the Address, Port, and Protocol-Specific Settings
Open the selected node’s edit screen in Home and compare its settings with the current details from your service provider. Check Type first, then the server address and port, followed by authentication and transport options. The server address field should not contain a webpage path, and the port must match the server’s listening port. A port number of 443 does not necessarily mean the protocol uses TLS, nor does it prove the settings are correct.
For example, if the server explicitly requires example.com:443, check that the address is example.com and the port is 443. Don’t change it to 8443 just to “test the speed.” The domain and port here illustrate the format only; they cannot be used to connect. Extra spaces, missing characters, or changes in capitalization in authentication details can also cause a connection to fail.
| Type | Check these settings | Common points of confusion |
|---|---|---|
| Shadowsocks | Server address, port, encryption method, and password | The password may be correct, but a different encryption method will still prevent communication |
| VMess | UUID, encryption settings, transport method, and TLS-related settings | The transport path, Host, and server address may not be the same |
| VLESS | UUID, transport method, and the TLS or other security settings specified by the server | You can’t infer the remaining options from the address and UUID alone |
| Trojan | Password, server port, and TLS server name | The connection address and the domain on the certificate may differ |
| Hysteria2 | Authentication, TLS server name, UDP reachability, and any options specified by the server | A successful TCP test does not prove that QUIC communication works |
| WireGuard | Local private key, peer public key, Endpoint, address, and Allowed IPs | A connected status does not necessarily mean that a valid handshake and data transfer have completed |
For configurations that use TLS, check the connection address, server name, and certificate requirements together. Replacing a domain with an IP address may change certificate name matching or the access path. Don’t disable certificate verification as a substitute for correcting the settings. If the certificate has expired, the server administrator needs to address it.
4. Use the Exact Error to Identify Where the Connection Failed
A timeout describes what happened; the exact error can help identify the connection stage that failed. When reviewing connection records or logs in the app, note the error text and when it occurred. The examples below are error snippets that may appear in low-level connection records—not fixed alerts that appear with every failure. If the wording differs, use the actual record as your guide.
Error: i/o timeout
Cause: A network read or write step exceeded its waiting time. This message alone can’t tell you whether the issue is with your local network, the server, or the destination’s response.
What to do: Compare the same node across networks, then use the address and connection stage recorded before and after the error to narrow down the cause. Don’t mask the issue simply by increasing the timeout.
Error: connection refused
Cause: The connection to the destination port was explicitly refused. Common causes include a port that isn’t listening, a stopped service, or a network device actively rejecting the connection.
What to do: Check whether the record points to the proxy server or the destination website. If it points to the proxy server, ask your service provider to confirm the address, port, and service status.
Error: no such host
Cause: The current lookup could not resolve the hostname to an address. The hostname may be misspelled, or DNS resolution may have failed.
What to do: Check for spaces, a protocol prefix, or a path in the address, then test on another network. Don’t keep changing the password before confirming the hostname.
Error: certificate has expired or is not yet valid
Cause: The certificate’s validity period does not match the device’s current time. The system clock may be wrong, or the server certificate may need attention.
What to do: Correct the date and time on your iPhone, then reconnect. If the time is correct and the error persists, report it to the server administrator. Don’t bypass certificate verification.
Before sharing connection records, hide passwords, UUIDs, private keys, and subscription tokens. You can include the protocol type, a redacted server address, port, test time, and exact error text. A full subscription link may grant access and should not appear in a public help screenshot.
5. Check the System Time and Update the Subscription
On your iPhone, go to Settings → General → Date & Time and check Automatic. If the device time is clearly wrong, correct it before reconnecting. Time is used to validate TLS certificate dates and may also affect authentication that checks the time. Manually moving the date forward or backward is not a fix.
Updating a subscription and connecting to a node use different request paths: the first retrieves configuration data, while the second connects to a server using the existing settings. So a failed update does not mean every node saved locally has immediately stopped working; a successful update does not mean every node is reachable. After updating, select the node you want to test and check what, if anything, changed in its settings.
- Check the subscription source: In Home, check that an existing Subscribe entry still uses your own valid link. Here is a format example:
https://example.com/sub?token=xxxx. This address is for illustration only. - Run one update: In Home, pull down to refresh the existing subscription. Wait for the result, then check the node list. Keep any error details and avoid repeated refreshes that could add noise.
- Check the update route: If the subscription address requires a proxy connection and you already have a working connection, check Settings → Subscribe → Update via Proxy. This setting requires a working proxy path; it cannot bring a failed node back to life.
- Check the service status: Ask your service provider whether the subscription is valid, your account is still active, or the address or authentication details have changed. Check your app purchase status and service provider account separately.
Takeaway: Retest just one destination after updating
Compare one failed node’s address, port, and authentication details before and after the update, then repeat the test on the same network. If nothing changed and it still times out, focus again on the network path and server status.
6. If the Test Passes but Websites Won’t Load, Check Routing
If the node test completes but access still fails, check whether the request is actually going through that node. In Home, review Global Routing: Config processes requests according to the configuration, Proxy provides a comparison using the proxy path, Direct provides a comparison using a direct connection, and Scene depends on the relevant scene settings. Don’t assume all traffic is proxied just because the connection switch is on.
When using Config, check the configuration that is currently enabled in Config—not just a file that isn’t active. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP uses an IP geolocation database, and FINAL handles requests that didn’t match any preceding rules. A request matching DIRECT won’t automatically use the proxy just because a node is selected. A request matching REJECT will be blocked.
- Works in Proxy but fails in Config: Check the configuration’s rule order, policy references, and DNS results first. There’s no need to rebuild the node right away.
- Only one website fails: Check which rule matched the request and whether the destination responded. A single-site failure doesn’t prove that the entire proxy connection is down.
- All destinations fail: Recheck the protocol settings and connection records to see whether the failure occurred during authentication, TLS, or the outbound connection.
After comparing routes, restore the routing mode you normally use. Proxy is a way to isolate the issue during troubleshooting, not a substitute for fixing every rule problem. For the full procedure, see the Global Routing guide.
7. Common Questions About Shadowrocket Node Timeouts
Only one node times out. Should I reinstall the app?
Don’t reinstall yet. In Home, select another node you already have and run the same test. If other nodes work, focus on the failed node’s address, port, authentication, and server status. Reinstalling won’t fix a remote port that isn’t listening and may erase useful local troubleshooting records.
The test shows a latency value. Why can’t I access anything after connecting?
First, check which connection steps the test method covers. Then try actual access using Global Routing → Proxy. If it still fails, check for authentication or TLS errors. If it fails only in Config, inspect the rules and policies in the currently enabled configuration instead of focusing only on the latency value.
The subscription refresh timed out. Does that mean my existing nodes won’t work either?
Not necessarily. Test a node saved locally, then troubleshoot the subscription address’s access path separately. Settings → Subscribe → Update via Proxy may help with an update that requires a proxy path only if you have a working proxy connection. Also ask your service provider to confirm that the link is valid.
What information should I send to my service provider?
Include when the issue occurred, whether you were on Wi-Fi or cellular, the protocol type, a redacted address, the port, and the results of three tests, along with the exact error text. Note whether switching networks fixed the problem and whether your other existing nodes work. Don’t share private keys, full passwords, or subscription links containing tokens.