A Shadowrocket connection timeout does not necessarily mean the server is offline, and a latency result does not guarantee that web requests will succeed. This guide is for users who already have their own provider and subscription. It narrows down the cause by checking the network, latency test, protocol settings, system time, and actual requests—in that order. Change one setting at a time, and keep the exact error and test time so you can document a reproducible issue instead of reinstalling the app or changing the entire configuration at once.
1. Identify the scope of the issue and record the details
First, distinguish between three issues: a failed subscription update, a failed server test, and a web page that will not load after connecting. These can occur at different stages. A subscription update retrieves configuration data; a server test runs the selected test; and web access also depends on routing, DNS, the protocol handshake, and the destination website. A single “timeout” does not mean all three are the same problem.
Before troubleshooting, note the selected server name in Home, the Global Routing option, and the action that triggers the error. Keep the existing configuration in Config; do not clear the rules first. If Settings → On Demand is enabled, note that too. When disconnecting manually for comparison, make sure an existing condition will not immediately trigger a new connection.
- Check the basic network connection: Disconnect temporarily and make sure your current Wi-Fi or cellular network can open a page that normally works without a proxy. If Wi-Fi requires a sign-in, complete it first.
- Use the same test server: Choose one of your existing servers and use it for all subsequent checks and tests. This keeps results from different configurations separate.
- Record the exact result: Note whether the test timed out, the connection switch would not stay on, or only a specific app request failed. Keep the complete error message.
- Change one thing at a time: After each change, repeat the same test. If it does not help, restore the setting before moving on.
2. Understand latency tests: a response time does not prove the connection works
Check which test is being used before interpreting the result. A TCP handshake checks whether the address and port are reachable, but it does not verify authentication for the full proxy protocol. An HTTP request sent through the server tests more steps, including the test destination itself. The results measure different things, so do not compare them directly or treat either value as download speed.
In Home, run the current test on the same server several times and note whether the results are consistent. If the app offers different test methods, record which one you used. Three tests are suggested here for troubleshooting; this is not an app requirement. The goal is to distinguish persistent failures from occasional variation.
Next step: check the protocol handshake after confirming port reachability
If TCP tests consistently get a response but requests through the server consistently fail, check authentication, TLS, and transport settings first. Do not switch servers based only on the latency result. A successful TCP test means only that the test established a TCP connection; it does not prove the server accepts the current protocol settings.
If the same configuration fails on Wi-Fi but works on cellular, the difference points first to the network path or a restriction on that network, but it does not confirm the specific cause. If both networks fail, that does not prove the server is offline. Check for an incorrect address, expired credentials, DNS resolution issues, and a protocol mismatch one by one.
3. Verify the address, port, and protocol settings—do not guess
Open the current server’s edit screen from Home and compare each field with the original configuration from your provider. Check that the protocol type matches, then verify the address and port, followed by authentication, TLS, and transport fields. A successful subscription import means the client received and parsed the data; it does not mean every server in it can connect.
| Item | What to check | Common misinterpretation |
|---|---|---|
| Address and port | The domain name or IP address must match the original configuration, and the port must be complete. If the original specifies 443, keep it as 443. | 443 is a common example, not a universal fix. Do not change the port to 443 just because the connection fails. |
| Shadowsocks | Verify the encryption method and password. If the configuration includes additional plugin parameters, make sure they match too. | Even with the correct address and port, the server may not work if the encryption method or password is wrong. |
| VMess / VLESS | Verify the UUID, applicable protocol options, and related fields such as transport type, path, and Host. | Do not apply a set of fields for one protocol to a different protocol. |
| Trojan | Verify the password, TLS settings, and the SNI required by the server. | The connection address may differ from the domain name on the certificate. Do not infer the SNI from the address alone. |
| Hysteria2 | Verify the authentication details, TLS, and any applicable obfuscation settings. Make sure the network path allows the required UDP traffic. | A standard TCP test alone cannot determine whether a QUIC-based connection will work. |
| WireGuard | Verify the keys, peer address and port, tunnel addresses, and routing scope in the configuration. | It runs over UDP. A TCP port test cannot replace a handshake check or verification of actual traffic. |
When using a domain name, check whether it resolves to the correct address. Do not replace it with an IP address just to bypass DNS; this can change which server endpoint is selected and affect TLS hostname verification. In configurations using WebSocket, the path, Host, and TLS SNI each serve a different purpose. Do not substitute one for another just because they all look like domain names.
- When copying a password, UUID, or key, check for leading or trailing spaces, line breaks, and truncation. Do not try to guess characters from a screenshot.
- If your provider confirms that the settings have changed, keep the existing configuration first, then update the relevant subscription. After updating, verify which server is actually selected.
- If a subscription update fails, first check that the link is valid and reachable on your current network. Do not delete your only working configuration first.
- Do not disable certificate verification to hide a TLS error. Check the system time, SNI, and certificate status first.
4. Check your iPhone’s date and time before investigating TLS errors
An incorrect date, time, or time zone on your iPhone can affect certificate validity checks and authentication processes that rely on time. Certificates have validity periods; if the device clock is significantly off, the handshake may fail even when the address and password are correct. This is not the cause of every timeout, but it is an easy item to check.
- On your iPhone, open Settings → General → Date & Time and check whether Set Automatically is enabled.
- Make sure the displayed date, local time, and time zone are correct. If the setting is unavailable, check device management or restrictions; do not remove a management profile without a reason.
- Return to Shadowrocket, disconnect, reconnect to the same server, and run the same test again.
- If the error still relates to TLS, send the exact error and time it occurred to your provider. Ask them to check the server certificate, certificate chain, and domain settings.
Correct system time is only one check; it will not fix an expired certificate, a hostname mismatch, or an incorrect server configuration. The messages below describe common network errors. Use the relevant guidance only if that exact text appears in your logs; wording can vary by system and failure stage.
Error: Connection refused
What it means and what to do: The destination or an intermediary explicitly rejected the connection. The port may not be listening, or a policy may be blocking it. Check the address and port, then ask your provider to verify the listener and access policy.
Error: Operation timed out
What it means and what to do: The operation did not complete within the allowed time. This message alone cannot distinguish packet loss, a network restriction, or an unresponsive server. Note whether the failure occurred during a test or an actual request, then compare results on another network.
Error: certificate has expired
What it means and what to do: The certificate validity check failed. First correct the device time. If the time is correct, ask your provider to check the certificate renewal and the certificate chain being served.
5. Connected but pages still will not load? Check Global Routing and rule matches
An active connection does not mean every request is going through the current server. Home → Global Routing controls the overall routing mode: Proxy routes traffic through a proxy, Direct connects without one, Config follows the current configuration, and Scene selects a routing mode based on the configured scene. Note the current option before troubleshooting; checking the server name alone is not enough.
To isolate the effect of rules, you can briefly select Proxy and send a request to the same destination, once you have confirmed the scope of the test. This changes how other requests are routed during the test, so understand the impact before proceeding. If the request works with Proxy but fails with Config, check the active configuration in Config and the policy actually matched by the request instead of changing the password again.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXYThis example explains match order; it is not a complete configuration. DOMAIN-SUFFIX matches domain suffixes, GEOIP checks the geographic location associated with an IP address, IP-CIDR matches an address range, and FINAL handles requests that did not match an earlier rule. Rules are evaluated in order. 192.0.2.0/24 is a documentation example range; do not use it to change real-world routing. Make sure the policy names are valid in your own configuration.
- Only one domain fails: Check the request’s domain, its resolved address, and the matched policy. Also rule out an issue with the destination website.
- All requests through the server fail: Recheck the protocol settings and handshake. Do not broaden the scope of rule changes.
- Web pages work, but a specific service does not: Check whether it depends on UDP, additional domains, or different ports. A standard web page test does not cover every transport requirement.
6. Common questions and what to include in a troubleshooting report
Why can I get a latency result but still fail to connect?
First check which test produced the result. If only the TCP handshake succeeded, verify authentication, TLS, transport type, and path. Then make an actual request through the selected server. Port reachability does not prove protocol authentication succeeded.
All my servers time out. Should I reimport the subscription first?
Disconnect and check the basic network first, then compare the same server over Wi-Fi and cellular. Update the subscription only if your provider confirms that the settings have changed or the subscription data is incorrect. Keep the existing configuration for comparison.
Why does the connection turn back on after I disconnect?
Check Settings → On Demand and any existing trigger conditions. If you need to test manually, you can temporarily turn off On Demand and restore its previous state afterward. This setting controls when a connection starts; it does not fix an incorrect address or password.
What if certificate errors persist after I correct the system time?
Keep certificate verification enabled and check that the server’s SNI matches your provider’s requirements. Send the exact error and the time it occurred, and ask your provider to check the certificate validity period, certificate chain, and endpoint domain. Do not keep trying different domain names.
When reporting an issue, include details that identify the stage of failure; this is more useful than simply saying “it doesn’t work.” Organize the information as follows. You can anonymize the server name, but authentication fields should not be included in a public report.
- Environment: Device type, system information, Wi-Fi or cellular network, and the local time and time zone when the issue began.
- Tests: Test method, three results for the same server, and whether switching networks changed the outcome.
- Configuration: Protocol type, port, current Global Routing option, and whether On Demand is enabled.
- Symptoms: The complete error message, the step where the failure occurred, and whether all requests or just one destination are affected.
- Privacy: Redact subscription URL tokens, passwords, UUIDs, private keys, and other authentication details. Do not share the full configuration.
Following these checks should narrow the issue down to one of these areas: basic network access, server reachability, the protocol handshake, device time, or request routing. Once you identify the affected layer, change the relevant setting. After a successful retest, restore any temporary changes so troubleshooting settings do not become your everyday configuration.
Verify the App Store listing
Shadowrocket is a paid client for Apple platforms, available exclusively through the App Store. Before purchasing, check that the developer is Shadow Launch Technology Limited and the app ID is 932747118. The app is a one-time purchase; buying the client does not include a service subscription. Check the App Store listing for system requirements. For initial setup, see Getting Started.