A node test timeout, websites failing to load while the Shadowrocket connection is on, and a subscription refresh timeout can each point to a different stage. This guide assumes you already have your own provider and subscription. Check the test scope, connection settings, system time, and network conditions in order. Change one thing at a time, keep a record of failures, and retest against the same destination.
1. Tell node, website, and subscription timeouts apart
A timeout means an operation did not finish within the allotted time. It does not automatically mean the password is wrong or the server is down. Turning on the Shadowrocket connection only indicates that the system tunnel is in the corresponding state; it does not confirm successful authentication with the remote server or access to every website. Identify the step where the failure occurs before changing settings, so you do not keep adjusting unrelated options.
This flow helps narrow down where to troubleshoot; it does not mean every protocol follows the same internal sequence. For example, TLS settings can affect the handshake, and rules may be evaluated based on the domain first. Use the test target and request logs to diagnose the issue. A single red result is not enough to identify the failing stage.
- A single node test fails: Check that node’s server address, port, protocol settings, and reachability from your current network.
- The node responds, but websites won’t load: Check authentication, DNS, Global Routing, and the destination site. A reachable port does not mean the full proxy request succeeded.
- Only subscription refresh fails: Check the subscription URL, access path, and your provider’s service status. Do not assume this means all existing nodes are unavailable.
- All nodes fail at once: Start with the local network, system time, and any shared configuration source, then check each server’s status.
2. Keep test conditions consistent and interpret latency results
Before running Connectivity Test from Home, note the selected node, current network, and test method. Some methods check only whether a connection can be established; others request a test URL and are also affected by DNS, TLS, and the destination’s response. Results from different methods are not directly comparable, and a single result does not measure bandwidth.
-
Record the current state
In Home, confirm the selected node and note the current Global Routing option, whether you are on Wi-Fi or cellular, and when the failure occurred. Do not include passwords or full subscription URLs in your notes.
-
Repeat the test
In Home, run Connectivity Test three times using the same method and record each result. If you are testing a URL, keep the destination unchanged as well.
-
Switch networks
If cellular data is available, switch from Wi-Fi to cellular and test the same node three times. Do not change the port, DNS, or protocol at the same time.
-
Verify a request
Select the node, turn on the connection, and visit an HTTPS page you know is working. Record the page result separately from the test result to distinguish server reachability from a successful request.
| Example results | What you can conclude | Next step |
|---|---|---|
| Same method: 180 ms, 210 ms, then timeout | Results vary; the lowest value does not indicate a stable connection | Keep settings unchanged and retest on another network |
| Connection test succeeds, but URL test times out | The connection is established, but the full request does not succeed | Check authentication, test destination, and DNS |
| Three Wi-Fi timeouts; three successful cellular tests | The issue is more likely related to the network path | Check Wi-Fi sign-in status and network restrictions |
The values in this table are examples of how to keep a record, not measurements by this site or an indication of any route’s performance. A URL test will also fail if the test destination is unreachable. Cross-check with a destination you know is working before treating a problem with the destination as a node failure.
Takeaway: Keep the test method consistent before changing settings
Keep a comparison record for the same node and destination on two networks. Continue troubleshooting a condition only if changing that condition produces a consistent change in results.
3. Check the address, port, credentials, and transport settings
From Home, open the selected node’s edit screen and compare its settings with the original configuration from your provider. Do not mistake the display name for the server address, or reuse settings from another node just because it uses the same protocol. Port 443 is just a port number; it does not automatically mean TLS is enabled. The server configuration determines both the actual port and TLS status.
| Item to check | What to verify | Common effects |
|---|---|---|
| Address and port | The server address should not include a URL path. Use the integer port specified by the server, such as 443 or 8443; do not substitute another port. | DNS resolution failure, connection refused, or timeout |
| Shadowsocks | Check the encryption method, password, and any plugin settings used by the configuration. | The underlying connection may be established, but a valid proxy request cannot be completed. |
| VMess / VLESS | Check the UUID, protocol-specific options, and transport. Fill in only fields required by the original configuration. | Authentication or transport mismatch |
| Trojan | Check the password, TLS settings, and Server Name required by the server. | Authentication failure or TLS handshake failure |
| WebSocket transport | Check Path and Host. Preserve the leading slash and capitalization in Path exactly as shown in the original configuration. | The request reaches the server but does not enter the correct proxy endpoint. |
| Hysteria2 / WireGuard | Check UDP reachability and protocol fields such as authentication details, keys, or Peer. | If the current network restricts UDP, successful TCP requests do not prove this connection will work. |
When copying a password, UUID, or key, check for leading or trailing spaces and line breaks. TLS Server Name is used for the handshake and certificate identity check; WebSocket Host is used for request routing. They are not interchangeable just because both are domain names. Even when the connection address is an IP, you may still need the Server Name specified by your provider.
4. Check error messages, system time, and TLS
Use the exact error recorded on your device. Wording can vary by protocol and underlying implementation. When contacting your provider, include the full error message and the time it occurred; this is more useful for diagnosis than simply reporting a “timeout.” The examples below are common underlying error messages, but they will not appear with every failure.
Error: i/o timeout
What it means and what to do: A read or write operation exceeded its time limit, but the message alone does not identify the cause. Note whether it occurred during connection setup or during a request, then switch networks and test the same node to check reachability.
Error: connection refused
What it means and what to do: The destination host or a device along the path explicitly refused the connection. Check the port, then ask your provider to confirm that it is listening and that access controls are configured as expected.
Error: TLS handshake timeout
What it means and what to do: The TLS handshake did not finish in time. Check the port, TLS settings, and Server Name, then switch networks to see whether handshake traffic is blocked or the connection is responding slowly.
Error: certificate has expired or is not yet valid
What it means and what to do: The current time falls outside the certificate’s validity period. First correct the device’s date and time. If the error persists, ask your provider to check whether the server certificate has expired or is not yet valid.
On your iPhone or iPad, open Settings → General → Date & Time and check that Set Automatically is enabled and the displayed date and time are correct. Then reconnect. VMess authentication also depends on time synchronization; if the device clock is significantly off, correct it before repeatedly changing the UUID. A TLS timeout and a certificate validity error are different issues, so not every handshake failure is caused by the system time.
5. Connected but websites won’t load: check routing and DNS
If the node test succeeds but websites still fail to load, return to Home and check Global Routing. Proxy, Direct, Config, and Scene are different routing modes: Direct sends traffic without a proxy; Config applies the rules in the current configuration; Scene depends on the selected scene. You can temporarily select Proxy for comparison, but restore the original option after testing. A temporary switch does not mean the rules have been fixed.
- Check which rule matches first: Review the current configuration in Config.
DOMAIN-SUFFIXmatches domain suffixes,GEOIPandIP-CIDRhandle IP-based conditions, andFINALis the catch-all rule. Rule order can change the outbound route. - Distinguish a rule rejection from a network timeout: If the destination matches
REJECT, the rule is rejecting the request; changing the node password will not help. First check whether a rule is incorrectly matching the destination domain. - Check which DNS lookup is failing: If the connection address is a domain, it must be resolved before the server can be reached. Resolving the website’s domain is a separate step. Record which domain fails, then check the DNS settings in the configuration and whether the resolver is reachable.
- Do not rely on visiting an IP over HTTPS as your only test: Direct access by IP may omit the correct domain information and cause a certificate or site-routing mismatch. This does not prove that DNS is working or failing.
If only large pages, video, or larger transfers stall while short requests succeed, consider issues such as path MTU. For WireGuard, use the MTU in the existing configuration first. If an adjustment is needed, keep the original value and retest that setting separately after checking with your provider. Do not change DNS, routing, and MTU at the same time.
6. Rule out network conditions, On Demand, and subscription updates
Public Wi-Fi may require you to sign in through a web page first. Turn off the Shadowrocket connection and confirm that the network itself can access the internet. Changing protocols will not help if the underlying network is not connected. On cellular, also make sure iOS allows Shadowrocket to use cellular data, and check whether another VPN configuration or device management policy is affecting the connection.
In Settings → On Demand, check whether automatic connection conditions are enabled. If the connection is being re-established automatically while you troubleshoot, you can temporarily turn off On Demand and control the connection manually. Restore the original setting after testing. On Demand controls when the system starts a connection; it does not fix the server address, port, or authentication details.
Why does it time out on Wi-Fi but work on cellular?
Keep the same node and test destination, complete Wi-Fi sign-in, then test again. If only Wi-Fi still fails, note the network type and protocol, then ask the network administrator or your provider about restrictions on ports, UDP, or other traffic. Do not start by resetting all settings.
A subscription update timed out. Should I delete all existing nodes?
Keep the existing configuration for now. In Home, update your subscription and check that its URL is still valid. Ask your provider whether the subscription address or access requirements have changed. A failed update does not mean all imported nodes have stopped working, and deleting the configuration removes useful comparison data.
Why does the node show latency if websites still won’t load?
First confirm the test method. In Home, temporarily set Global Routing to Proxy and retry the same HTTPS page. If it still fails, check authentication, TLS, and DNS. If it works, return to Config and check which rule matched before restoring the original routing mode.
Will reinstalling the app fix a timeout?
Reinstalling will not change the server port, subscription status, or network restrictions. Compare the settings and test on both networks first, and back up your configuration. Only proceed with app-specific troubleshooting if there is clear evidence of a local app state issue, so you do not lose your original records.
7. If the problem persists, prepare a concise report
If the steps above do not identify the cause, narrow the issue down to reproducible conditions instead of continuing to change settings at random. When contacting your provider, include the protocol, test method, and stage where the failure occurs. For a school or workplace managed network, ask the relevant administrator to confirm any network restrictions.
- When the issue occurred and the time zone, device model, and system and app details.
- Results on Wi-Fi and cellular, with three test records per network using the same method.
- Whether only one node fails, and the separate results of the connection test, URL test, and actual website request.
- Redacted protocol type, port, TLS status, and full error message. Do not share passwords, private keys, UUIDs, or full subscription URLs.
- Settings you changed and whether you restored them, especially Global Routing, On Demand, DNS, and MTU.