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

At a glance

If DNS works on your current network, start with system DNS. Test custom DNS when you need a specific resolver, and consider DNS over HTTPS when you want to encrypt queries between the client and resolver. This guide is for users who have loaded their own configuration in Shadowrocket. It covers where to change dns-server, what each option can and cannot do, and how to tell a DNS failure from a rule mismatch or connection failure.

1. Separate DNS Resolution from Connection Routing

DNS translates domain names into IP addresses. For example, when you visit www.example.com, a resolver may return an IPv4 A record or an IPv6 AAAA record. Once the address is available, the client still uses the current routing mode and rules to decide how to connect. A successful DNS lookup and a page that loads are two separate checkpoints.

Domain request Cache check Resolver query Address returned Connection check

This sequence shows a common order for checking domain resolution; it does not mean every request triggers a new DNS lookup. App and client caches, as well as connection methods that resolve domains remotely, can change where a lookup happens. Domain rules may also match before local resolution, so DNS is not necessarily a separate step that every rule must pass through.

When checking Global Routing on Home, consider the mode separately from DNS settings: Config uses the rules in the active configuration, Proxy and Direct change the overall connection policy, and Scene applies settings by context. Switching modes will not fix an incorrect resolver address. Configuring DoH also does not mean every connection goes through a proxy.

DOMAIN-SUFFIX,example.com,DIRECT: Matches a domain suffix; the decision does not depend on a specific IP address.
IP-CIDR,192.168.0.0/16,DIRECT: Matches the destination IP range. Whether a lookup is needed also depends on the request and rule parameters.
GEOIP,CN,DIRECT: Matches the geographic database entry for the destination IP; the domain name alone is not enough to decide.
FINAL,PROXY: Sets the final policy when no earlier rule matches; it is not a DNS server setting.

2. Choose Between the Three DNS Options

System DNS and custom DNS primarily determine which resolver to use. DNS over HTTPS also specifies how queries are transported. These options are not entirely in the same category: manually specifying a DoH endpoint is itself a custom DNS setting. First confirm the resolver and network reachability, then consider encryption in transit.

Option	Resolution path	When to use it	What to check
System DNS	Uses resolver information supplied by the current network.	DNS works on the network, or you need to resolve names on a local network.	The resolver may change when you switch Wi-Fi or cellular networks.
Custom traditional DNS	Sends queries to a manually specified DNS address.	You have a working resolver and need to keep queries pointed at it.	Whether the address is reachable, supports the domains you need, and allows DNS traffic.
DNS over HTTPS	Sends DNS queries to a specified endpoint over HTTPS.	You need encrypted query transport, and the endpoint and its certificate can be validated.	Endpoint path, TLS, initial resolution of the endpoint domain, and the actual outbound route.

Traditional DNS commonly uses UDP / TCP ports

443

Default port for DoH over HTTPS

2 types

Common address records: A and AAAA

DoH encrypts DNS query traffic between the client and the DoH resolver; the resolver still processes the domain lookup. It does not change how a website handles HTTPS or guarantee faster access. Establishing TLS can make the first lookup slower, while connection reuse and caching can affect later results. One page load is not enough to judge performance.

Takeaway: Keep a working baseline before changing resolvers

If the same domain resolves reliably with system DNS, save that setup as a fallback. Then change only dns-server in each test, leaving rules, connection policies, and server settings untouched so you can identify what caused the change.

3. Change dns-server in Config

Before editing, find the configuration currently in use under Config and save a copy. Then open its text editor. The field to change is dns-server in the [General] section, not the Address of a connection entry on Home. Use the editing options available in the current interface, and do not mistake a server address for a DNS address.

In Config, confirm the name of the active configuration and note the current dns-server value. If the field is absent, record that too.
Open the configuration text and find the existing [General] section. If the section is already present, edit it rather than adding a duplicate.
Keep only one dns-server setting for this test. Save the file, then select the configuration again.
Go back to Home and set Global Routing to Config to test the configuration rules. If a brief disconnection is acceptable, disconnect and reconnect to reload the changed settings.
Visit the same test domain again and note the DNS and connection results. If it fails, restore the previous value instead of adding more resolvers one after another.

System DNS: Start with a baseline

[General]
dns-server = system

system means using the system's DNS information. It does not guarantee that the router will answer directly, or that other apps will use exactly the same resolution path. Test again after changing networks, especially on Wi-Fi that requires a login first.

Custom traditional DNS: Use an address you know is reachable

[General]
dns-server = 192.168.1.1

192.168.1.1 is an example of a local network address. It works only if that device actually provides DNS and is reachable on the current network. A gateway address is not necessarily a DNS address, and a private address from a home network cannot simply be carried over to a cellular network. Use a value from a network or DNS service you already have access to.

DoH: Enter the full endpoint, not the website homepage

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

The dns.example.com value above is only an example of the format and will not connect as written. Replace it with a complete DoH endpoint you have confirmed works. The path is not always /dns-query; follow the DNS service's documentation. A regular HTTPS page loading successfully does not mean it can handle DNS queries.

4. Check the Endpoint, Network, and Outbound Route

DoH endpoints are usually specified by domain name, which may need to be resolved before an HTTPS connection can be established. If the initial lookup fails, the query cannot reach the DoH service. Adding more domain-based endpoints to the list will not necessarily solve this; check initial endpoint resolution, routing, and reachability on the current network.

Traditional DNS checklist

Configuration field: dns-server
Example address: 192.168.1.1, for the corresponding local network only
Common port: UDP 53 / TCP 53
Network requirements: Reachable through the current interface; the destination must provide DNS

First confirm the server's role, then check whether it returns answers for the domain.

DoH checklist

Address format: Full HTTPS endpoint, including any required path
Default port: TCP 443
TLS requirements: The certificate matches the endpoint domain, and the device clock is correct
Initial resolution: The endpoint domain can be resolved before the connection is established

HTTPS indicates encrypted transport; it does not mean queries necessarily go through a proxy.

Do not disable certificate verification to troubleshoot DoH failures. Check the full endpoint, the device's date and time, and whether the network requires a login. If the problem occurs only while Shadowrocket is on, also check the rules in Config and the endpoint's outbound route so the endpoint is not sent along an unreachable path.

If local names depend on an internal resolver, switching directly to an external resolver may return that no such record exists.
An AAAA record does not guarantee that the current IPv6 connection path works. Verify resolution and connectivity separately.
If an app uses its own DoH or keeps a long-lived cache, changing the client DNS setting may not produce a new query you can observe.
Some requests resolve domains remotely, so the absence of a query in the local log does not by itself mean the setting failed.

5. Verify DNS Changes in a Consistent Order

Keep the same network, rules, and connection entry throughout testing. First record the results with system DNS, then switch to one custom resolver. Use the same domain in every round. Do not also refresh a subscription, switch networks, or change DNS at the same time; even if access returns, you will not know which change made the difference.

Record a baseline: Note the network type, active configuration, Global Routing mode, test domain, and whether the original failure was a DNS timeout or a connection timeout.
Confirm the reload: Save, select the configuration again, and reconnect. If the app you are testing may be reusing an old connection, fully quit it and reopen it before testing.
Check the resolution stage: Look for a query, answer, or timeout for the same domain in the available diagnostics or logs. A cached result may not generate a new query, so do not treat that alone as evidence of failure.
Check the connection stage: If a destination IP is available but the connection times out, check the matching policy, destination port, and availability of the existing connection entry.
Repeat the comparison: Repeat the test several times under the same conditions, distinguishing the first lookup from cache hits. A one-off success is not proof of long-term reliability.

What you see	Check first	Next step
Query times out; no answer received	Resolver address, network reachability, DoH endpoint path	Switch back to system for comparison, then test one known-working endpoint on its own.
NXDOMAIN returned	Spelling, whether the domain exists, whether it depends on internal DNS	Check the full domain name and compare it using the baseline configuration on the same network.
An IP is returned, but the connection times out	Rule policy, destination service, and actual connection route	Check the policy record for that connection instead of blindly changing DNS again.
Works on Wi-Fi, fails on cellular	Whether a private resolver address is configured and whether the endpoint is reachable across networks	First rule out a local-network-only address, then establish a new baseline on cellular.

Takeaway: Let evidence from each stage guide the next step

Once you see a DNS response, focus troubleshooting on the connection policy and destination service. Change the resolver, endpoint, or its outbound route only when the query itself fails. Do not assume that every site that will not load has a DNS problem.

6. Common Questions About DNS Settings

Why does changing dns-server seem to have no effect?

In Config, first confirm that you edited the active configuration. Save it, select it again, and reconnect. Then quit and reopen the app you are testing. If the app reuses a cached address or handles DNS itself, the page result alone cannot prove the client setting failed; check the query logs as well.

If I set up DoH, do DNS queries always go through a proxy?

Not necessarily. DoH uses HTTPS to transport queries, but the actual outbound route depends on the client's DNS handling, the current mode, and the relevant configuration. Check the endpoint's actual route; an address starting with https does not tell you how it is routed.

Why did my home network's local names stop working after I changed DNS?

External resolvers usually do not know the internal records on a home router or workplace network. Switch back to system and test the same full name on the original Wi-Fi. If it works again, configure DNS for that internal network rather than treating an external resolver as a replacement for every name.

Why didn't updating my existing subscription fix DNS?

A subscribed connection entry and dns-server in Config are separate configuration items. Go to Config and check the field in the file that is actually active. If you updated a remote configuration, also check whether it overwrote your local changes. Repeatedly updating the connection list is not a substitute for checking DNS.

It reconnects as soon as I disconnect during testing. How can I compare settings?

Check Settings → On Demand and note the current conditions. If needed, temporarily turn off automatic connection for the test, then restore the original settings afterward. On Demand controls when to connect, not which resolver to use; keep the connection state from changing during the comparison.