This guide is for users who have installed Shadowrocket, have their own provider configuration or subscription, and can turn on the connection but cannot access websites. Start by checking your basic network with the connection off, then verify the server in Home, Global Routing, DNS, and Rule settings in Config. Change one setting at a time and retest the same destination to pinpoint whether the issue is with your network, proxy connection, DNS resolution, or routing policy—instead of repeatedly reinstalling the app.
1. Tell the Difference Between a VPN Connection and Website Access
When the connection switch is on and the system shows a VPN, it means the system has created a tunnel for the app to handle traffic. It does not confirm that the remote server authenticated successfully or that a website is reachable. The server address may fail to resolve, its port may be unreachable, authentication details may be invalid, or a Rule may reject the request—even with the switch on.
Choose two websites you can normally access for testing, ideally ones with different purposes. Note whether neither loads, only one domain fails, or the page opens but some resources do not. Don’t assume a single website’s issue means the whole network is down. And don’t change the server, DNS, and configuration file at the same time—you won’t know which change affected the result.
-
Turn Off the Connection
Go to Home, turn off the connection switch, and use a browser to visit both test sites. If they still don’t load, first check for Wi-Fi sign-in requirements, cellular data permissions, or an issue with the network itself.
-
Pause Automatic Connections
Go to Settings → On Demand. Note the current settings, then temporarily turn off automatic connection triggers so the system doesn’t reconnect after you turn it off manually. Restore the original settings when you’re done troubleshooting.
-
Keep Test Conditions Consistent
Use one network and a server you already have. Note the current Home → Global Routing selection and which configuration file is active in Config.
-
Retest While Connected
Turn the connection back on and visit the same sites in the same browser. To compare Wi-Fi with cellular data, treat switching networks as a separate test and leave other settings unchanged.
2. Check the Home Server and the Actual Connection Error
In Home, confirm that the selected entry is the server you intend to test—not just a subscription group name. Open its edit screen and compare the address, port, protocol, and authentication details with information from your provider. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different parameter formats; don’t apply one protocol’s fields to another.
The port must match the server configuration. For services that use TLS, also verify parameters such as the Server Name provided by your provider. Don’t hide a configuration error by disabling certificate verification. An incorrect device date or time can also affect certificate checks, so correct it first. Entries may change after a subscription update; confirm which one is currently selected instead of assuming an older entry is still valid based on its name.
- You can use Connectivity Test in Home to gather clues, but results depend on the test method and destination. A latency value does not prove that a website will load.
- If a TCP connection succeeds but the actual request fails, check the authentication and TLS parameters next. Reaching a port and successfully sending application traffic are separate stages.
- If only a Hysteria2 or WireGuard entry fails on a particular network, check UDP reachability on that network and at the server. TCP test results alone can’t determine whether these protocols work.
- If your subscription details have changed, use the update function for the original subscription to retrieve the latest parameters. Don’t guess the port or password, and don’t share subscription URLs, keys, or complete logs publicly.
The following are examples of error strings that may appear in network logs; they are not fixed dialog titles. Exact wording varies by protocol and underlying error. Follow a troubleshooting branch only if the corresponding message appears in your logs.
Error: connection refused
Cause and fix: The connection to the destination port was refused. The service may not be listening, or a network device may have actively rejected the connection. First check the server address and port, then ask your provider to confirm the service status. Don’t start by changing domain Rules.
Error: i/o timeout
Cause and fix: A read or write operation did not complete within the allowed time. This error alone doesn’t tell you whether DNS or the server is at fault. Check the surrounding log entries to identify what timed out, then retest the same configuration on a different network.
Error: no such host
Cause and fix: The hostname could not be resolved to a usable address. First determine whether it’s the server hostname or the website hostname, then check its spelling and resolution path. Don’t mistake a server hostname resolution failure for a Rule issue.
3. Isolate Routing Issues with Global Routing
Go to Home → Global Routing and note the current selection: Proxy, Direct, Config, or Scene. Proxy routes traffic through the proxy, Direct connects without the proxy, Config applies routing rules from the active configuration, and Scene uses the settings for the selected scene. Know which mode is active while troubleshooting. Changes to Rules in Config may have no visible effect if another mode is selected.
| Option | Purpose of this test | What to check next |
|---|---|---|
| Direct | Compare whether a direct connection works | If it fails, compare the result with the connection turned off and check the basic network and DNS settings. |
| Proxy | Test the proxy path with the same server | If both destinations fail, check the server, authentication, and DNS first—not Rule order. |
| Config | Test routing with the active configuration | If Proxy works but Config fails for the same destination, check the matching Rule and final policy. |
| Scene | Check which settings the selected scene actually uses | First confirm the active scene. To isolate the issue, temporarily compare using an explicit Proxy or Config mode. |
Takeaway: Test the proxy path before investigating Rules
If the same destination works in Proxy but fails in Config on the same network and server, check the matching policy and related DNS settings in Config during the next test. Don’t change the server at the same time. This comparison narrows down the cause, but check request logs to confirm it.
Switching Global Routing modes is a diagnostic step, not a permanent fix. Existing long-lived connections may continue using the old route, so start a new request after switching modes. If needed, turn the connection off and back on. Restore the original mode when you’re done, and don’t mistake a temporary switch to Proxy for a fix to your original routing configuration.
4. Find Where the DNS Failure Occurs
Start DNS troubleshooting by asking which domain failed to resolve. If the server address is a hostname, it must resolve to an IP before the proxy connection can be established. A website hostname may be resolved later, when the request is made. Both stages can time out, but they require different steps. Resolve the server address first, then check the destination hostname. A proxy connection that hasn’t been established can’t handle every prerequisite lookup for you.
These are common ports for DNS resolution methods, not a recommendation to change your server port to one of them. Encrypted DNS still requires access to its resolver. If the resolver is reachable only after the proxy is connected, but you need it to resolve the proxy server’s hostname, you may create a dependency loop. A correctly entered DNS address doesn’t guarantee that the current network can reach it.
- Note the existing settings in Settings → DNS, and check whether the active configuration in Config includes a
dns-serverentry under[General]. If there are multiple configuration sources, first confirm which one is active. Don’t change a file that isn’t enabled. - Check whether the failed request has a destination IP, whether a resolution error appears, and whether the failure occurs before connecting to the server or during the destination request. If an IP is already available and the connection then times out, a website failing to load alone isn’t enough to conclude that DNS is the problem.
- If you manually changed DNS, save the current value, then restore the previous working setting and test that change alone. Keep the server and Global Routing unchanged, reconnect, and try again.
- If resolution fails only on a particular Wi-Fi network, switch to cellular data for a single-variable comparison. A different result means the network environment is involved, but it doesn’t identify exactly which device or service is blocking the request.
5. Check Rule Order in Config
If the proxy path works but a specific destination fails in Config, open the active file in Config and check [Rule]. Rules are evaluated in order, and the first matching Rule determines the policy. Specific domain Rules generally go before broader ones, with FINAL at the end. Save a copy of the original file before making changes, and confirm that the same file is still active afterward.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThe example above shows syntax and ordering only; it is not a recommendation to replace your existing configuration. example.com is a sample domain. DOMAIN-SUFFIX matches the domain and its subdomains; IP-CIDR matches an address range; GEOIP uses the geographic location associated with an IP; and FINAL catches requests that did not match an earlier Rule. no-resolve means the IP Rule won’t actively resolve a domain for matching; it does not disable all DNS.
- Check rule order:If a target matches an earlier DIRECT rule, a later FINAL rule cannot change it to PROXY. Add exceptions before the rule that overrides them.
- Check the policy: If a Rule points to a custom policy name, confirm that the policy exists and that its selected server is available. A group name that looks correct doesn’t mean the selected entry is working.
- Check for rejects:Requests matching REJECT are blocked. If a page loads but a required resource fails, check that resource’s domain and policy—not just the domain in the address bar.
- Check IP rules:GEOIP and IP-CIDR rely on the IP information available for a request. Changes in DNS results can affect matches, so don’t treat a single observation as permanent.
Once you’ve identified the Rule, change only what’s needed for the failed destination, then repeat the original test. Don’t delete every Rule just to make one website load; that may change the result temporarily but leave you without a way to identify the original cause. For details on Rule fields, see the Configuration Fields Reference.
6. Common Symptoms and Recovery Steps
Why won’t a website load even though a latency value appears?
A latency test reflects only the response to a specific test; it doesn’t cover every authentication, TLS, DNS, or destination request. Keep the same server, switch Home → Global Routing to Proxy, and try the original destination. Then check the request error to determine whether the failure occurred during the handshake or while connecting to the destination.
Wi-Fi works, but cellular data doesn’t. What should I check first?
First turn off the connection and confirm that cellular data can access the internet on its own. Then check the system’s cellular data permission for Shadowrocket. Retest with the same server and mode. If only a configuration that relies on UDP fails, ask your provider about connection requirements on that network. Don’t change protocol fields at random.
Only one website won’t load. Should I reinstall the app?
First compare the destination in Proxy and Config, then check the failed resource’s domain, matching Rule, and final policy. If it fails in both modes while other sites work, consider the destination service’s status, the route from the remote server to that destination, and the website’s own access requirements.
The connection turns back on after I switch it off. What should I check?
Go to Settings → On Demand and temporarily turn off automatic triggers, then run the baseline test with the connection off. Restore the original settings when you’re done. Don’t mistake automatic reconnection for a faulty switch, and don’t delete the system VPN configuration as a first step.
Finally, restore any temporary changes to Global Routing, DNS, and On Demand, keeping only adjustments confirmed by testing. If the issue persists, give your provider the time it occurred, network type, protocol, redacted error text, and the differences between your Direct, Proxy, and Config tests. Remove passwords, UUIDs, keys, and subscription tokens. These details are more useful for identifying the failing connection stage than simply saying “the switch is on.”