If DNS works normally, keep system DNS. Use custom DNS when you need to specify a resolver, and consider DNS over HTTPS when you want to encrypt queries between your device and the resolver. This guide walks through the relevant settings on iPhone and iPad, including ports, rule dependencies, and troubleshooting. The same approach applies to Mac, Windows, Android, and Linux, though settings locations vary by platform.
First, distinguish DNS resolution from proxy connections
DNS translates domain names into addresses. For example, an A record lookup returns an IPv4 address, while an AAAA lookup returns an IPv6 address. A successful lookup only means an address was returned; it does not mean the destination port is reachable or that a proxy connection was established. Likewise, a successful server test in Home does not prove that every domain resolves correctly.
This flow illustrates the dependencies; it does not mean every request must be resolved locally first. DOMAIN-SUFFIX can match a domain name, while rules such as IP-CIDR and GEOIP may require an address lookup. Whether a domain request routed through a proxy is resolved remotely depends on the protocol, configuration, and actual connection path.
How the three DNS options work and what to consider
“Custom DNS” means specifying a resolver manually; it is not a particular encryption protocol. This guide compares traditional DNS using an IP address with DNS over HTTPS, so you can tell where each value belongs and which network path to check if it fails.
| Method | Resolution path | When to use it | What to check first |
|---|---|---|---|
| System DNS | Uses the resolver settings provided by the current network | The home or work network is functioning normally, or you need access to internal domains | Whether the resolver changes when you switch Wi-Fi networks, and whether internal domains still resolve |
| Custom DNS | Uses a specified traditional DNS resolver, typically over UDP 53 or, when needed, TCP 53 | You have a known resolver that is reachable and authorized for use | Whether the address is correct, port 53 is restricted, or internal domain resolution is affected |
| DNS over HTTPS | Sends DNS queries to a resolver endpoint over HTTPS, usually on port 443 | You need encrypted DNS queries and can reach the endpoint with a valid certificate | The endpoint URL, initial domain lookup, TLS, and routing |
System DNS is often the best fit for networks with internal domains. Office systems, printers, or home storage devices may rely on a resolver provided by the router. Replacing it with an external resolver may leave public websites accessible while internal names return errors or the wrong address. This is not a proxy protocol failure; the resolver simply does not have those internal records.
DNS over HTTPS is not necessarily faster. The first connection may require resolving the endpoint domain, establishing a TCP connection, and completing a TLS handshake. Later requests may reuse the connection and cache. Compare resolution errors and access results on the same network and domain instead of assuming a port 443 connection is reliable.
Bottom line: Keep a working resolution path
If public websites and internal domains both work, there is no need to change DNS just for the sake of switching. If you do need to make a change, test one resolver at a time and keep the original settings so you can restore them.
Settings and Config: Confirm which setting takes effect before making changes
On iPhone or iPad, open Home and check Global Routing. Select Config when testing rules, then open Config to confirm which configuration is active. Go to Settings → DNS to check the global DNS settings, and also inspect the DNS entries in the active configuration. A configuration may specify its own resolver, so the address shown in Settings alone may not determine the final behavior.
- Record the baseline. Note your current network, Global Routing mode, active Config, DNS settings, and the domain that is failing. First check whether you can reproduce the issue with the original settings.
- Back up the current configuration. Keep a copy of the original in Config. Check whether the configuration already has a
dns-serverentry in the[General]section to avoid adding a duplicate. - Change one setting at a time. To test system DNS, restore the relevant system resolver option. To test custom DNS, enter a resolver address you already have or a complete DNS over HTTPS endpoint.
- Reconnect. Save the change and confirm the configuration is still selected, then switch the Home connection toggle off and back on. Retry the domain and use the logs and access results to see whether the change took effect.
- Restore automatic connections last. During testing, check Settings → On Demand to make sure automatic connections do not change the test conditions. Restore your original on-demand setup once you have confirmed the results.
The two cards below illustrate field formats only. 192.0.2.53 is a documentation-only example address, and resolver.example is an example domain. Neither is a working DNS service, so do not use them to connect. Use values from a network configuration you are authorized to use. This guide does not recommend DNS or routing services.
Traditional DNS example format
- Configuration section
[General]- Configuration key
dns-server- Address format
192.0.2.53, example only- Common port
- UDP / TCP 53
A plain IP address does not encrypt DNS traffic. Do not treat the documentation address as a working service.
DNS over HTTPS example format
- Configuration section
[General]- Configuration key
dns-server- Endpoint format
https://resolver.example/dns-query- Common port
- HTTPS 443
A complete service endpoint is required. Use the path provided by the DNS service; not all services use the same path.
If your configuration is managed by a subscription or remote file you already use, updates may overwrite local changes. Keep a copy of your changes before updating, then recheck the active Config and DNS entries. Updating a server subscription is not the same as updating a configuration file: the former updates server entries and does not prove that DNS settings have changed.
How DNS works with Global Routing and rule order
Global Routing options—Proxy, Direct, Config, and Scene—control different routing modes. Use Config when troubleshooting rules. Proxy and Direct are useful for comparing paths, but after switching, the same results no longer show which rule matched in the original setup. With Scene, also check which settings are active in that scene.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis rule snippet explains the syntax; it is not a general-purpose routing configuration. example.com and 192.0.2.0/24 are documentation examples. Rules are checked in order, assuming the current configuration uses the relevant policies correctly. Do not replace your existing rules with this example.
- DOMAIN-SUFFIX: Matches a domain suffix and is useful when you know the destination domain. Once this rule matches, later GEOIP rules are not needed to determine the policy.
- IP-CIDR: Matches an IP address range. In this example,
no-resolvemeans the rule will not trigger an additional domain lookup for matching. It does not mean DNS will never be used for the connection. - GEOIP: Classifies the destination IP using a geographic database. A different resolved address can change the resulting classification; database classification does not indicate actual network latency.
- FINAL: Selects the final policy when no earlier rule matches. It cannot fix a failed DNS query or make an unreachable server address work.
If the proxy server itself uses a domain name, it also needs a working initial resolution path. If the DNS over HTTPS endpoint is routed through the proxy, but the proxy server's domain depends on that endpoint, startup can become a catch-22. Check separately whether the server domain and resolver endpoint can be resolved before the connection is established; repeatedly switching protocols will not fix this dependency.
Troubleshoot DNS by network and failure stage
For testing, keep the server and Config fixed and change only the DNS method. Record results separately on Wi-Fi and cellular, and do not change the server, rules, and resolver at the same time. A website failing to load does not necessarily mean DNS failed: after an address is returned, the connection, TLS, or application layer may still fail.
| What you observe | Check first | Next step |
|---|---|---|
| Only internal domains fail to resolve | Whether the custom resolver has the necessary internal records | Restore system DNS and retry the internal domain on the same Wi-Fi network |
| Traditional DNS times out, but HTTPS websites are accessible | The selected resolver and the network path to port 53 | Compare with system DNS first, then check whether your existing DNS over HTTPS endpoint is reachable |
| DNS over HTTPS reports a TLS error | System time, certificate name, and endpoint domain | Check the full URL and device time; keep certificate validation enabled |
| An A or AAAA record is returned, but the connection times out | Routing to the destination address, IPv6 reachability, and the server connection | Check the actual outbound policy; do not assume DNS failed |
| Results do not change immediately after editing the configuration | App cache, system cache, and reused connections | Reconnect and restart the target app, then compare with a fresh lookup |
NXDOMAIN means the resolver says the name does not exist. A timeout means no usable response arrived before the deadline; these are different errors. If timeouts occur only on one network, check that network's path to the resolver first. If public domains work but internal names continue returning NXDOMAIN, check whether the wrong resolver is selected.
Do not rely solely on entering an IP address in a browser as a test. Many HTTPS sites use the domain name for certificate validation and virtual host selection, so failure to access an IP directly does not prove that routing is unavailable. Check the lookup result, destination address, and connection stage in the request logs to distinguish DNS errors from TLS errors.
Bottom line: Choose the next step based on the failure stage
If no address is returned, check the DNS path. If an address is available, check the rules, outbound route, and destination connection. Compare DNS methods only if changing DNS actually changes the failure stage.
Common DNS settings questions and how to recover
Why is my connection slower after switching to DNS over HTTPS?
Restore the original DNS setting and compare on the same network. Then check endpoint name resolution, HTTPS reachability on port 443, and whether requests to the endpoint are taking an unnecessarily long route. A slow first handshake is not the same as every lookup timing out. Do not add multiple endpoints to mask an unreachable one.
It works at home, but internal systems stop working on office Wi-Fi. What should I do?
First, restore system DNS under Settings → DNS and check whether Config still specifies a custom resolver. Retry the internal domain on the same Wi-Fi network. If it works again, you need to preserve the internal resolution path rather than keep switching proxy servers.
Why do I still see DNS traffic with DNS over HTTPS enabled?
First, check which app and stage generated the traffic. The initial lookup for the endpoint domain, requests that do not use the current tunnel, and an app's own resolution behavior may not follow the selected DNS setting. Enabling one endpoint does not prove that every query on the device uses it.
DNS changed after a subscription update. How do I restore it?
Open Config and check which file is active. Compare its [General] section and dns-server entry with your backup. Confirm whether you updated a server subscription or a remote configuration. After restoring a DNS setting you have verified, reconnect and check whether Settings → On Demand is back to the expected state.
Keep a minimal troubleshooting record: network type, Global Routing mode, active Config, DNS method, destination domain, failure stage, and recovery steps. Before sharing it, remove tokens, credentials, and internal domain names from any subscription you already use. This site does not provide, sell, or recommend servers or subscriptions; this guide only explains how to check your existing configuration.
- Public websites and internal domains both work: Keep the current settings; there is no need to switch everything to one DNS method.
- Need a specific resolver? First confirm the address is reachable, that you are authorized to use it, and whether internal domains are required.
- Need encrypted DNS queries? Verify the complete DNS over HTTPS endpoint, TLS, and the initial resolution path.
- Something breaks after a change? Restore your backup, reconnect, and test one setting at a time instead of layering on more changes.
Get Shadowrocket and learn the basics
The iPhone and iPad app costs $2.99 as a one-time purchase on the App Store. See the App Store listing for system requirements. The Mac (Apple silicon and Intel), Windows, Android, and Linux versions are free. Choose your platform on the download page. On the iPhone and iPad product page, you can verify the developer, Shadow Launch Technology Limited, and app ID 932747118.
The one-time app purchase is separate from any service plan. Shadowrocket is a closed-source commercial app; connecting through a configuration requires a server or subscription you already have. DNS settings do not provide a route or server.