How to Configure DNS in Shadowrocket: System DNS, Custom DNS, and DNS over HTTPS

At a glance

Start with a working baseline before changing Shadowrocket’s DNS settings. System DNS helps confirm that your current network can resolve domains; custom DNS specifies a resolver; DNS over HTTPS encrypts queries sent to a chosen DNS service. Assuming you already have your own service and subscription, this guide covers where to find dns-server in a configuration file, how the three options differ, and how to verify each change. DNS changes do not replace server connectivity checks or determine the outbound route for website traffic.

1. Understand the difference between DNS resolution and traffic routing

DNS converts domain name queries into address information that can be used to establish a connection. For example, when you visit www.example.com, an app may look up an A or AAAA record before connecting to the resulting IPv4 or IPv6 address. A successful lookup only means an answer was returned; it does not mean the destination port is reachable, the TLS handshake will succeed, or the page will load completely.

App request DNS lookup Address returned Traffic routing Destination response

This flow helps identify which stage to troubleshoot; it does not mean every connection follows the same internal sequence. When a domain rule matches, the client may choose a policy based on the domain directly. Connections that resolve domains remotely may not obtain the destination address locally first. Encrypted DNS used by an app, existing cache entries, and other DNS options in the configuration can also affect what you observe.

Global Routing and DNS are separate settings. Proxy, Direct, Config, and Scene control how traffic is handled; dns-server specifies where DNS queries are resolved. Entering a DNS server address does not route every connection through Proxy, nor does it guarantee that queries go through the currently selected proxy server.

2. What the three DNS options change

In the [General] section of a configuration file, dns-server can use the system resolver, a specified DNS server address, or a supported encrypted DNS address. The comparison below covers configuration methods, not speed rankings. Actual response times depend on your network, resolver availability, cache, and returned results, so test on your own network.

Option	Example value	When to use it	Keep in mind
System DNS	`system`	To test the current network’s DNS, or resolve names on a local network	The DNS resolver may change when you switch between Wi-Fi and cellular
Custom DNS	`1.1.1.1`	When you need to specify a known, reachable DNS server	Standard DNS queries are not encrypted in transit
DNS over HTTPS	`https://cloudflare-dns.com/dns-query`	When you need to encrypt queries between the client and a specified DNS service	Requires a reachable endpoint, valid TLS verification, and an initial lookup of the endpoint’s domain

The public DNS addresses in the table illustrate syntax; they are not suitable for every network. Names on a company or home network may only exist on its internal DNS server. Switching to a public resolver may leave public websites accessible while preventing internal names from resolving. This changes the scope of DNS resolution, so access to a public website alone does not prove the configuration is fully correct.

Common port for standard DNS; traditional queries usually use UDP and may also use TCP

443

Default HTTPS port, commonly used by DoH endpoints to receive queries

Takeaway: choose a resolver you can verify, then consider encryption

If DNS already works, save that as your baseline. If you choose DoH, first verify that the endpoint is reachable and its certificate validates, then test the target domain. An address beginning with https does not eliminate the need to check server connectivity and rules.

3. Change dns-server in the active configuration

Before editing, check the current mode in Home → Global Routing, then open Config and confirm which configuration file is active. Changes to a saved but inactive file will not affect the current setup. To avoid confusion, copy or back up the active configuration, note the existing dns-server value, and then open the file for editing.

In Config, find the active configuration file and open its editing screen. The specific controls may vary; follow what is currently shown in the app.
Find the [General] section and its existing dns-server line. Replace the value if the line already exists; do not repeatedly add the same setting at the end of the file.
Choose just one of the three examples below. Keep the other required settings in the file; do not replace the entire configuration with these lines.
After saving, confirm that the configuration is still selected, return to Home, disconnect and reconnect, then run the test again.

System DNS: establish a baseline

[General]
dns-server = system

system uses the DNS resolver provided by the system; it does not hard-code a public address in the configuration file. On Wi-Fi that requires a network sign-in, complete authentication first. If network access has not been granted, switching to a public resolver or DoH endpoint may not solve the problem.

Custom DNS: specify a resolver

[General]
dns-server = 1.1.1.1

This IP address belongs to the DNS resolver, not your proxy server or the website you want to visit. To enter multiple standard DNS addresses, separate them with commas, for example dns-server = 1.1.1.1, 8.8.8.8. Do not assume the list order guarantees a strict primary-and-backup failover. When troubleshooting, start with one address to make the results easier to interpret.

DNS over HTTPS: enter the full endpoint

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

A DoH value should be the complete HTTPS endpoint provided by the DNS service, not its information page. Do not omit https:// or change the /dns-query path. A hostname-based endpoint must be resolved to an address before a connection can be made, so DoH does not eliminate every need for an initial DNS lookup.

Configuration checklist

Location: Config → active configuration file
Section: [General]
Key: dns-server
Action: Edit the existing value, save, and reconnect

These examples show only the DNS line; they are not complete replacement configurations.

DoH endpoint checklist

Scheme: https://
Host: cloudflare-dns.com
Path: /dns-query
Requirement: The endpoint is reachable and TLS verification succeeds

An error page when opening a regular website does not, by itself, prove that DoH queries have failed.

4. How DNS relates to rules and On Demand

To check rule-based routing, first select Config in Home → Global Routing, then inspect [Rule] in the active file. Domain rules and address rules use different information: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, and GEOIP matches against an IP geolocation database. Rules that require an address may be affected by the DNS response.

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

DOMAIN-SUFFIX,example.com,DIRECT matches the domain and its subdomains; it does not specify a DNS server for them.
The IP-CIDR example covers a private address range. no-resolve means the rule will not trigger an additional domain lookup for a match; it does not turn off all DNS.
GEOIP,CN,DIRECT makes a decision based on the IP address. The result is not simply determined by a website’s language or domain suffix.
FINAL,PROXY is the fallback when no earlier rule matches. This example illustrates syntax only; do not use it to replace your complete rule set.

Settings → On Demand controls when connections start or disconnect based on conditions; it does not choose a DNS resolver. If it changes the connection automatically after a Wi-Fi switch, two test requests may run under different conditions. Note or temporarily disable any triggers that could affect testing, then restore your original settings afterward.

Updates to your existing subscription and updates to a Config file are separate. A change to the server list does not mean the DNS line in your current configuration has also changed. If you fetch or replace the configuration file, check [General] again to confirm your edits are still there.

5. Verify the change under consistent conditions

Do not rely on a webpage opening occasionally as your only test. Keep the network, server, Global Routing mode, and test domain constant; change only dns-server. Cached results may persist after an edit, and existing connections may keep working. Disconnect and reconnect, then make new requests rather than revisiting an already open page.

Record a baseline. Note the original DNS value, network, and Global Routing mode. Run Connectivity Test with the same server and record whether it succeeds.
Change one setting. Edit just one DNS value, save the active configuration, and disconnect and reconnect. Do not change rules, the server protocol, or On Demand conditions at the same time.
Make new requests. Visit a known working domain again, then try one that failed before. If you need local network services, test an internal name as well.
Check the results. Review the destination, rule, and handling result in Data connection records. If the interface does not show DNS details, do not infer which resolver was used from traffic counts alone.
Test another network. Verify separately on Wi-Fi and cellular, and record the results. If the issue occurs on only one network, first check whether that network can reach the DNS server or DoH endpoint.
Revert and compare. Restore the original value and test again. If the failure consistently follows the setting change, investigate the new resolver or endpoint instead of layering on more changes.

Connectivity Test checks whether a connection works, but one successful test does not prove that every domain used the specified resolver or reveal the outbound path of DNS queries. Likewise, DIRECT or PROXY in Data describes how a particular connection was handled; it should not be taken as evidence about all DNS queries.

6. Common questions and how to revert

DoH is configured, but websites will not load. Why?

Restore the original dns-server value in the active Config file, reconnect, and test again. If things work after reverting, check the full endpoint, network reachability, and device time; an endpoint may need an initial DNS lookup, and certificate verification depends on the correct time. Do not change the server and rules at the same time, or you will not know which change caused the problem.

Internal names at home stopped working after switching to custom DNS. Why?

Restore system and try the internal name again on the same Wi-Fi network. Public DNS services usually do not know names maintained by a home router or an organization’s internal DNS. If you need to resolve such names, keep a resolver that can answer them, then handle public domains according to your network setup. Do not assume a failed internal lookup is caused by the proxy server.

I saved the change, but nothing seems different. Why?

In Config, check which file is actually active and make sure you did not edit a different copy. Then check for duplicate dns-server entries. After saving, disconnect and reconnect from Home, then make a new request. If the target app uses its own encrypted DNS or cache, what you observe may not directly reflect this setting.

Does using DoH mean all DNS traffic is encrypted?

No. This setting specifies the endpoint for the relevant DNS requests, but does not cover the endpoint’s initial lookup, DNS built into an app, or other configuration paths. Confirm the setting is active, then use available records to inspect actual requests. DoH encrypts the connection to the DNS service, which still processes the query contents.

Keep a verified working configuration and a record of your tests. To revert, restore only the DNS line changed in this guide, save, and reconnect. If the entire configuration was replaced, restore your backup and check Global Routing again. This lets you investigate DNS changes separately from traffic policy changes instead of toggling several settings at random.

Shadowrocket is a closed-source commercial app for Apple platforms, available exclusively on the App Store. It is primarily used on iPhone and iPad; check the App Store page for system requirements. The one-time app purchase does not include a server plan. This guide does not provide, sell, or recommend servers or subscriptions; connection and DNS checks assume you already have your own service.