Shadowrocket Connection Timeout: Troubleshoot Latency Tests, Protocol Settings, and iPhone Time

At a Glance

This guide is for users who have imported a configuration from their service provider but are seeing timeouts in Shadowrocket. First, distinguish a failed test from a failed request, then narrow down the cause by comparing networks, checking protocol settings, and verifying the system time. Change one setting at a time and keep the original configuration. When finished, restore your previous routing and On Demand settings.

1. Tell a Latency Test Timeout from a Failed Request

In Shadowrocket, a latency result reflects only the specific test method; it does not prove that the server is fully usable. A successful TCP handshake does not guarantee proxy authentication, a TLS handshake, or access to the destination. A timeout with another test method does not prove that all real requests will fail. Record the test method, not just the result.

Before troubleshooting, turn off the connection toggle and make sure your current Wi-Fi or cellular network can load a regular webpage. If Wi-Fi requires a sign-in page, complete that first. Editing server settings repeatedly will not help if the underlying network is unavailable.

Basic network Latency test Protocol settings System time Actual requests

One server times out: If other saved servers work on the same network, first check this server’s address, port, and service status.
All servers time out: Check the underlying network, DNS resolution, test method, and subscription status first. Don’t re-enter every server’s settings right away.
Latency test succeeds, but webpages fail: Check authentication, TLS, Global Routing, and the rule applied to the request.
Only one website fails: Note the destination domain and error. A problem with one site does not mean the entire proxy connection is down.

2. Run a Reproducible Connection Test

In Home, check which server is marked as the default in the SERVER list. Don’t assume a server is in use just because you opened a group or can see its entry. During testing, avoid changing the server, network, and routing mode at the same time; otherwise, you won’t know which change affected the result.

Record the Current Settings

In Home, note the default server, the current Global Routing value, and the connection toggle state. Go to Settings → On Demand to see whether on-demand connection is enabled. If it reconnects automatically, note its current setting, then temporarily turn it off.
Run a Latency Test

Go to Home → Connectivity Test and record the test method and result. Test the same server two or three times to distinguish consistent timeouts from intermittent failures. Don’t delete a configuration based on a single result.
Test an Actual Request

Select the default server and turn on the connection toggle. If needed, temporarily set Global Routing to Proxy, then open a known-working HTTPS page to reduce interference from rules in Config.
Switch Networks

Keep the same server and routing mode, and switch only between Wi-Fi and cellular. After each switch, wait for the connection to stabilize, reconnect, and open the same page.
Record the Comparison

For each test, note the network type, test result, whether the page loaded, and the exact error message. When testing is complete, restore your previous Global Routing and On Demand settings so temporary changes don’t affect everyday use.

Proxy tests the proxy route. Direct sends requests directly and does not prove that the server is usable. Config processes requests according to the current configuration. If you’re using a Scene, also check its activation conditions. Briefly switching modes can help isolate the issue, but it is not a long-term fix.

3. Check Protocol Settings One by One

In Home, open the server’s edit screen and compare each field with the original details from your service provider. Check Type, address, and port first, then authentication and transport options. Don’t treat the domain, SNI, and Host as interchangeable fields. And don’t change your port to 443 just because it appears in common examples.

1–65535

Valid port number range; use the value specified in your provider’s configuration

443

A common HTTPS port, not a fixed proxy port

6 types

Protocol settings to check in the table below

Type	Check first	Commonly confused details
Shadowsocks	Address, port, encryption method, password	The encryption method must match the server. Configure plugin options only if the server requires them.
VMess	UUID, transport, and any authentication options required by the server	For WebSocket, also check Path and Host. TLS settings must match the server.
VLESS	UUID, transport, and Flow (if applicable)	Don’t copy TLS or transport settings from a different configuration.
Trojan	Password, port, TLS, and server name	A reachable address can still fail if the password or certificate name doesn’t match.
Hysteria2	Authentication details, TLS, and obfuscation settings (if applicable)	This protocol depends on the UDP path. A basic TCP port test cannot confirm that it works end to end.
WireGuard	Keys, Endpoint, interface addresses, and Allowed IPs	Uses UDP. A mismatched key or incorrect routing range can also prevent data from flowing.

Compare Across Networks Before Changing Settings

If the same configuration fails on only one network, first ask your provider to confirm port and UDP reachability on that network. If it fails on both networks, focus on the service status and protocol fields. Don’t change the port, password, and TLS options all at once.

If you manage servers through a subscription, manual edits to an imported entry may be overwritten the next time it updates. Save a redacted record first, then update the relevant subscription and confirm that the update succeeded and the entry changed as expected. A successful subscription fetch only means the subscription URL is reachable; it does not mean every server in it works. A failed subscription update does not mean saved servers have immediately stopped working.

4. Use the Exact Error to Identify the Failure Stage

Error logs can come from different network layers, and the wording may vary by connection type. These are common examples; use them only if they appear in your logs. Record the full error and when it occurred. Don’t label every failure a “timeout.”

Error: i/o timeout

What it means and what to do: A stage did not receive the expected response before the timeout. This message alone can’t tell you whether the issue is authentication or the network. Check the surrounding log entries to identify the failure stage, then test the same configuration on another network.

Error: connection refused

What it means and what to do: The destination host or an intermediary actively rejected the connection. This commonly happens when nothing is listening on the port or access is denied. Check the port first, then ask your provider to inspect the listening service and access policy.

Error: no such host

What it means and what to do: The required DNS lookup failed, possibly because the address is mistyped or the resolution path has a problem. Compare the server domain with the original details and check DNS on your current network. Don’t replace it with an unknown IP address.

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 time used for verification. The cause may be the device clock or the server certificate. Correct the device time first; if the error persists, ask your provider to check the certificate’s validity period.

A TLS certificate name error is different from an expired certificate. For a name error, check the server name, SNI, and the domains covered by the certificate. For a validity error, focus on the system time and certificate renewal. Don’t hide the problem by disabling certificate verification: that removes identity checks and does not fix the server configuration.

5. Check Your iPhone’s System Time

TLS checks when a certificate becomes valid and when it expires. VMess authentication also depends on time. If the device clock is off, the connection may fail even when the address, port, and password are correct. A different displayed time zone does not necessarily mean the system clock is wrong; check both the date and the actual time.

On your iPhone, open Settings → General → Date & Time and check Set Automatically. These are iOS system settings, not Shadowrocket’s Settings.
When a network connection is available, turn on Set Automatically and confirm that the year, date, and time look right. If a device management policy prevents you from changing this setting, contact your administrator.
Return to Shadowrocket, turn the connection toggle off, then reconnect to the same server. Test the same page again, without updating the subscription or changing other settings at the same time.
If the time is correct but the certificate still appears expired, ask your provider to check the server certificate. Changing the time zone repeatedly will not extend a certificate’s validity.

6. Check Routing After Latency Returns to Normal

If the page loads with Proxy but fails after you switch back to Config, focus on the active configuration in Config and the rule matching the request. Rules are evaluated in order, and both their position and the policy assigned to FINAL affect the outbound route. A request routed through Direct does not mean the default server is unreachable.

DOMAIN-SUFFIX matches domain suffixes. Check whether the destination domain matches the expected policy.
GEOIP matches by IP geolocation; it is not a domain suffix rule.
IP-CIDR matches IP address ranges. Check whether the range is too broad.
FINAL handles requests that did not match earlier rules. Confirm that its final policy is what you expect.

Back up your configuration before editing rules, and keep the existing policy names. If only one destination fails, check its request details, DNS resolution, and actual outbound route. Don’t clear the entire configuration to fix a single destination. If the connection turns back on after you switch it off, go to Settings → On Demand and check the on-demand conditions so you don’t mistake an automatic reconnect for a faulty toggle.

7. Prepare Details for Your Service Provider

If the problem persists after these checks, send details that let your provider reproduce it instead of simply saying “it doesn’t work.” Don’t share your password, UUID, private key, or full subscription URL; these may give someone access to your service. Check screenshots and logs for sensitive information before sending them.

When it happened: Include the date, time, and time zone so your provider can compare them with server logs.
Connection details: Specify Wi-Fi or cellular, the protocol Type, the port, and a redacted server identifier.
Test results: For each network, give the test method, whether it timed out, and whether the page loaded.
Error details: Include the exact error and related log entries, and note that you checked the system time.
Changes made: List subscription updates, fields checked, and routing changes, and say whether you restored the original settings.

Shadowrocket is a closed-source commercial app available through the App Store on Apple platforms, primarily for iPhone and iPad. Check the App Store listing for system requirements. Buying the app does not include a service plan. Get existing subscriptions from your provider, who can check service status, credential validity, and server certificate issues. Buying the app again is not a troubleshooting step for these problems.