This guide is for Shadowrocket users whose connection works and whose node latency test returns a result, but websites report that the server cannot be found, certain domains keep loading, or a subscription refresh fails. First separate connection issues from DNS resolution, then check Settings → DNS, Global Routing, and the active config. Finally, use Log to see whether the request stops at DNS, rule matching, or proxy egress.
Normal latency does not mean DNS is working
When Shadowrocket tests node latency, the test target, connection method, and web browsing process are not identical. A latency value only shows that the client could connect to or probe an existing server address at that moment. It does not prove that every domain can be resolved correctly. Web access also involves DNS lookup, rule matching, a TCP or QUIC connection, the TLS handshake, and content transfer. A failure at any step can appear as a blank page or endless loading.
DNS converts domain names into IP addresses. If a domain returns no result, rules such as DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL may not complete the intended processing chain. If it returns the wrong address, the client may match a rule successfully but still connect to an unavailable destination. Therefore, “the node shows 80 ms, but the website won’t open” cannot be attributed to node speed alone.
Port numbers are shown only to clarify the lookup path; they do not mean that you need to open or enter each port manually. Your existing config, provider documentation, or current network may use a different resolution method. During troubleshooting, record the original settings and change one item at a time. Changing DNS, the node, Global Routing, and the config together makes the results impossible to compare.
How to understand the options under Settings → DNS
Open Shadowrocket’s Settings, then go to the DNS section. The options shown can vary with your current settings and config, so use the English labels displayed on your device. DNS Server is commonly used for primary lookups, Fallback DNS Server provides a backup when the primary path fails, and Bootstrap DNS resolves the hostname of an encrypted DNS service before it can be used. Bootstrap DNS does not replace every normal lookup; it solves the initial problem of finding the DNS service address.
System or system means using the resolution path provided by the operating system. If you have not entered a custom address and the config does not override it, keep the initial state currently shown by the client instead of copying settings from a screenshot on another device. After importing a config, fields such as dns-server, fallback-dns-server, and ipv6 under [General] may change the actual behavior, so check both the Settings page and the active config.
| Item | Purpose | What to check |
|---|---|---|
| DNS Server | Handles primary domain lookups | If no domain returns a result, first check whether this server is reachable and correctly formatted |
| Fallback DNS Server | Provides fallback results when primary lookups fail | If the primary resolver times out intermittently, check whether the fallback path is also blocked by the current network |
| Bootstrap DNS | Resolves the hostname of the DoH or DoT service | Check this first when the encrypted DNS address is a hostname and startup fails |
| IPv6 | Controls or affects AAAA lookups and IPv6 connections | On networks with limited IPv6 support, an AAAA record may be returned first while the connection eventually times out |
If the active config explicitly defines DNS fields, focus on how that config handles them. The example below is for recognizing the syntax, not a public configuration to copy. The addresses use documentation-only ranges and must not be used as real DNS services.
[General]
dns-server = system, 192.0.2.53
fallback-dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,198.51.100.0/24,DIRECT
FINAL,PROXYConclusion: First determine what controls DNS
When DNS settings exist in both Settings and the active config, do not focus on only one page. Record the currently enabled config first, then inspect its [General] section. This prevents repeatedly switching DNS Server without seeing any change.
Troubleshoot all websites failing in a fixed order
When every website reports that the server cannot be found, keep the current node and config unchanged at first. This lets you compare the result before and after a DNS change. After each step, retest the same familiar domain. Fully close previously failed pages before reopening them so the browser does not keep showing an old error.
Check the connection status
Return to Home and confirm that the connection switch at the top is enabled, and that the current node name and config are the expected ones. If the switch immediately turns off, resolve the connection issue before changing DNS.
Switch Routing
On Home, check Global Routing. Temporarily switch to Proxy for one test, then to Direct for another, and finally restore the original Config or Scene. If only Config fails, inspect the rules and config. If every mode fails, focus on DNS or the local network.
Check DNS
Open Settings → DNS and record the current values for DNS Server, Fallback DNS Server, Bootstrap DNS, and IPv6. Remove duplicate entries that you just added manually from an unknown source, and keep the app’s original state or settings that you have independently confirmed to work.
Rebuild the connection
Return to Home, turn the connection off, wait a few seconds, and turn it back on. After changing DNS settings, rebuild the tunnel; simply refreshing a webpage may continue using the previous session or cached result.
Change networks
Switch between Wi-Fi and cellular, then repeat the same test. If only one network fails, focus on that network’s DNS reachability, IPv6 support, or access restrictions instead of repeatedly changing the Shadowrocket node.
Check Log
Open the available Log entry under Data or Settings, reopen a domain that failed, and look for related records containing resolve, DNS, timeout, or hostname. Record the time of the event.
The four common Global Routing modes help narrow down the cause. Proxy sends supported requests through the proxy policy, Direct connects directly, Config matches rules one by one, and Scene selects behavior according to the configured use case. Switch modes only briefly for diagnosis, then restore the original setting. If Proxy works but Config does not, check the order of DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL instead of continuing to change DNS addresses.
Error: A server with the specified hostname could not be found.
Cause and fix: The system did not obtain a usable address for the hostname, or the result cannot be used for the current connection. Check Settings → DNS first, then rebuild the Shadowrocket connection and look in Log for a lookup timeout.
Error: The Internet connection appears to be offline.
Cause and fix: DNS, routing, or a network interface in the connection chain did not complete the request. Confirm that the Home switch stays on, then test with Proxy and Direct separately to determine whether the problem occurs in only one mode.
Error: Failed to load subscription
Cause and fix: The subscription domain may not resolve, the link may be invalid, or your provider may restrict access. Check the original subscription URL and its validity; for example, https://example.com/sub?token=xxxx is only a format example. After confirming it, refresh from Home.
Check rules and IPv6 when only some domains fail
If most websites work but a few domains fail, the primary DNS path is usually not completely down. Check whether a rule is matching the failed domain too early. For example, DOMAIN-SUFFIX,example.com,DIRECT sends that suffix through Direct. If the destination is reachable only through the proxy path, other websites may work while this domain times out. Rules are matched from top to bottom, so more specific rules should come before broader ones. FINAL handles requests that match none of the preceding rules.
GEOIP selects a policy based on the resolved destination IP, while IP-CIDR matches an address range directly. If DNS returns an unexpected address, the GEOIP result may also change. During troubleshooting, use Log to find the failed domain’s resolution result, the matched rule keyword, and the final policy, then inspect the relevant lines in Config instead of guessing from the domain’s presumed region.
- DOMAIN-SUFFIX: Check that the suffix is complete and that an earlier DOMAIN or DOMAIN-KEYWORD rule has not already matched.
- GEOIP: Check that DNS returned a usable IP first and that the policy selected by the rule matches the design of the active config.
- IP-CIDR: Check the address range and prefix length; for example, /24 and /32 cover clearly different matching ranges.
- FINAL: Check whether requests that matched none of the earlier rules ultimately enter PROXY, DIRECT, or another policy group.
- IPv6: If Log shows an AAAA result followed by a long wait, record the original value, test IPv6 availability on the current network, and restore the setting that matches the config.
On Demand may also explain why a problem appears only on one network. Open Settings → On Demand and check whether different connection actions are enabled based on Wi-Fi SSID, interface type, or domain conditions. If Shadowrocket does not connect as expected after leaving a Wi-Fi network, the webpage error may look like a DNS issue when the real cause is that an On Demand condition was not triggered. For testing, record the rules, temporarily disable On Demand, connect manually, and repeat the same domain test.
How to continue when changing DNS does not help
No change after switching DNS Server does not prove that DNS is unrelated. Old lookup results may still be cached by the app, the operating system, or the webpage process. The encrypted DNS service’s own hostname may also fail to resolve because Bootstrap DNS is unreachable. Rebuild the Shadowrocket connection, reopen the test page, and check Log at the same time instead of entering multiple resolver addresses in succession.
The protocol layer must also be assessed separately from the DNS layer. Connection parameters for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are determined by the service configuration you already have. If Log shows that the domain resolved successfully and matched the expected policy, but the next step times out or the handshake fails, shift the investigation from DNS to the current node, protocol parameters, packet loss, or server status. DNS only obtains the address; it cannot repair later transport failures.
Error: DNS request timed out
Cause and fix: The lookup was sent but no response arrived within the time limit. Compare Wi-Fi and cellular networks, and check whether traditional DNS port 53 or the 443 and 853 paths used by encrypted DNS are reachable on the current network.
Error: Could not connect to the server.
Cause and fix: If the earlier Log entries already contain a resolution result, this is usually a post-resolution connection problem. Check the matched policy, current node status, and protocol parameters instead of repeatedly switching DNS.
- Record the failure time, network type, Global Routing mode, active config, and node name.
- In Log, confirm whether a domain lookup appears and whether it returned an A or AAAA address.
- When an address is present, confirm the matched DOMAIN-SUFFIX, GEOIP, IP-CIDR, or FINAL rule.
- If the rule is correct but the connection times out, check the node connection, protocol parameters, and your provider’s service status.
- If only subscription refresh fails, check the subscription domain, URL validity, and the update requirements provided by your service provider.
Conclusion: Use the last successful step in Log to assign responsibility
If there is no resolution result, troubleshoot DNS. If an IP exists but the policy is wrong, troubleshoot Config. If the policy is correct but the handshake fails, troubleshoot the node and protocol. Working forward from the last successful step is faster than repeatedly replacing DNS Server.
Restore stable settings and keep troubleshooting records
After identifying the cause, restore the temporary Global Routing mode to the original Config, Proxy, Direct, or Scene. Restore On Demand to its pre-test state, and remove duplicate DNS entries added only for troubleshooting. If the problem came from a rule in the config, change only the line confirmed to be incorrect. If it came from the current network, keep the comparison result from the other network for future reproduction.
When contacting your own service provider, provide the failure time, network type, failed domain, the nearby lines in Shadowrocket Log for that request, and whether the issue can be reproduced under Direct and Proxy. Subscription contents and access credentials are sensitive. Before taking screenshots, cover tokens, authentication details in server addresses, and the WireGuard private key.
Shadowrocket is a paid commercial app for Apple platforms, primarily used on iPhone and iPad. Compatibility with Mac, Apple TV, and Apple Vision, along with system requirements, is subject to the App Store listing. The only official purchase channel is the App Store. The developer should be listed as Shadow Launch Technology Limited, and the app ID is 932747118. The one-time app purchase and connectivity services are separate; buying the app does not include a node or subscription.