A timeout in Shadowrocket does not necessarily mean every connection setting is wrong. This guide assumes you already have a provider and subscription, and walks through checks for your network, latency tests, protocol fields, system time, DNS, and routing rules. Change one setting at a time and retest against the same destination. Keep a record of reproducible symptoms and errors.
1. Distinguish a timed-out test from a failed connection
The key point: a latency test is a diagnostic clue, not proof that a connection works. A TCP test mainly checks whether a TCP connection can be established to a specified address and port; it cannot verify the password, UUID, or subsequent TLS handshake. Testing a URL through a proxy also involves protocol negotiation, destination DNS resolution, and the target site’s response. These tests cover different things, so their results are not interchangeable.
A VPN Connected status only indicates that the system tunnel has been established. It does not confirm that the remote service, DNS, or every routing rule is working. Record “test failed,” “connection toggle on,” and “whether the site loads” separately. For protocols that use UDP, a single TCP port test is especially unsuitable as a verdict on whether the connection works.
- Only the test times out: Note the test method and target, then try opening a known-working HTTPS page. Don’t delete the node right away.
- The test returns a value, but browsing fails: Check authentication, TLS, DNS, and routing rules. A latency value alone is not a reason to skip verifying the settings.
- Only one site fails: Check the target site, matching policy, and domain resolution first. Don’t assume the entire connection is unavailable.
2. Establish a repeatable troubleshooting baseline
Note the currently selected node, Global Routing mode, and Config name so you can restore them afterward. Use the same node and test target throughout. When switching between Wi-Fi and cellular, don’t also change the protocol or DNS. Cellular tests use mobile data, so decide whether to run them based on your plan.
-
Check the network first
Note your current Settings → On Demand configuration. Temporarily turn off automatic activation while troubleshooting, then switch off the connection toggle in Home. Open a known-working site. If public Wi-Fi requires a sign-in page, complete authentication first.
-
Keep the test target fixed
Return to Home, select the node you want to check, and note the latency test method and target. Run the test three times and record whether each attempt succeeds, times out, or returns a specific error. These tests help reproduce the issue; they do not establish long-term availability.
-
Compare network conditions
If possible, retest the same node over Wi-Fi and cellular. If it fails on only one network, check that network’s authentication, DNS, and transport restrictions first. Don’t re-enter all node settings at once.
-
Test an actual request
Turn on the connection, then temporarily select Proxy under Home → Global Routing and visit the same HTTPS destination. This helps reduce interference from Config routing rules. Restore the original mode afterward so the diagnostic setting isn’t left in place.
3. Verify the address, port, and protocol settings
Open the selected node’s edit screen from Home and compare each field with the original configuration from your provider. Don’t identify the protocol by the node name alone: the name may be outdated even if the fields have changed. Enter the required hostname or IP in the address field; don’t paste a full share link, subscription URL, or URL with a path as the server address.
| Check | What to verify | Common misjudgment |
|---|---|---|
| Address / Port | Compare the server address and port character by character. Ports range from 1 to 65535; use the value specified in the original configuration. | Assuming every node uses port 443 and changing a configured port such as 8443 to 443. |
| Shadowsocks | Check the encryption method and password. If there are plugins or additional transport settings, make sure they match the server configuration too. | Assuming the password is correct because the port is reachable, or changing the encryption method without confirmation. |
| VMess / VLESS | Verify the UUID, transport type, TLS, and any Host, Path, or Service Name required by the selected transport. | Checking only the UUID and missing the WebSocket path or gRPC service name. |
| Trojan | Check the password, server address, port, TLS, and SNI. Enter any additional transport settings as specified in the original configuration. | Changing the address to an IP and clearing SNI at the same time, causing a certificate name mismatch. |
| Hysteria2 | Check the authentication details, TLS, and any obfuscation settings required by the server. Also confirm that the network allows the relevant UDP traffic. | Using a failed TCP test alone to conclude that a QUIC-based connection is unavailable. |
| WireGuard | Verify the local PrivateKey, peer PublicKey, Endpoint, Address, and routing scope. | Mixing up the two types of keys, or treating the absence of a TLS error as proof that WireGuard completed its handshake. |
If the node comes from a subscription, first check whether the latest subscription update succeeded, then compare the updated fields. Updating a subscription and connecting to a node are separate requests: a successful update only means the configuration was retrieved; it does not mean every node in it can connect. Save any necessary details before making manual changes, as a later subscription update may overwrite them.
Bottom line: Once the port is reachable, check the handshake
If a TCP test returns a result but an actual proxy request still fails, check authentication, TLS, and transport settings next. Don’t keep changing the port. For UDP protocols, assess the connection using an actual request with the relevant protocol.
4. Narrow down the issue by the stage where it occurs
When reviewing connection logs in the app, keep the surrounding context, especially whether the error involves the server address, a DNS lookup, or the target site. The examples below are snippets that may appear in network errors; capitalization and exact wording vary by source. None should be treated as a fixed message that Shadowrocket is guaranteed to show.
Error: i/o timeout
Cause and fix: A network read or write did not complete before its deadline. This message alone can’t tell you whether the problem is the port, handshake, or target response. Check the destination address in context, then verify the network, port, and protocol settings in that order.
Error: connection refused
Cause and fix: The connection was refused. The target port may not be listening, or an intermediate device may have actively rejected the request. Check the address and port, then ask your provider whether that endpoint is still in service. Don’t troubleshoot by trying random ports.
Error: no such host
Cause and fix: A hostname could not be resolved. The address may be misspelled, the DNS record may not exist, or the current resolution path may have a problem. First determine whether the domain in the error belongs to the node or the target site, then check the domain and DNS settings.
Error: certificate has expired or is not yet valid
Cause and fix: The certificate validity check failed, possibly because of the device time or the server certificate. Correct the time on your iPhone first. If the error persists, ask your provider to check the server certificate status.
Don’t disable certificate verification to get rid of a certificate error. The address, SNI, and domain covered by the certificate need to match. Bypassing the error with a setting does not fix a name mismatch or the certificate itself.
5. Check your iPhone’s system time and TLS
On your iPhone, go to Settings → General → Date & Time and check Set Automatically. If a device management policy prevents changes, first confirm that the actual device time is accurate. Certificate validity is generally based on absolute time; displaying a different time zone does not necessarily mean the system clock is wrong.
- Time is significantly off: Set it to the correct time, disconnect and reconnect Shadowrocket, then test the same destination again.
- Time is correct but the certificate check fails: Return to the node edit screen and verify TLS and SNI. In particular, check that the server IP wasn’t entered as the certificate domain.
- Only one destination fails: Check whether the error is from the target site’s certificate rather than the proxy server handshake. Don’t conflate the two.
- Settings changed recently: Compare them with your provider’s current configuration and check whether the endpoint domain or certificate requirements have changed.
Some authentication mechanisms also depend on a reasonably accurate system clock. Check the time when relevant, but don’t treat time correction as a generic fix for every failure. If the error remains unchanged after correcting the time, move on to the next stage instead of repeating the same step.
6. Check DNS and Config routing last
Once you’ve verified the protocol settings and system time, distinguish between “the node hostname can’t be resolved” and “the target domain can’t be resolved after the connection is established.” The first prevents a remote connection from being established; the second may leave the connection toggle on while some sites remain inaccessible. Opening an IP address directly is not a complete HTTPS test because the certificate name and virtual host may still depend on the domain.
If you use Config, confirm which configuration is selected in Config, then check [General] and dns-server in its contents. Don’t assume changes in a different, inactive configuration have taken effect. Avoid adding several unfamiliar DNS addresses at once. Save the original value, change one setting, and retest the same domain.
- Check rule order:
DOMAIN-SUFFIXmatches domain suffixes,IP-CIDRmatches address ranges, andGEOIPuses IP geolocation. These rules don’t use the same matching criteria. - Check the final policy:
FINALis the fallback when no earlier rule matches. If its policy differs from what you expect, traffic may use a different route. - Compare routing modes: If the same node works with Proxy but fails with Config, check the rules, policy references, and DNS in the configuration first. Don’t re-enter authentication fields that have already been verified.
- Restore the original settings: After each comparison test, restore the original Global Routing and On Demand settings, and note any changes you decide to keep.
7. Common questions and how to document results
Why can’t I open a website even though the latency test returns a value?
First check the test method. A successful TCP connection doesn’t mean authentication and TLS succeeded. Temporarily select Proxy under Home → Global Routing, visit the same HTTPS destination, then check for handshake errors. If Proxy works but Config doesn’t, check the rules and DNS in the currently selected Config.
Why does the node still time out after a successful subscription update?
Retrieving subscription content and connecting to a remote endpoint are separate processes. Open the node edit screen and compare the address, port, and protocol settings, then retest on the current network using the same method. A successful update does not prove that every node is reachable.
Wi-Fi fails but cellular works. Should I add the node again?
Don’t delete it yet. Keep the node settings unchanged and check Wi-Fi sign-in and DNS. If you use Hysteria2 or WireGuard, also check whether the network allows the required UDP traffic. Share the comparison results with the network administrator or your provider; this is more useful for troubleshooting than repeatedly adding the node.
What should I send my provider when reporting an issue?
Include when the issue occurred and your time zone, network type, protocol, test method, the complete error snippet, and the comparison results for Proxy and Config. Hide passwords, UUIDs, PrivateKey values, and subscription tokens. Don’t send an unchecked full configuration or screenshot.
When you’re done troubleshooting, record three things: what happened before the change, the one setting you changed, and the result afterward. If the issue persists, keep the conditions from your last reproducible test. This lets you resume at a specific stage next time instead of randomly changing every setting again.