A normal latency result in Shadowrocket doesn’t mean every part of a web request is working. First distinguish DNS resolution failures from incorrect rule routing and failed connection handshakes, then check the DNS settings in your current Config. Change one setting at a time and retest the same domain. This guide is for users with a service provider and subscription who can connect but can’t browse normally. It focuses on identifying where a request fails, not on repeatedly changing settings.
1. Why won’t websites load when latency is normal?
A latency test’s result depends on how the test works: it may only check the connection to a server, or it may request a specific test URL. Even a successful test doesn’t prove that every website domain can be resolved, that every rule matches correctly, or that the target site’s TLS handshake will succeed. A latency reading is evidence that only part of the connection path is working.
This flow is a troubleshooting model, not a fixed sequence of internal operations. A domain rule may match before resolution; an IP rule may require an address first; and a proxy may resolve the destination domain remotely. If the server address itself is a domain, that address must be resolved before a proxy connection can be established.
- All domains fail: First check whether the DNS service is reachable, the current configuration is active, and the network requires sign-in authentication.
- Only some domains fail: Check their resolution results and matched rules. Don’t reset all network settings as a first step.
- Text loads, but images don’t: Page resources may come from other domains. Check requests for the resources that failed.
- An address is resolved, but the request still times out: Check the outbound route, IPv6 path, and destination service. Don’t assume DNS is at fault.
2. Compare the basics: network, mode, and configuration
Note your current network, the server selected in Home, the Global Routing setting, and the Config currently in use. Keep this record so you can restore the original state after testing. Don’t update a subscription, switch servers, and change DNS all at once—you won’t know which change made a difference.
- Check the underlying network. Temporarily disconnect Shadowrocket, then try a website that normally works without it over your current Wi-Fi or cellular connection. If public Wi-Fi displays a sign-in page, complete authentication first. Changing DNS usually won’t help if the underlying network itself isn’t working.
- Reconnect and reproduce the issue. Return to Home, confirm that your own valid connection configuration is selected, and try the same domain again. Note when it fails so you can find the matching entry in request records or logs.
- Check Global Routing. For everyday use with rule-based routing, select Config. Temporarily switching to Proxy can help determine whether rules are involved; Direct provides a comparison with direct connections over your current network. Restore the original mode after testing.
- Check the active configuration. Open Config and make sure the configuration you intend to inspect is selected—not just another file that you edited but haven’t enabled. If you’re using a Scene, check its mode and configuration first so a Scene change doesn’t affect your test.
- Retest the same targets. Record the results for opening the homepage, refreshing the page that failed, and visiting another domain. Fixing one domain doesn’t mean the whole issue is resolved.
3. DNS settings: understand the options before changing your current Config
Open Config, select the configuration in use, and enter its edit screen to review DNS-related options. For text configurations, check dns-server under [General]. Available options can vary with the configuration and app interface. Don’t confuse DNS in system Wi-Fi settings, DNS in the configuration, and a browser’s own encrypted DNS.
| Setting or concept | What it does | What to check |
|---|---|---|
dns-server | Specifies the DNS servers used by the configuration; supported formats depend on the app’s current documentation. | Check spelling, address format, and reachability. Don’t add a long list of unverified addresses at once. |
system | Uses the DNS source provided by the system. | Useful for comparison. If DNS on the current network is having problems, the system source may fail too. |
| DNS over HTTPS | Sends DNS queries over HTTPS, typically using TCP port 443. | Requires a complete, correct endpoint. Its hostname must resolve, and TLS and network access must work. |
| DNS over TLS | Sends DNS queries over TLS; standard services typically use TCP port 853. | Check that the network allows connections to the relevant port and that the hostname matches the certificate. |
| IPv6 and AAAA records | AAAA records provide IPv6 addresses. Getting an address and being able to connect to it are separate things. | If an AAAA record is returned but the IPv6 path isn’t working, the page may time out before trying another address. |
| Fallback | Uses an alternative DNS source when its conditions are met. | Read the trigger conditions carefully. Don’t assume every fallback source queries in parallel or automatically returns the fastest result. |
To make a controlled comparison, save a copy of the original configuration, then change only the DNS source to the system source. The following is an example of the relevant text configuration setting, not a complete configuration. Don’t overwrite other content in your existing file:
[General]
dns-server = systemAfter saving, confirm that the configuration is still active, then disconnect and reconnect to test. If the system source works but your original encrypted DNS source doesn’t, check the connection path to the original endpoint. The encrypted DNS hostname itself may need to be resolved first; repeatedly refreshing a page won’t bypass the need to establish that connection.
4. Check rule matching: successful DNS resolution can still lead to the wrong route
In Home, temporarily change Global Routing from Config to Proxy. If the same page loads, the issue may involve rule selection, the direct connection path, or how DNS works with different outbound routes. That alone doesn’t prove the original DNS is faulty. Switch back to Config and inspect the rule actually matched by the request.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThese are syntax examples only: example.com and 192.0.2.0/24 are documentation examples, not destinations to visit or routing policies to copy. Rules are evaluated from top to bottom in configuration order, and evaluation stops at the first match. FINAL handles requests that remain unmatched.
DOMAIN-SUFFIX: Matches a domain suffix. Check whether the target domain or a resource domain is routed through an unsuitable outbound before other rules can match it.IP-CIDR: Matches a destination IP range. In the example,no-resolveprevents an active DNS lookup solely to match this rule. It doesn’t mean the app will never need DNS to access the destination.GEOIP: Matches an address against a geographic database. Whether a domain request needs to be resolved first depends on the matching process and related settings; the rule name alone isn’t enough to tell.FINAL: Handles requests that didn’t match an earlier rule. If its outbound route is unavailable, access can still fail even after DNS returns an address.
Bottom line: find the rule matched by the failed request before deciding whether to change DNS or the outbound route
If Proxy works but Config doesn’t, switch back to Config and check the request record for the domain. Change DNS only when the evidence points to a resolution timeout or an incorrect answer. If the record already shows a destination address and the request reaches the connection stage, focus on the matched rule and outbound route.
5. Use logs to distinguish DNS failures, timeouts, and TLS errors
Find the entry in the app’s request records or logs using the time of the failure and the domain you just tried to open. Error wording can vary across network layers. The examples below are fragments that may appear in logs; they aren’t guaranteed to match the wording in every interface. When diagnosing the issue, check which address and stage the error refers to.
Error: no such host
Cause: The resolution step didn’t return a usable host address. The domain may be mistyped, the record may not exist, or the upstream resolver may have returned a negative response.
What to do: Check the spelling, then compare results using another resolver on the same network. If only your service provider’s server hostname fails, ask your provider to confirm that the address is valid.
Error: i/o timeout
Cause: A network operation didn’t finish in time. It could be a DNS query or an outbound connection; these words alone don’t identify which.
What to do: Check whether nearby log entries point to a DNS server, website, or proxy server. Test another DNS source only if the timeout occurred during a DNS query.
Error: connection refused
Cause: The destination explicitly refused the connection. Check the destination service and port rather than waiting for DNS.
What to do: Check the address and port the app actually tried to reach. If the refused connection was to an encrypted DNS endpoint, check that the service is listening on the relevant port.
Error: certificate verify failed
Cause: TLS certificate verification failed, possibly because of the device’s date and time, the endpoint hostname, or the certificate chain.
What to do: Check the system date and time and the endpoint address, then confirm the configuration with the relevant service provider. Don’t hide the problem by disabling certificate verification.
If the logs show a resolved IP followed by a connection or TLS error, focus on that stage instead. Don’t test HTTPS by entering a website’s IP directly in the browser’s address bar: the certificate name, SNI, and virtual host selection may change, so it isn’t equivalent to visiting the domain.
6. Retest after changes and common questions
After each change, save it, confirm the active Config, reconnect, and revisit the same domain. Browser cache or an existing connection may temporarily preserve the old result; close the affected page and open it again. Try these low-impact steps before making broader changes to system settings.
- On the original network, test the failing domain and one that normally works. Record whether each one resolves.
- Keep the server, Global Routing, and Config unchanged. Compare Wi-Fi with cellular data; note that cellular use may incur charges.
- If the issue occurs on only one network, focus on that network’s DNS reachability, authentication status, and port restrictions.
- Restore the original Config mode and On Demand conditions, then confirm that everyday rules, page resources, and other apps work as expected.
If latency shows a value, does that rule out a connection issue with my service provider?
No. Return to Home, keep the same server selected, and visit the failing domain. Then check the request record for an error during the connection stage. A successful test URL and a successful target website are two different results. If you need to verify subscription or server details, get valid information from your service provider.
Will switching to encrypted DNS definitely fix the problem?
Not necessarily. Save the original settings in Config, then change only the DNS source to compare. DNS over HTTPS and DNS over TLS also require a reachable endpoint and working TLS. If the actual failure is with the rule’s outbound route, changing resolvers won’t fix the underlying problem.
Websites won’t load on Wi-Fi, but work on cellular. What should I change?
Keep your Shadowrocket configuration unchanged at first. Check whether Wi-Fi requires authentication and whether DNS is manually set in the system’s Wi-Fi details. If you use encrypted DNS, check whether that network allows access to the relevant port. Don’t change multiple settings at once.
Websites still won’t load after updating my subscription. Should I keep refreshing?
No. A subscription update retrieves connection entries; it doesn’t fix DNS or rules in the current Config. First confirm the selected entry in Home, then return to Config and inspect the configuration. If the subscription update itself fails, see the subscription guide’s update instructions.
If turning off IPv6 fixed it, should I leave it off permanently?
That only indicates that the address family or its connection path needs further investigation. Record the original setting and compare A and AAAA results with the connection logs. Check whether IPv6 works on your network before deciding which setting to keep. Don’t assume one test applies to every network.
For further troubleshooting, tell your service provider the failing domain, when it happened, your current network, Global Routing setting, and the stage where the error occurred. Before sharing logs, remove subscription URLs, tokens, passwords, and other authentication details. For more basic steps, see Troubleshooting in the user guide; for subscription updates, see the Subscribe update guide.