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

At a glance

When troubleshooting DNS in Shadowrocket, first confirm the active config, then choose a resolver: start with system for a baseline on regular networks, use an IP when you need a fixed resolver, and test DNS over HTTPS when you want encrypted DNS transport. This guide is for users who already have their own service provider and subscription and can establish a connection. It includes config snippets you can swap in individually and explains how to distinguish DNS failures from incorrect rule matches and failed destination connections.

First, separate DNS resolution from webpage connectivity

DNS translates domain names into IP addresses. Whether a webpage loads also depends on routing, the connection to the destination port, and the TLS handshake. A latency value in Home only shows that a response was received under the test conditions; it does not confirm that Safari can resolve the domain it is accessing or establish every connection the page needs.

Domain requestDNS queryAddress resultConnect to destinationPage loads

This flow applies to requests that need local resolution; it does not mean every proxy connection must first resolve the destination IP on the device. A domain may be handled remotely, or a rule may match the domain before resolution. When troubleshooting, check separately whether a DNS result was returned and whether the connection succeeded afterward. Not every failure is a DNS issue.

Traditional DNS commonly uses UDP / TCP ports

443

DNS over HTTPS typically uses the HTTPS port

[General]

Config section containing dns-server

Ports only help identify the transport method. Being able to reach port 443 does not mean a particular DNS over HTTPS endpoint is available, and reaching port 53 does not guarantee a correct response. Check the actual returned address, error type, and subsequent connection result.

Choosing among the three DNS options

system is a good starting baseline, especially when you rely on local network resolution. A custom DNS IP is useful for repeatable tests, but entering an IP does not encrypt queries. DNS over HTTPS, or DoH, sends queries over HTTPS and can help prevent networks along the route from directly reading their contents. It still requires a reachable, trusted resolver endpoint.

Setting	Speed and reliability	Privacy considerations	Best for testing
`system`	Depends on the resolver path provided by the current system and network; often works well for local resources.	You cannot tell whether queries are encrypted from system alone.	Establishing a baseline, office networks, and local network name resolution.
Custom DNS IP	Results depend on the route to the specified resolver; a fixed address makes issues easier to reproduce.	Standard DNS queries are not protected by HTTPS in transit.	Isolating issues with the network's default resolver.
DNS over HTTPS	The first connection may require resolving the endpoint and completing a TLS handshake. Connection reuse and caching can change the time taken on subsequent requests.	Protects traffic to the DoH endpoint; the endpoint operator can still process queries.	When you need encrypted queries and have confirmed the HTTPS endpoint is reachable.

There is no fixed speed ranking among the three options. A nearby but congested resolver may be slower than a remote one. Changing resolvers can also change the IP address returned by a CDN, making DNS queries faster while webpages load more slowly. Test actual page loads, not just the time for a single DNS query.

Edit dns-server in Config: test one option at a time

Open Config and confirm which config file is active. Keep a copy of the original, then open the editor for that file. Find the existing [General] section and edit dns-server. The three snippets below are mutually exclusive test options, not a complete config to paste all at once.

Option 1: Use system as a baseline

[General]
dns-server = system

system uses the resolver provided by the system, so the result depends on the device and current network. If local network names resolve over Wi-Fi but fail with a public resolver, those names may only exist within the network. Check the network's DNS requirements rather than adding more public DNS addresses.

Option 2: Specify a traditional DNS resolver

[General]
dns-server = 1.1.1.1

The address here only demonstrates the IP format; it is not a claim about the resolver's speed or availability. Before using one, confirm that it is reachable on your current network and meets your requirements. Do not change the resolver, rules file, and proxy selection at the same time without recording a baseline, or it will be difficult to identify what caused the change.

Option 3: Use DNS over HTTPS

[General]
dns-server = https://cloudflare-dns.com/dns-query

This example shows the format of a complete DoH endpoint: https://, the hostname, and the /dns-query path together form the request URL. A regular website homepage cannot be used in its place. The hostname must also be resolved before the HTTPS connection can be established. If the failure occurs at this initial step, switching the target DNS to DoH will not automatically fix it.

Replace only the relevant setting in the current [General] section. Keep the other fields, and avoid creating a duplicate section or key.
Save the changes, confirm the updated config is enabled, disconnect and reconnect, then test access.
Return to Home and check Global Routing. Use Config to verify file-based rules; assess Proxy, Direct, or Scene separately based on the currently selected mode.
If the file comes from a remote config, check whether updates will overwrite local changes. Keep test copies separate from files that update automatically for everyday use.

Config boundaries: DNS returns addresses; rules determine policy

dns-server does not assign a website to DIRECT or PROXY. Rules are in the [Rule] section and are matched in order. Domain rules can match a domain directly, while IP-based rules use the destination address. A change in DNS results may affect subsequent IP rule matches, but changing DNS does not change routing policy.

Check DNS settings

Section: [General]
Field: dns-server
System-provided: system
Encrypted endpoint: https://cloudflare-dns.com/dns-query

First verify that the endpoint responds, then check the destination connection.

Check rule syntax

DOMAIN-SUFFIX: example.com,DIRECT
IP-CIDR: 192.168.0.0/16,DIRECT,no-resolve
GEOIP: CN,DIRECT
FINAL: PROXY

The keywords and parameters are shown separately here; connect them with commas in a complete config.

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

This rule snippet explains the syntax; it is not a complete setup for every network. no-resolve means not to perform an additional DNS lookup for the purpose of matching this IP rule; it does not turn off all DNS. Place FINAL at the end of the rules section to provide a fallback policy for requests that do not match any preceding rule.

If DNS returns an address but the webpage still times out, check the matched policy and the connection it uses. Your existing Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard connection details belong to a separate configuration layer. Changing DNS will not fix incorrect credentials, ports, or server settings.

Compare speed and reliability with a consistent test process

One successful test does not prove a setting will remain reliable, and one failure does not prove a resolver is unavailable. Keep the device, network, config rules, and destinations the same, then compare system, a fixed DNS IP, and DoH one at a time. Treat Wi-Fi and cellular tests as separate test sets and record them individually.

Record a baseline: Use system to test one domain that normally works and one that currently fails. Note whether each resolves, whether the page loads, and the specific error.
Change only the resolver: Replace dns-server, reconnect, and leave Global Routing and the selected connection unchanged.
Account for caching: Compare the first visit with subsequent visits. The device, browser, and resolver may all cache results, so refreshing repeatedly does not necessarily trigger a new query.
Check the response: If the relevant in-app diagnostics or logs show DNS results, check for an A or AAAA answer, a timeout, or NXDOMAIN. Different addresses alone do not mean the response is wrong.
Verify the actual connection: If resolution succeeds but the page fails, check the destination connection, rule policy, and IPv4 / IPv6 path instead of repeatedly adding DNS addresses.
Keep changes only after verification: Retain a setting only if it produces a repeatable improvement. If it does not help, restore the copy so a temporary test does not become a permanent config change.

NXDOMAIN means the resolver reports that the name does not exist; it is different from a response timeout. A missing AAAA answer does not mean resolution failed either: the destination may only have an IPv4 address. If both A and AAAA answers are returned but the device's network has an IPv6 routing issue, some pages may take longer to load. Check the address family and connection error separately rather than assuming DoH is broken.

Common issues: DoH timeouts, local network failures, and privacy limits

All webpages stop loading after setting up DoH. What should I change first?

In Config, restore dns-server to system in the active file, save, and reconnect. If access returns, check the DoH URL, whether its hostname resolves, whether the current network restricts HTTPS connections, and whether the device time is correct. Do not change rules and connection details at the same time.

Public websites work, but a printer and internal network domains do not. What should I check?

Restore system first, then retry the same name on the same Wi-Fi network. Internal domains may only be available from local DNS, which a public resolver cannot answer. Also distinguish regular DNS names from names that rely on local discovery; not every local network access issue is controlled by dns-server.

Why check rules if I'm already using DoH?

DoH only defines the DNS transport method. Return to Home and check Global Routing. To verify file-based rules, use Config, then check whether the request matches DIRECT or PROXY. If an IP address is returned but the connection times out, investigate the outbound path rather than focusing only on the resolver.

Does adding multiple DNS addresses always improve reliability?

Start with one resolver for comparison tests. How multiple addresses are selected and how failures are handled depends on the implementation; their order alone does not establish a primary and backup. Combining standard DNS with DoH also does not guarantee that all queries are encrypted. Confirm each address works on its own, then adjust based on the in-app guidance.

Can DoH keep the DNS provider from seeing my queries?

The DoH endpoint has to process queries, so its operator can still see the DNS requests sent to it. HTTPS primarily protects the data in transit between the device and the endpoint. When choosing a resolver, review its service information and treat transport encryption, trust in the resolver, and proxy routing as separate questions.

Choose the final config based on reachability on your current network, real-world page loads, and your privacy requirements. For details on more fields, see the Config Field Reference. If the issue only occurs on a particular network, continue troubleshooting with the Troubleshooting guide. Shadowrocket is primarily used on iPhone and iPad; check the App Store listing for system requirements and device compatibility.