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

1. Why Normal Latency Doesn’t Mean a Website Will Load

A latency test only reflects the network path covered by its test method. If it checks only whether a connection to the server port can be established, it doesn’t confirm that a target domain resolves or that the server can reach the website. Even an HTTP test reflects only the test URL and network path at that moment; it can’t replace checking the website that’s actually failing.

When you open an HTTPS site in a browser, the process typically involves resolving the domain, connecting to the destination, negotiating TLS, and sending an HTTP request. DNS provides the address associated with a domain; it won’t fix expired server credentials or remove access restrictions imposed by a website. Even if the connection appears normal, identify which stage the request is getting stuck at.

2. Establish a Repeatable Baseline

Before you begin, back up the current configuration in Config and note the selected server in Home and the current Global Routing mode. If you recently updated a subscription you already use, note whether the server address, port, or authentication details changed. A successful subscription refresh only means the request to retrieve its contents worked; it doesn’t confirm that every service listed is usable.

1. Record a Failing Example

   Choose one domain that fails and one that usually works. Record the full error message, the time, and whether you’re on Wi-Fi or cellular. Use the same pages for each test to avoid confusing results caused by changing the test target.

2. Check the Server

   In Home, verify the selected server and run an available latency or connectivity test. If the server itself won’t connect, check its address, port, and credentials against the details for your existing service before investigating DNS settings.

3. Record the Routing Mode

   Open Home → Global Routing and note whether the current mode is Proxy, Direct, Config, or Scene. Keep it fixed while troubleshooting. If you use Scene, confirm which scene is active so a network change doesn’t also alter routing behavior.

4. Rule Out Automatic Reconnection

   Check Settings → On Demand. If you need to compare behavior with the connection off and on, note the original setting, then temporarily disable automatic activation to prevent the connection from restarting as soon as you turn it off. Restore the original setting when you’re done.

5. Change One Setting at a Time

   Change just one setting, save, reconnect, and revisit the same domains. Record the result, then decide whether to keep or undo the change. Don’t change the server, DNS, and entire configuration at the same time.

3. Distinguish System DNS from Configuration Overrides

In Config, open the configuration currently in use, enter edit mode, and check whether dns-server is set under [General]. Don’t check only a different, inactive configuration. If other DNS-related settings are in use, record those too so you can account for settings that may override the field you change.

system means to use the DNS provided by the system. It’s useful as a baseline, but it doesn’t mean every network will return the same result: Wi-Fi, cellular, and the device’s DNS settings can all affect system resolution. If you specify a resolver manually, confirm that it’s reachable on the current network, not just that its address is entered correctly.

# Relevant fields shown for reference only; do not use this snippet to replace the entire configuration.
[General]
dns-server = system

The snippet above shows where the field goes. For testing, edit the relevant line in the existing [General] section, leave the other settings intact, and avoid adding duplicate sections or fields. Note the old value before saving, reconnect, and test again. If there’s no improvement, restore the old value before checking the next layer.

Encrypted DNS changes how queries are sent; it doesn’t automatically fix every DNS problem. Queries can still time out if the resolver endpoint is unreachable or its domain can’t be resolved initially. A browser or another app may also use its own DNS method and return different results from Shadowrocket. Use the same app throughout your tests.

4. Use Error Messages to Tell Missing Records, Server Failures, and Timeouts Apart

The following are common raw status codes or error strings used in DNS diagnostics; they aren’t necessarily displayed exactly as written in every Shadowrocket screen. Browsers may show only a general error. Check the logs, request details, or lookup results available to you rather than inferring the cause from “This site can’t be reached” alone.

A missing AAAA record isn’t necessarily an error; some domains publish only A records. Likewise, a successful query with no record of the requested type is different from NXDOMAIN. Record the query name, record type, and response status instead of noting only that there’s “no IP.”

5. After Resolution Succeeds, Check Global Routing and Rules

Proxy, Direct, Config, and Scene in Global Routing are routing modes, not DNS server options. Proxy routes through a proxy; Direct connects directly; Config follows the active configuration; and Scene follows the active scene’s settings. Switching modes can help you compare results, but it doesn’t prove that one mode always performs all resolution locally or remotely.

If the same domain works in Proxy but fails in Config, check which rule is actually matched in Config. If it works in Direct but fails in Proxy, also check the route from the server to the destination website. Neither symptom alone proves there’s a DNS problem.

# Explains rule syntax and order only; this is not a complete configuration to use as a replacement.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN-SUFFIX,example.com,DIRECT matches the domain and its subdomains. Check whether the failing domain matches an earlier rule with an unexpected policy.
• IP-CIDR matches an address range. 192.0.2.0/24 in this example is a documentation range, not a real service address.
• no-resolve prevents an IP rule from triggering a DNS lookup just to match that rule. It doesn’t disable DNS for the entire configuration or prevent a request from resolving an address at another stage.
• GEOIP matches based on the region associated with an IP address. Whether a domain request needs to be resolved depends on the available address and rule parameters.
• FINAL goes at the end and handles requests that didn’t match any earlier rule. Make sure the fallback policy points to the intended route; checking a single domain rule isn’t enough.

6. Compare Wi-Fi, Cellular, and IPv6

If the same configuration fails on Wi-Fi but works on cellular, the network environment is an important variable, but that doesn’t prove Wi-Fi DNS is at fault. The network may also restrict server ports, affect IPv6 routing, or require sign-in first. After switching networks, reconnect and confirm that Global Routing and the selected server haven’t changed with the active scene.

• Complete network sign-in first: If public Wi-Fi requires a login, complete its sign-in process before testing Shadowrocket. Redirects or blocked connections before sign-in can make several websites fail at once.
• Test the same domain: Visit the same page on both networks. Record whether DNS returns a result, whether the connection times out, and whether an HTTP status code appears; don’t compare latency alone.
• Check the IPv6 route: If a domain returns AAAA but the current network can’t connect over IPv6, pages may stall or some resources may fail. First confirm which address family the failing request actually uses, then run a temporary comparison. Disabling IPv6 isn’t a universal fix.
• Account for cached results: Reconnect and reopen the test page. An app may keep its own DNS cache or connection pool, so you may need to quit and reopen it. Reconnecting alone doesn’t guarantee that every app’s cache is cleared.

7. Common Questions and When to Stop Troubleshooting

Before you finish troubleshooting, retest both the original failing domain and the working control domain. Restore any temporarily disabled On Demand or original scene settings. Keep only the smallest set of changes that explains the improvement, and undo tests that made no difference. If you need to contact support for your existing service, provide the time of failure, network type, relevant errors, and a redacted configuration snippet. Remove subscription tokens, passwords, and other authentication details.