A timeout in Shadowrocket does not necessarily mean the remote server is at fault. For users with their own provider and subscription details, this guide distinguishes network reachability, protocol authentication, TLS verification, and device time issues, then checks routing and subscription updates. Change one thing at a time and record the test method, network type, and exact error to see whether a change helped.
1. Keep test conditions consistent and distinguish test results from actual connections
In Home, run Connectivity Test for the selected entry, then try accessing the same destination. The latency result reflects only the route and method used for that test; it does not by itself confirm that protocol authentication, the TLS handshake, and access to the destination are all working. A TCP connection may be established but fail during authentication; a timeout in one test does not prove that all traffic is blocked.
While troubleshooting, don’t refresh subscriptions, switch configurations, change DNS, and change networks all at once. Even if the connection recovers, you won’t know why. First save a copy of the configuration in use and note the entry name, protocol type, and Global Routing mode. Never include passwords, UUIDs, private keys, or full subscription URLs in public reports.
-
Keep the network fixed
Stay on the same Wi-Fi network and confirm that regular internet access works. If the network requires web-based sign-in, complete it first. Don’t switch to cellular data yet.
-
Keep the entry fixed
In Home, select one of your entries and note its Type, address, and Port. Don’t switch entries or change multiple settings at once.
-
Record the test
Run Connectivity Test in Home and record the method, result, and time. Use the same method for repeat tests; don’t compare results from different test methods.
-
Check connection triggers
Go to Settings → On Demand and note the current conditions. If automatic connection interferes with manual testing, temporarily turn off On Demand, then restore the original setting when you’re done.
-
Reproduce the issue once
Return to Home, turn on the connection, and visit the same destination. Note whether the switch stays on, an error appears immediately, or only one website fails.
2. Identify the likely failure point from latency results and exact error messages
If the latency test consistently times out, first check the address, port, and network path. If the test returns a result but an actual connection drops immediately, focus on protocol settings and TLS. If only one website fails, first check which policy handled the request instead of rebuilding every entry. The examples below show common network errors; the full message in the app may include an address, port, or contextual prefix.
Error: Connection timed out
What it means: The operation did not complete before the deadline. The cause may be the network path, the remote response, or the handshake; this message alone doesn’t identify which end is at fault.
What to do: Check the address and Port. Without changing other settings, switch between Wi-Fi and cellular once, then compare results from the same test method.
Error: Connection refused
What it means: The connection request was actively rejected. This commonly happens when nothing is listening on the target port or a network device rejects the connection; it is not direct evidence of an incorrect password.
What to do: Compare the Port with the information from your provider. If they match, ask whether that address and port are still in use.
Error: certificate has expired
What it means: The certificate validity check failed. The remote certificate may have expired, or the device date may be significantly out of sync.
What to do: First check automatic time setting on your device. If the time is correct, ask your provider to check the certificate; don’t disable certificate verification as a substitute for fixing the issue.
If switching networks fixes the issue, that only indicates a network-path difference; it doesn’t prove that a particular carrier is responsible. If both networks fail, incorrect settings are still possible. Record whether one network fails, both networks fail, or only a specific destination fails, then continue troubleshooting.
- All entries fail: Check the device’s basic internet connection, network sign-in, current routing mode, and system time.
- Only one entry fails: Check that entry’s address, port, credentials, and remote status first.
- Only certain apps fail: Check whether their requests use TCP or UDP and whether they match the expected policy.
3. Check Type, Port, and protocol-specific settings
In Home, open the selected entry for editing and compare it with your original connection details. Type must match the remote configuration; don’t change VMess to VLESS just to troubleshoot. Enter only the address required for that field. Don’t paste a full share link, webpage path, or text with extra spaces into it.
Port is the port the remote service actually listens on; it isn’t a value you can replace based on guesswork. For example, if the original configuration specifies 8443, don’t change it to 443 just because TLS is enabled. These numbers illustrate how protocols and ports relate; they do not identify a service you can connect to.
| Type | Check these settings | Common misdiagnosis |
|---|---|---|
| Shadowsocks | Address, Port, encryption method, and password; if a plugin is used, check its settings too. | Changing only the password and overlooking a mismatch between the encryption method and the remote configuration. |
| VMess / VLESS | UUID, transport, and any TLS, Host, Path, or other fields required by the original configuration. | Assuming a correct UUID is all that’s needed and missing transport settings. |
| Trojan | Password, TLS, Server Name, and the transport specified in the original configuration. | Entering the password in the wrong authentication field or omitting the domain associated with the certificate. |
| Hysteria2 | Authentication details, TLS, Server Name, and the UDP path. | Assuming the UDP path must work because a TCP test succeeded. |
| WireGuard | Local private key, peer public key, Endpoint, address, and routing settings. | Reversing the key roles or checking Endpoint but overlooking routing. |
Not every protocol uses every field in this table. Check only the fields that appear for the selected Type and are required by your original connection details. If the entry comes from your own subscription, record any local changes before updating. After the update, check the edit screen again to make sure an older subscription value hasn’t overwritten your correction.
4. Check TLS, Server Name, and system time
If TLS fails, first check the TLS settings and Server Name (SNI) on the entry’s edit screen. The connection address can be an IP address while the certificate is issued to a domain name. In that case, enter the Server Name from the original configuration instead of copying the address field. The name used for certificate verification and the Host used in a network request are separate fields and shouldn’t be swapped arbitrarily.
If you use WebSocket, Path and Host must match the remote requirements. Path capitalization, the leading slash, and any query parameters can affect the request. Don’t add a path just because it looks familiar, and don’t guess at fields the remote configuration doesn’t require.
- On the entry’s edit screen, compare TLS, Server Name, transport, Host, and Path with the original configuration. Save your changes, then test the same destination again.
- On your iPhone or iPad, open Settings → General → Date & Time. Check Set Automatically and confirm that the date, time, and time zone are correct.
- If Set Automatically is unavailable, check device management restrictions or system settings. Don’t set the date back to a time when the certificate was valid to bypass the error.
- Reconnect after correcting the time. If the device time is correct but the certificate is still expired or the name doesn’t match, keep the exact error message and ask your provider to check the certificate configuration.
5. Distinguish routing, DNS, and subscription update issues
Once you’ve checked the settings and TLS, go to Home → Global Routing. Proxy, Direct, Config, and Scene are different traffic-handling modes, not four latency test methods. You can temporarily use Proxy to verify the selected proxy route during troubleshooting. Restore the original mode afterward; a temporary switch isn’t a permanent fix.
- Proxy: To verify the proxy route, confirm which entry or policy group member is actually selected so you’re testing the intended one.
- Direct: Primarily tests the direct connection path. A successful connection in this mode doesn’t prove that a proxy entry is configured correctly.
- Config: Check the active configuration in Config and see whether an earlier rule matched the request.
- Scene: Check the specific settings for the selected Scene. Don’t assume its results will match Proxy or Config.
In Config, DOMAIN-SUFFIX, IP-CIDR, and GEOIP rules use different matching conditions; FINAL applies only when none of the preceding rules match. Rules are checked in order. If an earlier DIRECT or REJECT rule already handled a domain, changing a later FINAL rule won’t affect that request. Check the actual request record before changing rules, and don’t delete the entire configuration because one website won’t open.
Check DNS separately. If a domain fails but an IP address gives a different result, that’s a clue about the resolution path, not a reason to use the IP permanently; TLS may still require the original Server Name. Don’t change DNS, SNI, and the address all at once, or you won’t know which change made the difference.
Why does the website still fail when the latency test returns a number?
Record the Connectivity Test method, then visit the same destination. Check Global Routing and the matching policy. A successful test may confirm reachability at only one stage; it doesn’t cover authentication, TLS, and the full response from the destination.
Why does subscription updating time out when an existing entry works?
A subscription update connects to the subscription URL, not to the service port used by an existing entry. In Home, refresh your subscription and check that its URL is still valid. If an existing proxy connection works and the subscription URL requires that route, check Update via Proxy in Settings → Subscribe, then try again.
Wi-Fi times out, but cellular works. Should I re-enter the password?
Don’t change the password yet. Keep the same entry and test method, then check Wi-Fi sign-in, network restrictions, and UDP reachability. If only one network fails, leave the settings unchanged and investigate differences in the network path first.
It reconnects every time I turn it off manually. How can I test it consistently?
Check the automatic connection conditions in Settings → On Demand. Note them, temporarily turn off On Demand, then return to Home and test manually. Restore the conditions you need when troubleshooting is finished so automatic triggers don’t alter the test state.
6. If the issue persists, provide a concise troubleshooting report
If the issue persists after these checks, send your provider a concise report that reproduces the problem; this is more useful than simply saying “it won’t connect.” Specify whether the error occurred during a subscription update, Connectivity Test, or actual access, and what you changed most recently. Include only the relevant portion of the log around the time of the issue, not your entire configuration.
- Environment: Device type, system version as shown on the device, Wi-Fi or cellular network, and whether automatic time setting is working.
- Entry: Protocol Type, a redacted entry identifier, and Port. Don’t include passwords, UUIDs, private keys, or subscription tokens.
- What happened: Exact error message, time, test method, and differences before and after switching networks.
- Routing: Global Routing mode, active configuration or Scene, and the policy confirmed to have matched.
- Steps taken: Results of checking the settings, whether TLS and Server Name match, and whether reconnecting after correcting the time helped.
After the connection recovers, re-enable the original On Demand conditions, restore your usual Global Routing mode, and test the same destination again. Keep changes that worked and undo temporary diagnostic settings. Don’t leave certificate verification disabled or keep an unverified address replacement.