How to Set Up DNS in Shadowrocket: System DNS, Custom DNS, and DNS over HTTPS

At a glance

Shadowrocket DNS settings determine where some domain lookups are handled; they do not directly determine the outbound path for every connection. This guide is for users who have already added their own service and want to troubleshoot name resolution or adjust DNS. First check whether system DNS works on your current network, then compare custom DNS with DNS over HTTPS, and verify the results using the same domain, network, and rules. Available options and initial values depend on what the app currently shows.

1. Separate DNS Lookups from App Connections

DNS translates domain names into information needed to connect. An A record typically returns an IPv4 address, while an AAAA record returns an IPv6 address. Once it has an address, the client still needs to establish a TCP, UDP, or other connection. That means “the domain resolves” and “the website loads” are two separate checks. A returned address does not guarantee that the destination port is reachable, the proxy connection succeeds, or the site’s certificate is valid.

The flow below shows a common local-resolution scenario; not every request has to use local DNS. Some proxy connections can send the domain to the remote side for resolution, and some apps use their own encrypted DNS. When troubleshooting, check the actual request records. Don’t assume that a single DNS setting takes over every app’s lookups.

Send a domain lookup Choose a resolution path Get an address Establish the connection Check the result

For example, if a browser says “server not found,” check whether the lookup timed out or returned a non-existent domain. If an address was returned but the connection later times out, check the outbound path, destination port, and network conditions. Don’t keep changing DNS based only on a browser error message.

2. System DNS, Custom DNS, and DoH Compared

System DNS usually follows the current network’s DNS configuration, which may come from Wi-Fi, cellular service, or device management settings. Custom DNS means specifying a resolver. DNS over HTTPS (DoH) sends DNS queries over an HTTPS connection. These aren’t mutually exclusive categories: manually entering a DoH service URL is also a custom DNS configuration.

Method	Typical transport	When to use it	What to check
System DNS	Depends on the system and current network configuration	The current network’s DNS works, or you need access to internal domains	Whether the resolver and internal domains change when you switch networks
Custom traditional DNS	Usually UDP 53; some responses require TCP 53	You have the address of a reachable DNS resolver	Resolver routing, port 53, and whether returned records match expectations
DNS over HTTPS	Usually HTTPS 443	You have a reachable DoH service and need encrypted query transport	Full URL, certificate, service-domain resolution, and connection path

DoH protects queries in transit between your device and the DoH service, but the resolver still receives the queries. It also does not encrypt all of your app traffic. Whether queries go through a proxy depends on the actual resolution path and outbound policy. A URL starting with https:// alone does not mean app connections now use a proxy.

Recommended approach: keep a working baseline, then try encrypted DNS

If DNS works reliably on your current network, first note how system DNS behaves. Test a known reachable custom DNS or DoH service only if you can reproduce a resolution problem or have a specific need to encrypt query transport. Don’t add several unknown settings at once.

3. Settings → DNS: Setup Steps and What to Record

Open Settings → DNS and note the current values. Then check whether the active configuration under Config also includes DNS-related settings. App settings and Config may both affect actual behavior, so don’t rely on just one input field. Field names, initial values, and supported formats depend on what the app currently shows; don’t assume values from an older configuration are defaults on every device.

Keep the original settings. Record the current contents of Settings → DNS and the active Config. Keep a copy of the original Config if needed. Don’t overwrite your only working configuration.
Test one method at a time. When comparing system DNS, custom traditional DNS, and DoH, change only one setting per test. Keep Global Routing, server selection, and the test network the same.
Enter the actual service details. For traditional DNS, use the address of a reachable resolver. For DoH, enter the complete URL provided by the service. Don’t guess the path or use a regular website homepage as a DoH endpoint.
Save and apply as prompted. If the current interface says to reconnect for the change to take effect, follow the prompt and then make a new query. Existing connections and cached results may still reflect the previous settings.
Keep the change only if tests confirm it works. Check DNS resolution and the app connection using the same domain, then test again on Wi-Fi and cellular. If a new problem appears, restore the settings you recorded.

Traditional DNS: What to Record

What to check: Settings → DNS
Address format: The resolver’s IPv4 or IPv6 address
Common ports: UDP 53; TCP 53 when needed
Example: 192.0.2.53, documentation example only

This example address is not a usable resolver. Use a value provided by your existing network or DNS service.

DoH: What to Record

Address format: The complete URL, including scheme, domain, and path
Format example: https://dns.example.com/dns-query
Common ports: HTTPS 443
Requirements: The service domain resolves, its certificate is valid, and the endpoint is reachable

This URL illustrates the format only; it is not a usable service. Use the path provided by the actual service.

Adding multiple addresses does not necessarily mean they’ll be tried strictly in the order listed. How queries are scheduled, whether the app falls back, and which settings affect resolution depend on the app’s current behavior and active Config. To isolate a problem, test with one clearly identified resolver instead of stacking several addresses.

4. If DoH Won’t Connect, Check How Its Domain Resolves First

A DoH endpoint is usually a domain name too. Before establishing an HTTPS connection, the device needs to resolve that domain to an address; this is often called bootstrap resolution. If the only available resolution path depends on a DoH connection that hasn’t been established yet, a circular dependency can occur. You may see all new domain lookups time out after enabling DoH, while restoring the previous DNS settings restores access.

Check the URL. Make sure it has no leading or trailing spaces and that the path hasn’t been omitted or truncated. /dns-query is common, but it isn’t a required path for every service.
Check the certificate. Make sure the device’s date and time are correct and that the HTTPS certificate matches the service domain. Don’t disable certificate verification to hide a connection problem.
Check bootstrap resolution. Use a DNS method that already works to confirm the service domain resolves, then check the current configuration for a circular dependency.
Check the connection path. A reachable port 443 is only one requirement. Being able to load an ordinary webpage does not prove that DoH queries are getting valid responses.

Don’t casually replace the domain in a DoH URL with an IP address. The HTTPS certificate and service routing may depend on the original domain, and replacing it can cause a certificate mismatch. If the service documents a bootstrap-resolution method or address binding, follow its instructions and the options supported by the app rather than assembling parameters from guesswork.

5. How DNS Relates to Global Routing and Rule-Based Routing

Under Home → Global Routing, Proxy, Direct, Config, and Scene select a routing mode; they are separate from the DNS server address. Proxy uses the proxy path, Direct connects directly, Config follows the active configuration rules, and Scene follows the selected scene’s settings. Before troubleshooting rule matching, confirm that the current mode actually uses the rules you expect.

The following is a rule syntax example, not a complete configuration to replace your existing Config. PROXY must point to a valid policy in the active configuration; the documentation address range shown is not a real service destination.

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 and usually doesn’t need to look up the destination IP just to match that rule. It is not a DNS server setting.
IP-CIDR matches the subnet containing the destination IP. In this example, no-resolve means the rule won’t trigger a domain lookup. If the destination IP is already known, the subnet can still be checked.
GEOIP matches against IP geolocation data. For a domain lookup where no address has been returned yet, the check may involve resolution. Geolocation is not a definitive guarantee of the destination’s actual location.
FINAL sets the fallback policy when none of the preceding rules match. It won’t fix an incorrect DNS response or an unreachable resolver.

Changing DNS can change the destination address returned and, in turn, affect IP-based rule matches. Conversely, proxy egress and network conditions can affect whether the resolver is reachable. When troubleshooting, record “how the domain resolves” separately from “how the connection is routed” so you can identify the cause instead of changing both at once.

6. Test Under Consistent Conditions, Not with One Page Load

DNS caching, connection reuse, and a website’s use of multiple addresses can all affect what you observe. After changing settings, an existing page connection may keep working while a new domain lookup fails; that doesn’t necessarily mean the settings weren’t saved. Choose one public domain you know works and one domain that has actually failed. Keep the test conditions consistent and record the resolution and connection stages separately.

Set a baseline: Stay on the same Wi-Fi network and record the DNS method, Global Routing mode, selected server, destination domain, and error message.
Check basic connectivity: In Home, use Connectivity Test to check its test destination. A successful test only confirms that specific test path works; it doesn’t show that all domains or DNS queries are working.
Change one thing: Change only the DNS method and apply the setting as prompted. Make three new attempts to reach the same destination and record success, timeout, or a specific error. Don’t present three attempts as a long-term performance result.
Check network differences: Then switch to cellular and keep all other conditions unchanged. If the problem occurs only on Wi-Fi, first check that network’s DNS and port restrictions.
Test the rollback: Restore the original settings and repeat the same test. You can attribute the problem to a resolution path only if it consistently appears and disappears as you switch that setting.

How to interpret the results: if resolution succeeds but the connection times out, check the connection

If the records show a destination address and the failure occurs during the subsequent connection, check the matched rule, outbound policy, and destination port. If no address is returned, focus on resolver reachability, DoH bootstrap resolution, and caching.

7. Common Questions About DNS Settings

Websites load more slowly with DoH enabled. Should I keep using it?

Compare it with your previous DNS method on the same network and under the same Global Routing mode. The first DoH connection may involve bootstrap resolution and a TLS handshake; later connections may reuse the connection. If several new attempts are noticeably slower or time out, restore the previous settings and check whether the endpoint is reachable. Encryption does not automatically make DNS faster.

Internal domains at work or home won’t open. Will switching to public DNS help?

Internal domains may be known only to your current network’s resolver. Restore the network’s original DNS first and check whether the internal domains resolve again. If you need different resolution paths, configure them explicitly using the options supported by the current Config. Don’t keep sending internal-only domains to an external resolver that has no record for them.

Some websites still won’t open after changing DNS. Could IPv6 be the issue?

You can’t conclude that from a few failed websites alone. Check whether an AAAA record is returned and whether the failure occurs during the IPv6 connection. An AAAA record only indicates that an IPv6 address exists; it doesn’t prove that your current network has a working route to it. Note your existing IPv6 settings, then test one change at a time. Don’t change DNS, rules, and several network options simultaneously.

A subscription update failed. Will changing DNS fix it?

In Home, update a subscription you already have and note the specific error. If the message reports a domain resolution failure, check resolution for the subscription domain. If it reports an HTTP status error, invalid credentials, or an unreadable response, changing DNS usually won’t help. Subscription updates and app connections may use different paths, so test them separately.

When keeping a setup that works, also record the test network and active Config. If a problem appears after switching networks or updating Config, compare those conditions before changing DNS. For help with Global Routing and rule checks, see the Global Routing guide in the Options Manual and the Rules guide.