For cases where Shadowrocket shows test latency, but Safari or other apps still can’t load websites. First distinguish DNS errors from connection timeouts and TLS errors, then check Home → Global Routing and dns-server in Config. Use the same destination, change one setting at a time, and compare networks to isolate the cause. This guide assumes you already have a service provider and subscription; it does not cover choosing a service.
1. Normal Latency Doesn’t Mean DNS Is Working
A typical web request involves DNS resolution, establishing a connection, a TLS handshake, and receiving content. The test result shown in Home reflects only the stages covered by the selected test method. A successful TCP connection or reachable test address does not prove that the target domain resolves or that its HTTPS request will succeed. Note which method Connectivity Test uses so you don’t compare results from different tests as if they were equivalent.
DNS translates domain names into IP addresses. Even if the proxy server is reachable, a website may not load if the device’s resolver is unreachable, returns no answer, or resolves the domain to an address that doesn’t work through the current connection. Conversely, a connection timeout after an IP address has been obtained should not automatically be treated as a DNS failure.
Takeaway: Identify the failing stage before changing the resolver
If the error clearly points to a certificate or TLS handshake, first check the device’s time, the destination domain, and the connection route. Prioritize DNS troubleshooting only when you see a name resolution error, DNS timeout, or unexpected answer. A reachable port alone does not mean the resolver is responding correctly.
2. Keep Home Test Conditions Consistent
Keep the same destination domain and existing configuration while troubleshooting. Don’t change the server, rules, subscription, and DNS at the same time; if the issue clears, you won’t know which change fixed it. Start with a site you visit regularly and whose address you can verify, then add a second domain for comparison.
- Record the current state. In Home, note the connection toggle, selected server, Global Routing mode, and Connectivity Test method and result. Don’t include credentials in your notes.
- Check the routing mode. In Global Routing, Config processes traffic according to the active configuration rules; Proxy sends general traffic through the selected proxy; Direct provides a direct-connection comparison; Scene follows its configured scene. Don’t infer a Scene’s active policy from its name—check its settings.
- Run a brief comparison. If the current network permits, compare Direct and Proxy for the same domain. A failure in one mode only indicates a difference in the route; it doesn’t prove DNS is the cause. Restore the original mode when finished.
- Check for automatic changes. Review Settings → On Demand. For a manual comparison, note and temporarily disable any relevant triggers so an on-demand connection doesn’t reconnect after you disconnect manually. Restore them after testing.
- Retest on another network. Switch between Wi-Fi and cellular and test again with the same configuration. If only one network fails, focus on DNS reachability, sign-in requirements, or access restrictions on that network.
If Wi-Fi requires sign-in through a web page, complete that step before testing. If every site fails and the current server’s domain also won’t resolve, first address the connection entry point’s DNS issue; repeatedly changing website rules is unlikely to help.
3. What dns-server Means and How to Make a Minimal Change
Config manages configuration files, not the subscription server list itself. Before editing, save a copy of the current file, confirm which configuration is in use, and open that file for editing. The snippet below illustrates where the field belongs. Replace only the corresponding field in your existing file; don’t overwrite the entire configuration with it.
[General]
dns-server = system| Field or value | What it means | What to check |
|---|---|---|
[General] | General settings section of the configuration | Edit the existing section to avoid confusion from duplicate settings with the same name. |
dns-server | Specifies the DNS resolver used by the configuration | Use a value supported by your current version. This is not a proxy server address or subscription URL. |
system | Use the DNS provided by the current system network | Useful as a baseline comparison, though results may vary between Wi-Fi, cellular, and network profiles. |
| Resolver IP address | Specifies a traditional DNS server directly | Confirm that the address is correct and the service is reachable. Don’t enter a website IP or proxy port as a DNS server. |
| DoH URL | Gets DNS answers over HTTPS | Use a format and complete endpoint supported by your current version. A regular website homepage is not a substitute for a DoH endpoint. |
Start with dns-server = system as a baseline. If the original configuration specified a resolver and switching to system restores access, check the original resolver’s reachability, address format, and route before deciding whether to keep the change. If system still fails, that doesn’t prove the app is at fault: the DNS provided by the system may be unreachable, or the resolver may have no valid answer for the domain.
- Change one field at a time. After saving, confirm that this Config is still the file in use.
- If a setting requires a reload to take effect, disconnect and reconnect before testing. Keep the original value so you can revert if the change doesn’t help.
- Compare against an existing, trusted resolver that you know is reachable. Don’t copy unfamiliar endpoints from an unknown configuration.
- Encrypted DNS still depends on the underlying network being reachable. If the endpoint uses a domain name, its initial resolution and certificate validation must also succeed.
4. Choose a Troubleshooting Path Based on the Exact Error
The following are standard error messages or system error codes that may appear during network diagnostics; Shadowrocket is not guaranteed to display the same wording in every view. Record the error source, destination domain, and stage of failure. Messages from the app, Safari, and remote server logs may differ. Don’t diagnose the cause from “won’t load” alone.
Error: NSURLErrorDomain Code=-1003
Cause: Apple’s URL loading system couldn’t find the specified host. Common causes include a name resolution failure or a misspelled domain.
Fix: Check the spelling first, then compare system and the original resolver for the same domain. Check whether the issue occurs on only one network.
Error: NXDOMAIN
Cause: The DNS response says the queried name doesn’t exist. This differs from a resolver that doesn’t respond, and may also reflect the resolver’s policy.
Fix: Check the full hostname and try another existing, trusted resolver. If the result is the same, confirm the DNS records with the domain administrator.
Error: SERVFAIL
Cause: The resolver couldn’t complete the query. Possible causes include an upstream failure, an authoritative server issue, or DNSSEC validation failure.
Fix: Compare results across networks and resolvers, and note when the error occurred. Don’t treat it as proof the domain permanently doesn’t exist or change Host based on this error alone.
Error: NSURLErrorDomain Code=-1001
Cause: The request timed out. This can happen during resolution, connection, or while waiting for a response; the code alone doesn’t prove a DNS failure.
Fix: Check diagnostic records to see whether the target IP was obtained. If it was, continue by checking routing, the connection, and the target service’s response.
Don’t assume that “no AAAA record” means the entire domain can’t be resolved; it may still have a usable A record. Conversely, receiving an AAAA answer doesn’t mean the current network’s IPv6 route is working. If only some domains fail, check their DNS answers and the address family used for the actual connection separately rather than changing all IPv6 settings at once.
5. Check Rules and Overrides After DNS Resolves
A successful DNS lookup only means an answer was obtained; the website request still needs to follow the right policy. When Global Routing is set to Config, rules are generally matched in order, and the first matching rule determines how the request is handled. An incorrect rule order, policy name, or fallback can send a request with a valid DNS answer down an unusable route.
| What to check | Purpose | What to do |
|---|---|---|
DOMAIN-SUFFIX | Matches a specified domain and its subdomains | Make sure the entry is a domain, not a URL with a path, and check whether an earlier rule already matches. |
IP-CIDR | Matches an IP range | Check whether an earlier range rule captures the target IP. If it includes no-resolve, consider how that modifier affects matching. |
GEOIP | Matches using an IP geolocation database | A database classification is not the same as the website’s region. Check which policy actually matched. |
FINAL | Handles requests that didn’t match earlier rules | Check whether the request ultimately goes to DIRECT, a proxy, or a defined policy group. |
[Host] | Provides a configured DNS mapping for a specified host | Check for an outdated address. Back up the configuration, then remove one suspect mapping at a time for comparison. |
For example, DOMAIN-SUFFIX,example.com,DIRECT sends example.com and its subdomains to DIRECT. If the request only works through the user’s existing proxy route, the page may still fail even when the resolver returns the correct answer. Here, example.com illustrates rule syntax and is not an actual test target.
Takeaway: If you have the target IP, continue by checking the route and matching policy
If diagnostics show a DNS answer, check the domain’s matching rule, final policy, and selected route. Don’t keep changing DNS to fix a routing issue, and don’t pin a website’s changing address in Host just to get temporary access.
6. Common Questions and Recovery Checks
Why do I still see the same error after changing DNS?
First, confirm in Config that the change was saved to the file currently in use, then disconnect and reconnect. Close the failed page and make a fresh request to allow caches to update. If it still fails, record the error from the new request instead of relying on the old page retained by the browser.
Why does a site load on cellular but not on Wi-Fi? What should I change?
Keep the server and Config unchanged. First compare system DNS on both networks and check whether Wi-Fi requires web sign-in. If the issue occurs only on that Wi-Fi network, check its DNS and transport restrictions before changing client settings.
What if websites load again but subscription updates still fail?
A subscription update uses a different URL and is not the same as testing website access. Check the domain, validity period, and error response for your existing subscription. Remove tokens and other credentials before sharing records. Don’t put a subscription URL in dns-server or use repeated update attempts as a substitute for a DNS comparison.
Can I enter a website’s IP address to prove DNS is the problem?
Not as conclusive evidence. HTTPS relies on the domain for certificate validation and site selection, and a single IP can host multiple sites. Keep the original domain and use DNS answers and connection-stage records to find the issue; whether a page opens by IP is not enough to diagnose it.
Once access is restored, don’t stop after opening the homepage once. Use the checklist below to confirm the result is repeatable before keeping the final change. If you need to contact your service provider or network administrator, share redacted evidence rather than the full configuration.
- Function check: Reopen the domain that originally failed and a second comparison domain. Confirm access doesn’t depend on a page already in the cache.
- Configuration check: Restore your usual Global Routing mode and On Demand conditions, then confirm access still works after an automatic connection.
- Network check: Retest once on the Wi-Fi and cellular networks you actually use, and note any differences.
- Record check: Keep the test time, network type, exact error, whether resolution succeeded, matching policy, and the single setting changed. Remove subscription tokens, passwords, and other authentication details.