This guide is for users who have imported their own provider configuration into Shadowrocket but are seeing node timeouts or pages that won’t load. Troubleshoot in order: network basics, test methods, protocol settings, system time, and routing rules. Change one thing at a time to distinguish an unreachable server from authentication failures or requests taking an unexpected route. Get subscription links from your provider.
1. Tell node timeouts, connection failures, and page timeouts apart
A “timeout” means only that an operation didn’t finish within the allotted time; it doesn’t necessarily mean the password is wrong or the server is offline. The latency test in Home, establishing a proxy protocol connection, and loading a webpage through the proxy are three separate checks. A connected VPN status means only that the system tunnel is active; it doesn’t confirm that the remote server has authenticated successfully.
First note which stage fails, then choose the relevant settings to check. The table below explains how to interpret results; it does not report measurements from any particular node. A latency value alone does not prove that a service is working.
| What you see | What it may indicate | Next step |
|---|---|---|
| TCP test returns a value, but pages still fail to load | The test port may be reachable, but that doesn’t confirm protocol authentication or a successful TLS handshake | Check Type, password, TLS, and SNI |
| ICMP test times out, but webpages work | The server or network path may not respond to ICMP | Cross-check with TCP or an actual request |
| All nodes time out on the same Wi-Fi network | The issue may involve that network’s egress, authentication, or transport restrictions | Complete network authentication, then compare with cellular data |
| Only one website fails to load | Check the destination, DNS, or the rule matched for that site | Check the policy and error in the request log |
2. Set up repeatable tests from Home
Don’t start by deleting all your configurations. Note the currently selected node, the Global Routing mode, and the network you’re using. Keep a copy of the original configuration so you can restore it. During testing, stick to the same node and destination page. Repeat each test three times; the number of successful attempts is more useful than a single latency reading.
-
Check the base network
Turn off the connection switch in Home, then confirm that your iPhone can reach a known working website over Wi-Fi or cellular data. If public Wi-Fi requires a sign-in, complete it before testing the proxy.
-
Use the same test node
Return to Home and select a node you already have. Open its editor to check the server address and port. Don’t update a subscription, switch nodes, and change DNS at the same time, or you won’t know which change made a difference.
-
Check the test method
Go to Settings → Connectivity Test and check the selected method. For a TCP test, make sure it targets the node’s actual port. Then run the test from Home and note the method and result.
-
Test an actual request
In Home → Global Routing, temporarily select Proxy, turn on the connection switch, and visit the same destination page. Restore the original mode when you’re done. Proxy helps rule out routing rules, but it won’t fix incorrect node settings.
-
Retest on another network
Keep the node and its settings unchanged, then repeat the test over Wi-Fi and cellular data. If the difference is consistent, note the network type and time. If only one network fails, investigate that network first instead of changing every protocol setting.
Takeaway: First check whether the failure occurs on multiple networks
If the same node times out on only one network, keep the configuration and check the network path first. If it fails on both, move on to the port, authentication, and provider-side status. This helps avoid mistaking a local network issue for a broken configuration.
3. Check the port, password, TLS, and SNI for the selected Type
In Home, open the node editor and compare each field with the configuration from your provider. The server address, port, and authentication fields must all come from the same configuration. Port 443 doesn’t necessarily mean “TLS is enabled,” and port 8443 isn’t necessarily wrong. Use your provider’s settings to determine whether TLS is enabled and which transport method to use.
| Protocol or field | What to check | Common misinterpretation |
|---|---|---|
| Shadowsocks | Server, port, encryption method, and password | Assuming the password is correct because the port is reachable |
| VMess / VLESS | UUID, provider-required transport settings, and TLS options | Copying the UUID but missing Host, Path, or other required settings |
| Trojan | Password, TLS, and the SNI specified by your provider | Entering the connection address in every domain field |
| Hysteria2 | UDP path, authentication details, TLS, and obfuscation settings (if applicable) | Using a TCP port test to determine whether a UDP-based protocol works |
| WireGuard | PrivateKey, PublicKey, Endpoint, Address, and allowed IP ranges | Blaming a failed handshake on TLS or SNI |
TLS SNI specifies the server name during the handshake, and certificate validation must match the corresponding identity. The connection address may be an IP address while SNI is a domain specified by your provider; they don’t have to match. WebSocket Host and Path are separate fields and aren’t substitutes for SNI.
- Check that the password or UUID has no leading or trailing spaces, line breaks, or full-width characters. Copy the original value again rather than trying to guess it character by character.
- After updating a subscription, make sure you’re editing and testing the same node. Don’t mix an old node with new settings.
- If certificate validation is required, don’t disable it as a routine fix. Check SNI, the certificate’s validity period, and system time. Your provider must address certificate issues on the server.
- Troubleshooting WireGuard differs from troubleshooting TLS-based protocols. Don’t apply SNI settings to protocols that don’t use TLS.
4. Narrow down the issue using the exact error message
If a connection record or log contains one of the errors below, use it to guide your next checks. Wording can vary by protocol and system, so keep the complete message and the time it occurred. Don’t label every similar-looking error a “node timeout.” Before sending logs to your provider, redact subscription credentials, passwords, UUIDs, and private keys.
Error: Connection timed out
Cause and fix: The connection didn’t complete within the allotted time. Possible causes include packet loss along the network path, a filtered port, or an unresponsive server. Keep the node fixed and retest on another network, then ask your provider to check the server and port status.
Error: Connection refused
Cause and fix: The connection was actively rejected, often because nothing is listening on the port or the device refused it. Check whether the port is still valid; repeatedly increasing the timeout won’t fix the issue.
Error: No route to host
Cause and fix: The current network path can’t reach the destination address. The issue may involve routing or the address family. First confirm that your local network works, then compare results on Wi-Fi and cellular data.
Error: certificate has expired
Cause and fix: The certificate is considered expired based on the device’s current time. Correct the system date and time first. If the error persists with the time set correctly, ask your provider to check the certificate’s validity period.
Errors also have an order. A DNS resolution failure occurs before the connection to the server, so changing the password usually won’t help. A TLS handshake failure occurs after the underlying connection is established, so check TLS, SNI, and the certificate first rather than arbitrarily changing the port to 443.
5. Check your iPhone’s system time and automatic reconnection
A substantially incorrect system time can affect TLS certificate validity checks and authentication in protocols that rely on time validation. A webpage displaying the correct date doesn’t confirm that the system settings are correct. Check this especially if you changed the date manually, were offline for an extended period, or recently restored your device.
- On your iPhone, open Settings → General → Date & Time, turn on Set Automatically, and check that the current date and time are correct. If device management restricts this option, first identify the source of the restriction.
- Return to Shadowrocket, turn off the connection switch in Home, then reconnect and test so the new connection uses the corrected time.
- If the connection comes back automatically after you disconnect it, go to Settings → On Demand. Note the current settings, temporarily turn off On Demand, then run a basic network test.
- Restore any On Demand settings you need after troubleshooting. On Demand controls when connections are established; it won’t fix a server password, certificate, or port.
6. If the node test works, check routing and subscriptions
If the node connects but webpages still fail, check Home → Global Routing. Proxy sends proxy-capable requests through the selected proxy route; Direct connects directly; Config routes traffic according to the current configuration rules; Scene uses the selected scene’s settings. If you normally use Config, temporarily switch to Proxy for comparison, then restore Config and check which rule matched.
In Config, check the configuration you’re actually using, not just the file you’ve just imported. Rules are matched in order: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP address ranges, GEOIP matches against an IP geolocation database, and FINAL handles requests that don’t match earlier rules. An earlier DIRECT or REJECT rule may prevent a request from using the current node at all.
- Proxy works, but Config fails: Check the rule and policy actually matched by the failed request. Pay particular attention to earlier DIRECT and REJECT rules and the policy assigned to FINAL. Don’t delete the entire ruleset.
- Only domain names fail: Check for DNS resolution errors and whether the destination domain matches the expected rule. Don’t replace a domain test with the IP address from an HTTPS URL; the certificate identity may not match.
- The node list still shows old entries: Return to Home and update the relevant subscription. Once the update succeeds, select the node again. A successful subscription update confirms only that the configuration was retrieved; it doesn’t mean every server is available.
- The subscription update also fails: First determine whether fetching the link failed or the node connection failed. A subscription may have its own expiration date and access requirements. Get a valid link from your provider and check your account status.
Why won’t a webpage load when latency is only a few dozen milliseconds?
Latency reports only the result of a specific test; it doesn’t confirm that authentication, TLS, and access to the destination website all work. Temporarily select Proxy in Home → Global Routing and test an actual request, then check the node settings. If only Config fails, investigate the rules.
All nodes time out. Should I import them all again?
Don’t delete everything at once. Turn off the connection and confirm that the base network works. Check whether Settings → On Demand affects the disconnected state, then retest the same node on another network. Update your subscription only if you’ve confirmed that the configuration is expired or incorrect.
What should I do if Wi-Fi works but cellular data times out?
Keep the same node, Global Routing mode, and destination page. Repeat the test three times and record the results. Check whether the app is allowed to use cellular data. If only UDP-based protocols fail, give your provider the network type and protocol details so they can check for path restrictions.
What if the certificate still appears expired after correcting the time?
Reconnect, save the complete certificate error, and check the SNI specified by your provider. If the system time is correct and the error persists, ask your provider to check the certificate and certificate chain. Don’t bypass certificate validation instead of addressing the problem.
7. Keep reproducible records before contacting your provider
After completing these checks, send your provider a set of reproducible details rather than just a screenshot saying “timeout.” Your records should help distinguish a network issue from incorrect settings or a routing problem, without exposing authentication details.
- When it happened, your time zone, whether your iPhone’s system time was set automatically, and whether you were using Wi-Fi or cellular data.
- The node’s protocol, port, test method, and number of successful attempts out of three. Don’t send your password, full subscription link, or PrivateKey.
- The Global Routing mode, whether Proxy and Config produced different results, and whether only one destination website was affected.
- The exact error, which stage failed, and each individual change you tried. Note whether the issue also occurs after switching networks.
Buying the client and getting a connection service from a provider are separate things. Shadowrocket is a closed-source commercial app available as a one-time purchase through the App Store; buying the app does not include a service plan. The app is primarily for iPhone and iPad. Compatibility with Mac, Apple TV, and Apple Vision, along with system requirements, is as listed on the App Store page. Reinstalling the app usually won’t resolve a remote port, credential, or certificate issue. Diagnose the cause first and keep your original configuration.