Shadowrocket DNS settings handle domain name resolution; they do not determine your proxy exit. Assuming you already have a working connection configuration, this guide starts with system DNS as a baseline, then explains when to use custom DNS or DNS over HTTPS, how to spot configuration overrides, and how to verify changes using DNS records and rule matches.
1. Understand DNS servers, query transport, and traffic routing
Before opening a website, a device usually resolves its domain name to an IP address. DNS answers “Which addresses belong to this name?” Global Routing and rules answer “Which route should this connection use?” They affect each other, but changing DNS does not automatically route website traffic through PROXY or replace your existing connection service.
“System DNS” and “custom DNS” mainly refer to where the resolver is specified. DNS over HTTPS (DoH), by contrast, describes how queries are sent. Custom DNS can also use DoH, so these are not three mutually exclusive settings. The sections below group them by practical setup to make testing easier.
Ports are conventions, not proof that a service is available. DoH requires a valid HTTPS endpoint, a valid certificate, and a reachable network route. A website loading over HTTPS does not mean that the same host provides a DNS query endpoint. The reserved addresses and example domains in this guide illustrate formats only; they are not usable DNS services.
2. Choosing system DNS, custom DNS, or DoH
System DNS: establish a troubleshooting baseline
RecommendedUse the DNS resolution currently available to the system, which usually depends on the network connection. The actual DNS environment may change when you switch between Wi-Fi and cellular. DNS settings installed on the system may also apply, so system DNS does not always mean the router’s address.
Best for: initial checks, restoring default behavior, and confirming whether a custom setting caused the issue
Custom DNS: specify a resolver
Specify a DNS server to reduce variables when switching networks. If you enter a regular IP address and use traditional DNS, the query is not encrypted just because the server is custom. The server must also be reachable along the actual query route.
Best for: using a known resolver, resolving internal domains, and repeatable comparisons
DNS over HTTPS: encrypt DNS query transport
DoH wraps DNS queries in HTTPS, protecting them in transit between the client and the resolver. It does not hide queries from the resolver, nor does it guarantee the website traffic route, connection quality, or that DNS answers will meet your expectations.
Best for: environments with a trusted, reachable DoH endpoint that require encrypted DNS transport
Bottom line: verify default resolution first, then change DNS on its own
Record how sites resolve and load with system DNS, then change only the DNS method. Don’t change the resolver, Global Routing, and rule file all at once; otherwise, even if access is restored, you won’t know which change made the difference.
DoH does not mean “all DNS queries go through the proxy.” Whether a query uses a direct or proxied route depends on the active configuration and the actual records. If the endpoint is unreachable or its hostname cannot be resolved initially, enabling DoH may cause several websites to time out during DNS resolution.
3. Check active settings in Settings and Config before making changes
In Home, note the current server and Global Routing mode. Then check the existing settings under Settings → DNS and review the selected configuration file in Config. The active configuration may include its own DNS parameters. Don’t assume every connection uses a new resolver just because one field has changed. Settings groups and available options can vary by configuration; use the options shown in the app.
- Save the original values. Record the current DNS address, active Config name, and routing mode, and keep a restorable copy of the configuration. If it is managed by a subscription or remote file, check whether a later update could overwrite your local changes.
- Establish a baseline. Keep the same Wi-Fi network, server, and test domain. Test once with system DNS and record whether the result is a success, timeout, or resolution error—not just how quickly the page loads.
- Choose one place to make the change. Use the DNS setting in Settings or edit a Config you maintain yourself. Avoid entering different settings in multiple places and then guessing which one takes precedence.
- Check the format. For regular DNS, enter the server address. For DoH, enter the full HTTPS endpoint, including the path specified by the resolver. Don’t use a subscription URL or website homepage as a DNS endpoint.
- Reconnect. Save your changes, disconnect and reconnect Shadowrocket, close existing webpage connections, and make a new request to a domain. Verify the new request using its records rather than judging by an old session.
For a text configuration you maintain yourself, the examples below show three ways to write dns-server. Keep only one at a time; do not copy and combine all three [General] sections. The system setting can restore a baseline. The other two are format examples only and must be replaced with resolver details you already have and have verified.
# System DNS
[General]
dns-server = system
# Custom DNS: 192.0.2.53 is a documentation-only reserved address
[General]
dns-server = 192.0.2.53
# DoH: example.com illustrates the endpoint format only
[General]
dns-server = https://example.com/dns-query4. How DNS results affect DOMAIN-SUFFIX, GEOIP, and IP-CIDR
Domain rules and IP rules check different things. DOMAIN-SUFFIX checks a domain and its subdomains; IP-CIDR checks whether the destination IP belongs to a specified network range; GEOIP classifies an IP using a database. Different DNS answers may change the outcome of the latter two rule types, but they do not change the domain suffix itself.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- Domain rule matches first. If the request provides the domain
www.example.com, the first rule can match and select PROXY. Later IP rules no longer determine the policy for that request. - Address-based checks. For a request that has not matched a domain rule, later IP-based rules may depend on a known destination address or a DNS result. Whether additional resolution occurs also depends on the rule options and request state.
- Understand no-resolve. In the second example,
no-resolvemeans the rule will not actively resolve a domain to check for a match; it does not disable all DNS. If the request already has a destination IP, network-range matching can still occur. - Keep FINAL as the fallback.
FINALcatches requests that did not match earlier rules and should appear last. The reserved network range in the example illustrates syntax only; it does not represent a real service network.
To test these rules, select Config under Home → Global Routing. Proxy and Direct do not use the rule list in this Config for routing in the same way. With Scene, also check which settings the active scene actually uses. Otherwise, a change in traffic route may be due to a mode change rather than DNS.
Different IP addresses for the same domain do not automatically indicate a DNS problem. CDN routing, caches, resolver location, and A / AAAA query types can all produce different answers. Record “which address was returned,” “which rule matched,” and “where the connection went” separately rather than expecting identical answers every time.
5. Verify changes: test DNS resolution and access separately
A page loading only proves that this particular visit completed; it does not, by itself, prove that DoH is working. The browser may reuse an existing connection, and the device, app, or resolver may have cached results. If possible, use a test domain you control and can check query logs for. Otherwise, record the test time and distinguish new results from old ones.
Test plan: use the same configuration and test each network separately
Test on Wi-Fi
- Keep the server, Config, and Global Routing unchanged. Don’t edit the rules at the same time.
- After reconnecting, visit the test domain and record A / AAAA results and any resolution errors.
- Check that the endpoint is reachable and whether internal domains still resolve.
Retest on cellular
- Change only the network connection; keep the same DNS settings.
- Make a new request and compare whether timeouts occur on only one network.
- If DNS answers are normal but access fails, check the rules, traffic route, and IPv6 path next.
Keep the new settings only after both networks pass. If only one fails, first check the route from that network to the resolver.
- Check DNS records first. Look up the test domain in available DNS or connection logs and check the timestamp, returned address, and any errors. If the logs do not show the resolver or transport method, they cannot prove that DoH was used.
- Then check the rule match. Confirm that the policy in the record corresponds to the matching rule. For example, if the domain should match
DOMAIN-SUFFIXbut instead falls through toFINAL, check the actual request domain and active Config. - Finally, check the connection. If the address is valid but the TCP connection times out or the TLS handshake fails, check the connection route and destination site. Don’t attribute every error to DNS.
- Restore the baseline if needed. Restore the original DNS settings without changing anything else, then test the same domain again. If it works immediately, you have a basis for further checking the new resolver or endpoint route.
The most direct way to confirm that queries are using DoH is to check the resolver’s request logs or diagnostic information that clearly shows the HTTPS query destination. Faster resolution, changed IP addresses, or a browser’s security lock icon are not substitutes for this evidence.
6. Common issues: timeouts, internal domains, and updates
All websites stopped loading after adding a DoH address. What should I do?
Restore the saved system DNS baseline and reconnect. Once access is back, check the endpoint’s full path, certificate, port, and reachability one by one. If the hostname itself cannot be resolved, check the initial resolution requirements as well. Don’t add multiple unknown endpoints at once; that can obscure the cause.
Websites load, but company intranet domains don’t. Should I change DNS?
First confirm that the device is connected to the required internal network, then check whether the domain can only be resolved by internal DNS. Public resolvers usually do not have company-internal records. Restore a working internal resolution method or configure domain routing according to your organization’s requirements. Don’t repeatedly send internal domains to unrelated resolvers for testing.
Why does the log still show the old IP after I changed the settings?
Check the timestamp, close old webpage sessions, reconnect, and make a new request. You may not see a new DNS query while a result is cached or an app is reusing an old connection. If nothing changes, check which file is actually selected in Config instead of entering the same address again.
Only some websites fail. Should I disable IPv6?
Check A and AAAA results separately, then confirm which address family the failed connection actually used. An AAAA answer does not mean the current route can reach IPv6 addresses. Make a controlled, one-variable comparison only when the records support it; don’t disable IPv6 globally as a substitute for finding the cause.
Why did my DNS settings revert after an update?
In Config, check whether the active configuration comes from a remote update, then compare it with the copy you saved before updating. Updating a server subscription and updating a full configuration are not the same thing, so first confirm what was updated. To keep local DNS changes over time, maintain your own configuration copy and decide how future updates will be merged.
If the connection state changes automatically while troubleshooting, also check Settings → On Demand for automatic connection conditions. Note its current state during testing to avoid misreading an immediate reconnection after a manual disconnect. Restore the original automatic connection settings when testing is complete.
Keep the new settings only if DNS resolution is stable on the target network, required internal domains work, rule matches are as expected, and the original configuration can be restored. DNS over HTTPS changes how queries are transported; it does not replace checks for server reachability, Global Routing, or rule order.