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

At a glance

In Config, check the DNS fields in the active configuration. Then choose whether to keep system resolution, specify a resolver, or use DNS over HTTPS based on your network. This guide is for users who already have their own service and configuration and need to troubleshoot DNS or routing issues. Change one setting at a time, then check the lookup result, rule match, and connection separately instead of treating them as one problem.

First, distinguish DNS resolution from connection routing

Check the current connection and Global Routing in Home, then verify the active configuration in Config. Shadowrocket’s DNS settings control how some domain lookups are handled, while Global Routing and rules determine which policy handles a connection. Changing the resolver does not change the route used by every request.

Domain request Resolution Address result Policy decision Connection established

This flow helps identify where to troubleshoot; it does not mean every request triggers a new DNS lookup at each step. Apps, the system, and resolvers may cache results, and domain rules can determine a policy before an address is needed. Some connections resolve the domain remotely, so not every request should be understood as obtaining an IP address on the device first.

When Global Routing is set to Config, use the rules to determine where requests go. Proxy and Direct describe overall routing modes; neither alone tells you the actual path of a DNS query. For Scene, also check the settings associated with that scene. Keep the routing mode fixed while troubleshooting, and don’t switch scenes while changing DNS.

Choosing between system DNS, custom DNS, and DoH

First, note which domains resolve correctly on your current network, then compare the three options. System DNS uses the resolution environment available to the system; custom DNS specifies a resolver. DNS over HTTPS (DoH) describes queries sent over HTTPS. These options are not mutually exclusive: specifying a DoH address is also a custom DNS setting.

Option	What to enter	When to use it	What to check
System DNS	`system`	The current network resolves domains correctly, or you need internal network names	The resolution environment may change when switching between Wi-Fi and cellular
Custom traditional DNS	The IP address of a known, working resolver	You need a fixed resolver, and it is reachable on the current network	Traditional DNS queries are generally not encrypted in transit
DNS over HTTPS	A complete `https://` endpoint	You need queries sent over HTTPS, and the endpoint is reachable	Endpoint path, TLS certificate, and bootstrap resolution dependencies

Traditional DNS commonly uses UDP or TCP

443

HTTPS uses port 443 by default; an endpoint may specify a different port

If you need router management domains, company intranet services, or other internal names, keep the resolution path provided by the network. Public resolvers usually cannot resolve internal names. Sending all queries to an external resolver may leave public websites working while internal services fail.

Bottom line: keep a working baseline, then change the resolver

If system DNS currently works, save a copy of the configuration first. Change the resolver only if you need a fixed target or HTTPS query transport, then test the same domain on the same network.

Check dns-server and the DoH address in Config

In Config, find the active configuration, save a copy, then open its editor. If editing the text directly, locate dns-server under [General]. If the field already exists, edit its value rather than adding multiple fields with the same name to the same section; otherwise, it may be unclear which value takes effect.

[General]
dns-server = system

The example uses system DNS. To use a specified resolver, replace the value with an address you have verified is reachable. For DoH, enter the complete HTTPS endpoint provided by the service—not just a domain name, and not a regular DNS IP address with an HTTPS prefix added.

System DNS baseline

Path: Config → Current Configuration → Edit
Configuration section: [General]
Field: dns-server = system
Test conditions: Stay on the same Wi-Fi or cellular network

After saving, confirm this configuration is active, then reconnect and test.

Check the DoH endpoint

Field: dns-server
Address format: https://example.com/dns-query
Default port: HTTPS uses port 443
Security requirements: The hostname must match the certificate, and the path must support DoH

The example.com address illustrates the format only; it is not a working DNS service.

After saving, return to Config and confirm the edited configuration is active, then reconnect in Home. Editing an inactive file will not automatically change the current session as expected. If the configuration is maintained remotely, check the field again after an update; local edits to a remote configuration may be overwritten the next time it updates.

Record the original dns-server value and active configuration, and keep a restorable copy.
Change one resolver at a time. Don’t also change rules, protocol parameters, or routing policies.
Save, activate the configuration, and reconnect. Then test the same domain again.
If the result is worse, restore the original value and test again to confirm whether DNS caused the change.

If the DoH endpoint uses a hostname, its address must be resolved before the HTTPS connection can be established. This creates a bootstrap resolution dependency. Don’t make endpoint resolution depend entirely on the same DoH channel that has not yet been established. Keep a supported, working bootstrap resolution path, and use logs to identify where the failure occurs.

How DNS affects DOMAIN-SUFFIX, GEOIP, and IP-CIDR

When checking rule order in Config, first distinguish domain-based matches from IP address matches. DOMAIN-SUFFIX matches a domain suffix; GEOIP and IP-CIDR match addresses. If evaluating a rule requires the destination address, the DNS result may affect the match. If a domain rule already matches, later IP rules do not need to be evaluated.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

This syntax illustrates rule order only; don’t replace your existing configuration with the entire snippet. The first line sends matching requests with the example.com domain suffix to DIRECT. The second matches the corresponding private address range; no-resolve means not to trigger a DNS lookup specifically for this rule. The third uses IP geolocation data, and FINAL handles requests that did not match earlier rules. Make sure the policies you use are available in your configuration.

Domain information: Domain rules can only match when the request includes domain information usable for matching. A request made directly to an IP address cannot be identified by a suffix rule alone.
Address results: Resolvers may return different addresses because of caching, network location, or service routing. This can also change the outcome of subsequent IP-based rules.
Rule order: A broad rule placed first may prevent later, more specific rules from running. Check which rule matched before changing DNS.
Record types: A and AAAA records correspond to IPv4 and IPv6 addresses, respectively. Getting an address of either type does not guarantee that the network can connect to it.

Troubleshoot in order: timeouts, empty results, and pages that won’t load

Reproduce the issue on the same network and note the domain, time, active configuration, and Global Routing setting. Then check any available connection records or logs. First determine whether a DNS result was returned; next, check whether the connection succeeded. Don’t assume every failure is caused by DNS.

Check that the network itself works. On Wi-Fi that requires a captive portal, complete network authentication first. If Wi-Fi fails but cellular works, compare resolver reachability and network restrictions on each.
Confirm the configuration is active. Return to Config and check the active configuration and its dns-server value. If the system reconnects automatically, check Settings → On Demand for automatic connection conditions so you know the connection state during testing.
Identify the type of lookup failure. A timeout means no required response arrived within the waiting period. NXDOMAIN means the resolver considers the name nonexistent. SERVFAIL means the resolver could not complete the request. These errors do not all have the same cause.
Check DoH over HTTPS separately. Verify the complete path, device time, endpoint certificate, and reachability. Being able to open the endpoint’s website does not mean the specified path supports DoH. Don’t try to hide certificate errors by weakening verification.
If an address was returned, troubleshoot the connection. If DNS returns an A or AAAA record but the connection then times out, check the destination port, IPv4/IPv6 reachability, matched policy, and your existing connection settings instead of switching resolvers again.
Restore the baseline for comparison. Restore the saved system DNS configuration, reconnect, and test again. If the issue persists, broaden the troubleshooting scope rather than layering on more DNS changes.

Between tests, close and reopen the app used for verification, and wait for the DNS record’s TTL to expire if needed. Reconnecting does not guarantee that caches at every layer are cleared. Getting the same result for a domain within a short period does not prove the change had no effect.

Record each test result separately: whether an address was returned, what type of address it was, which policy matched, and where the connection failed. This is more useful for diagnosis than simply noting whether it works. For more on checking the connection process, see the connection troubleshooting guide.

Common questions about DNS settings

Pages still won’t load after switching to DoH. What should I check next?

In Config, first verify the active configuration and the complete endpoint address. Reconnect and check where the failure occurs. If the destination address was returned, check the matched rule and destination connection. If the endpoint reports a TLS error, check the device time and certificate; disabling verification is not a routine fix.

DNS works on Wi-Fi but times out on cellular. What should I do?

Keep the configuration and domain the same, and record the results on each network. If your custom address is local—for example, a router’s private IP address—cellular usually cannot reach it directly. Switch back to system DNS for comparison, then decide whether you need a resolver reachable on both networks.

Does setting up DoH guarantee that all DNS queries are encrypted?

You can’t determine that from a single field alone. It describes a particular query channel; lookups handled by apps, the endpoint’s initial resolution, and other resolution paths still need to be checked separately. Review the active configuration and actual query records to see whether the requests in question used the expected channel.

What if a DNS setting I entered manually changes after updating an existing configuration?

In Config, compare the files from before and after the update, and confirm whether you edited a remote configuration or a separate local copy. If you need to keep personal settings, back up the file first and maintain a clearly activated local copy. Compare each item when syncing later to keep connection parameters and DNS changes distinct.

After testing, keep a working baseline and a record of your changes. Choose DNS settings based on network reachability, internal name requirements, and query transport—not on the number of resolvers listed. Adding multiple targets also does not guarantee strict fallback in the order entered.