Shadowrocket DNS Settings: System DNS, Custom DNS & DoH

At a glance

Keep your current working DNS settings as a baseline, then choose a resolver and transport method based on your needs. For users with their own configuration in Shadowrocket, this guide explains system DNS, custom DNS, and DoH, outlines what to check, and separates lookup failures from rule-matching and connection issues.

First, distinguish the resolver from the DNS transport method

DNS resolves domain names to records such as IP addresses. System DNS refers to the settings provided by the device’s current network or system configuration. Custom DNS means specifying a resolver yourself. DNS over HTTPS, or DoH, describes sending DNS queries over HTTPS. Custom DNS and DoH are not mutually exclusive: a custom resolver can use DoH.

Start by asking two questions: which resolver handles the query, and how does the query reach it? Changing the resolver may change the returned address; changing the transport method changes the query’s route and how it is protected in transit. Neither changes a website’s own HTTPS settings or guarantees that the site will connect.

Method	How it works	Check first
System DNS	Uses the DNS settings provided by the current system; the actual query path may still depend on the tunnel and configuration.	Check whether lookup results or access to internal domain names change when switching between Wi-Fi and cellular.
Custom DNS	Sends queries to a specified resolver; standard DNS typically uses UDP or TCP port 53.	Check that the address is reachable, the port is available, and whether you need to resolve internal domain names.
DNS over HTTPS	Sends DNS messages over HTTPS to a resolver endpoint.	Check the full URL, certificate, initial resolution of the endpoint’s domain, and actual outbound route.

Decision: keep a working baseline, then change one variable at a time

If DNS works on your current network, record the results with system DNS first. Specify a custom DNS resolver only when you need to pin down the resolver, and test DoH only when you need encrypted query transport. Don’t change the resolver, Global Routing, and proxy settings all at once, or you won’t know which change affected the result.

DNS lookup and website connection are separate stages

In a typical domain-based request, an app needs to obtain the destination address before it can connect. The actual process may use a cache, resolve the name within the app, or resolve it through a proxy. The flow below does not mean every request completes every step locally.

Domain request Resolution Address returned Routing decision Connection to destination

During troubleshooting, record separately whether a lookup returned an address and whether the connection succeeded afterward. A returned address means the query received a response, but you still need to check whether the address works through the current route, whether the destination port is reachable, and whether TLS succeeds. A browser error alone does not prove that DNS is at fault.

Standard DNS commonly uses UDP or TCP

443

Default HTTPS port, commonly used by DoH endpoints

Port reachability is only one part of the check. DoH also requires a valid HTTPS path and certificate; changing the port after a standard DNS address from 53 to 443 does not turn it into a DoH service. DoH encrypts the query in transit to the resolver endpoint, but it does not hide the query from the resolver or automatically route all other traffic through a proxy.

Back up your settings and check whether the current configuration handles DNS

In Shadowrocket, first check the connection status and Global Routing on Home, then review the DNS settings under Settings → DNS. Also check the active configuration in Config: DNS entries in the configuration may affect actual behavior, so an address entered under Settings alone does not tell you which resolver is ultimately being used. Refer to the options currently shown in the app for available fields and settings.

Save the current values. Record the existing DNS entries, configuration name, and Global Routing option. Before editing a configuration file, keep a copy so you can restore individual settings.
Establish a baseline. On your current network, look up a known working public domain. If you need access to internal resources, also test an internal domain you actually use.
Change DNS only. Use parameters for a resolver you already have and are authorized to use. Don’t change servers, rules, or protocol settings at the same time.
Reconnect. After saving, disconnect and reconnect, then try again. Existing connections and cached results may still be in use, so don’t draw conclusions from a single page refresh.
Check each network. Test on the Wi-Fi and cellular networks you actually use. If Settings → On Demand is enabled, also check for automatic reconnections during testing.

Standard DNS settings to check

Address format: Resolver IP address
Documentation example: 192.0.2.53
Common port: UDP / TCP 53
What to check: Reachability, internal DNS requirements, and the actual outbound route

192.0.2.53 is an example address for documentation, not a usable DNS resolver.

DoH settings to check

Address format: Full HTTPS URL
Documentation example: https://dns.example.com/dns-query
Common port: HTTPS 443
What to check: Path, certificate, initial endpoint resolution, and reachability

The example endpoint does not provide DNS resolution. Use the complete URL and parameters supplied by a DNS service you already have.

If a DoH endpoint uses a domain name, that name must be resolved before the HTTPS connection can be established. This is often called initial resolution or bootstrap. The endpoint’s only source for resolving its domain cannot depend on the same DoH connection that has not yet been established. If your configuration has this dependency, check how initial resolution is handled instead of repeatedly entering the same URL. Don’t replace the endpoint domain with an IP address without good reason, as this may break certificate name validation.

How DNS relates to routing rules: a returned address does not mean a rule matched

Under Home → Global Routing, Config applies traffic according to the active configuration’s rules. Proxy and Direct are separate global routing choices; their test results are not a substitute for checking rules under Config. If you use Scene, first check which routing settings are active in that scene. Check the DNS query path separately from the policy applied to the destination connection.

Domain rules match available domain information; IP rules match the destination address. For traffic that requires an IP-based match, the lookup result may affect which rule applies. That does not mean every rule requires a local DNS lookup first. For example, when an app requests an IP address directly, there may be no original domain name to match.

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

DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains, then applies the specified policy.
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve shows an address-range rule; no-resolve means not to trigger a domain lookup specifically to match this rule.
GEOIP,CN,DIRECT matches against an IP geolocation database, not the domain text.
FINAL,PROXY is the fallback when no earlier rule matches. Rule order affects the result; rules are generally checked from top to bottom.

These examples illustrate syntax only. The sample domains and IP ranges are for documentation, not complete configurations you can apply as-is. If a DNS change causes a request to match a different IP rule, compare the returned addresses first, then check rule order. Don’t remove all your rules to fix a single domain. If resolver queries also need to go through a proxy, check for a dependency loop where connecting to the proxy requires DNS resolution, but DNS resolution itself depends on that proxy.

Troubleshoot lookup failures by symptom—not every timeout is a DNS problem

For each retest, record four things: the current network, the queried domain, the result or error, and whether the subsequent connection succeeded. Keep the configuration and destination consistent when comparing results, and account for caching. Connectivity Test on Home can provide a connectivity clue, but a single latency result is not download bandwidth and cannot prove that all domain lookups are working.

All domains time out after switching to DoH. What should I do?

Restore the previous DNS settings first and check whether the baseline works again. Then verify the full URL under Settings → DNS, whether the endpoint domain resolves, whether the device’s clock is correct, and whether the current route blocks the endpoint connection. A working regular webpage does not mean the specific DoH route is available.

Public websites work, but internal domain names at home don’t. Why?

First, confirm that the device is still connected to the relevant local network, then compare results from system DNS and custom DNS. Public resolvers typically don’t know private records on your local network; keep the appropriate internal DNS path instead of continuing to switch public resolvers. Also distinguish regular DNS names from mDNS names ending in .local.

The IP address is returned, but the page keeps loading. Is DNS the problem?

Check which rule and policy applied to the connection, then investigate destination connection timeouts or TLS errors. If both A and AAAA records are returned, also check whether the IPv4 and IPv6 routes work. If only one address path fails, that alone does not mean the resolver is broken.

Why do I still see the old results after changing the settings?

Save the settings and reconnect, then close the old page and try again. Also check whether Config still contains DNS settings that apply. DoH built into the app, system or app caches, and existing long-lived connections can all prevent a refresh from reflecting new settings. Check the relevant request records to determine what happened.

NXDOMAIN means the resolver reports that the domain does not exist; it is different from a timeout, where no response was received. SERVFAIL means the resolver could not complete the request, potentially because of an upstream issue, DNSSEC validation, or another resolution failure. Check the domain spelling first, then compare results for the same domain using the baseline resolution path. Don’t lump different errors together as “slow network.”

After testing, keep a record of the settings so you can roll back

Choose settings based on your actual access needs. System DNS provides a baseline for the current network; a fixed resolver is useful when you need to control where queries go; DoH is suitable when you need HTTPS query transport and the endpoint is reachable. To decide what to keep, check public and internal domains as well as the active routing rules—not just the time taken by one lookup.

Keep a record of the configuration source. Record where the resolver parameters came from and what they’re for. Don’t expose private addresses, credentials, or subscription content in public screenshots.
Check for automatic updates. Updating an existing subscription and editing a local configuration are separate actions. After an update, review the relevant settings so you don’t mistake update-related changes for DNS instability.
Keep rollback steps handy. Note the original DNS values and Global Routing option. If something goes wrong, restore the baseline first, then retest one change at a time.
Test one change at a time. If you need to change both rules and DNS, save and test them in separate rounds so you can tie each result to a specific change.

Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. For compatibility with other devices and system requirements, refer to the App Store listing. The app is a one-time purchase; buying the app is separate from any network service. This guide assumes you already have your own configuration. This site does not provide, sell, or recommend nodes or subscriptions.