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

1. Why Normal Latency Doesn’t Mean Websites Will Load

A server’s latency value in Home only shows that the link covered by the current test method responded. Test methods differ in their targets and processes: establishing a connection to a port doesn’t mean the target domain resolved successfully. And even if one test URL is reachable, that doesn’t confirm that another site’s DNS, TLS, and HTTP requests are working.

Opening an HTTPS page typically involves resolving the domain to an address, establishing a connection according to the active policy, completing the TLS handshake, and then requesting the page. A failure at any stage can appear in the browser as “The webpage is not available.” With a Proxy policy, also consider whether the domain is resolved remotely. A DNS test on the device alone can’t verify the entire connection path.

2. Check the Scope of the Problem Before Changing dns-server

Note the failing URL, whether you’re on Wi-Fi or cellular, the selected server, the Global Routing setting, and the browser’s full error message. Record only the domain and what happened—never include subscription tokens, account details, or configuration secrets. Get subscription links from your service provider, and don’t share them in troubleshooting screenshots.

1. Keep Test Conditions Consistent

   Note the current server in Home, then go to Home → Global Routing and check the selected option. If you’re using Scene, first confirm which scene and policy are actually active. Don’t assume Scene works the same way as Config.

2. Compare Two Domains

   In Safari, open the failing URL and another site that normally works. If only one domain fails, first check its spelling, DNS records, and matching rules. If all sites fail, investigate the shared connection path.

3. Compare Network Environments

   Keep the server and configuration unchanged, switch between Wi-Fi and cellular, then retry the same URL. If the problem occurs only on a particular Wi-Fi network, check whether you need to complete a web-based sign-in first.

4. Check Automatic Connections

   To test with the connection off, go to Settings → On Demand and note the current setting. Temporarily turn it off if needed. Otherwise, an on-demand connection may reconnect and invalidate the disconnected test. Restore the original setting when you’re done.

5. Keep the Original Configuration

   In Config, save a copy or export a backup of the current configuration, and note which file is selected. Change only one setting in that file, save it, reconnect, and test again. Don’t update the subscription or import another full configuration at the same time.

If the system can resolve and open the same URL but it fails after connecting, focus on DNS settings in the configuration, rule matches, and the remote connection path. If it also fails while disconnected, investigate the system network or the website itself. Neither result alone proves the cause.

3. dns-server, System DNS, and Custom DNS Explained

dns-server sets the DNS upstream in the configuration file’s [General] section. Go to Config, open the action menu for the current file, and select Edit Config. Check the existing [General] section; menu labels may vary by interface. Don’t put the setting in [Rule] or add multiple copies of the same setting to one file.

System DNS is obtained from the current network and is useful as a baseline close to the system default. Custom DNS specifies an upstream, but it may not be reachable on every Wi-Fi or cellular network, and it won’t automatically fix incorrect rules, server outages, or website certificate issues. Private domains on a corporate network may also resolve only through the organization’s internal DNS.

[General]
dns-server = system

The example above only shows where the setting goes; it isn’t a complete configuration. If the file already has a [General] section, replace the relevant line in that section rather than overwriting the entire file with these lines. To compare a custom upstream, change only that line to dns-server = 1.1.1.1, save, reconnect, and test the same domain again. This address is shown to explain the syntax and may not work on every network.

4. Distinguish Missing Records, Resolver Failures, and Timeouts

A browser’s generic error message usually isn’t enough to identify the cause. If diagnostic logs show a DNS response code or error text, use the three categories below to narrow it down. The English terms are DNS response codes and common network error messages; they may not appear verbatim in every Shadowrocket screen.

A NOERROR response doesn’t necessarily mean a usable address was returned; it may contain no matching A or AAAA record. If an address was returned and a TLS certificate or HTTP error appears afterward, check the device time, destination site, connection path, and rules. Don’t keep treating it as a DNS-only problem.

5. After DNS Resolves, Check Global Routing and Rule Matches

In Home → Global Routing, Config applies policies from the active configuration, Proxy routes traffic through the proxy policy, and Direct uses a direct connection. Scene must be understood in the context of its current settings. Routing mode and DNS upstream selection are separate settings. Switching to Proxy doesn’t guarantee that a particular DNS service will be reachable.

• Config fails, Proxy works: After confirming the result under the same conditions, check whether the destination domain matches Direct, REJECT, or another unexpected policy. This points to a possible rule-path issue; it doesn’t conclusively rule out DNS.
• Times out after an address is returned: Check whether the destination connection succeeds, and compare the IPv4 and IPv6 paths if needed. An A record corresponds to IPv4 and an AAAA record to IPv6; an AAAA response alone doesn’t mean the IPv6 path is usable.
• Only images or sign-in fail: Check the domains of the failing resources, not just the domain in the address bar. A page may rely on several domains; a DNS or policy issue with just one can leave part of the page blank.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

This example explains how the rules work; don’t replace your existing rules with it as-is: DOMAIN-SUFFIX matches example.com and its subdomains. FINAL is the fallback when no earlier rule matches. Rules are evaluated in order, so a broader match earlier in the list may already determine the policy. IP-CIDR and GEOIP operate on destination IPs, so check the matching result after an address is obtained. They aren’t DNS server settings.

6. Verify Recovery and Review Common Questions

Once you find an effective change, keep the final configuration and a brief record of the original symptom, the line you changed, the network used, and the test URL and result. Restore Global Routing and On Demand to their usual settings, then test once more. If the issue returns with Config selected, continue checking the rules instead of relying on a temporary switch to mask the problem.

• The same URL that failed now opens consistently, and the page’s main resources load.
• The site still works with your usual Global Routing setting, with no temporary test mode left enabled.
• On Demand has been restored to its original setting, and your subscription and configuration backups are still available.
• Before sharing troubleshooting materials, remove tokens, authentication details, and connection keys from subscription URLs.