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

1. DNS Resolution vs. Outbound Connections

DNS settings in Shadowrocket determine which addresses correspond to a domain name. Global Routing and rules determine how a connection is routed. A website may fail at either stage, or the destination service itself may be having a problem. Changing DNS alone cannot fix an unreachable service port, failed connection authentication, or a website that refuses access.

The simplified flow below shows a request that is resolved locally. In practice, a domain rule may match before an address-based rule. Some proxy requests may also send the domain to a remote resolver, so not every connection follows the same local DNS path from start to finish.

Keep in mind that apps may have their own DNS behavior. A browser or another app may use its own encrypted DNS, and existing connections or caches may continue using an earlier address. Adding a resolver in Config does not mean every query from every app on the device will use it. For troubleshooting, keep the app, domain, and network the same so you are comparing like with like.

2. System DNS, Custom DNS, and DoH Compared

System DNS generally uses the resolver settings provided by the current network, so the resolver may change when you switch between Wi-Fi and cellular. Custom DNS explicitly specifies a resolver address in the configuration. “Custom” describes how the resolver is selected; it does not mean the connection is encrypted. DNS over HTTPS, or DoH, describes DNS queries sent over HTTPS and can also be configured as a custom resolver.

DoH encrypts query traffic between your device and the selected resolver, but the resolver still processes the queries. It does not guarantee faster results or resolution of internal domains. The returned address, the destination service’s geographic routing, and the network path can all affect how the site loads.

3. Set DNS in Config: Back Up, Then Change One Setting

Before you begin, make sure you already have a provider and subscription of your own and have verified that the basic connection works. Subscribe imports or updates connection details you already have; it does not configure DNS by itself. This guide changes only the DNS settings in the current Config and does not cover choosing a service.

1. Open Config, confirm which configuration file is currently in use, and save a copy. Editing a file that is not enabled will not change the active setup.
2. Open the configuration’s editing controls and locate the [General] section and the dns-server entry. The label or icon for editing may vary by interface version; use the controls shown on your screen.
3. If dns-server already exists, edit that entry rather than adding multiple settings with the same name at the end of the file.
4. Save the changes and confirm that the configuration is still selected. Return to Home, reconnect when it is safe to interrupt the connection, and test the same domain again.
5. Keep the DNS results and error messages from before and after the change. If the issue persists, restore the backup before testing another option.

The three snippets below are mutually exclusive minimal examples. Use only one at a time to replace the corresponding entry in your current configuration. They are not complete configuration files and should not replace existing rules or connection details. The public resolvers shown are syntax examples; whether to use them depends on reachability and the provider’s service policies.

Option A: Use system DNS

[General]
dns-server = system

system uses system DNS. It is useful as a baseline and in environments that rely on a local resolver. If an internal domain works when disconnected but stops working after switching to a public DNS server, check whether the domain is known only to the resolver on the local network.

Option B: Specify a traditional DNS resolver

[General]
dns-server = 1.1.1.1

This example specifies a single resolver to keep the test focused. A traditional DNS address does not need an https:// prefix; do not enter a webpage URL in the ordinary DNS server field. If the current network blocks external DNS, specifying an IP address may still time out. Restore system DNS to test first rather than adding more addresses one after another.

Option C: Specify DNS over HTTPS

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

DoH requires a complete endpoint: the protocol, host, and path all matter. Entering a DNS provider’s homepage does not give you a DoH address. This example uses an endpoint with a certificate valid for the specified IP address. Do not assume other endpoints can be changed to IP addresses without risking certificate validation errors.

4. How DNS Works with Global Routing and Rules

Check Global Routing on Home: Config applies the rules in the active configuration, while Proxy and Direct select proxy or direct routing. Scene selects a behavior based on the configured scene. When troubleshooting rules, keep the routing mode fixed. Testing in Proxy or Direct and then trying to explain the result using Config’s routing rules can lead to the wrong conclusion.

The following shows rule syntax only and is not a complete configuration. 192.0.2.0/24 is a documentation-only example network, not the address of a service to access. DOMAIN-SUFFIX matches domains by suffix, while address-based rules require a known destination IP. Adding no-resolve means that this address rule will not actively trigger a DNS lookup; it does not prevent the connection from using DNS altogether.

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

A DNS response does not guarantee that the connection will be routed as expected. Check DNS results and rule-match records separately. If the domain matched an earlier rule, changing a later GEOIP or FINAL rule will not affect that match. Do not infer the outbound path of DNS queries from the Global Routing label alone; it depends on the current DNS settings and the records available.

5. DNS Troubleshooting Checklist

Connectivity Test shows the test result for the selected connection; it does not fully verify a website’s DNS, TLS, and application-level access. If the test succeeds but a webpage fails, troubleshoot “no address returned” separately from “address returned, but the connection failed.” The steps below do not rely on made-up speed figures; record what you observe at each step so the issue can be reproduced.

1. Keep the network and test cases consistent. Record whether you are on Wi-Fi or cellular, along with the target domain, current Config, and Global Routing mode. Start with a domain that is actually failing and use a known-working domain for comparison.
2. Confirm the configuration is active. After saving, reconnect and check that the file you edited is still in use. If a remote update may overwrite your changes, test a copy and check the settings again after the update.
3. Identify where the failure occurs. No address returned, a query timeout, and a “not found” response are different from a connection timeout after an address is returned. Use available connection logs or the target app’s error message to narrow it down; “the website won’t load” alone does not prove a DNS issue.
4. Restore system DNS for comparison. If the site works again immediately but the specified resolver continues to fail, first check whether that resolver is reachable on the current network and whether you need access to internal domains.
5. Test DoH requirements separately. Check the endpoint spelling, HTTPS path, device time, and certificate errors. Being able to open an ordinary HTTPS site only shows that some HTTPS connections work; it does not prove that a specific DoH endpoint is reachable.
6. Check A and AAAA records. If an address is returned but access still fails, check whether the issue occurs only with one address family. An IPv6 routing problem is not necessarily a resolver problem, so do not start by removing all IPv6-related settings.
7. Check caches and automatic connections last. Reconnect and reopen the target app. Also check Settings → On Demand to make sure an automatic reconnect is not changing the connection state during testing. Clearing the cache is not a substitute for the checks above.

6. FAQ: DNS Still Not Working After Setup

Keep a record that reproduces the result: network, Config name, Global Routing mode, DNS value, target domain, and failure stage. Before sharing it, remove subscription URLs, authentication details, and private domain names. Testing one setting at a time—and keeping a working baseline you can restore—makes it easier to pinpoint the issue.