Shadowrocket Connection Timeout: 3 Steps to Troubleshoot Connection Failures

Before you troubleshoot: distinguish test timeouts from failed requests

A latency test timeout means only that the test did not receive the expected response within the allotted time. It does not, by itself, mean the server is offline. Different tests check different parts of the connection: a TCP test mainly checks whether a port can be reached, while an application-level connectivity test may also involve a protocol handshake, TLS, and the test destination. Note which test you’re using before comparing results.

Likewise, a VPN status of Connected means the tunnel is established; it doesn’t confirm that remote authentication, DNS resolution, or requests to websites are working. Trace the request through each stage to narrow down the issue instead of assuming everything is working because the connection switch is on.

• Test fails and webpages fail: Check the network, address, and port first, then verify the protocol settings.
• Test fails but webpages load: Check the test method and destination first. Don’t rebuild the node right away.
• Test succeeds but webpages fail: Check authentication, TLS, DNS, rules, and the destination site. A reachable port doesn’t mean a complete proxy request will work.

Step 1: Keep the node and test method fixed, then compare networks

In Home, confirm which node is selected. Don’t update all your connection details or switch protocols yet. Use the same node and test method on your current network, repeat the test, and record the results. An intermittent failure calls for a different approach than a persistent one. Repeating the test helps confirm whether the issue is reproducible; a single latency reading isn’t a measure of connection quality.

1. Confirm what you’re testing

   Open Home and note the selected node’s name, server address, port, and test method. Make sure it’s the node you intend to test so you don’t confuse its results with another node’s or with webpage access.

2. Rule out routing rules

   Go to Home → Global Routing → Proxy and test a regular webpage using the selected node. This is only to temporarily rule out routing in Config. When you’re done, restore your original Global Routing selection.

3. Try another network

   If supported by your device and permitted, switch from Wi-Fi to cellular, or try another trusted Wi-Fi network. Wait for the connection to stabilize, keep the node and settings unchanged, and run the same test again.

4. Check automatic connections

   If the connection comes back automatically after you disconnect manually, go to Settings → On Demand and review the existing rules. To pause them, turn off On Demand before testing a manual connection. Restore your original settings when you’re done.

For connections that rely on UDP, such as Hysteria2 and WireGuard, don’t use a TCP test to determine whether the protocol works. A network that allows TCP traffic may still block UDP traffic to the same address. Keep the protocol unchanged when comparing results, and base your assessment on actual connection and request results.

Step 2: Check the address, port, and authentication settings for your protocol

Go to Home → the selected node’s edit screen, and check each field against the original details from your provider. Don’t guess the protocol from the node name or copy settings from another connection. The port must match the one the server listens on: if the details say 8443, don’t change it to 443 just because TLS is enabled. These numbers illustrate what to check; they aren’t universal settings.

First check that the server address doesn’t include an accidental space, protocol prefix, or path. Then check the port and authentication fields. The server address, TLS Server Name, and WebSocket Host may serve different purposes. Use the same value for them only if your provider’s details explicitly say to.

If you use a subscription, distinguish update failures from node failures

Updating a subscription retrieves connection details; connecting through a node uses those details to reach a remote server. These are separate processes. In Home, find your subscription group and update it, then check whether the node’s address, port, or authentication details have changed. A successful update doesn’t mean every node in it works. A failed update doesn’t necessarily mean your saved connection details are no longer valid.

• If your provider confirms that the settings have changed, update your subscription first, then select the node you want to test again.
• If the update itself fails, first check whether your current network can reach the subscription URL, then ask your provider to confirm the link is still valid.
• Keep a record of the original settings before making changes. Change only one type of field at a time, save, and test again so you can compare against a baseline.
• Don’t include a full subscription URL, Password, UUID, or private key in a public screenshot. When reporting an issue, share only the necessary error and network details.

Step 3: Correct your device’s time and check for TLS errors

TLS certificates have a validity period. If your device’s clock is significantly wrong, a valid certificate may appear not yet valid or expired. On your iPhone or iPad, open Settings → General → Date & Time. Check that Set Automatically is on and the displayed date and time are correct. If device management restricts this setting, contact your administrator.

After correcting the time, reconnect and test again. If the time is correct but the certificate error persists, check whether the Server Name matches the certificate domain, or ask your provider to check the server certificate and certificate chain. Don’t turn off certificate validation as a substitute for these checks. Correcting the time also can’t fix an expired server certificate.

These are examples of errors that may appear in logs, not fixed popup messages. The full message can vary depending on the protocol and connection stage. Keeping the surrounding error details is more useful than noting only “timeout,” but remove authentication details before sharing logs.

After the connection works again: check Config and routing

If webpages load temporarily in Proxy but only some fail after you restore Config, focus on the active configuration instead of changing a node you’ve already verified works. Open Config and check which configuration file is selected, then go to Home → Global Routing → Config and test again.

Rules are evaluated in order. DOMAIN-SUFFIX matches a domain and its subdomains, IP-CIDR matches an IP range, GEOIP matches based on the geographic location of an IP address, and FINAL catches requests that didn’t match an earlier rule. The example below demonstrates syntax and order only; it isn’t a complete configuration to replace yours with:

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,DIRECT

• example.com is a sample domain. Check which rule matches the actual destination domain you’re trying to reach; don’t copy the example as-is.
• If the request matches DIRECT, it can’t tell you whether the proxy node is working.
• If only one website has a problem, check the other domains it uses, DNS results, and the destination’s response. Don’t assume the entire node is down.
• If you were using Scene, check which scene was triggered and which configuration it uses. Restore your original setup after testing so temporary Proxy settings aren’t left in place.

Still failing? Collect reproducible details to share

If the connection still isn’t working after all three steps, give your provider reproducible details instead of just the node name. Test results can help narrow down the issue, but without server-side information they can’t prove whether the client or server is at fault. The details below are enough for the next round of checks; you don’t need to share full authentication credentials.

1. Test time and network: Include your local time and time zone, and whether you were on Wi-Fi or cellular. Note whether the issue also occurs on another network.
2. Protocol and test method: Name the protocol you’re using, such as Shadowsocks or Trojan, and say whether you ran a port test or tested a complete request.
3. Client status: Note your Global Routing selection, the current node, whether the device time is correct, and whether you checked On Demand.
4. Point of failure: Say whether the connection can’t be established, authentication fails, TLS validation fails, or only specific websites fail after connecting.
5. Redacted evidence: Include the relevant error context. Remove subscription tokens, passwords, UUIDs, private keys, and any QR codes containing them.

Rebuying the app won’t fix a node timeout. A one-time app purchase is separate from a connection plan: Shadowrocket is a closed-source commercial app, and buying it on the App Store is separate from the connection service you have with your provider. Shadowrocket is available only on Apple platforms, primarily for iPhone and iPad. Check the App Store page for system requirements.