A timeout in Shadowrocket doesn’t necessarily mean the password is wrong or the remote service is down. This guide is for users who already have their own provider and subscription. It covers iPhone, iPad, Mac (Apple silicon and Intel), Windows, Android, and Linux. The steps use iPhone and iPad menus as a reference; on other platforms, check the equivalent settings. Keep your original configuration and test results, then check the test method, protocol settings, device time, and network path one at a time.
1. Distinguish a failed latency test from a failed connection
A latency result only shows that a particular test completed over the network at that moment; it doesn’t prove that every app can connect. A TCP test checks the port connection. An HTTP test through a proxy also depends on the protocol handshake and the test target’s response. ICMP Ping may be dropped by the remote host or an intermediate network. These tests measure different things, so one result cannot stand in for another.
In Home, confirm the selected entry and note the test method. Run the same test three times for that entry. If only one test succeeds or the results vary widely, save the results and don’t change the protocol yet. Then connect and use a browser to visit an HTTPS page you’re authorized to access and that normally works reliably. Check whether the problem affects only a specific site. Don’t switch entries, change DNS, and change networks at the same time, or you won’t know which change made a difference.
| What you observe | What it may indicate | Next step |
|---|---|---|
| TCP test succeeds, but access still fails | The port may be reachable, but authentication, TLS, or the target request may still fail | Check the protocol fields and confirm the request is using the selected entry |
| No ICMP response, but access works | An ICMP result doesn’t show whether the proxy protocol is available | Keep the configuration; judge by actual access and protocol tests |
| Every entry in the same subscription times out | There may be a shared cause; this doesn’t prove every server is down | Check the network, subscription status, DNS resolution, and device time |
| Only one entry keeps failing | The issue is more likely limited to that entry or its remote service | Check the entry’s address and port, and confirm the service status |
Takeaway: Keep the test conditions consistent
Set a baseline with one entry, one test method, and one target page. Only after fixing the baseline can you meaningfully compare results after switching networks or changing settings.
2. Check the address, port, and subscription details in order
Start with the basic connection details. A typo in the address or a port set to another service’s listening port can cause a timeout. Ports aren’t fixed by protocol name: using TLS doesn’t mean the port must be 443, and a common port isn’t a reason to change the one provided to you.
-
Keep the original configuration
In Home, note the entry name, Type, and time the error occurred. Save a copy of the original configuration before editing Config. Keep passwords, UUIDs, and private keys on your own device; don’t post them in public forums.
-
Check the address
From Home, open the selected entry for editing and compare Address character by character with the details from your provider. This field usually takes a domain name or IP address. Don’t paste in a full web address, a path, or leading or trailing spaces.
-
Check the port
Make sure Port matches the remote listening port. Valid port numbers range from 1 to 65535. For example, if the remote port is 8443, don’t change it to 443 just because HTTPS commonly uses 443. A reachable port doesn’t prove that the expected proxy service is running on it.
-
Check authentication
Compare Password, UUID, or the relevant key field with the original details. Watch for line breaks and extra spaces when copying. A subscription URL’s access token is not a node password; they serve different purposes.
-
Update, then test again
If the entry comes from a subscription, update the subscription in Home or pull down to refresh. Wait for the update to finish, then select the entry again. An update may overwrite subscription-generated fields, so note any temporary edits first. If the update fails, don’t delete an older configuration that still works.
A successful subscription update only means the subscription could be fetched and parsed; it doesn’t mean every address in it is online. Conversely, an update failure doesn’t necessarily invalidate entries already saved. If your provider has changed the port, authentication details, or transport settings, old entries may remain listed but no longer work. Confirm the changes with your provider instead of repeatedly importing the same old data.
3. Check the handshake and transport settings for the protocol
Once Address and Port are correct, check Type and its related fields. Different protocols aren’t interchangeable by renaming them, and the same server address may host several different services. Use the table to guide your checks. Which fields appear depends on the protocol and configuration; don’t apply one row’s settings to every entry.
| Protocol | What to check | Common limitations |
|---|---|---|
| Shadowsocks | Encryption method, Password, Address, and Port | The password and encryption method must both match; a reachable port doesn’t prove decryption succeeded |
| VMess | UUID, encryption settings, transport, and any additional parameters specified by the server | A significant device time error may affect authentication; checking only the UUID isn’t enough |
| VLESS | UUID, transport, TLS, and security settings required by the server | Copying only the UUID doesn’t reproduce a complete, working configuration |
| Trojan | Password, TLS, Server Name, and certificate trust status | The connection IP and the domain used for TLS verification may differ; use the values from the original configuration |
| Hysteria2 | Authentication details, TLS, server-specified parameters, and UDP reachability | Uses QUIC; a successful TCP test doesn’t prove the UDP path works |
| WireGuard | Local private key, peer public key, Endpoint, tunnel address, and Allowed IPs | Uses UDP; after the handshake succeeds, check routing and DNS too |
When using WebSocket transport, check Path and Host. A different slash, capitalization, or trailing character in Path can send the request to the wrong service path. Host is used in the HTTP request; Server Name is used in the TLS handshake. They are separate fields, not interchangeable values. Set them to the same value only if the original configuration specifies that.
- TLS name: If Address is an IP but the certificate was issued for a domain, keep the Server Name specified by your provider. Don’t replace every name field with the IP.
- Transport: If the remote service requires WebSocket, switching to plain TCP won’t make it compatible. Transports such as gRPC also require matching server-side settings.
- Certificate validation: If you see a certificate error, first check the device time, domain, and certificate validity period. Don’t treat disabling certificate validation indefinitely as a fix.
4. Use the error to locate the problem; not every failure is a timeout
Record the full error text from the relevant request log or diagnostic result. The examples below are common underlying error messages, but wording may vary across platforms. If you only see a generic connection failure, use the stage at which it occurred to guide your checks. Don’t assign blame to the device or remote service based on one word.
Error: i/o timeout
Cause and fix: An operation didn’t finish within the allotted time. This can happen during DNS resolution, connection, or the handshake. Check the surrounding logs to identify the target address and stage, then test the same entry on another network for comparison. This message alone doesn’t prove the password is wrong.
Error: connection refused
Cause and fix: The connection was explicitly rejected, often because nothing is listening on the port or the request was actively refused. Check Port and ask your provider to confirm the listening status. Increasing the wait time won’t fix this.
Error: no such host
Cause and fix: DNS resolution didn’t return a usable result. Possible causes include a typo, DNS settings, or a missing domain record. Check Address character by character, then check DNS on the current network. Don’t assume this is an authentication failure.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The certificate’s validity period doesn’t match the device’s current time. First correct the device date, time, and time zone. If the error persists despite the correct time, the server administrator should check the certificate validity period and chain.
If the logs show that the connection was established before an HTTP error from the target site, distinguish the proxy connection from the target’s response. A 403 or 429 on a single page may reflect the site’s access policy or rate limit; it doesn’t mean the node’s port is unreachable. Note when the response occurred and the target domain. Don’t mistake a target site’s refusal for a client-wide failure.
5. Correct the device time, then check the network path
TLS checks certificate validity, and some authentication methods depend on a time window. A device set far in the past or future, or one that hasn’t synced after being offline for a long time, may fail the handshake even with correct settings. On iPhone or iPad, go to Settings → General → Date & Time and check Set Automatically. On other platforms, enable automatic time synchronization in the system date and time settings. Confirm the displayed time is correct, then test again.
- Establish a direct-connection baseline: Disconnect Shadowrocket and use a browser to confirm that the current Wi-Fi or mobile network can access regular pages. On hotel, campus, or similar networks, complete any required captive portal sign-in first.
- Compare networks: Test the same device, entry, and target once over Wi-Fi and once over mobile data. If only one network fails, check that network’s egress policy first rather than changing every protocol field.
- Check for UDP restrictions: Hysteria2 and WireGuard rely on UDP. If they fail on a network while an existing TCP-based connection works, that’s a reason to investigate the UDP path—not proof of a protocol implementation issue.
- Rule out tunnel conflicts: Check whether another VPN or network filter on the device is handling connections. Temporarily disable conflicting settings and test again. On managed devices, follow administrator policies; don’t bypass organizational restrictions.
If the connection turns back on automatically after you disconnect, check Shadowrocket’s Settings → On Demand. Note the original settings, then temporarily disable automatic triggers for testing. On Demand controls when a connection starts; it doesn’t fix the address, password, or remote service. Restore the original settings after troubleshooting rather than leaving automatic connections disabled as a general fix.
When to change DNS: Check DNS specifically when resolution fails or returns a clearly incorrect result. Don’t replace every DNS entry at once or arbitrarily substitute an IP for a domain. Doing so can break TLS name verification and make the original problem harder to reproduce.
6. If latency is normal but pages won’t load, check Global Routing and Rule
Node tests and app requests may take different paths. Go to Home → Global Routing and note the current selection. Proxy routes through a proxy; Direct connects directly; Config follows the active configuration; Scene follows the configured scene. These are not four connection protocols, and their names alone don’t show which route a webpage uses. Check the matching result and the entry actually in use.
- Quick comparison: If you understand the network implications, compare access using Proxy and Config, then restore the original setting. If Proxy works but Config doesn’t, check the rules and policies next rather than changing authentication fields first.
- Check the order: In Config, open the active configuration and review Rule entries from top to bottom. Once an earlier rule matches, later rules generally aren’t considered for that request.
- Check what each rule matches: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches against an IP geolocation database, and FINAL handles requests that didn’t match earlier rules. These rules match different things; no single one can explain every connection.
- Check the policy: Confirm that the matched PROXY, DIRECT, REJECT, or custom policy group leads to the expected behavior. A group appearing in the list doesn’t mean its currently selected entry is working.
The example below demonstrates rule order and syntax; it isn’t a recommended configuration to replace your existing Config in full. example.com and 192.0.2.0/24 are documentation examples. Interpret them in the context of your own destinations, not as real service settings.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYTakeaway: Change settings based on the failure stage
If the port isn’t reachable, check the address and network first. If the handshake fails, check authentication, TLS, and device time. Only after the handshake and actual proxy access work should you focus on whether a rule is routing a particular request to the wrong policy.
7. Keep reproducible records before contacting your provider
If the problem persists after these checks, provide details that help locate it rather than simply saying “everything times out.” Separate test results from guesses. For example, “the same entry fails on Wi-Fi but works on mobile data” is a verifiable observation; “the server is blocked” is only a theory to investigate. Don’t report conclusions you haven’t tested, and never expose credentials just to complete a report.
- Device and network: Device platform, network type, and whether network sign-in or organizational management policies apply.
- Time of occurrence: When the problem happened, including the time zone, and whether the device clock was synced. This helps compare your report with remote logs.
- Configuration details: Protocol Type, transport, whether TLS is in use, and whether one entry or the entire group fails.
- Comparison results: Test method, results from three consecutive tests, results across networks, and the Global Routing selection.
- Error details: Include the relevant stage, but redact Password, UUID, private keys, subscription tokens, and personal information.
This site doesn’t provide, sell, or recommend nodes or subscriptions. Ask your own provider to confirm route status, credential validity, and remote configuration. Getting the client and obtaining a network service are separate matters; reinstalling repeatedly is no substitute for checking settings. To install Shadowrocket or switch devices, use this site’s cross-platform download guide and choose the instructions for your device.