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

Normal latency doesn’t guarantee websites will load

A latency test only shows that its target responded using the test method. Whether it involves DNS resolution, proxy authentication, or access to a destination website depends on how the test works. A successful test doesn’t prove that every site will load. To open an HTTPS page, the browser also needs to resolve the domain, connect to the destination, complete the TLS handshake, and receive a server response. A failure at any step can prevent the page from loading.

This sequence helps narrow down a failure; it doesn’t mean every request follows exactly these internal steps. Domain rules can match before the destination IP is known, while IP rules may require a DNS result. Also distinguish between two lookups: if the proxy server is specified by domain name, that name must be resolved first. Where the destination website’s domain is resolved depends on the protocol, outbound route, and configuration.

• Nothing loads: Check basic connectivity, connection status, and DNS reachability first. Don’t immediately rebuild your subscription.
• Only one domain fails: Check the spelling, DNS result, matching rule, and the website’s status.
• The homepage loads, but images or sign-in fail: These resources may use different domains. Check each request rather than looking only at the domain in the address bar.
• Wi-Fi fails but cellular works: Compare network authentication, DNS transport, and the IPv6 path before investigating service settings.

Start with a repeatable test

Before testing, note the failing URL, network, server selected in Home, and Global Routing setting. Compare two sites that usually work with one that fails. Change one setting at a time, then revisit the same sites. The steps below assume you already have your own server or subscription; purchasing the client does not include a connection service.

1. Record the current settings

   In Config, confirm which configuration is active and save a backup first. Note the current Home → Global Routing option, selected server, and DNS values so you don’t mistake troubleshooting changes for your permanent setup.

2. Check basic connectivity

   Temporarily disconnect and try a site you can normally access directly. If it still fails, complete Wi-Fi authentication or switch to a working network. Check Settings → On Demand. During troubleshooting, temporarily disable conditions that may reconnect automatically, then restore them when you’re done.

3. Set a fixed outbound route

   Return to Home, select one of your working servers, and connect. In Home → Global Routing, temporarily select Proxy and retry the same URL. Proxy helps isolate the effect of rules; it doesn’t guarantee that every DNS request goes through that server.

4. Check DNS resolution

   Open Settings → DNS and note the current settings. Compare them with the DNS entries in the enabled Config. Start with a clearly identified DNS source; don’t combine several untested resolvers.

5. Restore and retest

   Restore the original Global Routing setting and revisit the same pages. If Proxy works but Config doesn’t, check your rules. If both fail, determine whether the problem is a DNS lookup, destination connection, or TLS error.

Check the DNS resolver, transport, and scope

DNS translates domain names into addresses. An A record provides an IPv4 address; an AAAA record provides an IPv6 address. Getting a record means the lookup succeeded, but it doesn’t guarantee that the address is reachable over your current network and outbound route. When checking DNS settings, ask three separate questions: which resolver is being queried, how is the query sent, and which requests does the setting apply to?

If you need to check the system DNS baseline in a configuration file, use the syntax below. This is a snippet, not a complete configuration or an instruction to replace an existing file. Edit the corresponding entry in a backup, and avoid creating multiple [General] sections.

[General]
dns-server = system

Using system DNS can help identify whether a problem comes from a previously customized resolver, but it doesn’t guarantee the same results on every network. If your configuration assigns a separate resolution method to specific domains, check those settings too. Adding more resolvers isn’t a universal fix: different sources may return different records, making the problem harder to reproduce.

Classify the error by stage

The following are actual error identifiers that may appear in Apple network requests. A browser or Shadowrocket may not display these exact strings. Record the error text you actually see, the time, and the requested domain, then classify the failure by stage. A timeout alone doesn’t prove the problem is DNS.

DNS results also have distinct meanings: NXDOMAIN means the resolver reports that the name doesn’t exist; SERVFAIL means the server couldn’t complete the lookup; a query timeout means no response arrived within the wait period. These are different failures. For a domain you’ve confirmed is valid, repeat the test with fixed DNS settings. This tells you more than the browser’s generic “page can’t be opened” message.

Check for Global Routing and rule interference

Even after DNS resolution succeeds, the page may fail if the outbound route isn’t suitable. In Global Routing, Proxy sends traffic through a proxy, Direct connects directly, Config follows the active configuration, and Scene follows the selected scene. Don’t just check whether a server is selected; confirm that the current mode is actually using it.

If Proxy opens the same page but Config doesn’t, check for an earlier matching domain or IP rule. Rules are evaluated in order: DOMAIN-SUFFIX matches a domain suffix, GEOIP and IP-CIDR use IP conditions, and FINAL is the fallback. The snippet below shows syntax only; don’t replace your existing configuration with it.

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

• example.com and 192.0.2.0/24 are documentation examples, not connection services provided here.
• no-resolve means the rule won’t trigger an extra lookup just to match that IP rule. It doesn’t turn off all DNS.
• If an earlier rule sends the destination to DIRECT, a later FINAL,PROXY rule won’t reroute that request through a proxy.
• A successful subscription update only means the subscription content was retrieved. It doesn’t confirm that the destination website’s DNS, rules, and connection are working. Updating the server list doesn’t necessarily fix the active Config.

Don’t use “open the destination IP directly in a browser” as your only HTTPS test. HTTPS also relies on the domain’s certificate, SNI, and site routing. Entering an IP directly may produce a different error. More useful evidence: did the same domain resolve, which action matched, and where did the subsequent connection fail?

Cache, IPv6, and common retest questions

After you change DNS, the app, system, or resolver may still have cached results. Once you’ve saved the configuration and confirmed it’s active, disconnect and reconnect, then make a fresh browser request. This may not clear every cache. Don’t assume one successful refresh proves the issue is fixed. Retest the same set of pages and note whether the network changed.

When contacting the provider of your own service, include the time of the failure, network type, Global Routing option, failing domain, exact error text, and whether an A or AAAA record was returned. Hide subscription tokens, credentials, and private keys; don’t share your full configuration file. Details such as “DNS resolved, but the connection failed” or “DNS times out only on this network” are more useful for troubleshooting than a latency screenshot alone.

• Restore any On Demand and Global Routing settings changed during testing.
• Keep changes that you’ve verified and can reproduce; undo changes that didn’t help.
• Retest on the original network and URLs to confirm the issue hasn’t merely disappeared temporarily.