A timeout in Shadowrocket does not necessarily mean the remote service is down. This guide is for users who already have a provider and configuration. First, use the same test method to distinguish a single-node issue from a network or destination-site issue. Then check the address, port, authentication, transport, and TLS, followed by system time and routing. Change one setting at a time, and keep the original configuration and test results so troubleshooting does not introduce new errors.
1. Distinguish a latency-test timeout from a connection failure
A latency test only covers the probe it actually performs; it does not confirm that every website and protocol is working. A successful TCP handshake usually means only that the target TCP port is reachable—it does not verify the password, UUID, or subsequent TLS handshake. Results from a test URL accessed through a proxy also depend on the test URL, DNS, and the remote exit. Record the test method before comparing results, and do not rank latency values from different test methods together.
The scenarios below are for interpreting results, not measurements performed by this site. Enter the results from your own device. Test at least three times, keeping the method, node, and network unchanged.
| What you see | What it may indicate | What to check next |
|---|---|---|
| Only one node times out three times in a row | The issue is more likely with that node or the route to it | Check the node's address, port, and protocol settings |
| All existing nodes time out | There may be a shared network, DNS, or configuration issue | Check that the internet works, then retest on another network |
| Port test returns a result, but webpages fail | A reachable port does not mean proxy authentication succeeded | Check authentication, TLS, transport, and routing |
| Webpages work, but the test times out | The test target or method may not suit the current connection | Check the test settings; don't rebuild the node yet |
| Only one website fails | That alone does not mean the entire node is down | Check the domain's rules, DNS, and the destination site's status |
Takeaway: Keep the test conditions consistent
Test the same node three times using the same method, then retest after changing only the network. Don't change protocol settings and rules at the same time, or you won't know which change affected the result.
2. Run a controlled retest, step by step
This guide uses the Home, Config, and Settings labels in the iPhone and iPad interface to point out where to troubleshoot. On other platforms, check the equivalent settings. Save a copy of your current configuration first. Keep separate records of existing subscriptions and manually edited nodes, and never delete the entire list without a backup.
-
Confirm that the internet works
Turn off the connection on Home and use a browser to visit a site you can normally access directly. If basic internet access also fails, troubleshoot Wi-Fi sign-in, cellular data permissions, or your router connection first. Don't start by changing the node password.
-
Choose a fixed test target
Go to Home, select a node you already have, and record the test method and three consecutive results. If you use Connectivity Test, check its test settings first. Keep the test target unchanged throughout the retest.
-
Switch the network
Keep the same node and test method, switch from Wi-Fi to cellular, and test again. If the issue occurs on only one network, first check whether that network affects port access, UDP, or DNS resolution.
-
Check automatic connection
Go to Settings → On Demand and record the current setting. If the connection comes back automatically after you disconnect it manually, you can temporarily turn off On Demand while troubleshooting. Restore the original setting after the comparison test.
-
Record the retest results
Note the network type, node name, test method, time, and exact error text. Change one field at a time, save, reconnect, and retest under the same conditions.
3. Check the address, port, authentication, and transport settings
On Home, open the target node for editing and compare each field with the original configuration from your provider. Check the server address and port first, then the protocol and authentication fields, followed by transport and TLS. Don't mistake a configuration name for a server address, and don't change a port just because it is commonly used: port 443 does not necessarily mean the node uses TLS, and 8443 is not a drop-in backup port.
| Protocol or field | What to verify | Common pitfalls |
|---|---|---|
| Address and port | Full hostname or IP address and original port; port range is 1–65535 | A missing character, an extra space, or mistaking another number in the connection address for the port |
| Shadowsocks | Encryption method and password; check plugin settings too if the original configuration includes a plugin | The port is reachable, but the encryption method or password does not match |
| VMess / VLESS | UUID, server-required options, and transport settings | Copying only the UUID and missing the WebSocket path or other transport settings |
| Trojan | Password, TLS, Server Name, and certificate match | The connection IP is correct, but the name used for TLS is wrong |
| Hysteria2 | Authentication, TLS, port, and whether the current network allows the required UDP traffic | Using a TCP test to determine whether UDP is reachable |
| WireGuard | Key, Peer, Endpoint, interface address, and allowed IP ranges | Setting only Endpoint and missing other configuration; swapping the private and public keys |
| WebSocket / gRPC | Transport type and any required Host, Path, or Service Name from the original configuration | Using a WebSocket path as the gRPC Service Name |
The server connection address, TLS Server Name, and WebSocket Host may differ. They are used for the connection, certificate validation, and application-layer request, respectively. Follow your original configuration; don't set them all to the same domain just for consistency. Preserve the full path too—for example, if the original configuration uses /gateway, keep the leading slash and exact capitalization.
- For nodes imported from a subscription, first confirm that the subscription updated successfully, then check whether the local settings are out of date.
- Back up a subscription node before editing it manually; a later update may overwrite its fields.
- Different nodes from the same provider may use different ports, passwords, or transport settings. Don't copy settings from one to another.
- Don't disable certificate verification to hide a TLS error. Check the server name, certificate, and system time first.
4. Tell timeouts, connection refusals, and TLS failures apart
If the connection log shows an error, keep the exact text and the time it occurred. Wording varies across systems and protocols, so the examples below are common network error strings—not lines that every platform will display exactly as shown. A single error term usually isn't enough to identify the cause; compare results across networks as described above.
Error: i/o timeout
What it means and what to do: A network operation did not finish before its deadline. It may involve connecting, handshaking, or reading. Check which stage produced the error, verify the address and port, then repeat the test on another network.
Error: connection refused
What it means and what to do: The connection attempt was explicitly rejected, often because no service is listening on the target port or the connection was actively refused. Check that the port is correct, then ask your provider to confirm the service status on that port.
Error: no such host
What it means and what to do: The server hostname could not be resolved. Check the spelling and DNS resolution on your current network. Don't change the password or replace the original hostname with an IP address found online.
Error: certificate has expired or is not yet valid
What it means and what to do: The certificate's validity period does not match the device's current time. Turn on automatic time first. If the time is correct and the error persists, ask your provider to check the certificate's validity period.
If there's no specific error and the only result is a timeout, fill in the missing test details before assuming authentication failed. Authentication errors, TLS handshake failures, and a nonresponsive remote server can look similar in a simplified status display, but they require different fixes.
5. Check system time and certificate validation
System time is not a common cause of every timeout, but it's worth checking when TLS- or authentication-related connections fail together. Certificates have start and expiration dates, and a device clock that's significantly wrong can cause validation to fail. Some protocol authentication methods also involve time. Changing the time zone only changes how the time is displayed; it does not correct the device clock.
- iPhone / iPad: Open system Settings → General → Date & Time, then turn on Set Automatically. If the option is unavailable, check device management or system restrictions instead of repeatedly changing Shadowrocket settings.
- Mac: In System Settings → General → Date & Time, check automatic date and time and make sure the device can sync.
- Windows: In Settings → Time & language → Date & time, check that automatic time is enabled and use the system's sync option.
- Android / Linux: Check network time or the time synchronization service in the system's date and time settings. Menu names vary by device and desktop environment.
After correcting the time, return to Shadowrocket, disconnect and reconnect, then run the same test again. If the time is correct but the certificate error persists, check whether the Server Name matches the certificate and whether the certificate chain is valid. Don't manually set the device date to fall within the certificate's validity period. This can affect other apps and won't fix a problem with the remote certificate.
Takeaway: Fix the time before troubleshooting certificates
If automatic time is working but certificate errors persist after repeated connection attempts, share the exact error and time with your provider for verification. Keep certificate validation enabled; lowering the validation requirements is not a long-term fix.
6. Check Global Routing and rules after the node works
If the node test succeeds but webpages still won't load, check how traffic is routed. On Home → Global Routing, review the current mode: Proxy routes traffic through a proxy, Direct connects directly, Config follows the rules in the active configuration, and Scene uses the selected scene settings. Selecting a node does not guarantee that every connection will use it.
After recording the original setting, temporarily select Proxy for a comparison. If the target webpage works with Proxy but fails with Config, check the active Config, the matching rule, and its policy instead of changing node authentication again. Restore the original mode after testing so you don't leave a setting in place that doesn't suit your regular use.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYThe rule snippets above explain how matching works; they are not recommendations to overwrite your existing configuration. DOMAIN-SUFFIX matches a domain and its subdomains; IP-CIDR matches an IP range. Rules are generally evaluated in order, and FINAL handles connections that didn't match earlier rules. GEOIP uses an IP geolocation database rather than matching domain suffixes.
- In Config, confirm that the expected configuration is active—not just that a configuration file is open.
- Check whether the target domain first matches DIRECT, a reject policy, or an unexpected policy group.
- If access by domain fails but connecting by IP works, check DNS. Don't treat access by IP and access by domain as equivalent TLS tests.
- If another VPN connection is running on the device, disconnect it while troubleshooting to reduce interference from other network settings.
7. Common questions and what to include in a troubleshooting report
Why do I get a latency result but still can't open webpages?
First check whether the latency test only checks the port. On Home, review Global Routing, note the original mode, then select Proxy and test the site. If it still fails, check authentication, TLS, and transport settings. A reachable port is not a substitute for testing the full proxy connection.
It works on cellular. Do I need to import the configuration again?
Don't delete the original configuration yet. Test the same node three times on each of the two networks, and record the network type. If the difference is consistent, check Wi-Fi sign-in, DNS resolution, and UDP reachability. Importing the same configuration again usually won't explain why the networks behave differently.
The subscription update also times out. Does that mean all the nodes are down?
Not necessarily. Fetching a subscription and connecting through a node are separate request paths. Ask your provider to confirm that your existing subscription link is still valid, and check whether the update succeeded. Don't delete all your nodes first. Hide credentials such as tokens in the link before sharing an error report.
I've checked everything. What information should I provide?
Include the protocol, system platform, time of the error, network type, test method, three results, and a redacted copy of the exact error. Also report what happened after switching networks. Never include passwords, private keys, full subscription links, or authentication tokens in public screenshots or discussion forums.
If you need to reinstall or check where to get the app for your platform, visit this site's download page. Get Shadowrocket for iPhone / iPad from the App Store. The developer is Shadow Launch Technology Limited; check the App Store listing for system requirements. Mac versions are available for Apple Silicon and Intel, along with versions for Windows, Android, and Linux. Don't use reinstalling as a substitute for checking settings and the network; back up your configuration first.