A latency result doesn’t prove that a website’s DNS, connection, and TLS are all working. This guide is for users who already have their own server or subscription but can’t load a website. Keep the test conditions fixed, check the DNS response, then use Global Routing and connection records to distinguish a resolution issue from an outbound connection issue. Change one setting at a time and keep the original configuration so you can restore it.
01 A Successful Latency Test Doesn’t Mean the Website Connection Works
A Shadowrocket server test and a browser request to a domain are not the same request. Different tests cover different parts of the connection: reaching a server port doesn’t mean the target domain resolved to the right address, and a response from one test target doesn’t prove that every resource on another website is reachable.
You can break down a typical webpage request using the checkpoints below. In practice, rule evaluation and DNS lookups can overlap: a domain rule may match first, while an IP rule may need a resolved address. This sequence is a troubleshooting aid, not a claim that every request inside the app follows exactly the same order.
- Server not found: Check the domain spelling and DNS response first. A browser message alone doesn’t prove the server is unavailable.
- Page keeps loading, then times out: The DNS lookup, connection, or remote response may have timed out. Check the records to identify where.
- Certificate warning: Check the device’s date and time, the domain, and the certificate details. Don’t fix this by bypassing certificate validation.
- Text loads but images don’t: Page resources may come from other domains. Check each failed request instead of looking only at the address bar.
02 Record the Current Setup, Then Open Settings → DNS
Open Home and note the selected server and Global Routing mode, then go to Config and confirm which configuration is active. Next, open Settings → DNS and record the current DNS settings. Check DNS-related content in the configuration file too, if present; reviewing just one screen may miss settings that affect resolution.
This section explains what each setting does; it doesn’t assume that any particular value is the default on every device. Available fields and options depend on the current app interface. Focus on who handles the lookup, how the query reaches them, and whether a local mapping overrides the result—not on turning on every option.
| Setting | Purpose | What to check |
|---|---|---|
| DNS server | Receives domain queries and returns results | Confirm the address is entered correctly and the service is reachable on the current network. |
| DNS transport | Determines how queries are sent | Plain DNS and encrypted DNS use different address formats. Changing only the port doesn’t change the protocol. |
| Local mapping | Assigns an address to a specific domain | Check for outdated addresses or a mapping that pins a single website to an address that no longer works. |
| DNS settings in the configuration | Affects resolution for the active configuration | Confirm that the active Config is the file you just edited and that there are no duplicate or conflicting settings. |
| IPv4 / IPv6 | Applies to different address families and network paths | Receiving an AAAA record doesn’t guarantee that IPv6 outbound connectivity works on the current network. |
These are common protocol port numbers, not recommended values to enter in Shadowrocket. A service may use a non-default port, so use the actual settings for your existing DNS service. Encrypted queries still need a working connection; they won’t fix incorrect routing or an unavailable server.
Bottom line: Confirm the query reaches the DNS service, then check the response
If the DNS service itself can’t be reached, restore a previously recorded working setting first. If it returns an address, investigate the outbound path to that address. A DNS response and a working webpage are two separate checks.
03 Run a Reproducible Test with the Same Domain
Choose the full URL of a website that won’t load and note the time and network you’re using. Don’t switch Wi-Fi, server, DNS, and rules all at once; even if access comes back, you won’t know which change made the difference.
- Save the original settings: Record the server, Global Routing mode, Config file, and Settings → DNS values shown in Home and Settings. Make a copy of the configuration file before editing it.
- Establish a baseline: Keep the original settings, request the same URL again, and check the connection record or log for that request. Look for the domain, resolved address, matched rule, policy, and error details. Available fields depend on the records shown.
- Distinguish a response from a timeout: If there’s a DNS response code, interpret it first. If the query just times out without a response, check whether the DNS service is reachable; a timeout doesn’t mean the domain doesn’t exist.
- Change only one DNS setting: If you have a DNS setting you’ve already verified works, temporarily use it for comparison. Save the change, reconnect, and request the same URL without changing anything else.
- Check for cached data: Reloading a page may reuse an existing connection or cached content. If needed, close the page, quit the browser, and reopen it. Reconnecting doesn’t guarantee that every app cache is cleared immediately.
- Restore and retest: If there’s no improvement, restore the original DNS setting and continue checking rules and outbound connectivity. Retest any change that appears to work so you don’t mistake a temporary recovery for a fix.
04 Understand DNS Errors Instead of Treating Every Timeout as a Resolution Failure
The messages below are DNS response codes and system network errors; Shadowrocket may not display these exact words every time. Browsers often show simplified errors. Follow the corresponding guidance only if you actually see the message in diagnostic results or logs.
DNS response: NXDOMAIN
Cause: This response means the queried domain doesn’t exist, though an incorrect query name or an abnormal response may also be involved.
What to do: Verify the full domain and spelling, then compare using a DNS path you’ve confirmed works. If different DNS paths return the same result, check the domain’s status with the site operator.
DNS response: SERVFAIL
Cause: The DNS server couldn’t complete the query. The issue may involve upstream resolution, an authoritative server, or validation.
What to do: Note the domain and time, then test again using another known-working DNS path. This response doesn’t mean the domain doesn’t exist, and it’s not a reason to disable TLS verification.
System error: The request timed out.
Cause: The request didn’t finish in time. This message alone doesn’t show whether the timeout happened during DNS resolution, connection setup, or the webpage response.
What to do: Check whether a DNS address or connection record appeared before the timeout. If there was no response, check the DNS path. If an address was returned, investigate the policy, server, and connection to the destination.
If the records show a valid address followed by a connection failure, focus your troubleshooting on the outbound path. Conversely, if there’s never a DNS result, repeatedly changing the webpage protocol or editing FINAL may not address the actual failure point.
05 Compare Global Routing and Check Rule Matches in Config
In Home → Global Routing, Proxy, Direct, Config, and Scene represent different routing modes. Note the current selection first. If you use Scene, confirm which behavior the active scene actually applies. An enabled connection doesn’t by itself prove that a website is using the selected server.
With the same network, server, and URL, briefly compare Config with Proxy. If the site works in Proxy but not Config, check which rule matched and compare the configuration. This narrows the possibilities but doesn’t prove the cause: changing routes may also change whether DNS queries can reach their destination, so verify the records too.
| What you see | What to check next |
|---|---|
| Proxy works, Config fails | Check whether the domain matches DIRECT, REJECT, or the wrong policy, and compare the DNS results. |
| Direct works, Proxy fails | Check whether the selected server can reach the destination, along with remote DNS resolution and the destination connection. Don’t rely on latency alone. |
| All routing modes fail | Check the domain’s status, DNS response, current network, and website. Don’t assume the Config rules are at fault. |
| Works after switching networks | Compare DNS reachability, IPv6 paths, and connection restrictions on both networks. Leave other settings unchanged for now. |
The examples below demonstrate rule syntax and order using a reserved example domain. They aren’t a configuration that will fix every website issue. Check the relevant entries in your existing rule section rather than replacing the entire Config with these two lines.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIXmatches domain suffixes; this example matchesexample.comand its subdomains.IP-CIDRandGEOIPevaluate IP-based conditions. Check the actual resolved address and the configuration’s DNS-handling options.- Rules are evaluated in order, and the matching rule’s policy is applied. If an earlier rule already matches, adding a new rule later may not change the result.
FINALis the fallback when no earlier rule matches. Changing it toPROXYaffects every request that reaches the fallback; it isn’t a default fix for a DNS issue affecting one domain.
After the comparison, restore your usual Global Routing mode. If a configuration change caused the issue, revert that change first and then check the rules one by one. Updating an existing subscription refreshes server information; it doesn’t necessarily fix DNS or rules in the active Config. Check those separately.
06 Common Questions and Diagnostic Details to Share
Why do some websites fail even when latency is low?
A latency test doesn’t cover every website or its resource domains. Note the failing URL, check the policy matched under Config, then compare with Proxy. If only images or a login step fail, look for the related resource domain instead of repeatedly testing the same server port.
The site works after changing DNS. Should I keep the new setting?
Retest on the same network and check whether the original DNS timed out or returned an abnormal result. If the new setting is stable and matches the details of a DNS service you already use, you can keep it; note the original value first. One successful test doesn’t rule out caching, a temporary website issue, or a network change.
Wi-Fi fails but cellular works. Should I turn off IPv6?
Compare the resolved A and AAAA records with the actual connection results. An AAAA response doesn’t mean the IPv6 path works, but it also doesn’t mean you need to disable IPv6 permanently. If you change a related setting, treat it as a one-variable test and record the result or restore the original value afterward.
The connection turns back on after I disconnect. How can I test without it?
Open Settings → On Demand and check whether on-demand connection is enabled. Note its original state, temporarily turn it off, and test while disconnected. Restore it afterward if needed. On Demand controls when the connection starts; it doesn’t fix DNS responses or rules.
If you need further help, reproducible test conditions are more useful than a latency number alone. If your records include subscription URLs, server credentials, or personal request details, redact sensitive information and share only what’s needed to diagnose the issue.
- Device type, current network type, and whether the issue occurs only on one network.
- Failing domain, time of the issue, Global Routing selection, and active Config.
- Whether DNS returned a response, the response code, and whether a connection was established afterward.
- The policy matched by the rule, results from comparing Config with Proxy, and any changes you’ve since reverted.