A normal latency result in Shadowrocket only shows that the test target was reachable at that moment; it does not confirm that a website’s domain resolved successfully. Assuming you already have your own service details and subscription, this guide checks the basic network, DNS responses, Global Routing, IPv6, and configuration overrides in order. Keep your original configuration, change one variable at a time, and retest the same domain.
1. Why websites may fail even when latency is normal
Loading a website involves more than a latency test. A browser usually resolves the domain to an IP address, establishes a connection, completes the TLS handshake, and then requests the page. If a test probes only a server address or a specific test target, it does not cover the DNS, routing rules, or certificate validation used by the website. A low latency result does not rule out a DNS failure.
This sequence helps identify where a failure occurs; it does not mean DNS queries and website requests always use the same outbound route. A configuration may handle DNS traffic separately, and some connections may resolve domain names remotely. So “normal server latency” and “local DNS is working” are two different conclusions.
- All websites fail: Check the basic network, tunnel status, and whether the DNS upstream is reachable. Don’t start by changing rules for a single website.
- Only one domain fails: Check the spelling, the DNS response for that domain, and the rule it matches. The website itself may also be having an outage.
- The homepage loads, but images or sign-in fail: Note the actual domains used by the failing resources. Don’t test only the main domain in the address bar.
- You see a certificate warning or HTTP 403: The failure is at a later stage. A page that won’t load does not by itself indicate a DNS failure.
2. Establish a reproducible baseline
Before you begin, note the current connection on Home and the active configuration on Config, then save a copy. For every test, use the same full URL and record the network type, time, Global Routing mode, and error. Don’t update a subscription, switch connections, change DNS, and edit rules all at once, or you won’t know which change made a difference.
- Check the basic network: Temporarily disconnect Shadowrocket and visit a website that normally works. If public Wi-Fi requires a sign-in page, complete network authentication first. If the basic connection is down, troubleshoot Wi-Fi or cellular service before anything else.
- Control automatic reconnection: In Settings → On Demand, check whether automatic activation is enabled. To compare with Shadowrocket disconnected, temporarily disable the relevant triggers and restore them after troubleshooting. This avoids mistaking an automatic reconnect for a manual disconnect test.
- Reproduce the failure: Reconnect, visit the affected URL, and note whether it stalls, reports a domain error, times out, or shows a TLS error. A browser’s generic failure message is not a substitute for a DNS query result.
- Retest on another network: If possible, switch the same device from Wi-Fi to cellular while keeping the connection and configuration unchanged. If the failure occurs on only one network, focus on whether that network can reach the DNS service or destination address.
- Check relevant records: Review Shadowrocket’s connection logs, DNS query results, or any diagnostic tools currently available. Check the failing domain, returned address, and actual policy. The exact location of these options depends on the current interface.
Don’t use “open the website by IP address” as a general test. HTTPS websites may rely on the domain for SNI, certificates, and virtual hosting. Failing to open an IP address does not prove that the network is down.
3. Tell DNS error responses from unanswered queries
DNS failures fall into two broad categories: the server returns a specific error, or the query receives no valid response. Each calls for a different approach. The names below are actual DNS protocol status codes, not guaranteed on-screen messages in Shadowrocket or a browser. Some logs show only a generic resolution failure or timeout.
Error: NXDOMAIN
Cause: The response means the queried name does not exist, though a local mapping or an abnormal upstream response could also be involved. What to do: Check the full domain, then query the same name through another known-good resolution path. Waiting longer won’t fix a name that doesn’t exist.
Error: SERVFAIL
Cause: The resolver could not complete the query. Possible causes include an authoritative upstream server, validation, or a temporary service issue. What to do: Query another known-good domain with the same resolver, then cross-check the failing domain to determine whether the resolver is generally failing or only that domain is affected.
Error: REFUSED
Cause: The server refused the query, often because of access controls or because recursive queries are not allowed from the current source. What to do: Check the DNS service’s usage restrictions and switch back to a resolver permitted by the current network or existing configuration.
If there is no response at all, check the DNS server address, transport method, and outbound route. Note that NOERROR does not guarantee a usable address: a query can succeed with an empty answer section if the requested record type does not exist. No AAAA record with a working A record does not mean the domain failed to resolve.
- A: Returns an IPv4 address and helps check whether IPv4 resolution is working.
- AAAA: Returns an IPv6 address. After receiving an address, confirm that the current network has a working IPv6 route.
- CNAME: Indicates an alias that must be resolved further. A response for the main domain does not mean the entire alias chain is working.
4. What each DNS setting does
The effective DNS behavior in Shadowrocket depends on the active configuration. Check the configuration enabled in Config and its General settings. In a text view, look for relevant sections such as [General]. Don’t infer the current behavior from values in a different, inactive configuration, and don’t mistake a server address in your service details for a DNS server.
| Setting or concept | What it does | When to change it and limitations |
|---|---|---|
dns-server |
Specifies the DNS upstream. Enter supported address formats and transport methods as described by the current app configuration. | Change it only after confirming that the current upstream is unreachable or returning abnormal responses. Multiple addresses do not necessarily mean fixed, sequential failover. |
system |
In DNS configurations that support this value, use the resolver provided by the current system network. | Useful as a baseline for comparison. The actual server may change with Wi-Fi, cellular service, or network management settings. |
fallback-dns-server |
Configures a fallback resolver as a supplement to the primary resolution process. | The conditions for using it depend on the current configuration mechanism. It does not mean every failed query will be fixed automatically. |
ipv6 |
Affects IPv6-related handling; consider the system, tunnel, and actual network capabilities together. | Use it as a one-variable test when AAAA records resolve but IPv6 connections fail. Disabling it is not a universal fix for DNS problems. |
[Host] |
Configures local domain mappings that may affect the address ultimately used for specific domains. | Check for outdated mappings when only certain domains fail. Website addresses can change, so don’t rely on a temporary IP address in place of normal resolution for an extended period. |
If you use an encrypted DNS endpoint identified by a domain name, that endpoint’s name resolution and connection must work first. Simply replacing regular DNS with encrypted DNS won’t restore access if the endpoint cannot connect. Also check certificate validation, device time, and the route used to reach the endpoint.
Takeaway: verify upstream reachability before changing the resolution method
A port number can help identify a transport type, but it does not prove that an endpoint is reachable. If the same upstream cannot connect on the current network, restore a known-good configuration first. Then test regular DNS and encrypted DNS separately, and keep the option that returns the correct answers.
5. Use Global Routing to distinguish DNS from routing issues
Check the current mode under Home → Global Routing. When using a rules-based configuration, Config is usually the mode to examine. Temporarily switching to Proxy or Direct can provide a comparison, but neither guarantees that separate DNS settings are overridden. Scene selects a scenario; it should not be treated as a fixed direct or proxy policy.
| Mode | How to use it for troubleshooting | How to interpret the result |
|---|---|---|
| Config | Check which rules and policies the request matches in the current configuration. | If the failure occurs only in this mode, focus on rule order, policy group selection, and DNS settings in the configuration. |
| Proxy | Temporarily compare whether the destination website is reachable through the proxy route. | If access returns, the outbound route is worth checking, but this alone does not prove that DNS has been fixed. |
| Direct | Temporarily check the result of connecting directly to the destination. | This comparison is meaningful only if the destination allows and supports direct access. |
| Scene | Check which configuration and behavior the current scene actually selects. | Check what the scene contains first, so changes caused by switching scenes aren’t mistaken for random DNS failures. |
If the correct IP is returned but the connection still times out, continue by checking the outbound policy. Domain rules and IP rules are not interchangeable: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP relies on an IP geolocation database, and FINAL handles requests that matched no earlier rule. Matching rules that require a destination IP may involve DNS resolution; with no-resolve, don’t expect the rule to initiate a lookup just to match.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThese are syntax examples, not recommendations to replace your current configuration. example.com is an example domain, and PROXY must refer to a usable policy in the current configuration. During diagnosis, check the actual match records: if a broader rule above has already matched, later corrective rules won’t be considered. Keep FINAL at the end.
6. If resolution succeeds but access still fails: check IPv6, caches, and configuration overrides
Getting an address from DNS is only the first step. If both A and AAAA records are returned but IPv6 works poorly on one network, the browser may wait for a failing route before trying another, causing long waits or intermittent access. Compare the address family used by the connection instead of repeatedly changing DNS.
- Compare address families: Note whether the failed connection used IPv4 or IPv6. If needed, test IPv6-related options in a copy of the configuration. Keep the original value and decide whether to restore it based on the test results.
- Rule out caching: After changing the configuration, reconnect and make a new webpage request. The browser, system, and resolver may each keep a cache, so a single refresh may not trigger a new DNS query.
- Confirm the active configuration: Return to Config and make sure the edited configuration is still enabled. Editing a copy without activating it often makes changes appear to have no effect.
- Distinguish two kinds of updates: Updating an existing Subscribe entry on Home mainly refreshes the associated service details. Updating a remote Config may replace configuration contents. Refreshing a subscription is not a required step for fixing DNS settings.
- Check whether changes were overwritten: If the problem returns after each remote configuration update, compare the DNS, Host, and Rule contents before and after the update to see whether local changes were replaced.
Don’t share a full subscription URL, authentication details, or unredacted logs. When asking for help, include the error type, destination domain, network type, and policy name. Remove any account details and tokens first.
7. Wrap up based on evidence: when to stop changing DNS
By the end of troubleshooting, you should be able to identify whether the issue is a “no response,” a “specific error response,” an “incorrect address,” or a “correct address but failed connection.” If each query returns the expected address and logs show that the failure occurs during connection establishment or the TLS handshake, stop changing DNS. Check the connection status of your existing service, the destination website, device time, and policy route instead.
- DNS is likely the issue: The same domain fails through the original upstream but resolves through another verified path, and the webpage loads after switching paths with all other conditions unchanged.
- More likely a routing issue: DNS results are identical, only Config fails, and access returns after you adjust the rule that actually matched.
- More likely a network route issue: The configuration is unchanged, but Wi-Fi fails while cellular works, or connections fail only for one address family.
- More likely a destination issue: Only one website fails despite successful resolution, while other websites work with the same connection and policy.
When contacting your service provider, include the time of the failure, whether you were on Wi-Fi or cellular, the affected domain, the DNS response status, the returned address family, and the difference between Config and the temporary comparison mode. Reporting “the domain query returned SERVFAIL” is more useful for troubleshooting than simply saying “latency is normal, but it doesn’t work.” When finished, re-enable any On Demand triggers you temporarily disabled and keep a copy of the final working configuration.