Choose DNS settings in Shadowrocket based on what works on your current network. If everything is working, start with system DNS. Use an existing custom DNS server when you need a specific resolver, or check DNS over HTTPS when you want to encrypt queries in transit. This guide is for users who already have their own provider, subscription, and working connection. It explains the difference between resolution, routing, and connectivity, and covers how to make one change at a time, check logs, and restore the original settings.
First, distinguish DNS resolution from Global Routing
DNS (the Domain Name System) translates domain names into addresses that can be reached. A successful lookup is only the first step in loading a page; the rest includes rule matching, establishing a connection, the TLS handshake, and receiving a response. A page failing to load does not necessarily mean DNS is at fault, and changing resolvers will not fix every connection timeout.
This flow helps identify which stage to troubleshoot; it does not mean every request follows the exact same sequence. Cached results, early domain-rule matches, remote resolution, and an app’s own resolver can all change what happens. In particular, domain rules can match locally before an IP address is obtained.
Home → Global Routingcontrols the overall routing mode; it does not select the DNS server.Configmode routes traffic according to the rules in the active configuration.ProxyandDirectselect the corresponding global outbound route.Scenelets you choose a scene. When troubleshooting, note the active scene and the configuration it uses; a scene is not a DNS protocol.Settings → On Demandcontrols when a connection starts. If network conditions change during testing, the connection state may change too, so record it as well.
If you already have a subscription, updating it typically refreshes its connection entries; it does not necessarily update the DNS settings in the active Config. Before troubleshooting, note the selected connection, active configuration, and Global Routing mode separately so you don’t confuse these three states.
Choosing between system DNS, custom DNS, and DoH
System DNS uses the resolver settings provided by the current network environment, which may differ between Wi-Fi and cellular. Custom DNS specifies a resolver; if you enter a standard DNS server address, queries usually use traditional DNS transport. DNS over HTTPS (DoH) changes how queries are transmitted, but does not guarantee faster responses or addresses better suited to your network.
| Option | What you need first | Useful for | Main limitation |
|---|---|---|---|
| System DNS | The current network provides working DNS resolution | Establishing a baseline, resolving local network names, completing network sign-in | The resolver may change when you switch networks |
| Custom DNS | An existing server address that is reachable on the current network | Using a specific resolver, comparing results across networks | Standard DNS queries are not encrypted in transit |
| DNS over HTTPS | An existing, complete endpoint, a valid certificate, and a working HTTPS route | Encrypting queries between your device and the resolver endpoint | Depends on endpoint reachability, bootstrap resolution, and a successful TLS handshake |
A DoH endpoint can use another explicitly specified port. Being able to access an HTTPS website does not prove that a particular DoH endpoint is reachable. The server name, port, request path, and certificate must all match. Encrypting query transport still lets the resolver process and see queries; it does not mean all traffic is hidden.
Bottom line: keep a working baseline, then change the resolver
If system DNS reliably reaches your target, record that result first. Don’t change both the resolver and outbound connection just to chase a faster result from a single test. If resolution is failing, change one DNS setting per test and retry the same domain.
Check DNS in the active Config before changing one setting
Open Config and confirm which file is active, then check its [General] section and dns-server entry. You can also review the in-app DNS options under Settings → DNS. Don’t edit an inactive configuration file and then assume the resolver failed to take effect.
- Keep the original settings. Make a rollback copy of the current configuration and record the DNS field, Global Routing mode, and current network. Store the copy securely if it contains credentials.
- Choose test domains. Pick one public domain that you know works and one domain that is actually failing. Test local network names separately rather than grouping them with public domains.
- Change DNS only. Check
dns-serverin the active configuration, or review the existing value in the relevant DNS settings. Don’t change outbound routing, rules, IPv6, or On Demand at the same time. - Save and reconnect. End the current connection, turn it back on, and then make new requests. An already open page, existing connection, or cached result is not enough to verify the change.
- Identify where it fails. Check whether the issue is a DNS timeout, connection timeout, or certificate error. If things get worse, restore the original configuration and reconnect.
The two snippets below show alternate ways to write the same field. Don’t add both to the same configuration. Keep any other settings the file needs; don’t replace the full configuration with a few example lines.
[General]
dns-server = system[General]
dns-server = https://resolver.example.com/dns-queryIf your configuration is managed by remote updates, first check whether an update will overwrite local changes. Test with a backup in place, then recheck the active file’s actual value after updating instead of relying on what you entered last time.
How to enter and verify a DoH URL or standard DNS address
A standard DNS address and a DoH URL are different formats, not interchangeable values. The former identifies a server; the latter also includes a protocol, hostname, and request path. Adding https:// to a standard DNS address does not make that server support DoH.
Check a standard DNS address
- Address example
192.0.2.53- Common port
53; check both UDP and TCP paths- Where to enter it
- The
dns-serverentry in the active configuration - Prerequisite
- An existing, working server and network access to it
192.0.2.53 is a documentation example address and cannot be used for testing.
Check a DoH endpoint
- Protocol
https://- Example host
resolver.example.com- Example path
/dns-query; use the path specified in the endpoint documentation- Certificate requirements
- The certificate must be valid and match the endpoint hostname
DoH uses a complete URL. This example explains the format; it does not provide a DNS service.
A DoH endpoint specified by domain name needs bootstrap resolution: its address must be found before an HTTPS connection can be established. If bootstrap resolution is unavailable, this can create a dependency loop: DNS is needed to look up the DNS server’s hostname. Check the network’s basic DNS resolution and the route to the endpoint; adding more endpoints that cannot connect will not help.
- Reachable address doesn’t mean the protocol is available: reaching an IP does not mean its specified port offers DoH.
- An HTTP response doesn’t mean the query succeeded: an error page when opening an endpoint in a browser does not, on its own, prove that DoH is down. A regular browser request is not a valid DNS query.
- Investigate certificate errors: check the device’s time, hostname, and network sign-in status. Don’t disable certificate verification as a fix.
How rules, IPv6, and local DNS can affect results
After DNS returns an address, traffic still goes through the applicable routing decision. DOMAIN-SUFFIX matches domain suffixes, while IP-CIDR and GEOIP match address information. Changing resolvers can change the returned address, which may also change which address-based rules match.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThe example above illustrates syntax and matching, not a complete configuration. DIRECT means direct routing, and PROXY routes through a proxy; check that the policy names are supported by your active configuration. Rules are evaluated from top to bottom, and FINAL handles traffic that did not match earlier rules. The address range is for documentation only and should not be copied into a real-world routing configuration.
no-resolvemeans the address rule won’t trigger a DNS lookup for a domain. It does not disable all DNS or clear existing resolution results.- The
AandAAAArecords for the same domain may point to different addresses. Receiving an AAAA record only means resolution returned an IPv6 address; it does not mean the current IPv6 connection route works. - Internal domains on a home or corporate network may rely on a local resolver. If public websites work but internal names fail after switching to an external resolver, investigate that separately.
- Some apps use their own encrypted DNS or caching. If behavior in one app doesn’t change, that alone doesn’t mean Shadowrocket failed to save its DNS settings.
When using Wi-Fi that requires a sign-in page, complete network authentication before testing custom DNS. If authentication is incomplete, an HTTPS endpoint may be unreachable, certificates may appear invalid, or all external requests may time out. These are often network access issues, not DNS syntax errors.
How to verify a change: identify the failing stage, not just whether a page opens
Test on the same network, with the same outbound connection and routing mode. Establish a baseline with the original settings, then try the new ones. For each test, record the time, target domain, whether an address was returned, and the result of the subsequent connection. Don’t directly compare an instant cached response with the time required to establish a DoH connection for the first time.
| What you see | Check first | What to do next |
|---|---|---|
| No address appears in the log, followed by a timeout | Resolver reachability, endpoint format, and bootstrap resolution | Restore system DNS, leave other settings unchanged, and test again |
| An address is returned, but the connection times out | Matched rules, outbound route, and destination port | Check the active policy; don’t change DNS again yet |
| Public domains work, but internal names fail | Whether the names rely on local network DNS | Retest on the original network with the original DNS settings |
| Works on Wi-Fi but fails on cellular | Endpoint reachability and connection state on each network | Reconnect on each network, record the results, and check On Demand conditions |
| The previous address still appears after reconnecting | DNS cache, app cache, and existing connections | Make a new request to distinguish a cached result from a fresh lookup |
In-app logs can help narrow down the issue, but not every request displays the same fields. If no new DNS entry appears, the result may have come from cache, or resolution may have happened elsewhere. Check the request time and routing records together; the absence of a single log entry is not enough to draw a conclusion.
- For a domain with a reproducible issue, record the results with both the original and new settings.
- Check whether an A or AAAA record was returned, then check the address and policy used for the connection.
- For privacy testing, use a test domain and server you control. Different resolver exit addresses do not necessarily indicate a problem.
- After comparing results, keep only verified changes, remove test values, and retain a rollback copy.
Bottom line: if an address was returned, check the connection and rules
If your records show that an address was returned and the failure happened later during connection, check the matched policy and destination route first. Changing DNS again introduces another address variable and makes the original issue harder to isolate.
FAQ: DNS settings saved, but still not taking effect?
Why do I still get the same results after changing DNS?
First, use Config to confirm you changed the active file, then save and reconnect. Close the old page and make a new request; compare its timestamp with the logs. Also check whether a configuration update overwrote your change, and whether the target app is using a cache or its own resolver.
Does using DoH mean all requests go through a proxy?
No. DoH describes how DNS queries are sent over HTTPS; it does not determine the proxy policy. Check Home → Global Routing first, then see how the active configuration handles connections to the endpoint and traffic to the destination. Verify DNS query routing and webpage request routing separately.
The node latency looks normal, but domains won’t open. Should I change DNS first?
First check whether the logs show a returned address. A latency test only reflects its own test process; it doesn’t prove that the target domain resolved or that the webpage connection works. Only after confirming a DNS-stage failure should you compare with system DNS while leaving the outbound connection unchanged.
I can’t access anything after changing DNS. How do I restore it?
Switch back to the configuration you saved before making changes, check the original dns-server value, and reconnect. If the network requires a sign-in, complete authentication first. If each network change triggers a new connection, review the existing conditions under Settings → On Demand.