Shadowrocket DNS Settings: System DNS, Custom DNS, and DNS over HTTPS

At a glance

System DNS provides a baseline for troubleshooting your current network. Custom DNS lets you specify a resolver, while DNS over HTTPS encrypts queries between the client and resolver. This guide is for Shadowrocket users with their own service provider and subscription. It explains how to edit the General section in Config, distinguish DNS issues from connection failures, verify a DNS change, and roll it back.

1. Distinguish DNS resolution from website connectivity

DNS resolves domain names to addresses. For example, an A record lookup returns an IPv4 address, while an AAAA lookup returns an IPv6 address. Reaching an HTTPS website also requires establishing a connection, completing a TLS handshake, and retrieving content. So a DNS response does not guarantee that a webpage will load, and a page that will not load does not necessarily indicate a DNS problem.

Request a domain Query a resolver Get an address Establish a connection Retrieve content

This flow helps isolate problems; it does not mean every request is resolved locally. In Shadowrocket, where resolution takes place also depends on the request type, rules, and proxy egress. Some connections can pass the destination domain to a remote endpoint. Setting a DNS address locally does not prove that every domain is handled by that resolver.

When troubleshooting, check the current server on Home, then review Global Routing. Config applies routing rules from the active configuration; Proxy and Direct change the global routing mode, while Scene follows the selected scene's settings. Keep the routing mode unchanged while comparing DNS options. Changing both the egress and resolver at once makes it difficult to tell which change caused the result.

Query timeout: First check whether the resolver is reachable and whether the current network restricts the relevant transport.
NXDOMAIN response: The resolver reports that the domain does not exist. This is not the same as a network timeout; check the spelling and the domain's record status as well.
Address returned, but connection failed: Check rule matching, egress reachability, the IPv4/IPv6 path, and TLS instead of repeatedly changing DNS.

2. System DNS, custom DNS, and DoH compared

Here, “custom DNS” means traditional DNS with a resolver IP entered directly, as distinct from an HTTPS endpoint. From a configuration perspective, a DoH endpoint you enter yourself is also a custom setting. Choose based on your network, resolver reachability, and query transport requirements—not on which option sounds more advanced.

Method	Resolution path	When to use it	What to check
System DNS	Uses the resolver currently available to the system, which is typically affected by the current Wi-Fi or cellular network.	Establishing a troubleshooting baseline or resolving internal domain names provided by the current network.	The resolver and results may change when you switch networks.
Custom DNS	Sends traditional DNS queries to a specified resolver IP.	You need a fixed resolver, and its address is reachable on the current network.	UDP/TCP port 53 reachability, and whether the resolver accepts queries from your current source.
DNS over HTTPS	Sends DNS queries to a DoH endpoint over HTTPS.	You need encrypted query transport, and the HTTPS endpoint and certificate are available.	The full endpoint path, TLS certificate, initial resolution of the endpoint domain, and actual routing.

Traditional DNS typically uses UDP/TCP port 53

443

HTTPS uses port 443 by default when no port is specified

2 types

Address records: A for IPv4, AAAA for IPv6

DoH encrypts the connection between the client and resolver. The resolver can still process and see the queries it receives, and website connections still follow their own egress paths. Enabling DoH does not automatically route all traffic through Proxy, nor does it replace checking rules and server status.

Bottom line: verify reachability before choosing DoH

If system DNS resolves reliably but DoH queries time out, check the endpoint and TLS path first. Don't change Global Routing at the same time. For internal domain names, keep the system DNS test results and check whether an external resolver has the same records before switching.

3. Set dns-server in Config

dns-server belongs in the [General] section of the configuration file, not in [Rule]. Each code block below is a separate option; do not combine all three into one file. When editing an existing configuration, keep its rules and other fields intact, and change only the DNS setting you are testing.

In Config, confirm which configuration file is active. Save a local copy first, and note the current dns-server value.
Open the file's edit option and locate [General]. If dns-server is already present, edit that line to avoid duplicate keys.
Choose one option at a time. After saving, confirm that this file is still active; editing an inactive copy will not change the current connection.
Return to Home, disconnect, and reconnect to test the saved configuration with a new connection. Existing connections and cached data may affect what you see.

Option A: Use system DNS

[General]
dns-server = system

[General]: Declares the general settings section.
dns-server = system: Uses the DNS currently available to the system and provides a baseline for comparison with custom settings.

Option B: Specify a traditional DNS address

[General]
dns-server = 192.0.2.53

[General]: This is still the general settings section; there is no need to create a separate section named DNS.
dns-server = 192.0.2.53: Shows the syntax for entering an IPv4 address directly. This address is from a documentation-only example range and is not a working resolver. Before testing, replace it with a resolver address you are authorized to use and have confirmed is reachable.

Option C: Specify a DoH endpoint

[General]
dns-server = https://dns.example.com/dns-query

[General]: The same configuration section used in the first two options.
https://: Specifies HTTPS transport. Do not omit it and assume the app will treat the address as DoH.
dns.example.com: An example domain, not a DNS service provided by this guide. Enter the endpoint for a resolver service you already use.
/dns-query: A common DoH path, but not all endpoints use it. Enter the full address supplied by your DNS service; do not add or truncate the path yourself.

4. Check DNS settings separately from rules and Host

DNS resolves addresses, rules select a request policy, and Host can provide fixed mappings for specific domains. They affect different stages. If the configuration already has a Host mapping, a domain might not be queried upstream as expected. If the app retains an old address, refreshing the page immediately may not reveal a change.

Check DNS settings

Location: Config → active file → Edit
Section: [General]
Field: dns-server
Check mappings: Is the target domain listed in [Host]?

Confirm which file is being tested, then check whether a fixed mapping is affecting the result.

Check routing mode

Location: Home → Global Routing
Config: Applies routing rules from the active configuration
Proxy / Direct: Use to distinguish the global egress mode
Scene: Check the settings for the selected scene

Keep the routing mode unchanged during DNS tests. Don't change the resolver and egress in the same test.

For example, DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP matches against an IP geolocation database, and FINAL handles requests that did not match earlier rules. When using IP-based rules, check the resolution results and rule options to confirm what matched. A domain rule match alone does not prove that DNS succeeded.

Domain rules: Check that the target domain and suffix match, then review the resulting policy.
IP-based rules: Note the actual destination address; different resolution results can affect which address rule matches.
Host mappings: If the target domain has a fixed address, check that the mapping is still appropriate for its intended use.
FINAL: This is a routing fallback, not a backup resolver for failed DNS queries.

5. Verify and document your changes

For a valid comparison, keep the network, target, and routing mode the same, and change only one field. Choose a domain you are authorized to access and that is actively maintained. Record how it behaves with system DNS first, then test traditional DNS or DoH. Don't judge resolvers by how quickly a page loads once: connection reuse, page caching, and website response times can all obscure DNS differences.

Establish a baseline: Record whether you are on Wi-Fi or cellular, the current server on Home, the Global Routing mode, the active Config file, and the target domain.
Save and reconnect: Change only dns-server, save the configuration, and reconnect. End old requests in the target app, then make a new request to the domain.
Check resolution: Use an available DNS lookup tool or app log to inspect the result for the target domain. Record A and AAAA results, timeouts, or error responses. If the tool lets you select a resolver independently, confirm it is using the one being tested.
Check the connection: See whether the actual request succeeds, which policy it matches, and whether any connection or TLS errors occur. Don't record only a latency number.
Test network changes: After comparing options on the same network, test Wi-Fi and cellular separately. If only one network fails, first investigate differences in reachability on that network.

Observed result	What to check next	Conclusion to avoid
Traditional DNS times out; DoH returns a result	Check the UDP/TCP port 53 path between the current network and the resolver.	This does not establish that all website connections are working.
DoH reports a TLS error	Check the endpoint domain, certificate validity, system time, and connection path.	A certificate error is not simply a slow DNS response.
A returns a result; AAAA does not	Check whether the domain has an AAAA record, and distinguish a missing record from a query timeout.	No AAAA record does not mean DNS is failing overall.
An address is returned, but the webpage still times out	Check the matched rule, current egress, and reachability of the returned address.	Changing resolvers is not guaranteed to fix the problem.
Results are exactly the same after the change	Check the active file, Host mappings, cache, and existing connections.	The same results do not, by themselves, prove the change did not take effect.

Bottom line: use both query results and connection results

The setting meets your current needs only when the DNS response is normal and the actual connection succeeds. If it fails on just one network, keep a record of the error, revert to a configuration you have verified, and investigate the failing step separately.

6. Frequently asked questions and safe rollback

If I enter multiple resolvers, will Shadowrocket automatically fall back in order?

Don't infer query order, parallel behavior, or fallback behavior from the order in which entries are written. For initial troubleshooting, use just one resolver you have confirmed is reachable. After verifying it works, adjust the setup to meet your needs. Mixing system DNS, traditional DNS, and DoH in one list makes it harder to identify which resolver returned a given response.

Does enabling DoH guarantee that queries go through Proxy?

Not necessarily. DoH describes the query transport, not the routing policy. Check the actual path against the active configuration, Global Routing, and DNS-related settings. The presence of https:// alone does not prove that queries use a particular egress or that every app follows this resolution path.

What should I check if the problem returns after switching Wi-Fi networks?

First, check whether system DNS changes with the network and whether the custom endpoint is reachable on the new network. If Settings → On Demand is configured, also review its connection conditions and confirm that an automatic rule did not change the connection state during testing. On Demand controls when a connection starts; it does not replace dns-server.

How do I restore the previous settings?

In Config, restore the original dns-server line or re-enable the local copy you saved earlier, then return to Home and reconnect. If the original file did not include this field, remove it to restore the original state rather than adding a guessed value. Retest with the same target to confirm the rollback, and change just one setting at a time afterward.

The goal of DNS settings is to get verifiable results that suit your needs, not to find one method that works on every network. Check system DNS, traditional custom DNS, and DoH on the network you actually use. Keeping a copy of your configuration and a record of tests is more useful for troubleshooting than frequently switching several settings.