Turning on the Shadowrocket connection switch only confirms that the client has started connecting. It does not confirm that the server, DNS, or websites are working. This guide is for users who already have their own provider and subscription, can open the app, but can’t access websites. Check in this order: basic network → server → Global Routing → DNS → rules. Change one setting at a time, retest the same URL, and keep a record of what resolves the issue.
Establish a repeatable baseline
Before troubleshooting, note your current network, the server selected in Home, the Global Routing mode, and the configuration file in use under Config. Back up your configuration before making changes. Don’t update your subscription, switch servers, and change DNS all at once; even if things start working, you won’t know which change fixed the problem.
The steps below refer to Home, Config, and Settings in the iPhone and iPad interfaces. On other platforms, check the equivalent settings; system VPN prompts may differ between devices. Use a website you normally visit that is currently failing, rather than an unfamiliar link, as your test URL.
-
Pause On Demand
Note the current setting under Settings → On Demand, then pause automatic connection triggers while troubleshooting. This prevents the connection from turning back on after you switch it off manually. Restore the original setting when you’re done.
-
Check the basic network connection
Turn off the connection switch in Home and open a website you can normally access directly. If it still won’t load, first check for Wi-Fi login requirements, a router outage, or cellular data permissions. Don’t change rules yet.
-
Use fixed test URLs
Choose one URL that works directly and one that’s failing, and record the results. Reload the same full URL for each test so you can compare results for the same website.
-
Reconnect
Make sure no other VPN connection is active, then turn on the Shadowrocket connection switch. After changing a setting, send a new request; don’t rely on a page already cached by your browser to confirm that the issue is fixed.
Confirm that the server is working
Seeing a server entry in Home doesn’t mean it’s still valid. First make sure the intended entry is selected, then run a Connectivity Test. Results depend on the test method and target: a latency result only shows that this test succeeded; it doesn’t prove that every domain, protocol, or website is reachable. A single timeout doesn’t prove that the entire subscription is invalid, either.
Open the entry’s details and compare each setting with the information from your provider. The address, port, authentication details, encryption method, and TLS-related fields must match. Server ports don’t have one universal default; don’t assume that the commonly used web port 443 applies to every protocol. If the server address is a domain name, make sure it resolves first.
- All entries time out: Switch from Wi-Fi to cellular data and test again. If it fails only on one network, check that network’s access restrictions rather than changing server settings across the board.
- Only one entry fails: Compare it with another known-working entry from your own subscription. Ask your provider to check the failed entry’s status, quota, and validity period.
- It still points to the old address after updating: Update your own subscription in Home, then check the update result and entry details. A successful update only means the data was retrieved and parsed; it doesn’t confirm that the remote server is working.
- The update itself fails: Keep the existing configuration and first check that your subscription URL is valid and your network is working. Don’t post a private subscription URL in a public forum; its token may grant access to your account.
If the error details include any of the messages below, use them to narrow down the cause. Messages vary by protocol and operating system; these are clues, not fixed text that must appear in the interface.
Error: connection refused
Cause and what to check: The remote server or an intermediary explicitly rejected the connection. This commonly happens when nothing is listening on the port or an access policy blocks the request. Check the server address and port, and ask your provider to confirm the listener is active. Changing DNS repeatedly won’t fix a port refusal.
Error: i/o timeout
Cause and what to check: The operation didn’t complete in time. The issue could be with the network path, remote response, or a DNS lookup. Check the logs to see where the timeout occurred, then try another network or compare with another working entry you already have. This message alone doesn’t mean the password is wrong.
Error: no such host
Cause and what to check: The domain lookup didn’t return a usable result. First check whether the domain in the error is the server domain or the target website’s domain. Then verify the spelling, DNS settings, and whether the domain still exists.
Use routing modes to isolate rule issues
Go to Home → Global Routing, note the current mode, and then run a brief comparison. Proxy, Direct, Config, and Scene are not connection-quality ratings, and switching to a later option won’t make the connection more reliable. In particular, an enabled connection switch doesn’t guarantee that the current request is going through a proxy server.
| Mode | What it does | How to use it for troubleshooting |
|---|---|---|
Proxy | Routes requests through the proxy instead of applying the usual configuration rules. | Use it to check whether the selected server can reach the target. DNS, protocol, system routing, and other factors may still affect the result. |
Direct | Routes requests directly. | Use it to compare direct access on the current network. Turning on the connection switch doesn’t make this a proxy connection. |
Config | Uses the rules in the current configuration to decide how to handle requests. | If Proxy works but Config doesn’t, first check which rules and policies are being matched. |
Scene | Selects behavior based on the configured scene conditions. | Check which scene is currently active and how it’s configured. To reduce variables, temporarily switch to Proxy or Config for comparison. |
If one mode works, keep that path for now
On the same network, with the same server and URL, if Proxy works but Config doesn’t, leave the server settings alone and check the matched rules and policy groups in the current configuration. Don’t start by reinstalling the app or reimporting every subscription.
If both Proxy and Config fail, don’t assume the rules are to blame. Recheck the server, then check DNS. After comparing, restore the Global Routing mode you normally need; a temporary test mode isn’t a permanent fix.
Tell DNS issues from connection failures
DNS resolves domain names to addresses, but the connection can still fail later at the server, TLS, or target website. A browser that keeps spinning doesn’t by itself prove there’s a DNS problem. Likewise, a DNS response doesn’t prove that the service at that address is reachable. Use the requested domain, resolved address, and error stage in the request log to narrow it down.
In Config, find the configuration currently in use and open it for editing. Check dns-server under [General]. If a custom DNS server is already set, back up its value before testing one change at a time. The example below shows how to use system DNS; it doesn’t mean you should replace your entire configuration with these two lines.
[General]
dns-server = system- Test system DNS first: Save the change, reconnect, and visit the same website that failed. If it works, check whether your original custom DNS server is reachable and how traffic gets to it; don’t assume all custom DNS servers are at fault.
- Check DNS dependencies: If the server address is a domain name, it may need to be resolved before the proxy connection can be established. If that lookup fails, changing the target website’s rules alone won’t establish a server connection.
- Rule out caching: Send a new request and, if needed, reconnect or restart the relevant app. Don’t change several DNS servers in a row and try to infer every cause from one successful result.
- Don’t replace an HTTPS domain with its IP address: This can cause a certificate name or SNI mismatch and introduce a new error. It isn’t a general-purpose way to test DNS.
Check rule order and FINAL
When Global Routing is set to Config, open Config and confirm which file is actually enabled. Don’t edit a copy that isn’t in use. Rules are usually matched in order, so an earlier broad rule may take effect before a more specific one later in the list. FINAL provides a fallback policy for requests that didn’t match any earlier rule.
Here’s a minimal example to illustrate rule matching order. example.com is a sample domain; don’t use it in place of the website that’s actually failing. Back up your configuration before testing this snippet. It doesn’t cover all everyday browsing needs or fix server or DNS issues automatically.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT| Rule keyword | What the example means | What to check |
|---|---|---|
DOMAIN-SUFFIX | Matches the specified domain and its subdomains. | Enter the domain itself, without a scheme, path, or port. Check for other domains the website actually requests. |
IP-CIDR | Matches an IPv4 range; the example is a private address range. | no-resolve means this IP rule won’t trigger a DNS lookup. It doesn’t disable DNS globally. |
GEOIP | Matches against an IP geolocation database. | Classification may depend on the resolved address and database. It doesn’t necessarily indicate where the domain is based. |
FINAL | Sets a policy for requests that didn’t match any earlier rules. | Put it at the end of the rule list. In this example, DIRECT sends requests that matched no earlier rule directly. |
If only some websites won’t load, check the matched rule and final policy in the request log. If a site that should use a proxy matches FINAL,DIRECT, fix its routing rule first. If it matches a custom policy group, also check which server the group currently selects. A rule can match correctly even when its selected route isn’t working.
- Put specific domain rules before related broad matches so an earlier rule doesn’t take precedence.
- Check that the custom policy name exists and is spelled correctly. Don’t mistake a name in a comment for a valid policy.
- After making a change, save it and confirm the file is still enabled. Send a new request and check whether the matched rule changed as expected.
Retest based on what you observed
Once you’ve narrowed down the issue, restore everyday settings such as On Demand and test again. In particular, after switching from Wi-Fi to cellular data, make sure scene conditions and automatic connections haven’t invalidated your earlier results. Use the questions below to decide what to keep and what to check next.
Why won’t websites load even though latency is shown?
A latency test and a website visit may use different targets and processes. Keep the same server, temporarily switch to Proxy under Home → Global Routing, and test the failing URL. Then check DNS and the error stage. A latency number alone doesn’t confirm that websites are reachable.
Should I reinstall if only one website won’t load?
Not yet. In Config, check which rule and policy the website actually matches. If only that site fails in Proxy mode too, check the website’s status, certificate validity, and whether it displays an access restriction.
Wi-Fi fails but cellular works. What should I change?
Keep the server and configuration unchanged, then test the same URL on both networks. Complete any Wi-Fi login first, then check that network’s DNS and access restrictions. Also check the network conditions under Settings → On Demand and Scene; don’t change subscription settings across the board.
The connection still fails after updating my subscription. What next?
In Home, confirm that the new entry is selected and check its validity period, quota, and address. If another existing entry works, send your provider the time of failure, network type, and a redacted error message. Don’t share the full subscription URL or authentication details publicly.
To investigate further, record these seven items: network type, Global Routing mode, server test result, DNS comparison result, matched rule, final policy, and exact error message. Remove subscription tokens, passwords, UUIDs, and other authentication details before sharing. For configuration keyword definitions, see Configuration Fields. Don’t paste in an unfamiliar full configuration to mask an undiagnosed problem.