This guide is for users who have imported their own provider’s settings into Shadowrocket and still can’t open websites after connecting. First, distinguish a latency test from a domain lookup. Then check Global Routing, DNS in the active configuration, and your local network. Change one setting at a time and retest the same URL. Use the error message to decide whether to adjust DNS, rules, or connection settings.
1. Normal latency doesn’t mean a web request succeeded
Opening a website typically involves resolving its domain, establishing a connection, completing the TLS handshake, and sending an HTTP request. The latency result in Home reflects only the target and test method used for that test. It doesn’t show whether every website can be resolved or whether server authentication, transport settings, and the website response are all working. Even when the test succeeds, the browser may still get stuck at DNS lookup. Conversely, a website may fail to load because of a connection or TLS issue, so latency alone can’t confirm a DNS problem.
First, note the full domain of the failed URL, when the issue occurred, the current server, the Global Routing mode, and the network type. Compare it with a website that worked before. Don’t keep changing websites, servers, and DNS settings at once, or you won’t know which change affected the result. The symptoms below are clues, not conclusions; verify them with the tests that follow.
| What you see | Check first | What it doesn’t prove |
|---|---|---|
| Several domains show “server not found” | Whether DNS queries are timing out and whether the current resolver is reachable | The message alone doesn’t prove the server is down |
| Only one domain won’t load | Domain spelling, its DNS records, and the rule it matches | It doesn’t prove that all DNS settings are wrong |
| The destination IP is returned, but the connection times out | The outbound route, port, and provider settings | A connection timeout isn’t a DNS timeout |
| A certificate or secure connection warning appears | Device time, the TLS hostname, and the destination website | Changing DNS isn’t guaranteed to fix it |
2. What each DNS setting does
DNS translates domain names into addresses that can be connected to. System DNS usually comes from the current Wi-Fi or cellular network. The dns-server entry in a configuration specifies a resolver for Shadowrocket. These are different settings, and other factors—including the browser’s encrypted DNS, configuration rules, and connection method—can change the query path. Adding a resolver address doesn’t guarantee that every request will use it.
| Setting or concept | What it does | What to check |
|---|---|---|
dns-server | Specify a DNS resolver in [General] in the configuration | Check the spelling, format, and resolver reachability; first confirm the active configuration uses it |
system | Use the DNS provided by the system | The system’s DNS source may change when you switch between Wi-Fi and cellular |
| DNS over HTTPS | Send DNS queries over HTTPS | The resolver’s hostname may itself need to be resolved; HTTPS connectivity matters too |
| A / AAAA | Return IPv4 and IPv6 address records separately | An AAAA record doesn’t mean the current IPv6 outbound route is working |
| Cache and TTL | Reuse lookup results for a set period | Seeing an old result shortly after a change doesn’t necessarily mean the setting hasn’t taken effect |
Approach: Check reachability before switching resolvers
If traditional DNS queries time out but HTTPS connections work, try a DNS over HTTPS configuration from a trusted source you already use. If HTTPS is also unreachable, troubleshoot the network and connection path first instead of adding more and more resolvers.
Port numbers are common protocol defaults, not values to enter uniformly in server settings. The DNS port is separate from the connection port for your existing server. Don’t change the server’s Port in Home to 53 to troubleshoot DNS.
3. Troubleshoot step by step, with a way to undo changes
Before you begin, save a copy of the current configuration and note the existing DNS entry. If a configuration is managed by a subscription you already use, a later update may overwrite local changes. Keep the troubleshooting copy separate from the original. Don’t publicly share a configuration containing passwords, UUIDs, subscription tokens, or full server addresses.
-
Record the baseline
In Home, note the current server and connection status. Open Home → Global Routing and record the selected mode. In Safari, visit the same URL that failed and note the exact message and test time.
-
Check the network
Temporarily disconnect and check whether the current Wi-Fi requires you to sign in first. To compare networks, test the same URL on Wi-Fi and cellular separately. Cellular data charges may apply.
-
Compare routing modes
In Home → Global Routing, record the result under Config, then temporarily switch to Proxy and test again. If the result changes, check the rules and outbound route first. This doesn’t mean DNS has been fixed across the board.
-
Check the configuration
Go back to Config, confirm which file is active, and open that file for editing. Check
dns-serverunder[General]. Change only this setting in the copy; don’t change server authentication or transport settings at the same time. -
Retest
Save the changes and make sure the updated configuration is active. Disconnect, reconnect, and visit the same URL again. Reconnecting may not clear every app cache; if needed, close and reopen the browser, then note whether the result changed consistently.
-
Restore your settings
Restore the original Global Routing mode. If the connection reconnects automatically during testing, check the original setting under Settings → On Demand. Turn it off temporarily for a manual connection test, then restore it to suit your usual setup.
Here’s a minimal configuration snippet that uses system DNS. It shows where the field goes; it isn’t a complete, working configuration. When editing, change the existing line rather than adding a duplicate [General] section, and don’t overwrite other required settings. System DNS may also be unreachable, so this snippet isn’t a universal fix.
[General]
dns-server = system4. Identify the DNS failure from the exact error
Below are common response codes and error messages found in DNS tools or diagnostic logs. They may not appear verbatim on every Shadowrocket screen. A browser’s “server not found” message alone can’t distinguish NXDOMAIN from a timeout. Follow the relevant steps only when you have a specific query result.
Error: NXDOMAIN
Cause and fix: The resolver says the domain doesn’t exist. Check the spelling and subdomain, then query the same domain using another known-reachable resolver. If multiple resolvers return the same result, contact the website operator to check its DNS records.
Error: SERVFAIL
Cause and fix: The resolver couldn’t complete the query, possibly because of an upstream issue or DNSSEC validation. Note the domain, resolver, and time, then compare the result with another reachable resolver. Don’t assume the domain doesn’t exist.
Error: REFUSED
Cause and fix: The resolver refused the query, possibly because recursive queries are restricted to certain sources. Check whether the resolver permits use from your current network. Switch back to system DNS or use a resolver you’re authorized to use, then test again.
Error: DNS query timed out
Cause and fix: No response arrived within the query’s timeout period. Check the resolver address, query path, and whether UDP / TCP 53 is reachable on the current network. If you test on another network, keep the other settings unchanged to avoid introducing multiple variables.
5. If DNS works, check rules and address families
Proxy, Direct, Config, and Scene in Global Routing select how requests are handled. Proxy and Direct can be used for comparison; Config follows the active configuration, while Scene determines the behavior set for that scene. These aren’t simply four DNS switches. If changing modes affects the result, check which rule matches the request and the outbound route it takes.
DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP matches against an IP geolocation database, and FINAL handles requests that don’t match earlier rules. Domain rules can match a domain without first resolving its destination IP. IP-based rules may involve DNS, depending on their options. The snippet below illustrates syntax only; don’t use it to overwrite existing rules.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYno-resolveprevents a domain lookup from being triggered solely for that IP rule; it doesn’t disable DNS globally.- Rule order affects which rule matches. If a domain fails under Config but works under Proxy, first check whether an earlier rule assigns it to a different route.
- If A records work but the route for AAAA records fails, check IPv6 support on the current network and server. After saving the original value, you can test with IPv4 only for comparison, but disabling IPv6 isn’t a universal fix.
- If the server address is entered as a domain, it also needs to be resolved. Replacing it with an IP address may affect TLS verification, SNI, or provider routing. Follow the settings supplied by your own provider.
6. Common questions and when to stop troubleshooting
Why won’t websites load after I change DNS?
In Config, first confirm that the modified file is active. Then check whether the query actually returns an address. If it does but the connection still times out, go back to Home and check the server settings and Global Routing. Don’t keep changing DNS.
What if Wi-Fi fails but cellular works?
Keep the server, configuration, and URL unchanged. First complete any Wi-Fi sign-in, then check the system DNS provided by that network. If only that network can’t reach a specific resolver, save the comparison results and ask the network administrator about any restrictions.
Will adding more DNS servers make things more reliable?
Not necessarily. Adding addresses doesn’t guarantee that every query will get the desired result. Start with one resolver from a known source that’s reachable on your current network, and test the failing domain. Once it works, decide whether to add other resolvers based on your needs.
What should I do if the issue returns after a subscription update?
In Config, compare the DNS settings and rules before and after the update to see whether it overwrote local changes. Report the specific field and time of failure to your own provider, but don’t send a full subscription token. Keep the original file so you can revert the test copy if needed.
You’re done when three conditions are met: the same URL that failed opens consistently; Global Routing is back in its usual mode; and the result remains consistent after reconnecting. Keep a brief record—for example, “System DNS timed out on Wi-Fi; issue resolved after testing a copy; retest passed in Config mode”—rather than just “Changed DNS and it worked.” A useful record helps distinguish a recurring network issue from an overwritten configuration.
- If you need to report the issue, include the failed domain, time, Wi-Fi or cellular network, Global Routing mode, and the error message with sensitive details removed.
- If DNS returns an address but the handshake fails afterward, check the Port, TLS, and transport settings provided by your own service provider.
- If your changes don’t help, restore the saved original configuration. Don’t leave temporary test settings in place long term.