Shadowrocket DNS Troubleshooting: Websites Won’t Load Even Though Latency Looks Normal

1. Why Normal Latency Doesn’t Prove DNS Is Working

Shadowrocket’s Connectivity Test checks connectivity for the selected test method. The time shown reflects only the target and route involved in that test. Even a successful result doesn’t prove that every website’s domain can be resolved, every outbound route is reachable, or every HTTPS handshake will succeed. Check the test method and target before interpreting the result; don’t rely on a latency number alone.

Loading a web page also requires resolving its domain to an address, selecting a routing policy, establishing a connection, and completing a TLS handshake. The steps below are a troubleshooting model, not a claim that the client always processes everything in strict sequence. For example, a domain rule can match before an IP is resolved, while an IP-based rule may require a resolved address.

To identify a DNS problem, look for evidence that resolution failed. A browser message saying it can’t find the server, or a system lookup tool that returns no address, is more conclusive than a page that simply keeps loading. If an address was resolved but the connection or certificate check failed, investigate the outbound route, rules, system time, or the website itself.

• All domains fail: Check whether the resolver is reachable, whether the current network requires a sign-in page, and whether the VPN connection is actually staying up.
• Only a few domains fail: Check the spelling, per-domain DNS settings, matching rules, and the status of the affected website.
• Text loads, but images don’t: Note the domains of the failed resources. The main site, images, and APIs may use different domains and rules.
• Direct IP access also fails: This doesn’t immediately rule out DNS or confirm a connection failure. HTTPS sites typically rely on the correct domain, SNI, and certificate, so accessing a bare IP is not a reliable comparison.

2. Record the Current Setup, Then Run Three Comparisons

Before changing anything, note the current Home → Global Routing selection, the server in use, the active configuration in Config, and the current values in Settings → DNS. Duplicate the configuration for troubleshooting instead of repeatedly editing your only copy. Subscription content may be overwritten during an update, so distinguish your manual settings from those supplied by your provider.

1. Compare on the same network: On the current Wi-Fi, test one website that normally works and the site that’s failing. Record the full error, not just “won’t load.” If you disconnect for comparison, test only sites that are allowed to connect directly, and check whether Settings → On Demand reconnects under its configured conditions.
2. Compare across networks: Keep the server, Config, and DNS settings unchanged, then switch from Wi-Fi to cellular or to another known-working network. If the problem occurs only on one Wi-Fi network, first check its sign-in page, DNS restrictions, and router settings.
3. Compare routing modes: Note the original selection, then temporarily compare Config and Proxy under Home → Global Routing. Proxy helps compare how ordinary web traffic behaves when sent through the proxy, but it doesn’t mean all DNS requests automatically use the proxy. Restore the original selection when you’re done.

3. Settings → DNS: Addresses, Defaults, and Recommended Values

Open Settings → DNS and check whether it currently uses the system resolver or a custom one. There is no single default address that applies to every device: the active value can depend on the platform, existing settings, and imported configuration. Use the values shown on your device and in the active Config as your reference. If you’ve set a custom value, save it before testing one change at a time.

The resolver address determines where queries go; the transport determines how they’re sent; and per-domain settings determine whether a specific domain uses a different resolution path. Check these separately. Changing the resolver won’t fix an incorrect PROXY policy or restore a connection to an unreachable proxy server.

Adding multiple DNS addresses does not automatically fix anything. Query and fallback behavior varies by implementation, so don’t assume the second address will take over whenever the first times out. First confirm that a single resolver is reachable, then restore settings as needed.

If the encrypted DNS server is specified by hostname, but resolving that hostname depends on the same service that hasn’t connected yet, a startup dependency issue can occur. Check the bootstrap resolution and routing requirements from your configuration provider rather than disabling certificate verification. Don’t casually replace the hostname in an encrypted DNS address with an IP; doing so may break certificate name matching.

4. Check DNS Overrides and Rule Order in Config

If changing only Settings → DNS makes no difference, return to Config and inspect [General], [Host], and [Rule] in the active configuration. DNS options, domain mappings, and rules can all change the route a request takes. Don’t assume the address shown in Settings is the resolver ultimately used for a domain; confirm against the configuration and any available request records.

Rules are evaluated from top to bottom, and the matching rule’s policy is applied. The examples below demonstrate order only; they are not a complete configuration to replace your existing file. PROXY must refer to a policy or policy group available in your current configuration, and the example domain must be replaced with the domain you’re troubleshooting.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN-SUFFIX,example.com,PROXY: Matches the domain and its subdomains. If an earlier rule already matches, a rule added later may never take effect.
• IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Routes this private address range using DIRECT. no-resolve means not to trigger a domain lookup just to match this IP rule; it does not turn off DNS for the entire client.
• GEOIP,CN,DIRECT: Matches using an IP geolocation database. Results depend on the address and database; check the matched rule against the actual resolved IP.
• FINAL,PROXY: The fallback policy used when none of the preceding rules match. It cannot replace DNS configuration or fix an incorrect domain mapping.

If a domain matches REJECT, check whether the filter rule was intentionally enabled. If it matches DIRECT and fails while proxying works, adjust the policy for that domain; you don’t need to change all DNS settings first. Company intranet domains often require internal DNS together with DIRECT. A public resolver cannot replace an internal domain service.

5. Use the Exact Error to Distinguish DNS, Connection, and Certificate Problems

The messages below are examples that browsers or command-line tools may display; they are not fixed messages used on every Shadowrocket platform. Record the app showing the error, the target domain, and when it occurred, then compare with the client’s request records. Not every browser error is a DNS failure.

On Mac, Windows, or Linux, you can use the built-in nslookup utility for an additional comparison. example.com below is a sample domain; replace it with the domain that’s actually failing. The first command queries the default resolver used by the tool; the second specifies a public resolver:

nslookup example.com
nslookup example.com 1.1.1.1

Check the response for the queried server, whether an address was returned, and any timeout or NXDOMAIN result. This tool may not reproduce a browser’s built-in encrypted DNS or all of Shadowrocket’s domain policies, so use it as supporting evidence, not as a substitute for the client’s own query results. If the browser has Secure DNS enabled separately, note that setting too, then compare with system resolution under controlled conditions.

6. Retest After Changes, Then Restore Settings If Needed

DNS responses may be cached separately by the client, operating system, and browser. Old connections or responses can affect results after a setting changes, so refreshing a page once isn’t enough to conclude that the change had no effect. Don’t repeatedly update a subscription to clear caches either: an update may also change the server and configuration, making comparisons inconclusive.

1. Save one change: Confirm that the active Config hasn’t changed, and note the DNS or rule values before and after the change.
2. Reconnect: If a brief interruption is acceptable, turn the connection switch on Home off and back on. Check whether Settings → On Demand reconnects automatically.
3. Make a fresh request: Close the affected page and reopen it; if needed, quit and relaunch the browser. A private window can help rule out some site data, but it won’t necessarily clear the system DNS cache.
4. Retest the same target: Use the same domain, network, and Global Routing option. Check whether the error changed, then verify that sites that worked before still work.
5. Keep or revert: Keep a change only if the result is reproducible. If there’s no improvement, restore the original value and move on to the next check; don’t stack unverified changes.

7. Common DNS Troubleshooting Questions

For more help, see the Rules Manual to check the matching order, or the Connection Troubleshooting Guide to distinguish DNS from outbound issues. This site does not provide, sell, or recommend servers or subscriptions. For account status and server-side settings, contact your own service provider.