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

At a glance

If DNS is working, keep the system setting. Use a custom DNS resolver when you need a specific one, or DNS over HTTPS when you need encrypted DNS transport. This guide is for users with their own provider and configuration who are troubleshooting unreachable domains or unexpected routing. It explains where to make changes, how rules match, and how to test one variable at a time while keeping a working baseline.

1. Separate DNS resolution from connection routing

Shadowrocket DNS settings determine which address a domain name resolves to. Global Routing and configuration rules determine which route a connection takes. Changing DNS does not switch servers or automatically fix server authentication failures, unreachable ports, or network congestion. Treat these as separate issues before changing settings when a website won't load.

Domain request DNS resolution Rule evaluation Connection routing Response

This flow illustrates the troubleshooting logic; it does not mean every connection must be resolved locally first. DOMAIN-SUFFIX can match a domain directly, while address-based rules such as IP-CIDR and GEOIP may require a resolved address. Whether a proxy connection resolves remotely also depends on the protocol, request type, and configuration. A website loading does not prove that all DNS requests use the proxy.

Common UDP and TCP ports for traditional DNS

443

Default port for DoH over HTTPS

4 types

Global Routing：Proxy / Direct / Config / Scene

Port numbers can help identify a protocol, but they are no substitute for a complete configuration. A DoH service may use a specified non-default port, and traditional DNS can fall back to TCP even if you usually see UDP. Firewall restrictions, network sign-in portals, and resolver outages can all affect the result.

2. Choosing between system DNS, custom DNS, and DoH

“System DNS” and “custom DNS” describe where the resolver comes from; “DNS over HTTPS” describes how queries are transported. These are not mutually exclusive options: a manually entered DoH endpoint is also a custom resolver. First decide whether you need to change the DNS results, then whether you need to change the transport.

Setting	When to use it	Check before changing
System DNS	The current network resolves names correctly, or you need access to work, campus, or home-network domains	Whether the resolver provided by Wi-Fi or cellular is available
Custom traditional DNS	You need a specific resolver and have its address from a trusted source	The resolver is reachable on your current network and UDP/TCP port 53 is not blocked
DNS over HTTPS	You need DNS queries sent over HTTPS and already have a working endpoint	The full endpoint path, TLS certificate, initial hostname resolution, and outbound route all work

System DNS is generally more likely to preserve access to names on the current network. A public resolver may not recognize internal hostnames. After switching to a fixed public resolver, external websites may work while internal systems become unreachable. This is a change in DNS scope, not necessarily a Shadowrocket connection issue.

DoH encrypts DNS queries between your device and the selected resolver. The resolver can still see the queries, and DoH does not replace HTTPS on websites. It adds steps such as connecting to the endpoint and establishing TLS. Actual latency depends on the network, connection reuse, and caching, so DoH is not guaranteed to be faster than traditional DNS.

Bottom line: restore system DNS if internal domains stop resolving

If internal domains fail only after you switch resolvers, restore system DNS first. Keep the server and Global Routing unchanged, then try the same domain again. Don't change rules and protocols at the same time.

3. Set DNS in Config and keep a rollback point

These steps use the configuration profile settings on iPhone and iPad. Open Config, find the currently enabled profile, open its edit menu, then check DNS Server under General. Menu locations and field layouts can vary by version; the configuration key is included below for reference in the text editor. Do not enter a DNS endpoint in the server address field under Home → Add Server.

In Home, note the selected server and Global Routing mode. In Config, confirm which profile is enabled.
Duplicate or export the profile as a rollback point. Change DNS only in the copy and leave the original untouched. Store exported contents as sensitive information.
Go to Config → the current profile's edit menu → General → DNS Server. In the text editor, look for dns-server under [General].
Enter the address of a resolver you already have, or a complete DoH endpoint. Save and confirm that the copy is enabled. If needed, disconnect and reconnect to apply the setting to the current session.
Test the same domain and record whether it works and what error appears. If it fails, switch back to the original profile instead of piling on more changes.

System DNS baseline

Location: Config → Edit Profile → General
Section: [General]
Key: dns-server
Value: system

Use the system resolver as a baseline and first confirm that the original network works.

DoH endpoint details

Protocol: https://
Hostname: The endpoint hostname specified by the resolver service
Path: Use the full path specified in the service documentation
Default port: 443

Don't guess the endpoint based on a familiar path, and don't judge whether the service works by whether a browser can display a webpage.

The following snippets are alternatives; do not declare dns-server twice in the same configuration. The second snippet uses a reserved example domain to illustrate the syntax and is not a working service. Use an endpoint you already have; this guide does not recommend DNS services.

# System DNS baseline
[General]
dns-server = system

# DoH syntax example: example address is not usable
[General]
dns-server = https://dns.example.com/dns-query

A DoH endpoint that uses a hostname requires initial DNS resolution: the device needs the endpoint's IP address before it can establish an HTTPS connection. Don't casually replace the hostname with an IP address; this can cause certificate name validation or service routing to fail. If the current network cannot resolve the endpoint hostname, restore a working baseline first, then follow the service's instructions for initial resolution.

4. How DNS works with routing rules

To test rules in a configuration profile, set Global Routing to Config in Home. Proxy and Direct are different global routing modes; results from either one do not prove that a specific configuration rule is working. For Scene, first check which scene is active and its settings. Keep the same mode before and after changing DNS so the results are comparable.

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

DOMAIN-SUFFIX,example.com,PROXY: Matches the domain and its subdomains. It matches by domain, not primarily by address ownership. The example domain is not a service recommendation.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Matches this private address range. no-resolve means this rule will not trigger a DNS lookup; a known destination address can still match.
GEOIP,CN,DIRECT: Classifies the destination IP using a geographic database, not the webpage language or domain suffix. Changes in DNS results may indirectly affect whether this rule matches.
FINAL,PROXY: The fallback policy when none of the preceding rules match. It cannot fix DNS resolution failures or prove that DNS queries use the same outbound route.

Rules are evaluated from top to bottom. In the example, specific domains are handled first, then the address range, and finally the fallback. Don't move a broad rule to the top to “fix DNS”; it may mask more specific rules below. Before copying an example, check the policy names used in your configuration so you don't override an existing policy group.

5. Isolate DNS issues with one-variable tests

Before testing, confirm in Home that a server is selected, then run Connectivity Test. Use it as a reference for connection status, not as a complete test of all DNS requests. Even if the test succeeds, a particular domain can still fail because the resolver returned an incorrect result, a rule matched unexpectedly, or the website itself is having an issue.

Keep conditions constant. Use the same Wi-Fi network, server, domain, and Global Routing mode. Don't change the protocol or update subscriptions during the test.
Test the baseline first. Enable the system DNS configuration and note whether the site opens, whether a DNS error appears, and whether the issue affects only specific sites.
Change only the resolver. Enable the custom DNS or DoH configuration, reconnect, and try again. Record first-request results separately from requests served from cache.
Then change the network. Keep the DNS configuration unchanged and switch from Wi-Fi to cellular. If it fails on only one network, check network authentication, port restrictions, and endpoint reachability.
Verify the rollback. Restore system DNS and test again. One successful attempt isn't enough to identify the cause; check whether the result is reproducible.

Symptom	Check first	Next step
System DNS works, but DoH keeps timing out	Endpoint hostname, full path, outbound route, and network restrictions	Restore the baseline, check the endpoint documentation, then test only that endpoint
External websites work, but internal work domains fail	Whether the resolver was changed to one that does not recognize internal domains	Restore system DNS on the same network for comparison
The domain resolves, but the connection still times out	Rule match, destination port, and server connection	Check the actual policy in connection logs instead of changing DNS again
The behavior doesn't change right away	App cache, existing connections, and whether the configuration is enabled	Reconnect, reopen the target app, and confirm the active configuration

The table shows troubleshooting paths, not benchmark results measured for this guide. If you use a command-line tool to help with a lookup, check which resolver it uses. A standalone query outside Shadowrocket cannot prove that the app's requests follow the same path. Don't replace an HTTPS website address with an IP for comparison either; differences in certificates and virtual hosts can skew the result.

6. FAQs and configuration rollback

After setting up DoH, none of my webpages load. What should I change first?

In Config, switch back to the saved system DNS profile, reconnect, and revisit the original site. If it works, check the DoH endpoint's protocol, hostname, path, and port. Don't switch servers at the same time. If the problem persists after restoring the profile, check the connection and Global Routing in Home.

If a DoH address opens in a browser, does that mean it's configured correctly?

No. A DoH endpoint handles DNS requests in a specific format. A regular browser request may return an error or show an information page. Judge it by the client's actual DNS results, connection logs, and the endpoint instructions—not just by whether a page appears.

Why does DNS behave differently after I switch Wi-Fi networks?

The system resolver may change with the network, and endpoint reachability or access to internal domains may differ too. Compare the same configuration over Wi-Fi and cellular. If the connection also switches on or off automatically, check the trigger conditions under Settings → On Demand so you don't mistake automatic connection behavior for a DNS issue.

What if a subscription update reverts my DNS changes?

First, distinguish a server subscription update from a remote profile update. The former mainly updates server entries; the latter may replace configuration contents. Check the source of the active profile in Config, keep a local copy, and verify dns-server after an update. Don't post a complete configuration containing credentials on a public page.

A stable setup lets required domains resolve, routes connections as expected, works consistently on the networks you use, and has a rollback option. If system DNS meets those needs, there's no reason to change it just for the sake of changing it. If you need DoH, start with one known-working endpoint rather than adding several options at once and making the results hard to distinguish.