This guide is for users who have already set up a connection in Shadowrocket and want to check their DNS settings. First, distinguish the DNS resolver, query transport, and traffic policy. Then check dns-server in Config and troubleshoot timeouts, unexpected results, and network-switching issues one variable at a time. The steps assume you already have your own service and subscription. Examples do not include working connection details or lists of public DNS resolvers.
1. DNS Resolution vs. Outbound Connections
Shadowrocket is a closed-source, paid app for Apple platforms, primarily used on iPhone and iPad. The App Store is the only place to buy and install it, and the app is sold as a one-time purchase. Buying the app does not include a connection plan. This site does not provide, sell, or recommend nodes, subscriptions, or service providers. Check the App Store listing for pricing, system requirements, and purchase availability. DNS is one part of the app’s configuration; it does not replace a connection service you already have.
DNS looks up records such as IP addresses for domain names; it does not establish a connection to a website. When you visit a domain, your browser may use a cached result or send a new query. Once it has an address, it still needs to route traffic, establish a transport connection, and complete the TLS handshake. So a successful DNS lookup does not guarantee the site will load, and a failed connection does not necessarily point to DNS.
This flow illustrates dependencies; it does not mean every request follows the same complete sequence on the device. A cache hit can bypass a new query. Some proxy setups resolve the domain remotely, and apps that perform their own encrypted lookups may not use the server configured here. Before troubleshooting, identify which type of request you are observing.
2. System DNS, Custom DNS, and DoH: What to Consider
“System DNS” and “custom DNS” describe where the resolver comes from, while “DNS over HTTPS” describes how queries are transported. They are not mutually exclusive categories: manually specifying a DoH URL is also custom DNS. The system’s resolution path may also be affected by settings such as DNS configuration profiles on the device, so it is not safe to assume that system DNS always uses unencrypted transport.
| Option | Source or transport | When it makes sense | Check first |
|---|---|---|---|
| System DNS | Uses the current system DNS settings | The current network resolves domains correctly and you need a baseline | Whether results differ between Wi-Fi and cellular |
| Custom traditional DNS | Manually specified server, typically using UDP or TCP port 53 | You know the server address and have access to it | Server reachability, port, and access to the local network |
| DNS over HTTPS | Sends queries to a resolver endpoint over HTTPS | You have a complete, trusted, reachable DoH URL | Hostname, path, TLS certificate, and initial resolution |
An open port does not prove that a service is available. A server listening on port 443 is not necessarily a DoH resolver. Traditional DNS may also use TCP for larger responses or in certain conditions, so checking only UDP is not enough. DoH encrypts queries between the client and the resolver; the resolver can still process their contents, and this does not automatically route website connections through the same path.
In short: Keep a working baseline, then change the resolver
If the current network works, note how system DNS behaves first. Change DNS only when you have a clear reason to choose a specific resolver or encrypt queries. Avoid changing rules, connections, and DNS settings at the same time.
3. Find and Edit dns-server in Config
First, check the current Global Routing option in Home, then open Config and confirm which configuration is in use. Do not edit a similarly named file that is not active. This guide uses [General] and dns-server in the configuration text to identify the setting, rather than relying on button placement, which can vary between interface layouts.
- In Config, select the active configuration and save a copy of the original file or note the existing DNS line so you can restore it.
- Open the configuration’s edit menu, choose the option for editing its text, and find the
[General]section. Menu labels may vary depending on the current app interface. - Find the existing
dns-serversetting and edit that line. Do not add a duplicate at the end of the file or in a different section. - After saving, confirm the configuration is still selected. If it needs to reload, turn the connection off and back on in Home; this will briefly interrupt the current connection.
- Retest using the same network and test domain, and compare the results with your notes from before the change. If it fails, restore the original line and check whether access returns.
System DNS baseline
- Configuration section
[General]- Setting key
dns-server- Setting value
system- Check
- Save, confirm the configuration is selected, and reconnect
system means “use system DNS”; it does not specify a fixed server address.
Checking a DoH URL
- Configuration section
[General]- Setting key
dns-server- URL components
- HTTPS scheme, hostname, and service path
- Documentation example
https://dns.example.com/dns-query
example.com is a reserved documentation domain, not a working DNS resolver. Do not use this URL to connect.
To restore system DNS, change the relevant setting to the form shown below. The code shows only the relevant section, not a complete configuration; do not replace the entire file with it. If a remote update manages the current configuration, it may overwrite local changes. Keep a copy and check the setting again after updates.
[General]
dns-server = system4. How DNS Relates to Global Routing and Rules
Home → Global Routing controls how traffic is handled; it does not select a DNS server. Config applies the rules in the active configuration. Proxy routes general traffic through proxy handling, Direct uses a direct connection, and Scene applies conditions from a configured scene. Switching these options does not replace checking dns-server, nor does an option’s name prove that DNS queries are encrypted or use a particular route.
DOMAIN-SUFFIXmatches a domain suffix. The rule itself does not require the destination IP to be known, though a later lookup may still be needed to connect.IP-CIDRandGEOIPmatch IP information. Their behavior also depends on whether the request already has an IP address and whether the rule includes options that affect resolution.FINALis the policy applied when no earlier rule matches; it is not a “backup server for DNS failures.”- Settings → On Demand controls when a connection starts based on conditions; it does not convert traditional DNS to DoH. During troubleshooting, note whether it changes the actual connection state.
The addresses returned by DNS can affect which IP-based rules match, but not every change in rule matching is caused by DNS. If the route changes after you switch resolvers, check the A and AAAA records, the matched rule, and the final outbound route. Do not rewrite your entire ruleset to get one particular result.
5. Troubleshoot Resolution Issues One Variable at a Time
Start by describing the issue: does one domain fail or do all domains fail? Is the query timing out, or does it return an address before the connection fails? Does the issue occur only on Wi-Fi, or can you reproduce it on cellular too? Change one thing at a time and note whether restoring the original configuration restores access. This helps narrow down the cause to something you can verify.
- Confirm the configuration is active. Return to Config and check which file is selected and the actual value in
[General]. A subscription update and a configuration file update are separate processes; updating a node list does not show that the DNS setting changed. - Restore the system baseline. Temporarily set
dns-server = system, leaving Global Routing and the selected connection unchanged. If access returns immediately, focus on the custom resolver endpoint rather than changing connection settings again. - Test each network separately. Run the test on Wi-Fi and cellular. A local DNS server being reachable only over Wi-Fi is expected. If the network requires a web-based sign-in, complete that first.
- Check DoH dependencies. Verify the complete URL, service path, device date and time, and any certificate errors. The endpoint’s hostname usually needs to resolve first; if that initial lookup fails, the HTTPS query may not be established.
- Distinguish cached results from new ones. Reopen the test page and consider both app and system caches. Disconnecting and reconnecting does not guarantee that every cache is cleared. An old cached result does not mean the setting failed to save.
- Check the address family. If failures occur only after an AAAA record is returned, check IPv6 reachability on the current network and outbound route. Do not remove all IPv6 settings just because an AAAA record exists; first determine whether the failure is in resolution or connection setup.
| Observed issue | Check first | Do not assume |
|---|---|---|
| System DNS works, but custom DNS times out | Destination address, port, and network reachability | This does not mean all custom DNS services are unavailable |
| DoH returns a TLS-related error | Hostname, certificate validity, and device time | Do not hide the error by disabling certificate validation |
| An address is returned, but the website still will not connect | Matched rule, outbound route, destination port, and TLS | A website failing to load alone does not prove a DNS timeout |
| Wi-Fi works, but cellular fails | Whether the resolver endpoint is a local-network address and whether it is reachable on each network | Do not assume the same address is reachable on both networks |
Do not open a DoH endpoint in a browser and assume it is unavailable because you see a blank page or an error. DoH requires a DNS request that follows the protocol; an ordinary browser visit is not an equivalent test. Likewise, a direct request to a website’s IP may fail because of its HTTPS certificate, SNI, or virtual-host configuration. That does not prove the site would work if DNS were bypassed.
6. Common Questions
Do I need to wait if DoH makes things slower?
Switch back to system DNS and retest using the same network and domain. DoH can add connection setup overhead, and caching and connection reuse can affect results. A single page-load time is not a reliable measure of DNS speed. If you can reproduce the difference, check whether the endpoint is reachable and how the request is routed.
Can I replace the DoH hostname with an IP address?
Do not replace it yourself. The HTTPS certificate may no longer match the hostname, and the endpoint may depend on that hostname. Keep the full URL provided by your resolver. If initial resolution fails, restore a working baseline and follow the service’s official configuration instructions.
If I enter multiple DNS servers, will they automatically be used in order as backups?
Do not assume a list of addresses enforces a strict primary-and-backup order. Results may depend on concurrent requests, caching, and the app’s handling. When troubleshooting, start with one known-working setting and confirm it works on its own before adding other addresses. Otherwise, it may be unclear which server returned the result.
Why can’t I open a website after a subscription update succeeds?
A successful subscription update means the subscription content was retrieved and processed; it does not confirm that every domain or connection route works. Check DNS in Config, then verify Global Routing and the selected connection in Home. If DNS has returned an address, check the rules and outbound route instead of repeatedly updating the subscription.
Keep a restorable configuration and a concise record of the network used, DNS setting, test domain, whether an address was returned, where the failure occurred, and whether restoring the original setting fixed it. When contacting support for a service you already use, share only what is necessary. Hide subscription tokens, authentication fields, and personal network information; do not publish the full configuration.