Turning on Shadowrocket’s connection switch only starts the local connection process. It does not confirm that the server, DNS resolution, or routing rules are working. This guide is for users with their own provider and subscription whose webpages still won’t load after connecting. Narrow down the cause in this order: server → Global Routing → DNS → rules. Retest the same destination each time so you can identify the cause without changing several settings at once.
Start with consistent tests to separate local network issues from proxy problems
Seeing a VPN status on your device does not mean the remote server has authenticated successfully—or that the destination website is reachable. Shadowrocket can establish a network tunnel on your device before connecting to a server for a request. That means the connection switch may remain on even when the server address is unreachable. Check what happens to actual requests rather than repeatedly toggling the switch.
Choose one website you can usually access directly and one destination that currently won’t load. Use your browser to make a fresh request to each, and note when it fails, which network you’re on, and which server is selected. Don’t rely on an already-open tab or an app’s home screen: cached content can remain visible after the connection is lost. The steps below use iPhone and iPad interface labels; check the equivalent settings on other platforms.
-
Check your basic network connection
Turn off the connection on Home, then try a website you can normally access directly. If it still won’t load, complete any Wi-Fi sign-in, check cellular data permissions, or restore your router’s internet connection first. Changing routing rules won’t fix an underlying network outage.
-
Keep the test destination consistent
Note the same destination domain, whether you’re using Wi-Fi or cellular, and the server selected on Home. Change only one setting at a time, then make a fresh request to that destination. Don’t compare results from different websites.
-
Pause automatic connections
Go to Settings → On Demand, note the current setting, and temporarily turn off automatic connections. This prevents the system from reconnecting as soon as you disconnect manually. Restore the original setting after testing.
-
Keep a copy of your original configuration
Before making changes, note your Global Routing mode, current Config, and custom DNS settings. Save a copy of the configuration before editing rules so temporary diagnostic changes don’t become your everyday setup.
1. Check whether the server connects and handles a real request
On Home, check the selected entry—not just the subscription group name. Run Connectivity Test and note whether you get a latency value or a timeout, then verify with a real browser request. The test method and destination affect the result: a latency reading may confirm only part of the connection process, not account authentication, the TLS handshake, and access to the destination.
If you have your own subscription, check the server address, port, and selected entry again after updating it. An old entry remaining in the list doesn’t mean it still works. For manually imported entries, verify the protocol and credentials field by field. For example, Trojan’s password and TLS settings, a VLESS UUID, and a Shadowsocks encryption method and password are not interchangeable. Use the port specified in your configuration; don’t automatically change it to 443 just because TLS is enabled.
- Every entry times out: Compare Wi-Fi and cellular once. If it fails only on one network, check that network’s outbound restrictions, sign-in status, or UDP availability first.
- Only one entry fails: Ask your provider to confirm the server address, port, authentication details, and service status. There’s no need to reset the entire client first.
- Latency is normal, but webpages fail: Check the error from an actual request. A successful TCP connection can still be followed by a TLS or authentication failure, and the test destination may be reachable when the webpage destination isn’t.
- Hysteria2 fails: Hysteria2 uses QUIC over UDP, so a successful TCP test doesn’t prove that the UDP path is available. Check the conditions for UDP communication with WireGuard as well.
Error: connection timed out
Cause: The connection didn’t receive the required response before the timeout. The server may be unreachable, the link may be dropping packets, or the network may be filtering traffic. A timeout alone doesn’t prove the password is wrong.
Fix: Check the server address and port, then retry the same entry on another network. If only this entry continues to time out, ask your provider to check the server status.
Error: connection refused
Cause: The destination port refused the connection. Common causes include an incorrect port, a service that isn’t listening, or an intermediate device actively rejecting the connection.
Fix: Check the port and protocol against your existing configuration. Don’t try to fix a clear port refusal by changing DNS.
These are common snippets from network logs, not fixed pop-up messages you’ll see every time a connection fails. When recording an error, include the time and destination. Before sharing diagnostic details, redact subscription tokens, passwords, UUIDs, and other credentials.
2. Check whether Global Routing matches your test
Go to Home → Global Routing and check the current mode. The mode determines how requests are handled; it’s separate from whether the connection switch is on. Check the mode before investigating rules. If it’s set to Direct, turning on the connection switch won’t send ordinary requests through the current proxy server.
| Mode | How it handles traffic | Troubleshooting use |
|---|---|---|
| Config | Selects a policy according to the rules in the current configuration. | Check whether everyday routing works as expected, and confirm which Config is in use. |
| Proxy | Sends ordinary traffic through the current proxy path. | Compare temporarily with Config to rule out interference from ordinary routing rules. |
| Direct | Uses a direct connection. | Compare it with the proxy path; this doesn’t prove that the remote proxy server is working. |
| Scene | Uses the handling method specified by the configuration’s scene conditions. | Check which scene is triggered on the current network. Don’t infer the traffic route from the Scene label alone. |
Note the original mode, temporarily switch to Proxy, and use the same server to access the same destination. Then switch back to Config and try again. If Proxy works but Config doesn’t, check the rules and policy selection in the configuration first. If both fail, don’t assume the rules are the cause. A Proxy comparison doesn’t isolate every network setting: DNS, server parameters, and the underlying connection can all affect the result.
Takeaway: Compare modes to narrow down the cause
If the same destination works in Proxy but fails in Config on the same network and server, keep the working server settings and check which rule matched in Config and where its policy sends traffic. Don’t change the protocol and DNS at the same time.
3. Find out where DNS resolution is failing
A webpage request usually resolves a domain name to an address before establishing a connection. A DNS timeout can leave the next connection without a usable destination, but the proxy server’s hostname may also need to be resolved first. Identify which name fails: the proxy server’s hostname or the website’s domain. The next troubleshooting steps depend on which one it is.
Go to Settings → DNS to review the current settings, and check whether the Config also contains DNS-related options. Changing one setting in the interface doesn’t guarantee that every request uses that resolver. The app’s encrypted DNS, existing caches, and different resolution paths can all make the result differ from what you expect.
- Identify the hostname that failed. Note the hostname that couldn’t be resolved in the logs. If the server hostname can’t be resolved, fix that step first; testing a different website won’t tell you whether the server is working.
- Revert recent changes. If the problem began after you entered a DNS address manually, note the original value, undo the change, and test again. Don’t add several unfamiliar resolver addresses at once; that makes the results harder to interpret.
- Check that the resolver is reachable. Traditional DNS commonly uses port 53. Encrypted DNS also requires a working connection to the corresponding server and successful certificate validation. Encryption doesn’t guarantee reachability.
- Make a fresh request. Save your settings, disconnect and reconnect, then close and reopen the destination page. If a cache may still be affecting the result, restart the relevant app and test again. Don’t treat an old page as evidence of a fresh DNS lookup.
- Check the address family. If the problem occurs only on some networks, see whether the IPv6 path is involved. A temporary comparison can help narrow it down, but record what you change; disabling IPv6 isn’t a universal fix.
Error: No such host is known
Cause: This hostname resolution error can occur on Windows. It means the current lookup returned no usable result; it doesn’t tell you whether the remote port is open.
Fix: Check the hostname spelling, then review your network and DNS settings. If it’s your own server’s domain, ask your provider to confirm that the domain is still valid.
4. Check whether a rule matches REJECT or DIRECT
Go to Home → Global Routing → Config, then open Config to confirm which configuration is actually active. Ordinary rules are checked in order, and the first matching rule determines how traffic is handled. FINAL is reached only if none of the preceding rules match. Updating a subscription’s server list is separate from updating its rules; refreshing servers doesn’t mean the active rules have changed.
The examples below show rule structure only. They use example.com and documentation-only address ranges and aren’t ready-to-use configurations. Here, PROXY refers to a proxy policy; an actual configuration must have a matching policy name and a valid destination.
[Rule]
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX: The first line matches example.com and its subdomains, then sends them to REJECT. The later FINAL rule doesn’t override a rejection that has already matched.
- IP-CIDR: Matches a destination IP range. In this example, no-resolve means the rule won’t trigger a DNS lookup just to match it; it doesn’t disable all DNS requests.
- GEOIP: Matches using geographic data for the destination IP, not the website’s interface language or domain suffix. The result can also depend on the database and the address returned by DNS.
- FINAL: Handles traffic that didn’t match any earlier rule. If the active configuration uses FINAL,DIRECT, unmatched destinations connect directly; they don’t automatically use the server selected on Home.
If only certain websites fail, check the domain, matched rule, and final policy for the failed request. A webpage may load content from its main domain, login domain, script domains, and image domains. If the home page loads but sign-in fails, one required domain may be blocked. Fix the rule affecting the failed request instead of removing an entire set of filtering rules because of one resource.
DIRECT isn’t inherently an error; it means a direct connection. If the destination isn’t reachable directly on your current network, a DIRECT match can cause the request to fail. Likewise, if a rule selects a proxy policy, check which server that policy actually uses. Seeing PROXY in a rule isn’t the end of the investigation.
Takeaway: Fix the layer that actually matched
If the logs show that a destination was sent to REJECT, check the matching rule and its order. If a DIRECT request times out, check whether it should use a proxy. If it already went through a proxy but failed, go back to the server and DNS checks instead of repeatedly changing unrelated rules.
Common questions and restoring your settings
After checking all four areas, restore temporary diagnostic changes to settings you have a clear reason to use. In particular, don’t leave Proxy, On Demand, or temporary DNS changes in place just because they made a test work. Use these questions to check for missed automatic reconnections, rule fallbacks, or network differences.
Why does the connection turn back on after I switch it off?
Check whether Settings → On Demand is enabled. Note the original setting, temporarily turn it off, and disconnect manually to test again. Also check for other automatic connection management settings on the device. Restore the original setting when you’re done.
Why do webpages keep loading even though the latency is low?
A latency test isn’t a substitute for a complete request. Keep the same server selected and check whether the webpage request resolves successfully or fails during TLS or authentication. Then compare Proxy and Config. Don’t keep switching entries based only on their latency readings.
Proxy fixes it. Should I leave it on?
This points to the Config routing path as the first thing to check; it doesn’t mean all requests should use a proxy all the time. Switch back to Config and check the rule matched by the failing destination, the FINAL policy, and the server actually selected for that policy.
Wi-Fi fails but cellular works. What should I check first?
Keep the server settings unchanged. First make sure you’ve completed the Wi-Fi sign-in, then check that network’s DNS, outbound restrictions, and UDP availability. If the same configuration works on another network, that’s evidence of a network difference—not a reason to reinstall the app.
- Restore the Global Routing mode you need and confirm that the current Config is the one you expect.
- Restore the original On Demand setting and verify which traffic path is used after switching networks.
- Keep a change log with the issue, settings changed, and results before and after. This helps avoid repeating the same troubleshooting next time.
- If you need to contact your own provider, share only the necessary error time, protocol, network type, and redacted logs. Don’t share a full subscription link or credentials.