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

At a glance

This guide is for users who have imported their own subscription into Shadowrocket and want to troubleshoot domain resolution. First, distinguish the resolver address, query transport, and connection route. Then make one change at a time in the active configuration’s [General] section and dns-server field, and verify the result using the same domain and network while keeping a record of what happens. Don’t rely on whether a webpage loads to determine whether DNS is working.

1. What DNS settings do—and don’t—control

DNS settings in Shadowrocket control domain resolution: translating a domain name into an IP address for a subsequent connection. System DNS uses the resolver provided by the current network. Custom DNS usually means specifying a resolver address. DNS over HTTPS describes how queries are transported: over HTTPS. These terms are not mutually exclusive; a manually specified resolver can also use DNS over HTTPS.

DNS and proxy routing are separate steps. Resolving an address does not mean the subsequent connection will use Proxy, and encrypted DNS does not mean every DNS request will pass through an existing server. Actual behavior also depends on the active configuration, Global Routing, the route used by DNS queries themselves, and whether the destination domain is resolved remotely.

Domain request Resolution path Resolved address Connection rule match Destination connection

The flow above separates responsibilities; it does not mean every connection must be resolved locally first. When the domain is available, domain rules such as DOMAIN-SUFFIX can be matched directly. Some connections may also pass the domain to a remote resolver. Rules such as IP-CIDR and GEOIP, which depend on address information, need to be understood in the context of actual resolution and rule options.

2. Choosing between system DNS, custom DNS, and DNS over HTTPS

Start with a baseline that works reliably. If DNS from the current network resolves the domains you need, system DNS adapts easily to Wi-Fi, cellular, and internal networks. Test custom DNS when troubleshooting a specific resolver or when you want to specify the query destination. Consider DNS over HTTPS when you need to encrypt queries between your client and the resolver.

Method	Query destination and transport	When to use it	Key limitations
System DNS	Uses the resolver provided by the current system; transport depends on the network configuration.	Keep the network’s default behavior; check internal domains and captive network sign-ins.	The resolver and results may change when you switch networks.
Custom traditional DNS	Specify an IP address; standard DNS typically uses UDP port 53, with TCP port 53 when needed.	Compare the reachability and responses of the default and specified resolvers.	Specifying an address does not encrypt the transport.
DNS over HTTPS	Specify an HTTPS query endpoint, usually on port 443.	Verify the encrypted query channel and endpoint connectivity.	Requires a working HTTPS connection, valid certificate, and available endpoint.

Standard service port for traditional DNS, over UDP or TCP

443

Default HTTPS port and a common port for DoH endpoints

2 types

Common record types: A for IPv4 and AAAA for IPv6

DNS over HTTPS protects query transport between your device and the resolver, but the resolver can still process the query contents. It does not replace HTTPS when you visit a website, nor does it guarantee lower latency. Initial connection setup, network blocking, resolver location, and cache state can all affect query time.

Bottom line: choose based on the issue, not an assumption about speed

If default resolution works, keep it as your baseline. If it fails, test one clearly specified resolver. To verify encrypted query transport, switch to DoH separately and leave the rest of the configuration unchanged.

3. Edit dns-server in Config

First check the active mode in Home → Global Routing, then open Config to confirm which configuration is enabled. The steps below use Config mode as the baseline. Proxy and Direct change how connections are handled. If you use Scene, first check the configuration and routing mode associated with the active scene so the baseline doesn’t change when you switch networks.

In Config, identify the configuration in use, save a copy of the original, and note its current dns-server value.
Open the configuration’s edit menu and choose Edit Plain Text. Find the existing [General] section; don’t add a duplicate section with the same name.
Replace the dns-server value in the existing [General] section. The three examples below are alternatives; don’t paste all three lines with the same field name.
Save the changes, confirm that the edited configuration is enabled, reconnect, and make a new request to a domain. Don’t just refresh a page that may still be reusing an existing connection.

System DNS syntax

[General]
dns-server = system

system means use the resolver provided by the system; it is not a fixed address. The DNS information available to the system may differ between Wi-Fi and cellular networks. If an internal domain works only on a workplace or home network, switching to a public resolver may prevent it from resolving.

Specify a traditional DNS address

[General]
dns-server = 1.1.1.1

The address here demonstrates the field syntax; it is not a recommendation for a resolver or a claim about its speed. To specify multiple resolvers, separate them with commas, for example dns-server = 1.1.1.1, 1.0.0.1. Don’t assume the second resolver will be queried only if the first one fails. To make troubleshooting easier, test with a single resolver first.

DNS over HTTPS syntax

[General]
dns-server = https://1.1.1.1/dns-query

This endpoint is shown only to illustrate the format of a complete URL. A DoH address must be an HTTPS query endpoint actually provided by a DNS service; a regular website homepage is not a DNS server. If you use an HTTPS endpoint in IP address form, the service certificate must cover that IP. Don’t replace an endpoint’s hostname with its resolved IP or disable certificate verification to work around a failure.

Configuration checklist

Menu path: Config → Active configuration → Edit Plain Text
Section: [General]
Field: dns-server
Change: Change only one DNS value per test

Edit the relevant line in the existing configuration; don’t replace the entire configuration with a snippet.

Check that the changes take effect

Configuration: Enable the configuration you just saved
Mode: Check Home → Global Routing
Connection: Reconnect before making a new request
Automatic connection: Check Settings → On Demand

On Demand connects according to specified conditions; it does not select a DNS resolver.

4. Verify DNS with repeatable steps

A webpage loading only shows that this visit succeeded; it doesn’t prove which resolver handled the query. A browser may reuse an existing connection, an app may cache addresses, and some apps use their own encrypted DNS. Record whether a query occurred, what it returned, and how the subsequent connection was routed as separate observations.

Keep the test conditions fixed. Use the same device, network, existing server, and Global Routing mode. Record the configuration name and current dns-server value.
Establish a system DNS baseline. With system, test one domain known to work and one domain that has caused problems. Record whether each succeeds, times out, or returns a domain-not-found error.
Change DNS only. Switch to a single custom resolver, reconnect, then close and reopen the test app before trying again. A new connection can reduce the effect of connection reuse, but it doesn’t clear every system or app cache.
Check available records. In Shadowrocket’s logs or request records, look for the test domain, query type, returned address, and any error. Record the resolver or outbound route too, if shown. An increase in traffic under Data is not, by itself, proof that DNS is working.
Test DoH last. Switch to an HTTPS endpoint and repeat the same steps. If the endpoint returns a webpage, HTTP error, or TLS error, troubleshoot the endpoint first; don’t change rules at the same time.

Item	What to record	Purpose
Network and configuration	Wi-Fi or cellular, configuration name, Global Routing mode	Rule out changes in test conditions
Query	Domain, A or AAAA, success or specific error	Distinguish address family from query failure
Response	Returned IP, visible TTL, whether it came from cache	Identify caching and changes in results
Subsequent connection	Matched rule, outbound policy, connection result	Distinguish DNS issues from routing issues

Different resolvers returning different IP addresses is not necessarily an error. CDN routing, resolver location, cache updates, and network conditions can all affect the response. Consider whether the destination connects, whether its certificate is valid, and whether the issue is reproducible. Don’t conclude that DNS is faulty just because two queries returned different IPs.

5. Narrow down the issue by symptom

When something fails, return to the one-variable test. In particular, don’t change DNS, Global Routing, your existing server, and rule files all at once. Otherwise, even if access is restored, it will be difficult to tell which change fixed the problem.

System DNS works, but custom DNS times out: Check whether the current network allows access to the resolver over UDP/TCP port 53. Being able to reach a regular HTTPS website doesn’t mean traditional DNS ports are reachable.
Traditional DNS works, but DoH fails: Check the endpoint path, port 443, device time, and any certificate errors. If the endpoint uses a domain name, its address must first be resolved to establish the initial connection. This is a bootstrap resolution issue.
Internal domains stop resolving: Switch back to system to verify. Public resolvers usually don’t know names used on a local network or within an organization; encrypted transport can’t make up for missing DNS records.
An address is returned, but the webpage still times out: Check the matched DOMAIN-SUFFIX, IP-CIDR, GEOIP, or FINAL rule, as well as the selected outbound route. Successful DNS resolution does not guarantee a successful connection to the destination.
Some websites fail intermittently: Check A and AAAA responses separately, along with connectivity over each address family. An AAAA response doesn’t mean IPv6 is usable on the current network. Don’t infer that everything is working based on just one address family.
Behavior doesn’t change after editing: Check whether you edited the enabled configuration, whether an old connection is still in use, and whether the test app has its own resolver. If the configuration is updated remotely, check whether the update overwrote your manual changes.

Bottom line: if you have an address but can’t connect, stop changing DNS

Once you’ve confirmed that the query succeeded, focus on the matched rule, outbound route, and destination connectivity. Keep adjusting the resolver only if the response is wrong or the resolution path is failing.

6. Save your results and restore the original settings

Once you have a reproducible result, decide whether to keep the change. System DNS suits networks that rely on their own resolvers. A specified resolver lets you control the query destination. DoH suits networks where encrypted query transport is needed and the endpoint is reliably reachable. All three need to be tested on your actual network; the field name alone can’t tell you which option is best.

Record the working dns-server value, test network, and symptoms. Don’t record credentials from an existing subscription.
Retest on your usual Wi-Fi and cellular networks to make sure the configuration doesn’t depend on a resolver that becomes unreachable when you switch networks.
If you use a remote configuration, recheck [General] after updating. Refreshing a server subscription and changing DNS settings are separate operations.
To undo the change, restore the original value from your backup and reconnect. If you originally used system DNS, restore dns-server = system.

These steps focus on editing and troubleshooting configurations on iPhone and iPad. Shadowrocket is a paid Apple-platform app available exclusively from the App Store. Check the App Store listing for system requirements, compatibility with other devices, and purchase details. App purchases and existing user subscriptions are managed separately; buying the app does not include a service plan.