Shadowrocket DNS Settings: System DNS, Custom DNS, and DoH

What DNS resolution and traffic routing rules each do

DNS looks up domain names and returns records such as IP addresses. When you open a website, DNS resolution is only one part of the connection process. After an address is returned, the device still needs to select a route, establish a transport connection, complete the TLS handshake, and load the page. If changing DNS makes a site work, that can help narrow down the cause—but a site failing to load does not automatically mean DNS is at fault.

Shadowrocket's dns-server specifies the upstream resolver; DIRECT and PROXY in rules specify how matching traffic is handled. They are separate settings. Encrypted DNS does not mean website traffic must go through a proxy, and system DNS does not mean website traffic must connect directly.

This sequence highlights distinct troubleshooting stages; it does not mean every rule must wait for DNS resolution. DOMAIN-SUFFIX can match a domain suffix directly. IP-CIDR and GEOIP match IP addresses and may require DNS resolution when only a domain is available. Rules are evaluated in order, and FINAL handles traffic that matches no earlier rule. Changing DNS does not reorder these rules.

When to use system DNS, custom DNS, or DoH

“System” and “custom” describe where the resolver comes from; DoH describes how queries are transported. These categories are not mutually exclusive: manually entering a DoH URL is also choosing a custom upstream resolver. Consider network reachability, the need to resolve internal domains, and how queries are transported—not just the names of the options.

Check your active configuration before editing in Config

This guide uses edits to the [General] section of a configuration file, rather than relying on buttons that may move between app versions. Home shows connection status and Global Routing; Config manages configuration files; Settings contains app settings. Editing a file that is not active usually does not change the configuration used by the current connection.

1. In Home, note the current connection and Global Routing setting. To test rules, use the Config mode and confirm which configuration is active.
2. Open Config and back up or duplicate the current configuration. Keep the existing DNS line and other General settings so you change only one variable at a time.
3. Open the file's editing controls and find [General]. If dns-server is already present, edit that line instead of adding multiple settings with the same name to switch resolvers.
4. Save the file and make sure the test configuration is active. Then disconnect and reconnect so the next test uses the updated configuration.
5. Note whether you are on Wi-Fi or cellular, which domain you are testing, what happens, and how to restore the original settings. Then begin the comparison.

Three ways to set dns-server in [General]

These are three mutually exclusive minimal examples. Choose one at a time to replace the corresponding setting in your current configuration. Do not use these snippets to overwrite the entire file, or you will lose existing rules and other settings. If your configuration includes specific domain mappings or other DNS options, check how those interact as well.

Use system DNS

[General]
dns-server = system

system uses the DNS provided by the system. It makes a useful baseline for comparison, especially when the current network needs to resolve internal domains. “System” does not guarantee a fixed resolver address; the resolver may change when you switch between Wi-Fi, cellular, or system network settings.

Set a custom standard DNS resolver

[General]
dns-server = 1.1.1.1

1.1.1.1 is an example of a standard DNS address, not a recommendation for every network. Use an address for a resolver you trust and know is reachable. Entering an IP address alone does not turn standard DNS into DoH, nor does it tell you whether queries travel through a proxy.

Set a DNS over HTTPS endpoint

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

dns.example.com is a reserved example domain. The address above illustrates syntax only and cannot be used for DNS resolution. In practice, replace it with the full DoH endpoint provided by your DNS service, including https://, the hostname, and the path. /dns-query is a common path, but use the one specified by the endpoint—do not enter only the service homepage.

DoH protects DNS query transport, but does not replace outbound connection checks

DoH protects DNS queries between the client and resolver endpoint using HTTPS. It does not hide the queries the resolver must process, and it does not replace the TLS connection required by the website. The addresses returned by a resolver can vary with location, caching, and service policies; a difference alone does not prove an error or a faster result.

When a DoH endpoint uses a hostname, the client first needs to resolve that hostname to an address. This is called bootstrap resolution. If the hostname cannot be resolved, the certificate fails validation, or the HTTPS connection to the endpoint cannot be established, DNS may not work even when the configuration syntax is correct.

• Check the resolution result: Does the target domain return an address, an explicit not-found response, or only time out? These are different outcomes.
• Check the DNS transport: Is port 53 reachable for standard DNS, or can the client establish an HTTPS connection to the DoH endpoint?
• Check the destination connection: After an address is returned, does the website connection, TLS handshake, or resource request fail?
• Check rule matching: With Global Routing set to Config, check which domain and IP rules match and which final policy applies.

Do not map Global Routing's Proxy, Direct, and Config modes one-to-one to DNS types. These modes control traffic handling; Scene switches behavior based on a scene and is not a fourth DNS protocol. For comparable results, keep the same mode, connection, and rule file while testing DNS.

Use the same test steps to avoid misleading results from caching

Browsers, the system, and apps may all retain connection or DNS caches. A page that was already open may keep loading after you change settings; that does not prove the new resolver is active. A first visit may also be slower because a new connection needs to be established. Test the same set of destinations repeatedly rather than drawing conclusions from a single page load.

1. Establish a baseline: On the current network, use the original configuration to visit a familiar website and one that is currently failing. Record the specific symptoms, such as “DNS timeout,” “connection timeout,” or “some page resources failed to load.”
2. Change DNS only: Keep the connection, Global Routing mode, and rules unchanged. Replace only dns-server, save, and reconnect.
3. Make fresh requests: Close the existing pages and visit them again. Check connection records or logs for information that is actually available. A private browsing window does not guarantee that the system DNS cache has been cleared.
4. Compare after restoring: Restore the original DNS setting and test again. If both settings fail, check the destination service, outbound connection, and rules instead of repeatedly switching resolvers.
5. Test network changes separately: Only after that, repeat the test on Wi-Fi and cellular. Do not change networks in the same test round as DNS settings.

Common questions about DNS settings