This guide is for users who have imported their own subscription and are ready to adjust DNS. First, distinguish name resolution from outbound connections. Then check Settings → DNS and the active Config. Finally, test one change at a time using the same domain on the same network. You’ll learn when to keep system DNS, when to enter a resolver address, and which layer to check first when DoH times out.
1. Establish a baseline before changing DNS
Shadowrocket is a paid Apple-platform app, primarily for iPhone and iPad, available exclusively on the App Store. Check the product page for the developer, Shadow Launch Technology Limited, and app ID 932747118. The app is a one-time purchase; refer to the App Store page for system requirements and Universal Purchase details. Buying the app is separate from any service plan; this guide assumes you already have your own provider and subscription.
DNS translates domain names into IP addresses; it doesn’t guarantee that a connection will succeed. A webpage may fail to load because the lookup timed out, or because an address was returned but the destination port, proxy connection, or TLS handshake failed. Record the original settings first, and don’t assume every problem is caused by DNS.
- On Home, note the connection currently in use. Keep it the same throughout testing; don’t update your subscription or switch protocols at the same time.
- Note the current Global Routing option. If you’re using Config, also record the active configuration and keep it unchanged for comparisons.
- Record the current settings under Settings → DNS, and check whether the active configuration’s
[General]section already containsdns-server. - Check Settings → On Demand. Keep the connection state stable during testing so changes to automatic connection conditions don’t affect the results.
2. System DNS, custom DNS, and DoH compared
“System DNS” means using a resolver provided by the current network or managed by the system. “Custom DNS” usually means specifying a resolver address. DNS over HTTPS (DoH) describes how queries are transported. A custom address can also use DoH, so these aren’t mutually exclusive protocol categories.
| Option | What to enter | When to use it | What to check |
|---|---|---|---|
| System DNS | system | The current network resolves names correctly, or you need to access local network names. | The network-provided resolver may change when you switch Wi-Fi networks. |
| Custom traditional DNS | The IP address of a resolver you’ve confirmed is reachable | You need a specific resolver, and it’s accessible from your network. | Usually uses UDP port 53; some queries use TCP port 53. The transport itself isn’t encrypted. |
| DoH | A complete HTTPS endpoint | You have a working DoH service URL and its HTTPS endpoint is reachable. | Usually uses TCP port 443. Check the hostname, certificate, path, and initial resolution. |
DoH encrypts queries between your device and the selected resolver. It doesn’t hide queries from that resolver or automatically change how website traffic is routed. It may also add connection setup time. Speed depends on the network, cache, and endpoint; the name alone doesn’t mean it will be faster.
Bottom line: keep the current setting if resolution works
Change DNS only after confirming that the current resolver times out, returns unexpected answers, or doesn’t meet your query transport requirements. Don’t change the routing mode and connection at the same time.
3. Configure DNS in Settings and Config
Check the current DNS setting under Settings → DNS. Use system to keep system resolution; enter the address of a traditional DNS resolver you’ve confirmed is reachable; or enter the complete HTTPS endpoint provided by your DoH service. Keep the full path in the URL. Don’t enter the service’s homepage or use a subscription URL as a DNS address.
If the active Config specifies dns-server, open that configuration and check its [General] section as well. The cards below illustrate the format only. Their example addresses are reserved for documentation and aren’t working resolvers; don’t save them as real settings.
Traditional DNS format
- Where to check
- Settings → DNS
- System resolution
system- Example address format
192.0.2.53- Configuration field
dns-server
192.0.2.53 is reserved for documentation. Use a resolver you’ve confirmed is reachable.
DoH format
- Example address format
https://dns.example.com/dns-query- Transport requirement
- HTTPS with a valid certificate
- Path requirement
- Keep the full path provided by the endpoint operator
- Prerequisites
- The endpoint hostname must resolve, and the connection path must be reachable
dns.example.com is an example domain for documentation. Don’t use it for real queries.
If you only want to specify system resolution in an existing configuration, check whether its [General] section already contains the field below. Don’t add a second section with the same name just to paste the example, and don’t delete existing rules or other settings.
[General]
dns-server = system- Save your changes in Settings or save the configuration you’re editing. Confirm that Config is using the same configuration you just checked.
- On Home, disconnect and reconnect so the new connection session uses the updated settings. Reconnecting doesn’t clear all app caches.
- Retest using the same domain. If a new timeout occurs, restore the original value you recorded instead of adding more resolvers.
4. Check DoH endpoints and rule routing separately
When a DoH endpoint uses a hostname, the device must first resolve that hostname to an address before it can establish an HTTPS connection. This is often called initial resolution. If the existing resolver is already failing and the new setting relies on it to find the DoH endpoint, you may find that no domains load after switching to DoH. Restore a working DNS baseline first, then check the endpoint.
Global Routing controls how connections are handled; DNS settings control how lookup results are obtained. One can’t replace the other. Keep these distinctions in mind while troubleshooting, and don’t change the handling of your entire configuration just to make one webpage load.
- Config: Traffic is handled according to the active configuration’s rules.
DOMAIN-SUFFIXmatches domain suffixes.IP-CIDRandGEOIPinvolve address-based matching; whether local resolution is needed also depends on the specific rule options and processing path. - Proxy: Handles traffic using the selected proxy, but that alone doesn’t prove every DNS query goes through it. Check the DNS settings, endpoint routing, and actual records too.
- Direct: Connects directly, but that doesn’t mean DNS on the current network is working. Direct access and successful name resolution are separate things to check.
- Scene: Selects a configured scene; it isn’t a DNS repair button. Check which scene is actually in use, then make sure the test conditions are consistent.
5. How to verify that DNS is working
Verification should distinguish three things: whether the resolver responds, which address it returns, and whether the subsequent connection succeeds. A webpage loading or a lower latency on one visit doesn’t tell you which resolver was used. A cached result may mean no new DNS query was made at all.
- Keep conditions consistent: Use the same Wi-Fi or cellular network, connection, Global Routing option, and Config. Record what happens before making changes.
- Choose a test domain: Use a domain you’re authorized to test and whose record status is known. Test A first, then check AAAA. Record AAAA lookup failures or IPv6 connection failures separately.
- Check the lookup result: If the current interface provides a DNS query tool, record the result, duration, and any error. Also check available logs for endpoint connection failures, resolution timeouts, or certificate errors.
- Account for caching: Existing results may come from the app, system, or resolver cache. You can close and reopen the app you’re testing, or use another name under your own domain with a record already configured. Don’t use a random nonexistent domain as a normal test case.
- Check the connection: After getting an A or AAAA result, check the route and errors for the corresponding connection. If DNS succeeds but HTTPS times out, investigate the destination connection instead of repeatedly changing DNS.
| What you observe | What it tells you | Next step |
|---|---|---|
| Query times out with no result | The resolution process didn’t complete; the failing step is still unknown. | Restore the original resolver and compare endpoint reachability and network conditions. |
| Returns NXDOMAIN | The resolver reports that the name doesn’t exist; this is different from a connection timeout. | Check the spelling, domain records, and whether the resolver covers internal domains. |
| Returns an address, but the webpage still times out | At least one address lookup completed successfully. | Check which rule matched, the destination port, and subsequent connection logs. |
| Only the second visit is faster | This may be due to caching or connection reuse. | Record the first and repeat visits separately. Don’t assume this proves DoH is faster. |
Bottom line: record the failure stage, not just “it won’t load”
At a minimum, record the network, DNS method, A or AAAA result, and any subsequent connection error. If you don’t have logs that identify the resolver, report only that the issue improved; don’t claim to have confirmed the query path.
6. Common DNS setup issues
After switching to DoH, no webpages load. What should I change first?
Restore the original value recorded under Settings → DNS or in the active Config, then reconnect. Once things work again, check the DoH URL’s hostname, full path, initial resolution, and any certificate errors one at a time. Reintroduce only one change at a time.
Public websites work, but names for devices at home don’t. What should I do?
Check whether your home router or internal DNS provides those names. Public resolvers usually don’t know about local network records, so switch back to system DNS for comparison. Internal names may also use mDNS; not every device discovery issue is a standard DNS problem.
Will entering multiple DNS addresses always make things more reliable?
Not necessarily. Resolvers can return different answers, respond at different speeds, and have different access to internal names. Don’t assume they’ll be tried strictly in the order entered. Start with one resolver you’ve confirmed is working, record the results, and then decide whether to add another.
Why do my settings change when I re-enable Config after editing Settings?
In Config, check the active file’s [General] section and dns-server to see whether it specifies another resolver. If the configuration updates remotely, check whether the field was restored after an update. Note where you made changes so you don’t keep editing a setting that isn’t taking effect.