A timeout in Shadowrocket does not necessarily mean the server is down. This guide applies to iPhone / iPad, Mac, Windows, Android, and Linux. Troubleshoot in this order: local network → test scope → protocol settings → system time → rules and DNS. The interface steps refer to Home, Config, and Settings on iPhone / iPad; check the equivalent settings on other platforms. You’ll need your own service provider and subscription; get the subscription URL from your provider.
1. Distinguish a server timeout from a local network issue
Turn off the connection switch in Shadowrocket, then use a browser to open a site that normally works without a proxy. If your local network is unavailable, latency test results can’t tell you whether the remote service is working. Public Wi-Fi may also require you to sign in first. Seeing the Wi-Fi icon does not mean you have full internet access.
Change one variable at a time. Start with the same network, server, and destination, then switch between Wi-Fi and mobile data. Don’t update the subscription, change protocols, and replace the configuration all at once. Otherwise, even if the connection recovers, you won’t know which change fixed it.
-
Check the local network
Turn off the connection on Home and confirm that a browser can open a known site accessible without a proxy. Sign in to Wi-Fi networks that require authentication.
-
Record the scope of the failure
Select the server to test on Home. Note whether one server, a group of servers, or all servers fail, and whether you’re using Wi-Fi or mobile data.
-
Check the actual connection
Turn on the connection, run Connectivity Test on Home, and use a browser to request the same destination. Record the test result and whether the page loads; don’t rely on the connection switch alone.
-
Retest on another network
Keep the server and configuration unchanged, switch to another network you can use, and repeat the test. If only one network fails, check its DNS, access restrictions, and UDP availability first.
2. Why can a latency test succeed while websites still won’t load?
Interpret latency results in light of the test method. A TCP connection test checks only part of the path to a specified address and port; it does not verify your password or prove that the proxy can reach a website. Tests that make an actual request cover more steps, but only show the result for that destination at that time—not that every website is reachable.
| What you observe | What to check first | Next step |
|---|---|---|
| One server times out; others work | The issue is more likely with that endpoint or its settings | Check the server address, port, and service status. Don’t reset the entire configuration. |
| All servers fail on Wi-Fi but work on mobile data | The local network path differs | Check Wi-Fi sign-in, DNS, and whether UDP traffic is allowed |
| Port test shows latency, but actual requests fail | Authentication, TLS, or access to the destination is failing after the connection is established | Check failed-request logs and verify credentials, SNI, and system time |
| Websites work, but some tests fail | The test destination or method may not suit this connection | Note the test type and cross-check with an actual request |
| Only one website fails | The destination website, a rule, or DNS may be the issue | Compare Proxy and Config under Global Routing, then check which rule matches the domain |
Key takeaway: keep a reproducible baseline
If the same server works after you switch networks, investigate the original network first. If only one server fails on the same network, check that server first. This narrows down the cause more effectively than repeatedly reinstalling the app.
For transports that rely on UDP, such as Hysteria2, a single TCP port test can’t determine whether the protocol works. Likewise, a successful TCP test doesn’t prove that UDP is available. Record the test method separately from the protocol in use so you don’t confuse the two results.
3. Check the address, port, and authentication settings for each protocol
On Home, open the selected server’s edit screen and compare each field with the original details from your provider. Imported subscription servers can also become outdated after remote changes. First confirm the subscription updated successfully, then check the settings. Don’t change every port to 443 based on guesswork or disable certificate verification just to clear an error.
- Shadowsocks: Check the address, port, Password, and encryption method. The connection will fail if the password is correct but the encryption method doesn’t match. Any additional plugin settings required by your provider must also match.
- VMess: Check the UUID, authentication settings required by the server, and transport. For WebSocket, also verify Host, Path, and TLS settings; copying the UUID alone isn’t enough.
- VLESS: Check the UUID, transport, and any TLS, REALITY, or Flow settings explicitly provided by your provider. Don’t mix fields from different security modes.
- Trojan: Check Password, port, and TLS settings. Enter the hostname provided by your provider as SNI, without a scheme, port, or path. The connection address and SNI can differ, but don’t substitute one arbitrarily.
- Hysteria2: Check the authentication details, TLS, and any obfuscation settings required by your provider. Also confirm that the current network allows the required UDP traffic. TCP reachability alone isn’t enough.
- WireGuard: Check the configuration, including the local private key, peer public key, Endpoint, and tunnel address. WireGuard doesn’t use a TLS SNI field, so don’t apply the Trojan troubleshooting checklist.
TLS SNI and the WebSocket Host are different things: SNI identifies the service during the TLS handshake, while Host is an HTTP request field. They may be the same, but check each against your provider’s details. A server name is only a local display label; renaming it won’t fix authentication or connection failures.
4. Use the exact error message to identify where the connection fails
Check the log or system error details for the failed connection, and keep the exact error text and timestamp. These are common network- and TLS-level errors; prefixes vary by platform and connection stage. If the interface only shows Timeout, use the network comparison tests above to narrow down the cause.
Error: connection timed out
Cause and fix: The connection didn’t receive the expected response in time. The address, port, network path, or remote service may be at fault. Retest the same server on another network, then ask your provider to confirm that the endpoint is still valid.
Error: connection refused
Cause and fix: The destination or an intermediary actively rejected the connection. Check the port and protocol rather than simply increasing the timeout. If the port is correct, ask your provider to check that the service is listening.
Error: certificate has expired or is not yet valid
Cause and fix: Your device time may be incorrect, or the server certificate may genuinely be outside its validity period. Correct the system time and try again. If the error persists, ask your provider to check the certificate; don’t leave verification disabled as a workaround.
Error: no such host
Cause and fix: The hostname couldn’t be resolved, or no usable DNS record was returned. Check the address for typos, confirm that your local network works, and identify whether the failed lookup is for the server hostname or the destination website.
Don’t assume EOF in a log means “wrong password.” It only indicates that the connection ended, which can happen for several reasons, including mismatched authentication, incorrect transport settings, or the remote side closing the connection early. Check the surrounding TLS, DNS, and connection details before deciding which setting to change.
5. Check system time and automatic time settings
An inaccurate system clock can affect certificate validity checks and some authentication processes. Check whether the device’s current time is correct, not just which time zone is displayed. Manually changing the time zone doesn’t replace time synchronization. After enabling automatic settings, confirm that the date, year, and time are actually correct.
- iPhone / iPad: Open “Settings → General → Date & Time” and turn on “Set Automatically.” If the option is unavailable, check device management or system restrictions, then reconnect in Shadowrocket.
- Mac: Open “System Settings → General → Date & Time,” enable automatic date and time, and confirm that the displayed time is correct.
- Windows: Open “Settings → Time & language → Date & time,” turn on automatic time, and use the system’s Sync now option.
- Android: Search Settings for “Date & time” and turn on automatic time. Menu names vary by device; also check the automatic time zone setting.
- Linux: Turn on network time synchronization in the system’s date and time settings. If there’s no graphical settings page, ask the device administrator to check the time synchronization service.
6. If the connection is established, check Global Routing, DNS, and On Demand
If a server is reachable but websites fail, check Home → Global Routing. Proxy sends traffic handled by the proxy through the selected proxy; Direct connects without a proxy; Config routes traffic according to the active configuration. Scene uses the selected scene’s settings, so check those rules too. For troubleshooting, briefly compare Proxy and Config, then restore your usual setting.
- Proxy works, but Config fails: Open Config and check the active configuration and rule order. DOMAIN-SUFFIX matches domain suffixes; GEOIP and IP-CIDR match by IP criteria; FINAL handles connections that don’t match an earlier rule.
- Both Proxy and Config fail: Go back to checking the endpoint, protocol, and DNS rather than changing FINAL alone. If the server hostname can’t be resolved, the connection can’t start. A failed lookup for the destination hostname may occur after the tunnel is established.
- The connection turns back on after you turn it off: Check Settings → On Demand and its existing conditions. While troubleshooting, temporarily disable automatic connection triggers so they aren’t mistaken for a manual action that didn’t work. Restore the settings you need afterward.
- Connection fails after waking from sleep or switching networks: Record the network type before and after reconnecting, then disconnect and reconnect manually. If the issue occurs only under a particular trigger, check the corresponding On Demand setting.
Rules are evaluated from top to bottom, and the first matching rule affects what happens next. Don’t just check whether the domain appears in the file; see whether an earlier rule matches it first. If only one website fails, noting its domain and the policy actually applied is more useful than replacing the entire Config.
7. Common questions and what to record before reporting an issue
The subscription update also times out. Does that mean all my servers are down?
No. Downloading a subscription and connecting to a server use separate request paths. First check whether your existing servers work, then verify that the subscription URL is valid and check for expiration or access restrictions. Get the URL from your provider. After a successful update, compare the server settings to see whether they changed.
Latency is low, but video keeps buffering. Why?
Latency measures the response time of a single test; it doesn’t measure sustained throughput. Keep the destination the same and compare other servers you already have and another network. Also check whether only that website is affected. Don’t choose a server based only on the lowest latency.
If disabling certificate verification lets it connect, is the problem fixed?
That doesn’t mean the problem is fixed. Turn certificate verification back on and check system time, SNI, and the server certificate. If your provider requires special trust settings, ask them to explain the certificate source and correct configuration rather than ignoring the error long term.
Should I send my full subscription link and logs?
Don’t share a full subscription URL, password, UUID, or private key publicly. When reporting an issue to your provider, include the time of the failure, platform, network type, protocol, exact error text, and only the necessary redacted logs. Hide authentication details before sharing screenshots.
Keep a brief record of the time and time zone, device platform, Wi-Fi or mobile data, whether one or all servers failed, the current Global Routing option, the exact error, and the result after switching networks. Back up your existing configuration before resetting or reinstalling. Reinstallation won’t fix server downtime, incorrect credentials, or an invalid certificate.