Shadowrocket Node Timeout: Troubleshooting Latency Tests, Protocol Settings, and System Time

Use latency tests to define the scope

A latency test checks whether Shadowrocket can complete a probe within the allotted time; it is not a bandwidth test. A result of tens or hundreds of milliseconds only confirms that a reachable response was received at that moment. A timeout means the probe did not return before the deadline. An offline server, failed address resolution, blocked port, mismatched transport, or current network restrictions can all produce the same timeout result.

Do not change the password, port, and rules all at once just because you see timeout. From Home, run the same latency test on several existing entries and record the results. If only one entry times out, focus on its settings. If every entry from one subscription times out, check whether the subscription has updated and whether your service provider changed the configuration. If every source times out, switch networks and check system-level settings first.

1. Close the old session

   Return to Home, turn off the connection switch, and wait a few seconds for the previous incomplete connection to close before testing again.

2. Test one entry

   Test the currently selected server first, then test two different addresses from the same subscription. Do not use a single result to represent every entry.

3. Switch networks and retest

   Test over both available Wi-Fi and cellular networks. If the result changes with the network, the problem is more likely in the current network path than in the configuration file.

4. Record what happens

   Note whether the request fails immediately, waits before showing timeout, or displays a latency value but carries no traffic after connection. Each symptom points to a different troubleshooting path.

Verify protocol and transport settings field by field

The address and port are the first layer. Address should contain the domain or IP supplied by your service provider, and Port must exactly match the original configuration. Numbers such as 443, 8443, and 2053 are common examples, not interchangeable values. Do not change a port to 443 just because it looks like HTTPS. An extra space in the domain, a missing port digit, or a copied old address can all leave the connection stuck at the timeout stage.

The second layer is authentication. Shadowsocks requires matching Password and Method values; VMess and VLESS usually require checking the UUID; Trojan requires checking Password; Hysteria2 requires checking the authentication value and server port; WireGuard involves the local Private Key, peer Public Key, Endpoint, Address, and Allowed IPs. Similar field names do not mean values can be reused across protocols.

The third layer is transport and security. When using TLS, Server Name or SNI, certificate verification, and the target domain must match the information supplied by your service provider. With WebSocket, also check Host and Path. For example, if Path is /ws, omitting the leading slash can cause the handshake to fail. Hysteria2 uses UDP and QUIC; if the same configuration works on one network but consistently times out on another, include the UDP path difference in your investigation.

• Shadowsocks: Check Address, Port, Password, and Method. Pay particular attention to an exact character-for-character match for Method.
• VMess: Check UUID, Transport, TLS, Host, Path, and any other fields explicitly provided by your service provider.
• VLESS: Check UUID, Flow, Transport, Security, and SNI. Do not apply VMess configuration values directly.
• Trojan: Check Password, Port, SNI, and certificate-related settings. The domain and SNI are not necessarily interchangeable.
• Hysteria2: Check the server port, authentication value, SNI, and Obfuscation settings, and confirm that the current network provides a usable UDP path.
• WireGuard: Check the keys, Endpoint, Address, Allowed IPs, and MTU. An incorrect Endpoint port will cause the handshake to receive no response.

Example: for identifying field structure only, not a working server
Address: server.example.com
Port: 8443
Transport: websocket
TLS: enabled
Host: edge.example.com
Path: /ws

Check Global Routing, Config, and On Demand

If the latency test returns a result but webpages remain inaccessible after connection, shift the investigation from server reachability to the traffic path. Shadowrocket’s Global Routing options include Proxy, Direct, Config, and Scene. Proxy sends applicable traffic through the current proxy; Direct connects directly; Config determines the route using the current configuration rules; Scene switches according to the selected scenario. During testing, identify which option is active.

If Global Routing is set to Direct, the device may show an established system VPN state while web requests bypass the selected server. With Config, check the destination of the final FINAL rule and confirm whether the target domain was already matched by a preceding DOMAIN-SUFFIX, GEOIP, or IP-CIDR rule. Rules are evaluated in order, and the first match takes effect.

DOMAIN-SUFFIX,example.com,Proxy
IP-CIDR,192.168.0.0/16,Direct
GEOIP,CN,Direct
FINAL,Proxy

In the example above, requests matching the example.com suffix use Proxy, while local-network addresses and traffic matching GEOIP conditions use Direct. All other requests are sent to Proxy by FINAL. If FINAL is set to Direct, requests not matched by earlier rules will bypass the proxy. This does not mean the server has failed; it means the rule result differs from the test target.

On Demand triggers a connection based on network conditions. When troubleshooting a manual connection, open Settings → On Demand to check its current status. Temporarily disable automatic triggering before testing to avoid situations where a network change reconnects immediately or a scene replaces the server you just selected. Restore the original setting when testing is complete.

Check the subscription link and entries separately when updates fail

Subscription updates and server connections are separate paths. An update fetches a configuration list from the specified URL; a server connection uses the address and settings of a specific entry in that list. Existing entries may still connect even if the subscription URL has expired. Conversely, a subscription can download successfully while one server in the list times out because its port or settings changed.

An example subscription address can be written as https://example.com/sub?token=xxxx to show its structure, but actual use requires a valid link obtained from your own service provider. A missing token, a truncated copy, spaces around the link, or an address change by the service provider can all cause an update to fail. This site does not provide subscriptions or recommend specific service sources.

1. Verify the original link

   Edit the Subscribe entry and compare the scheme, domain, path, question mark, and token with the original text from your service provider. Remove any leading or trailing spaces introduced during copying.

2. Run the update separately

   Return to Home and pull down to refresh. Check whether one Subscribe entry or every source fails; do not delete server entries that still work.

3. Check proxy-based updates

   If your service provider explicitly requires the subscription to be accessed through the current connection, open Settings → Subscribe and check Update via Proxy. Before enabling it, confirm that the selected server can connect.

4. Verify the update result

   After the update completes, check whether the number and names of entries changed. Then select one entry and run a latency test to confirm that the new settings were actually loaded.

Sync system time and handle network changes

TLS certificate verification, timestamped authentication, and some protocol handshakes depend on the device clock. A wrong date, time zone, or significant clock offset may appear as a TLS handshake failure, an authentication failure, or a timeout after several retries. Check system time if the date was changed manually, the device crossed time zones without syncing, or it has been offline for an extended period.

On iPhone or iPad, open Settings → General → Date & Time, check Set Automatically, and confirm that Time Zone matches your location. After making a change, do not repeatedly tap the connection control. First turn off Shadowrocket’s connection switch and wait for the system network state to stabilize, then return to Home and select the server again.

When the network switches from Wi-Fi to cellular, the local address, DNS, and route used by the existing connection change. If it does not recover after a long wait, turn off the connection, wait until the status bar shows that the new network is available, and turn it on again. If On Demand is enabled, also watch whether its automatic rules select a different scene after the network changes.

• Check Settings → General → Date & Time → Set Automatically.
• Confirm that Time Zone is not still set to a previous location or an incorrect manual value.
• After a network change, turn off the old connection and wait a few seconds before establishing a new one.
• Temporarily turn off Settings → On Demand to prevent automatic scenes from interfering with manual testing.
• If only one TLS entry fails, continue checking SNI, the domain, and certificate settings instead of changing only the system time.

Complete the final retest in a fixed order

After checking settings, rules, subscriptions, and system time, finish with a consistent workflow. Keep On Demand paused and select a server whose settings have been verified. Run a latency test to confirm that the entry responds, then turn on the connection and run Connectivity Test. If latency is normal but Connectivity Test fails, return to Global Routing, Config rules, DNS, and transport settings instead of repeatedly refreshing the subscription.

At minimum, record the current network, server name, protocol, whether a latency value appeared, the connection-switch state, and the failed stage in Connectivity Test. When contacting your own service provider, do not send the full Password, UUID, Private Key, or subscription token. Provide only redacted fields, the time, and the original error text.