This guide is for users who have imported their own provider’s configuration into Shadowrocket. First, distinguish a latency test timeout from a protocol handshake failure or a failed webpage request. Then check the server settings, routing, and system time one by one. Change only one variable at a time, and compare the same request before and after each change. A test result alone does not prove the entire connection is working.
1. Record what’s happening: distinguish test failures from request failures
Open Home, confirm which server is selected, then run Connectivity Test. Note the test method, result, and network in use. If you can choose a test method, record TCP tests separately from tests of actual requests. A test result reflects a specific probe—not connection status across every website, protocol, and network condition.
A TCP test mainly checks whether a TCP connection can be established to a specified address and port. A result in milliseconds does not confirm that the password is correct, TLS verification succeeds, or the destination website is reachable. Hysteria2 uses QUIC over UDP, and WireGuard also uses UDP, so a basic TCP probe cannot verify their actual traffic.
| What you see | What it may indicate | What to check next |
|---|---|---|
| TCP test returns a time, but webpages fail | The TCP connection may succeed while a later step fails | Check authentication, TLS, routing, and DNS |
| Test times out, but actual requests work | The probe method or target may differ from the actual request | Record the test method; don’t change protocol settings yet |
| The same configuration fails only on Wi-Fi | The issue may be related to that network path | Switch to cellular and retry the same request |
| Only one website fails | This alone doesn’t point to a problem with the entire connection | Check DNS, the matched rule, and the destination service |
Bottom line: verify test results with actual requests
Keep the same server and configuration, then retry with a known-accessible HTTPS page. Use both the test result and the actual request behavior to decide what to check next.
2. Retest in a set order; don’t change multiple settings at once
First, make sure your iPhone can use the current network with Shadowrocket disconnected. If public Wi-Fi requires a sign-in page, complete that step before connecting. Then follow the checks below. Use your own provider’s information for any existing subscription and server settings.
-
Record a baseline
In Home, note the selected server, Connectivity Test result, and current Global Routing setting. Also record whether you’re on Wi-Fi or cellular. Don’t start by deleting configurations in bulk.
-
Check the address
Open the selected server’s edit screen in Home and verify its address and port. Make sure there are no leading or trailing spaces. Don’t enter a subscription URL as a regular server address, and don’t add
https://or a path unless specified. -
Verify the settings
Compare the Type, authentication details, TLS, and transport settings with your provider’s information. After saving, reconnect and make a new webpage request rather than relying on results from an existing connection.
-
Switch networks
Keep the settings unchanged and switch between Wi-Fi and cellular. If the timeout occurs on only one network, note the difference. A temporary connection on one network doesn’t mean the password has been revalidated.
-
Check the time
On your iPhone, go to Settings → General → Date & Time. Check Set Automatically, the current date and time, and the time zone. After correcting anything, reconnect and retry the same HTTPS request.
3. Check the address, port, and protocol settings one by one
Open the server’s edit screen in Home. First confirm that its protocol type exactly matches the type provided by your service provider, then compare each field. The port is the listening endpoint specified by the server. A port number such as 443 does not guarantee that it provides working HTTPS or TLS. Don’t replace the original port just because another one is commonly used.
| Protocol | Check these settings | Common mistakes |
|---|---|---|
| Shadowsocks | Server, port, encryption method, password, and any plugin settings required by the server | Copying only the password and missing the encryption method or plugin settings |
| VMess | UUID, encryption settings, and the transport and TLS settings required by the server | Entering the UUID in the wrong authentication field or missing transport settings |
| VLESS | UUID, transport, and any TLS, Reality, or flow settings required by the server | Assuming the same UUID works with any transport or security settings |
| Trojan | Password, TLS, server name, and transport settings | Assuming the address is enough and overlooking the server name used for certificate verification |
| Hysteria2 | Authentication details, TLS server name, and any obfuscation settings required by the server | Assuming a successful TCP probe means the UDP path is also available |
| WireGuard | Local private key, peer public key, Endpoint, interface address, and allowed routes | Confusing the private key with the peer’s public key, or overlooking UDP reachability |
The TLS server name may differ from the address used to connect. The connection address determines where the request is sent; the server name is used during TLS negotiation and certificate identity verification. With WebSocket, Host and Path are also part of the application-layer request. These values may happen to match, but don’t treat them as interchangeable just because they look similar.
- Password and UUID: Check for line breaks, quotation marks, or trailing spaces introduced when copying. Don’t paste or share complete authentication details.
- Path:
/connectis only an example of a path. Use the value from the server configuration, and check capitalization and the leading slash. - Address and port: A domain name also depends on DNS resolution. Replacing it with an IP address isn’t a general fix, and you should especially avoid removing the TLS server name at the same time.
- Subscription updates: Your provider may change server addresses or settings. Keep a record of custom changes, update your own subscription, and recheck the selected server instead of reusing outdated fields.
4. Narrow down the issue from the error; don’t use the same fix for every failure
Note the log messages around the connection failure, starting with the earliest error and its target. The following snippets may appear in network or TLS logs, but wording can vary. A single log line doesn’t prove that the issue is on the server side.
Error: i/o timeout
Cause and next steps: A read or write operation didn’t complete in time. The cause may involve name resolution, the network path, or a remote response. First identify the target associated with the error, then keep the settings unchanged, switch networks, and retry the same request.
Error: connection refused
Cause and next steps: The target or an intermediate device explicitly rejected the connection, often because nothing is listening on that port or the connection was actively refused. Verify the address and port specified by your provider, then ask them to check whether that endpoint is available.
Error: certificate has expired or is not yet valid
Cause and next steps: The certificate’s validity period may not match the device’s current time, or the remote certificate may actually have expired. First correct the time on your iPhone. If it’s already correct and the error persists, ask your provider to check the certificate rather than bypassing verification.
Error: no such host
Cause and next steps: The domain couldn’t be resolved to a usable address. Check the spelling, then determine whether the failed lookup is for the server domain or the destination website. Next, check the configured DNS and your basic network connection.
If the same error keeps appearing, simply waiting longer won’t help. First identify where the failure occurs: if the server domain can’t be resolved, check the address and DNS; if TLS negotiation has started, check the time, server name, and certificate; if authentication fails, recheck the protocol settings. Different stages call for different checks.
5. If connected, check Global Routing and DNS
Go to Home → Global Routing and note the current selection. Proxy, Direct, Config, and Scene determine how requests are routed; they are not four different connection protocols. A VPN-connected status mainly indicates that the system tunnel is established. It doesn’t confirm that every request passed through the selected server and reached its destination.
- Proxy: Use this mode to compare the proxy route. After switching temporarily, retry the request. Keep in mind that access to local network resources may change, and restore the original setting after testing.
- Direct: Requests use a direct route. If a webpage opens in this mode, that doesn’t confirm that server authentication and forwarding are working.
- Config: Rules are applied from the currently selected configuration. Confirm which file is active in Config, then check its Rule section—not just a file that isn’t selected.
- Scene: Routing behavior is determined by the configured scene. Check the settings the scene actually uses; don’t assume it behaves like a fixed Proxy or Direct mode.
In Config mode, rules in the Rule section are matched in order. Earlier DOMAIN-SUFFIX, IP-CIDR, or GEOIP rules may determine where a request goes first; FINAL handles requests not matched above and should be placed at the end. If the same destination works in Proxy but fails in Config, check the matched rule and its policy before changing the password.
6. Check the system time and keep useful troubleshooting notes
On your iPhone, go to Settings → General → Date & Time and check Set Automatically. If the date, time, or time zone looks wrong, restore the correct settings and confirm the device’s actual time. Certificate checks depend on the current time; changing only the displayed time zone doesn’t correct the device clock. Protocols such as VMess, which use time-sensitive authentication, may also be affected by a significant clock discrepancy.
If the time is correct but the connection still fails, prepare a concise report for your provider. Include when it happened and the time zone, network type, protocol, test method, a redacted error snippet, and the result after switching networks. Don’t send your password, private key, full UUID, or complete subscription URL.
Why can I get a latency result but still not open a webpage?
First check which test produced the result. Go to Home → Global Routing, note the mode, then try the same request in Proxy for comparison. If it still fails, check protocol authentication and TLS settings. A successful TCP connection doesn’t test the later authentication or destination request.
Wi-Fi times out, but cellular works. Do I need to re-enter my password?
Keep the existing password for now. Confirm that you’ve completed any Wi-Fi sign-in page, then retry with the same server and request. For Hysteria2 and WireGuard, also check whether UDP is reachable on that network. Reporting the network difference to your provider is more useful than repeatedly entering the same settings.
Does a successful subscription update mean all servers are reachable?
No. A successful update only means the subscription content was retrieved and processed. In Home, select a specific server and check the test result and actual requests separately. Your provider may still need to verify the addresses and authentication settings in the subscription.
Should I delete the system VPN configuration or buy again first?
Neither should be the first step when troubleshooting a timeout. If the system tunnel can be established, check the address, protocol, routing, and time first. If system authorization or tunnel setup itself fails, follow the first connection guide to check the authorization steps.
Bottom line: verify the fix by changing one variable at a time
After correcting one setting, reconnect and make the same request several times to confirm the original error is gone. Then restore any temporary routing changes and On Demand conditions. One successful attempt is a clue, not a substitute for retesting the original failure scenario.