This guide is for users who have already imported their own configuration into Shadowrocket. Starting with what latency tests can and can’t tell you, it walks through Global Routing, the active Config, DNS responses, and IPv6 paths to help distinguish lookup failures from connection failures. Keep your original configuration, change one setting at a time, and retest the same domain.
1. Normal latency doesn’t mean DNS is working
A latency reading in Home only confirms that the target, protocol, and path used for that test received a response. Different tests cover different stages: an open port doesn’t mean a website can complete a TLS handshake, and a successful HTTP test doesn’t mean every site is reachable. To check for a DNS issue, inspect the lookup result for the affected domain rather than relying on the latency indicator.
When you open a website, the browser typically looks up the domain’s IP address, establishes a connection using the applicable route, then sends TLS and HTTP requests. Proxy protocols, domain rules, and remote DNS resolution can change where these steps happen. The sequence below is a troubleshooting guide, not a claim that every request follows the exact same path.
If the logs show no address returned, start with DNS. If an A or AAAA address was returned but the connection times out, check the actual outbound route, destination port, and network path. A certificate validation error calls for checking the device’s clock, the domain, and certificate details—not assuming DNS is at fault.
Don’t use direct access to an IP address as a complete test. Many HTTPS sites rely on the domain name to select the right certificate and site content. If replacing the domain in the address bar with an IP address fails, that doesn’t prove the IP is unreachable or that DNS is working.
2. Check Home, Config, and connection status first
DNS settings only make sense in the context of the active configuration and route. First check which connection entry is selected in Home, then review Global Routing. Proxy, Direct, Config, and Scene are different routing modes; success or failure in just one mode doesn’t establish that the DNS server is at fault. What Scene does also depends on its configured conditions.
-
Record the baseline
In Home, note the selected connection entry and Global Routing value, and whether you’re on Wi-Fi or cellular. Choose one domain that consistently fails to load and use it for every test.
-
Check the configuration
Open Config and confirm which file is selected. Open its editor, save a copy of the original content, then check
[General]and[Rule]. Editing a different, unselected file won’t change how the active connection behaves. -
Temporarily disable automatic connections
Go to Settings → On Demand and note its current state. If you need to disconnect manually for comparison, you can temporarily turn off On Demand so the system doesn’t reconnect automatically based on its conditions. Restore the original setting when testing is done.
-
Retest one change at a time
After saving a change, return to Home, disconnect and reconnect, then request the same domain again. Open a new browser tab if needed; the old page, system cache, or browser cache may keep the result from changing right away.
To compare different Global Routing modes, note the original value, test briefly, and restore it immediately afterward. Direct sends the target traffic over a direct connection; Proxy changes the outbound route. This comparison may reveal differences in network paths, but it isn’t a general-purpose fix for a production configuration. Consider the impact of changing routes before testing with sensitive traffic.
3. Understanding the DNS settings
When checking the active Config’s text, look for dns-server under [General]. This specifies the DNS resolver; system uses the DNS provided by the system. If the configuration includes other DNS options, check each one against the app’s current parameter documentation. Don’t combine addresses with different purposes in the same field.
| Setting | Meaning | What to check |
|---|---|---|
dns-server | DNS resolver specified in the configuration | Is the address correct and reachable on the current network? Is this Config active? |
system | Use the DNS provided by the system | The system resolver and network access conditions may differ between Wi-Fi and cellular |
A | The domain’s IPv4 address record | Was a response returned? Can a connection be established to the returned address? |
AAAA | The domain’s IPv6 address record | An address being returned doesn’t mean the current IPv6 path is usable |
TTL | How long DNS records remain cached | Old results may remain cached for a while after changing settings |
This minimal snippet illustrates the configuration structure; it isn’t a complete Config and shouldn’t replace your original file. To compare against the system resolver, change only the relevant key in the existing [General] section. Avoid adding duplicate sections or keys.
[General]
dns-server = systemA port number only describes the transport; it doesn’t guarantee reachability. Standard DNS requests may time out on your current network. DoH also needs an HTTPS connection, and a DoH endpoint specified by domain name requires an initial address lookup. Choose a resolver based on your existing configuration requirements, network reachability, and data-handling needs—not on the assumption that encrypted transport is always faster.
4. Identify three types of DNS failure from the response
When reviewing in-app requests or diagnostic logs, look for the affected domain, query type, response status, and subsequent connection result. The examples below are DNS response codes or common timeout messages; Shadowrocket may not display these exact strings in every view. A browser may show only a general error. Preserve the original message rather than assigning an error code yourself.
NXDOMAIN
Cause: The resolver says the domain doesn’t exist. The domain may be misspelled or expired, or the current resolver may have returned a negative response.
Fix: Check the full hostname, then test a domain you know works. If only this domain continues to fail, contact the website administrator rather than simply waiting longer.
SERVFAIL
Cause: The resolver couldn’t complete the query. This may involve an upstream response, an authoritative server, or a validation process; it doesn’t mean the domain doesn’t exist.
Fix: Keep the original value, then compare with another existing, reachable resolver. If only one domain is affected, give the website administrator the query time and response code to help with troubleshooting.
timeout
Cause: No response arrived before the request timed out. The failure may be on the path to the resolver or on the destination connection after resolution.
Fix: First identify which stage timed out. If there’s no DNS response, check the resolver address and network reachability. If an address was returned, check the outbound route and destination port.
One failure isn’t enough to draw a conclusion. Retry the same domain and compare it with another domain you know works. If all lookups fail, the shared DNS path may be the issue; if only one domain fails, check that domain and its authoritative DNS. Keep the query type in your notes: a valid response with no AAAA record doesn’t mean the domain can’t be resolved at all.
- No address returned: Check the spelling, response code, and path to the resolver first.
- A address returned, but the connection times out: Check the rule and outbound route used by the request. Don’t keep switching DNS resolvers.
- Only the AAAA path fails: Compare IPv4 and IPv6 connection results before changing address-family settings.
- The home page loads, but some resources fail: Check the domain of each failed resource; a single page may use several domains.
5. How rules and IPv6 can look like DNS problems
When Global Routing uses Config, rules help determine the outbound route. DOMAIN-SUFFIX matches domain suffixes; IP-CIDR and GEOIP match address-based conditions; FINAL handles requests that haven’t matched an earlier rule. Rule order, whether a lookup is needed, and where resolution takes place can all affect the result you observe.
The following examples show rule syntax and what it matches. example.com and 192.0.2.0/24 are documentation examples, not sites or routes to add. Don’t append the whole snippet to the end of your existing rules; an existing FINAL rule or earlier rules may make the added lines ineffective.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXYno-resolve means the app won’t actively trigger domain resolution just to match this IP rule. It doesn’t disable all DNS or fix lookup failures. If a domain rule sends a request over the wrong route, the page may still fail even when DNS works. Check the request log to see which rule actually matched instead of relying on the configuration text alone.
Troubleshoot IPv6 with a comparison. An AAAA record only tells you that the resolver returned an IPv6 address. If IPv6 connectivity on the current network is incomplete, the request may stall or fall back. Note the current IPv6-related settings first, then test one change at a time. Don’t change DNS, Global Routing, and IPv6 settings together, or you won’t know which change affected the result.
6. Common questions and a repeatable troubleshooting record
Why didn’t changing DNS change the result?
First, confirm in Config that you edited the selected file. Save it, return to Home, reconnect, then open a new tab and request the same domain. The system, browser, and app may all cache results. Repeatedly refreshing an old page doesn’t prove it used the new resolver.
What if it works on cellular but not Wi-Fi?
Keep the same connection entry, Global Routing, and Config, and change only the network for comparison. The difference may come from the network’s DNS, resolver reachability, or IPv6 path. If you’re using system, be sure to note the network change as a variable.
Latency looks normal, but updating an existing subscription fails. Could DNS be the issue?
First distinguish a failed lookup of the subscription hostname from a connection timeout or an HTTP error. If resolution succeeds but the server returns 401 or 403, check authorization and link validity with your own service provider. Changing DNS won’t fix access credentials.
If switching to Proxy makes it work, does that mean DNS is fixed?
No. Changing Global Routing to Proxy can change both the outbound route and the path used for resolution. Restore the original value, check which rule matched the failed request in Config and what address was returned, then change only a setting linked to a confirmed issue.
If you need help, reproducible conditions are more useful than a latency screenshot. Collect the details below during the same test session. Remove subscription credentials, account details, and the full connection configuration from logs; include only the fields needed to diagnose the issue.
- Device and network: iPhone or iPad, Wi-Fi or cellular, and whether On Demand is enabled.
- Status: Global Routing value in Home, current Config name, and whether you just reconnected.
- Request: Failed domain, time of failure, A or AAAA lookup result, and DNS response code or original error message.
- Connection: If an address was returned, the matched rule and outbound route, and whether the failure occurred during connection, TLS, or HTTP.
- Comparison: The single setting changed each time, what happened before and after the change, and whether the issue returned after restoring the original value.
The goal isn’t to lower the latency reading. It’s to resolve the same domain reliably, send the request over the expected route, and get a page response. If you’ve confirmed that only one domain or network path is affected, keep the useful comparison and leave other working settings alone.