This guide is for users who already have their own service provider, server details, or subscription. First distinguish a test timeout from an actual request failure, then check the network, protocol settings, system time, and routing configuration in turn. Change one setting at a time and keep a record of the original value to avoid turning a fixable issue into configuration confusion. Check Shadowrocket’s connection status, test results, and whether webpages load separately.
1. Run a Latency Test to Identify Where the Failure Occurs
timeout means an operation did not complete within the allowed time. It does not, by itself, mean the password is wrong, the server is offline, or the app is malfunctioning. Connectivity Test in Home is the place to start diagnosing the issue; different test methods check different stages. Note the current test method and compare results for the same entry. Do not compare values from different test methods.
A successful connection to the port does not mean proxy authentication succeeded or that the destination webpage can return content. Conversely, a failed test does not prove that every real request will fail. First, turn off the connection toggle and confirm that your current Wi-Fi or cellular network can access the internet. Then test an existing entry, turn the connection on, and visit a destination you normally use.
-
Record the Current State
In Home, note the selected entry, the current Global Routing option, the Connectivity Test method, and the error message. Record the test time so you can compare it with server logs.
-
Confirm Internet Access
Turn off the Home connection toggle and check whether you need to sign in to the local network first. Do not change server protocol settings until basic internet access is restored.
-
Repeat the Test
Use the same entry and test method for three consecutive tests. Record whether each succeeds, times out, or returns another error, and note whether the failure is constant or intermittent.
-
Switch Networks
If possible, repeat the test on both Wi-Fi and cellular. Change only the network; do not switch entries, protocols, or Global Routing at the same time.
-
Verify a Request
Turn on the Home connection toggle and visit the same destination. Record “test failed, but the page loads” separately from “both the test and page failed,” then proceed to check the settings.
2. Verify the Server Address, Port, and Protocol Settings
From Home, open the edit screen for the relevant entry. First confirm that Type matches your original configuration, then check the address, port, and authentication fields. Do not switch VLESS to VMess or Hysteria2 to Trojan just because the connection failed; the client and server must use matching protocols.
| Field to Check | What to Verify | Common Misconception |
|---|---|---|
| Address and port | Domain spelling, IP address, and port number | Port 443 is only an example; it does not automatically mean the protocol, TLS, or authentication settings are correct. |
| Shadowsocks | Encryption method and password specified by the server | Checking the password alone is not enough; the encryption method must also match. |
| VMess / VLESS | UUID, transport, and any required TLS, Host, Path, or other fields | A correct UUID does not compensate for an incorrect transport path or handshake setting. |
| Trojan | Password, TLS settings, and server name | The connection address may differ from the name verified by the certificate. Use the original configuration as your reference. |
| Hysteria2 | Authentication details, TLS parameters, and UDP reachability | A TCP port probe cannot replace validation of a UDP-based protocol. |
| WireGuard | Key, Endpoint, port, address, and routing parameters | Do not use a TCP handshake result to determine the status of a WireGuard UDP tunnel. |
When copying fields, watch for leading or trailing spaces, missing characters, and full-width punctuation. If the original configuration specifies port 8443, do not change it to 443 to try to “fix” the issue. If the server does not provide the same service on the new port, this change only introduces another mismatch. Do not hide TLS-related failures by disabling certificate verification; instead, check the name, time, and certificate configuration.
What to Check Next, Based on the Failure
If only one entry keeps failing, start by checking its original settings. If a group of entries fails on just one network, first check that network’s access conditions. Do not rewrite your rules as the first response to either problem.
3. Use the Error Message to Guide Your Checks
The test list may show only a brief status, while detailed errors may appear in connection logs or your own server logs. The following are common snippets from network diagnostics; they may not always appear in the same place in Shadowrocket. Keep a record of the full message you actually see, rather than labeling every failure “server timeout.”
Error: timeout
Cause and next steps: This operation exceeded its time limit; this alone does not identify where the failure occurred. Retest the same entry, compare results on another local network, then verify the address, port, and protocol requirements.
Error: connection refused
Cause and next steps: This usually means the destination actively refused the connection, possibly because no service is listening or access was denied. Check that the port matches the original configuration, then ask your service provider or server administrator to confirm the service status.
Error: no such host
Cause and next steps: The destination name could not be resolved. Check the server domain spelling and local internet access first. If you manage the domain, confirm that the relevant DNS record exists.
Error: TLS handshake timeout
Cause and next steps: The TLS handshake did not complete in time. Check that TLS matches the server requirements, verify the server name, and compare network paths. Do not assume the password is the cause.
When reporting the issue to your service provider, include the time and time zone, network type, protocol, test method, exact error message, and whether the failure is constant or intermittent. Passwords, UUIDs, private keys, and full subscription URLs are sensitive and should not appear in public screenshots or records.
4. Check the System Date, Time Zone, and Automatic Connection
An incorrect system time can affect certificate validity checks and authentication for some protocols, but it is not the cause of every timeout. On iPhone or iPad, check Set Automatically under Settings → General → Date & Time. If the device is managed, this option may be restricted; follow your device management requirements.
- Check the actual date and time first: Make sure the year, date, hour, and minute are not noticeably off. Checking only the hour in the status bar is not enough.
- Then check the time zone: The time zone affects local display and log comparisons; a different displayed time zone does not mean the device’s absolute time is wrong. Include the time zone when sharing logs.
- Reconnect after correcting the time: Once the time is corrected, turn the Home connection toggle off and back on, then retest using the same method. Do not keep judging the issue based on results from before the correction.
- Control automatic connection: If connection attempts resume after you disconnect manually, check the existing settings under Shadowrocket Settings → On Demand. Note the original state and, if needed, temporarily disable it while testing manually.
5. Check Global Routing and Rule Matches
If the connection test succeeds but a page still will not load, check Home → Global Routing. Proxy, Direct, Config, and Scene are different routing modes, not different protocols. Proxy routes eligible traffic through the proxy, while Direct connects directly. Config applies the routing rules in the selected configuration. For Scene, check the active scene and its associated settings; it is not simply another name for Config.
To isolate the effect of routing, note the original option, briefly switch to Proxy, and try the same destination using the same selected server. Restore the original mode afterward. If Proxy works but Config does not, check the active configuration, rule order, and policy targets in Config first. This narrows down the issue but does not rule out every DNS or destination-site problem.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThe example below illustrates rule matching; it is not a complete configuration to replace your own. DOMAIN-SUFFIX matches a domain and its subdomains; IP-CIDR matches a destination IP range, and 192.0.2.0/24 is a documentation-only example range. no-resolve means the IP rule will not actively resolve a domain for matching. GEOIP matches by the geographic location of an IP address, and FINAL handles requests that did not match an earlier rule.
- Check rules from top to bottom. The first matching rule determines the policy, so put rules that need priority earlier in the list.
DIRECT,PROXY, andREJECTroute traffic directly, through a proxy, or block it, respectively. If a matching rule returns REJECT, do not continue troubleshooting it as a server timeout.- If you use a custom policy group, check that the names referenced by your rules match the group and review its selection. The server that passed the test is not necessarily the outbound route used by the rule.
- If only specific domains fail, note the matching rule and policy for each destination. Avoid moving FINAL arbitrarily, as this can affect other requests.
6. Subscription Updates and Other Common Connection Questions
Does a subscription update timeout mean all my existing entries are invalid?
Not necessarily. A subscription update fetches configuration data; testing a saved entry follows a different request path. First test an entry already saved in Home, then check whether your existing subscription is still valid. If you need to update through an existing proxy, confirm that the connection works first, then check Settings → Subscribe → Update via Proxy. Enabling this option will not restore the connection if all entries are unavailable.
Why does a latency test show a value when webpages still will not load?
First check which test method Connectivity Test used. An accessible port does not mean authentication, TLS, destination resolution, and the destination response all succeeded. Verify the protocol settings in order, then compare the same destination under Proxy and Config. Do not judge the entire connection path by a single millisecond value.
Only Wi-Fi times out, while cellular works. Should I change the password?
Keep the password and other fields unchanged, and repeat the comparison using the same entry. Check whether Wi-Fi requires a sign-in or restricts the port or UDP in use. Report the network difference to your administrator; changing the password blindly can break a configuration that already works.
After a subscription update, connections time out. Should I delete and re-add the entry right away?
First compare the address, port, Type, and transport settings before and after the update, and check whether the selected entry changed. Keep the original details, then ask your service provider to confirm any changes. Deleting the entry removes your basis for comparison and will not fix an unresponsive remote service.
Conclusion: Keep a Minimal, Reproducible Record
After troubleshooting, keep the results for the same entry, the same test method, two networks, and one destination, changing only one setting at a time. This makes it clear whether the next step is to correct a local setting, check network conditions, or ask your service provider to investigate the server.