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

At a Glance

This guide is for users who have already connected with Shadowrocket and want to choose a DNS option or troubleshoot domain resolution. First, distinguish the DNS server, query transport, and query route. Then compare system DNS, custom DNS, and DoH one variable at a time, and check the results against your Config rules and connection logs.

What DNS Settings Affect

DNS resolves domain names to IP addresses. When you open a website, the client typically needs an A or AAAA record before connecting to the corresponding address. A records map to IPv4; AAAA records map to IPv6. A successful DNS lookup does not guarantee that the subsequent TCP, TLS, or proxy connection will succeed, so a site that will not load is not necessarily having a DNS problem.

The flow below is a troubleshooting model, not a sequence that every connection follows exactly. Domain rules can match before the destination IP is known, while IP-based rules may depend on a DNS result. Some proxy connections may also send the domain to the remote server for resolution.

Domain request Rule evaluation Resolve if needed Select outbound route Establish connection

There are three separate questions: which DNS server receives the query, which protocol carries it, and which network route the query takes. Entering a server address answers only the first. Choosing DoH mainly changes the second. The DNS query's outbound route still depends on your configuration and connection conditions, so you cannot infer it from the setting alone.

Common UDP / TCP ports for traditional DNS

443

Common HTTPS port for DoH; the endpoint may specify another

2 types

Common address record types: A and AAAA

System DNS, Custom DNS, and DoH

System DNS usually uses the resolver configuration provided by the device's current network. It is a useful baseline and is more likely to resolve internal domains on a company, campus, or home network. The DNS server in use may change when you switch from Wi-Fi to cellular, so record results separately for each network.

Setting	What it controls	When to use it	What to check
System DNS	Uses the system resolver configuration	Establish a baseline; access domains that rely on local DNS	Network changes, internal domains, and system settings
Custom traditional DNS	Specifies a DNS server address	You need a fixed resolver, and the server is reachable	UDP / TCP 53 reachability and returned records
DNS over HTTPS	Queries a specified endpoint over HTTPS	You need encrypted query transport, and the endpoint can establish an HTTPS connection	Full URL, certificate, device time, and initial resolution

“Custom” and “encrypted” are different things. Manually entering the IP address of a standard DNS server does not turn it into DoH, and DoH does not guarantee more suitable addresses for your network. A resolver may return different content delivery addresses based on the query source and its own policies. If a site gets slower after changing resolvers, the query itself may not be the cause.

DoH encrypts DNS queries between your device and the DoH endpoint. It does not hide the queries from the endpoint, replace a website's own HTTPS, or mean every app uses the same DNS route. Some apps maintain their own caches or resolution mechanisms, so account for them separately when testing.

Rule of thumb: Keep a working baseline before changing transport

If system DNS reliably reaches the site, record that result first. Test custom DNS or DoH only when you have a specific resolution problem or need encrypted query transport. Do not change your proxy, rules, and DNS settings at the same time.

Entering DNS Settings in Shadowrocket

The steps below refer to the Home, Config, and Settings layout on iPhone / iPad. Check the active connection on Home, confirm the enabled configuration in Config, then go to Settings → DNS to review resolution settings. Menus may differ across platforms, so do not assume the mobile tap sequence applies everywhere.

Note the current connection and Global Routing selection on Home, and save a copy of your current Config. Obtain proxies and subscriptions from your service provider; this guide does not provide or recommend those services.
Go to Settings → DNS to review the current setting. Also check whether dns-server appears under [General] in the active Config. Do not assume the effective configuration has changed after editing just one location.
First test access with system DNS, then change only the DNS setting. For DoH, enter the full HTTPS endpoint specified by the DNS provider, not its product or information page.
After saving, reconnect and try the same domain again. If the old result persists, consider cached data or an existing app connection before deciding whether the setting took effect.

Use the cards below to check what each field means; they are not ready-to-use DNS services. 192.0.2.53 is a documentation-only example address, and dns.example.com is an example hostname. Replace both with real values you are authorized to use and have confirmed are reachable.

Traditional DNS checklist

Setting: Settings → DNS
System value: system
Example address: 192.0.2.53, format example only
Config entry: dns-server under [General]

Entering an IP specifies the resolver; it does not enable encrypted transport.

DoH checklist

Protocol: https://
Example endpoint: https://dns.example.com/dns-query
Path: Use the path specified by the DNS service
Certificate requirements: The certificate must be valid and match the endpoint hostname

A DoH endpoint is not a subscription link. Do not enter subscription content in a DNS field.

If you manage DNS through a Config file, start with the minimal snippet below to establish a system DNS baseline. This is only a file snippet; it does not include proxy or rule settings and must not replace your full existing configuration. A remote Config update may change the file, so check the relevant fields again after updating.

[General]
dns-server = system

How DNS Works with Rule-Based Routing

Proxy, Direct, Config, and Scene in Global Routing are different routing modes, not four DNS protocols. Proxy and Direct select the overall outbound route; Config applies the rules in the active configuration; Scene uses the settings for the selected scene. When troubleshooting rules, first confirm the expected mode. A result in Direct mode cannot prove that a proxy rule is working.

The snippet below shows the order of domain, IP, and fallback rules. example.com and 192.0.2.0/24 are syntax examples only. PROXY must point to a proxy policy available in your current configuration.

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

DOMAIN-SUFFIX matches a domain suffix; this example includes the domain and its subdomains. It determines the request policy, not the DNS server.
IP-CIDR matches an IP address range. In this example, no-resolve means the rule will not actively trigger a domain lookup; address matching can still occur when the request already has a destination IP.
GEOIP matches based on IP geolocation data, not page content. A change in the resolved IP address may change which rule matches.
FINAL catches requests that did not match an earlier rule. Rules are processed from top to bottom; a broad rule near the top may prevent more specific rules below it from matching.

A DoH request also needs to connect to a server. If the endpoint uses a hostname, the device usually needs to resolve that hostname first; this is called initial resolution. If that lookup or the connection to the endpoint fails, regular websites may appear to get stuck resolving. Avoid a circular dependency where the endpoint must be reached through a proxy, while establishing that proxy depends on resolving through the endpoint.

How to Verify DNS Is Working

Check three layers: configuration, queries, and outbound connections. Seeing a saved setting only confirms that the input was accepted; opening a website only confirms that some working route completed the request. For a reliable conclusion, match the active configuration with query results and connection logs rather than relying on a single successful page load.

Keep conditions constant. Use the same device, Wi-Fi network, proxy, Global Routing mode, and destination domain; change only DNS. Record whether resolution timeouts, connection timeouts, or TLS errors occur before and after the change.
Check the query. Use a DNS lookup tool available on your platform or connection logs to inspect the domain's A / AAAA results. If the tool specifies a different DNS server, it can only verify that server; it cannot show that Shadowrocket's current setting is working.
Check the endpoint. When using DoH, look for a connection to the endpoint hostname and check the actual port. An HTTPS connection alone does not prove that a DNS answer was returned successfully; check the error logs too.
Check the rule. Review the rule, policy, and outbound route matched by the request. If DNS succeeds but the request matches an unexpected policy, adjust the rule order in Config instead of changing resolvers again.
Test again. Reconnect, reopen the app, and test once more. Then switch to cellular and run a separate test. Keep the network-switch test separate from the first comparison so you do not mistake a network difference for a DNS difference.

Caching can make results misleading. The system, browser, app, and resolver may all cache results, and existing connections may continue to be reused. A page that opens immediately may not have triggered a new lookup; seeing the old address after changing DNS does not necessarily mean the change failed. Check the timestamps of new queries and connections instead of repeatedly switching settings.

Rule of thumb: Confirm resolution before checking outbound connections

If you have reasonable A / AAAA results but connection logs show subsequent timeouts, check destination reachability, the IPv6 route, and proxy outbound connections. Do not treat another DNS change as the default fix.

Common DNS Problems and Fixes

After setting up DoH, no websites load. What should I check first?

Restore the system DNS baseline you had before the change and reconnect. If access immediately returns, check the full DoH URL, initial resolution of the endpoint hostname, its certificate, and the device time. Do not bypass errors by disabling certificate verification; an incorrect endpoint path can also cause queries to fail.

Why does DNS work at home but fail for company intranet domains?

First check whether the domain is only available through your company's internal DNS. External resolvers usually do not know internal records. Restore the system DNS required by that network, or use a split-DNS configuration approved by your administrator. Do not send company intranet domains in bulk to an external endpoint for testing.

The domain resolves, but the website keeps loading. What should I do?

Check the connection status and Global Routing on Home, then review the matched policy in Config. Check A and AAAA separately: if only connections to IPv6 addresses fail, investigate the IPv6 route. Successful resolution and address reachability are separate issues; a DNS result alone cannot tell you whether the route is working.

A DNS test shows a different resolver. Does that mean my setting did not take effect?

Not necessarily. The result may reflect the DNS service's upstream resolver or egress, and the app may use its own resolver. First make sure Shadowrocket was connected during the test, then check the active Config, DNS queries, and endpoint connection logs. The organization name shown by a test is not enough to determine the DNS route.

A subscription refresh timed out. Should I change DNS first?

First identify whether the subscription domain failed to resolve, the HTTPS connection failed, or the provider returned an error. Get subscriptions from your service provider; check with them if a link has expired or its authorization is invalid. Follow the DNS comparison steps in this guide only when the logs clearly show a domain resolution failure.

Keep the setting that reliably resolves domains on your actual network and meets your needs for internal access and privacy. Before returning to everyday use, remove the example values, restore any required On Demand conditions, and save the verified Config. If you later change both the network and configuration, establish a new baseline for comparison.