This guide is for users who have already configured their own connection service in Shadowrocket and want to adjust domain resolution. First, distinguish the resolver from the transport protocol; then check the active Config and verify the result using the same network, domain, and connection records. DNS changes and subscription updates are separate tasks, and a webpage that won’t load isn’t necessarily a DNS problem.
1. Understand DNS resolution and traffic routing
DNS looks up records associated with a domain name, such as an IPv4 A record or an IPv6 AAAA record. Once an address is returned, the client still has to establish a connection according to the active rules. A successful lookup only confirms that a response was received; it doesn’t prove that the destination port is reachable, the TLS handshake succeeds, or the web server is working.
In Shadowrocket, DNS and Global Routing are related but separate settings. Proxy, Direct, Config, and Scene under Global Routing determine routing behavior; DNS settings determine the resolver and lookup method. Changing one does not mean the other has changed as well.
This is a simplified flow; not every request has to be resolved on the device first. A domain rule may match before resolution, and some proxy connections send the domain to be resolved remotely. A cache hit may also mean no new upstream lookup occurs. So, the absence of a new DNS request doesn’t prove that the setting failed to take effect.
- Domain rules:
DOMAIN-SUFFIX,example.com,DIRECTmatches a domain suffix; it does not specify a DNS server. - IP rules:
IP-CIDRorGEOIPmatches based on the destination IP. Some matching processes may need to resolve the domain first. - Fallback rule:
FINALhandles requests that did not match earlier rules; it does not select a resolver.
2. System DNS, custom DNS, and DoH compared
“System DNS” and “custom DNS” mainly describe where the resolver comes from. DNS over HTTPS, or DoH, describes how queries are transmitted. These categories are not mutually exclusive: manually specifying a DoH endpoint also means using a custom resolver. When choosing a setup, consider both who receives the query and how it is sent.
| Setup option | Resolver and transport | When to use it | What to check first |
|---|---|---|---|
| System DNS | Uses the resolver provided by the current system network; the transport depends on system configuration. | As a baseline, or when accessing internal domain names on the current network. | The resolvers provided by Wi-Fi and cellular networks may differ. |
| Custom traditional DNS | Manually specifies a server address. Traditional queries usually use UDP port 53 and may also use TCP port 53. | When you know a resolver is reachable, or need to look up internal records on a work or home network. | Whether the address is reachable, accepts queries from your current source, and allows port 53. |
| DNS over HTTPS | Sends HTTPS requests to a DoH-enabled endpoint, usually over port 443. | When you need encrypted query transport and have confirmed that both the endpoint and its connection path are available. | The complete endpoint, certificate validation, initial resolution of the endpoint’s domain, and the actual outbound route. |
DoH encrypts query traffic between the client and that resolver. The resolver can still see the requested domain, and DoH does not determine the route used by subsequent website traffic. System DNS does not necessarily mean unencrypted DNS; the device may have separate encrypted-resolution settings. Record them as variables when troubleshooting.
How to choose: verify reachability before comparing transport methods
If system DNS is responding reliably and internal domains work, keep it as your baseline. Test custom DNS or DoH separately only after confirming a resolution problem or a specific need for encrypted transport. Avoid changing both the resolver and routing behavior at the same time.
3. Check the active Config before making changes
On Home, check the connection status and Global Routing, then open Config to confirm which configuration file is active. Editing a different file—even if it saves successfully—does not mean the current connection is using its DNS settings. Menu locations and editing options may vary; to inspect the configuration text, search for [General] and dns-server.
- Record your baseline: Note whether you’re on Wi-Fi or cellular, the Global Routing selection, the active configuration name, and a domain that is actually failing.
- Keep a copy: Save a recoverable copy of the configuration in Config before changing DNS. Don’t change rules, connection protocols, and DNS in the same test.
- Check existing settings: See whether the configuration already specifies a resolver, and check Settings for options that may affect DNS resolution. Don’t assume the final effective value based on one input field alone.
- Change one variable: Switch from system resolution to a resolver you’ve confirmed is available. For DoH, use the complete HTTPS endpoint provided by the resolver administrator.
- Save and reconnect: Return to Home, reconnect, and test the same domain again. If the network requires Wi-Fi portal authentication, complete it first.
The two cards below describe separate tests; you don’t need to enter both sets of parameters at once. In configuration text, system resolution can be expressed as dns-server = system; custom traditional DNS requires a reachable server address. DoH uses a different transport. Adding https:// to a regular IP address does not mean the server supports DoH.
Test A: System DNS baseline
- Where to check
- [General] in the active Config
- Parameter
- dns-server
- Value
- system
- Keep these conditions fixed
- Same network, same Global Routing selection, same destination domain
If other DNS settings are present, note them first. Adding a line does not necessarily remove all overrides.
Test B: Custom traditional DNS
- Where to check
- [General] in the active Config
- Parameter
- dns-server
- Address requirement
- Enter the IP address of a DNS server you’ve confirmed is reachable
- Port check
- Traditional DNS usually requires UDP port 53 or TCP port 53 to be reachable
For example, 192.168.1.1 is suitable only if it is actually the DNS server address on your current network. Don’t copy it as a universal address.
4. Check these four things when using DNS over HTTPS
A DoH endpoint is not a regular website homepage. It must support the appropriate DNS message format. Being able to open an HTTPS website only shows that the webpage is reachable; it does not prove that the same domain provides DoH. Use the complete path and any required parameters provided by the administrator. Don’t remove or alter the hostname, path, or protocol headers.
- Endpoint format:
https://example.com/dns-queryis an example of the format, not a usable resolver. The actual path may not be/dns-query. - Certificate and device time: HTTPS connections require certificate validation. An incorrect device clock, an invalid endpoint certificate, or an intercepted network sign-in page can cause the connection to fail.
- Initial resolution: If the endpoint uses a domain name, its address still has to be resolved when the connection is first established. DoH cannot connect if that initial lookup depends on an unreachable resolution path.
- Outbound route: Don’t assume DoH automatically uses a particular proxy route. Check the active configuration, rules, and connection records to confirm the actual path and its reachability.
Don’t fix DoH problems by turning off certificate validation. First restore a known-working DNS setup, confirm the device clock is correct, and check whether the endpoint is reachable and still points to the expected address. If the issue occurs only on a particular Wi-Fi network but not on cellular, start by checking that network’s sign-in status and restrictions.
5. Verify that your DNS changes took effect
Check both the resolution result and the actual connection; don’t rely solely on whether a webpage loads. A site may be served from cache, and a browser may reuse an existing connection. Keep the network and Global Routing setting fixed, record the before-and-after results, and compare new requests. Don’t switch between Wi-Fi and cellular during the test.
- Record the issue before changing anything: Note the failing domain, test time, active configuration, and whether the error is a lookup failure, connection timeout, or TLS error.
- Save the configuration and reconnect: Disconnect and reconnect from Home, close any old test-page tabs, and make a new request. Reconnecting can help apply the new settings, but it does not guarantee that every system or app cache has been cleared.
- Check resolution evidence: Use available DNS query or diagnostic records to check the domain, A/AAAA responses, and error status. If upstream server details are available, confirm that they match your expectations.
- Check connection evidence: Review the rule matched by the request, its destination address, and the actual outbound route. A change in the resolved address alone does not prove that the route changed.
- Repeat the test and compare after reverting: Test several times under the same conditions, then restore the original setting and test again. Record consistent differences; don’t judge everything by a single page-load time.
| Observed result | What it may mean | What to check next |
|---|---|---|
| NXDOMAIN returned | The resolver says the name does not exist; this is different from a query timeout. | Check the spelling and full domain name, and whether the name exists only on an internal network. |
| Query timed out with no response | The current query path did not complete within the wait period. | Check the resolver address, network reachability, and endpoint connection before changing website routing rules. |
| A/AAAA returned, but the webpage timed out | Resolution succeeded; the failure may be in the subsequent connection. | Check the destination connection, IPv6 route, rule match, and remote reachability. |
| The address changed after changing DNS | The difference may be due to the resolver, cache, or content delivery routing. | Check whether access remains reliable. A different IP address alone does not mean the result is wrong. |
Troubleshooting order: if DNS responds but the connection fails, check the connection layer first
If the failing domain already returned an A or AAAA record, leave the DNS settings in place and check the matched rule and destination connection first. Compare resolvers only if the lookup itself times out, returns an unexpected result, or fails to resolve an internal name. This avoids repeatedly changing unrelated settings.
6. FAQ: DNS, routing, and automatic connections
Why does a diagnostic page still show the same network information after I changed DNS?
First, check whether the page is showing your public exit IP or the recursive resolver address it observed. DNS settings do not directly change your public exit IP, and a resolver may use multiple outbound addresses. Check Global Routing on Home, then review resolution and connection records for a new request. Don’t treat a single label on one page as conclusive evidence.
Public websites work, but I can’t open devices by name on my home network. What should I do?
Restore system DNS as a baseline and check whether your home router provides a record for that name. Public resolvers usually don’t know names on a private network. Names ending in .local may also use mDNS rather than regular upstream DNS. Don’t switch to a public resolver blindly to fix an internal-name lookup.
All domains time out after I enable DoH. What should I check first?
Restore the DNS settings you had before and reconnect. Confirm that basic access works, then check the complete DoH endpoint, device time, and initial resolution of the endpoint separately. Don’t change the connection server or remove all rules at the same time, or you won’t know whether the endpoint was unreachable or the route changed.
How can I keep automatic reconnection from affecting DNS tests?
Check Settings → On Demand and note or temporarily disable the relevant automatic connection conditions during testing. Confirm the actual status on Home before testing, then restore the original settings when you’re done. On Demand controls when to connect; it is not where you choose a DNS server.
If a webpage loads, does that confirm all DNS queries are using DoH?
No. Caching, an app’s own resolution method, and remote resolution can all affect the result. Check available diagnostics for new requests. To verify query transport more rigorously, use a controlled network or resolver-side logs. Without that evidence, you can confirm only that access has been restored, not draw conclusions about every query path.
Keep a known-working copy of your Config, and change only one variable at a time. These are the foundations of effective troubleshooting. For help checking rules or connection permissions, see the Troubleshooting Guide. To configure the app for the first time and import your own subscription, follow the setup guide.