Shadowrocket DNS Settings: Troubleshooting Websites That Won’t Load Despite Normal Latency

1. Distinguish a latency test from loading a website

A latency test only shows that the connection covered by that particular test received a response at that time. It may not access the website that is failing, or use all the same resolution and connection steps as the browser request. So even with a latency reading, a request can still fail during domain resolution, policy selection, the TLS handshake, or page resource loading.

Note a specific failing domain, the time of the failure, the network in use, and the current Global Routing setting in Home. Don’t use “all websites are down” as a substitute for test results: a page may load resources from its main domain, image domains, and a login endpoint. A page with some resources failing is a different problem from a main domain that cannot be resolved at all.

2. Keep Home, Config, and On Demand test conditions consistent

Before troubleshooting, save a copy of the current configuration or export a backup, and note the original Global Routing setting. This guide focuses on Config because it lets you inspect the rules in your configuration. Proxy and Direct can be used for brief comparisons, but neither proves on its own that DNS is working or failing. Scene is not a useful comparison unless you first document the behavior of the current scene.

1. Record the current state

   Go to Home → Global Routing and note whether it is set to Config, Proxy, Direct, or Scene. Also note the currently selected server. Don’t change the server and DNS at the same time during testing.

2. Check the active configuration

   Go to Config and confirm which configuration file is selected. Tap the information button beside that file, choose Edit Plain Text, and check the saved [General] and [Rule] sections—not a file that is not currently in use.

3. Check automatic connections

   Go to Settings → On Demand and note whether it is enabled and which conditions are configured. If the connection turns back on after you disconnect, check this setting first. If you temporarily disable it, note its original state and restore it after testing.

4. Change one variable at a time

   Stay on the same Wi-Fi or cellular network, then visit the same domain repeatedly with Home → Global Routing → Config selected. After each change, save and reconnect before making a new request, and record the result.

If the problem occurs only on a particular Wi-Fi network, first check whether it requires a web-based sign-in. Until sign-in is complete, DNS requests and HTTPS connections may be restricted; editing rules repeatedly will not authenticate you to the network. If you compare with another network, treat that as a separate test and don’t combine it with other setting changes.

3. What to check in DNS settings

The DNS upstream returns addresses for domain names; rules choose the policy for a request. These are separate settings. In the active configuration’s [General] section, dns-server specifies DNS servers. Check the actual values, address format, and reachability before changing them. A familiar-looking address is not necessarily reachable on your current network.

This minimal snippet shows where the fields go; it is not a template for replacing your entire configuration. It sets the DNS upstream to the servers provided by the system, making it a clear comparison case, but it may not suit every network. Edit the existing field, keep the rest of the configuration, and don’t add multiple entries with the same name.

[General]
dns-server = system

When using an encrypted DNS endpoint with a hostname, consider how that hostname is resolved first and whether the endpoint can be reached. Encryption changes how queries are transmitted; it does not guarantee correct results or a working connection to the website. If the upstream connection itself fails, check its reachability instead of adding more addresses to mask the problem.

• Make changes only in the configuration currently in use. After updating a remote configuration, check whether your local changes were retained.
• Don’t enter a website URL, subscription link, or server connection parameters in dns-server.
• To investigate IPv6 issues, compare results on the same network. Permanently disabling IPv6 is not a universal fix for DNS problems.

4. Use rule matching to distinguish DNS issues from routing issues

With Config selected under Global Routing, rule order affects the final policy. Check more specific domain rules first, then address rules and the final FINAL rule. A domain may resolve correctly while its request is routed through an unavailable path; changing DNS won’t directly fix a policy mismatch.

This snippet demonstrates rule syntax only; the example domain and reserved documentation address do not represent a service. Don’t paste the whole snippet over your existing rules. Find the corresponding entries in your own configuration and check connection logs to confirm which rule matches. In particular, FINAL,DIRECT is the final policy in this example, not a general recommendation.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

5. Choose the next step based on the actual error

Interpret an error in the context of the stage that produced it. The examples below are messages that may appear in DNS responses or network logs; they are not messages Shadowrocket displays for every failure. Use each diagnosis only when the corresponding text appears in your actual records. A browser’s generic “can’t open this page” message does not, by itself, mean NXDOMAIN.

If you see a certificate error, check the device’s date and time, the domain being accessed, the certificate name, and the HTTPS connection. Don’t “fix DNS” by ignoring certificate validation. If the page text loads but images don’t, check the rules and DNS resolution for each resource domain instead of repeatedly testing only the main site.

• Only one domain fails: Check the spelling, DNS response for that domain, and any specific rule for it. Then check whether the website itself is having an issue.
• Failures across the same network: Check network sign-in status, system DNS, and upstream reachability. If you switch networks, keep all other conditions the same.
• Resolution succeeds but the connection fails: Check address reachability, IPv4 / IPv6 routing, policy, and TLS instead of repeatedly changing DNS addresses.
• It works occasionally after a change: Consider cache expiration, reconnecting, and the setting change as separate factors. One successful request is not enough to establish the cause.

6. Retest, restore settings, and record what you found

After changing DNS, existing connections may not resolve the domain again immediately, and the browser or system may retain cached data. Save the configuration, reconnect, and make a new request; if needed, close and reopen the page. Don’t treat repeatedly refreshing the same page as an independent test, and don’t assume reconnecting clears every app’s cache.

After access is restored, undo temporary changes one at a time and keep only those that remain effective in repeated comparisons. In particular, restore the original On Demand and Global Routing settings so you don’t leave the device in a temporary Proxy or Direct state. If the configuration is updated afterward, check whether the active file or relevant fields have changed.

Before sharing records with your own provider or support channel, hide the full subscription URL, tokens, UUIDs, passwords, and other credentials. Don’t publish your entire configuration. This guide covers client troubleshooting only and does not provide, sell, or recommend servers or subscriptions. A one-time client purchase is not a network service plan.