This guide is for iPhone and iPad users who have configured Shadowrocket and already have their own server or subscription, but find that websites won’t load even though the latency test looks normal. Follow these steps in order: confirm the symptoms, compare routing, check DNS, inspect IPv6, and test again. This helps distinguish DNS lookup failures from server connection issues and routing-rule problems—without changing several settings at once and losing track of the cause.
1. A Normal Latency Test Doesn’t Mean a Web Request Succeeded
In Shadowrocket, a latency result only shows that a particular test completed one connection step at that moment. A TCP test typically checks whether the server port is reachable; an HTTP-based test only reflects its specific target and route. Neither replaces checking DNS lookup, the TLS handshake, or page resources for the site that is actually failing.
Loading a webpage usually involves resolving its domain to an address, connecting over the selected direct or proxy route, then completing a TLS handshake and HTTP request. When using a proxy, the destination domain may also be resolved remotely. A latency number alone can’t confirm that either local or remote DNS is working, let alone that the website is reachable.
These ports describe DNS transport methods; they are not instructions to change your server port to one of these values. A successful DNS over HTTPS connection doesn’t mean the destination website is reachable. Conversely, being able to load ordinary webpages doesn’t prove that the network allows every DNS transport method.
2. Establish a Repeatable Baseline
Use the same full URL, browser, and device throughout troubleshooting. Don’t treat the homepage, an in-site redirect, and video playback as a single test: the main document may load while separate domains for images, sign-in, or media still fail. Change one condition per test and record the result.
- Identify the scope. Try the affected site and one site that worked before. Note whether all pages fail, only one domain fails, or text appears while images keep loading.
- Check the underlying network. Temporarily disconnect Shadowrocket and check whether the current network requires you to sign in through a web portal. This only verifies the underlying network; the affected site does not need to work over a direct connection.
- Restore the connection. Return to Home, select a server you already have, and connect again. Then visit the same URL. Don’t just repeat the latency test.
- Compare access networks. Keep the server and configuration unchanged, switch between Wi-Fi and cellular, and test again. If the issue occurs only on one Wi-Fi network, first check its DNS reachability, sign-in status, and access restrictions.
- Rule out automatic reconnection. If the connection turns back on after you stop it, check Settings → On Demand. Note the original setting, pause it during testing if needed, and restore it afterward.
Browsers may reuse existing connections, and DNS results may be cached. After changing a setting, disconnect and reconnect Shadowrocket, then reopen the affected page. If results are inconsistent, close the relevant browser tabs and try again. Don’t assume the issue is fixed just because a single refresh worked.
3. Use Global Routing to Separate Routing Issues from DNS Issues
Check the current option under Home → Global Routing. Config handles traffic according to the active configuration; it doesn’t mean every request goes through a proxy. Proxy is mainly useful for comparing results with traffic sent through the selected proxy, while Direct provides a direct-connection comparison. Scene follows its scene settings, so check which scene is active rather than assuming its name tells you the actual route.
| Result | Check first | Next step |
|---|---|---|
| Config fails; Proxy works | Rule matching, policy selection, and differences in resolution paths | Check the rule and policy for the destination domain in the active Config |
| Both Config and Proxy fail | Current server, DNS reachability, or destination website | Keep the configuration unchanged and compare with another server you already have |
| Direct works; Proxy fails | Proxy exit, remote DNS resolution, or destination site restrictions on that exit | Check the server status; don’t rewrite the entire rule set first |
| Fails on only one access network | That network’s transport restrictions and DNS path | Compare Wi-Fi with cellular and check the DNS transport method |
Takeaway: If Proxy works, check Config first
If only Config fails with the same server and network, first check which rule matches the destination domain and which policy it selects, then review DNS. Don’t leave Proxy enabled indefinitely and assume the routing issue is fixed.
These results are clues to narrow down the issue, not proof based on a single test. Switching Global Routing can change both the connection path and DNS conditions, so verify the results against the DNS settings in the next section. When you’re done comparing, restore your usual option.
4. Check DNS Addresses, Transport Methods, and Configuration Sources
Open Settings → DNS and note the DNS settings currently shown. Then check Config to see whether the active configuration file contains DNS-related settings. Don’t assume a change to one address will take effect on its own: the configuration file, global settings, and related options can all affect the final behavior. Verify by reconnecting and checking the request result.
- Make sure each value goes in the right field. A regular DNS address, a full DNS over HTTPS URL, and a DNS over TLS server name aren’t interchangeable. Use a format supported by the interface, and don’t paste a subscription URL into a DNS field.
- Check that the endpoint is complete. DNS over HTTPS usually requires a full HTTPS endpoint; a website’s homepage URL alone doesn’t show that it provides DNS service. Check the details for the resolver you use, and don’t guess or assemble a path yourself.
- Check for an initial lookup dependency. If the DNS endpoint uses a domain name, that domain may need to be resolved before the endpoint can be reached. If basic resolution isn’t working, switching to another endpoint that also uses a domain name may not help.
- Check that the route is reachable. The current network may allow HTTPS but block other ports. If the proxy server itself uses a domain name, account for the lookup needed before the proxy connection can be established. Avoid making DNS requests and proxy setup depend on each other.
- Change one setting and test again. Back up the current configuration first, then compare it with DNS settings you’ve already confirmed work. Keep the server, Global Routing option, and test URL unchanged; reconnect and record the result.
If changing DNS fixes the issue, check that it still works after reconnecting and switching networks. If it works only once and fails again, review caching, endpoint reachability, or automatic switching conditions. Refreshing a subscription mainly updates server information; it doesn’t necessarily update DNS settings in the active Config.
5. Choose What to Check Based on the Exact Error
An error may come from the browser, the system network layer, or a request log—not necessarily from a Shadowrocket alert. The messages below are common network errors, but wording can vary between devices. Note whether the error refers to the destination website, the proxy server, or the DNS endpoint; that’s more useful than recording only “won’t load.”
Error: The server with the specified hostname could not be found.
Cause and fix: The hostname didn’t resolve to a usable result, or it may be misspelled or no longer valid. Check the full domain, compare Settings → DNS with the active Config, and test the same URL on another access network.
Error: NXDOMAIN
Cause and fix: The resolver says the domain doesn’t exist; this is different from a timeout. Check the spelling and make sure you haven’t added an unintended subdomain, then compare with another DNS path you know works. Increasing the wait time repeatedly won’t fix this result.
Error: SERVFAIL
Cause and fix: The resolver couldn’t complete the query, possibly because of an upstream issue or a domain validation problem. Keep other conditions unchanged and compare with another working DNS path. If the issue affects only the same domain, record the result and report it to your service provider.
Error: The request timed out.
Cause and fix: A request stage exceeded its time limit, but the message alone doesn’t identify a DNS failure. First check whether an address was resolved, then inspect the connection path. If resolution succeeded, check TCP, TLS, or the destination service’s response.
If you see a certificate error, check the device’s date and time, the destination domain, and the configured endpoint. This is a different issue from a domain not being found. Don’t disable TLS verification to suppress the warning, and don’t change DNS, the server, and the protocol all at once before identifying where the failure occurs.
6. Only Some Domains Fail: Check Rules, AAAA Records, and Page Resources
If most websites work but a few domains fail, look for what’s different about them. A records provide IPv4 addresses; AAAA records provide IPv6 addresses. Having an AAAA record doesn’t mean the current network has a working IPv6 route. If a domain resolves but the connection stalls, compare the IPv6-related settings if you can restore them afterward. Change one setting at a time, test, then restore it or note the final choice.
Rules are evaluated in order. DOMAIN-SUFFIX matches a specified domain and its subdomains; IP-CIDR and GEOIP apply to IP information and may require a lookup first in some cases. FINAL is the fallback when no earlier rule matches. The example below illustrates rule order and syntax; it is not a replacement configuration.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- Check domain rules first. In this example,
example.comand its subdomains match DIRECT first. If the domain needs to use your own proxy, check for an earlier rule that matches it incorrectly. - Understand no-resolve. It avoids triggering a domain lookup just to evaluate that IP rule. It isn’t a general-purpose DNS fix, and it doesn’t guarantee that no lookup will ever happen.
- Confirm that the policy exists. In this example,
PROXYmust refer to a policy that is actually available. Don’t just copy the name without checking that the active configuration defines it. - Check related resources. If page text loads but images fail, check the domains used by images, scripts, or sign-in requests. Changing a rule for the main domain may not cover separate resource domains.
Takeaway: If an address is returned but the connection fails, check what happens next
If you’ve confirmed that the affected domain returns an address but the request still stalls during connection or TLS, check the actual exit, the IPv4 and IPv6 routes, and the destination site’s response. Don’t attribute every failure to DNS resolution.
7. Common Questions and Final Checks
Why does the latency test stay normal, but switching servers lets the site load?
A latency test covers only its target and some connection steps. Another server may have a different exit, remote DNS resolution, or reachability to the destination site. Keep DNS and Config unchanged while comparing the two servers, and note whether the affected site’s behavior changes with the server. This alone doesn’t prove that local DNS is the problem.
If Proxy lets the site load, can I ignore Config?
Use that result as a troubleshooting clue, but go back to Config and check rule order, the policy matched by the destination domain, and DNS-related settings. After making changes, switch back to your usual option and confirm that the page and its resources all load.
Only Wi-Fi fails while cellular works. Should I reinstall?
There’s no need to reinstall yet. Keep the same server and configuration, then check Wi-Fi sign-in and DNS transport reachability. If the connection turns back on when you pause it, also check Settings → On Demand so automatic reconnection doesn’t change the test conditions.
Will refreshing my subscription fix DNS too?
Not necessarily. A server subscription and Config contain different information. First check in Home whether the selected server changed, then inspect the active configuration in Config, and finally review Settings → DNS. Updating the server list doesn’t reset every network setting.
After making changes, test again with the original affected URL, one working comparison URL, and a switch between access networks. If you need to report the issue to your service provider, include the failed domain, time, access network, Global Routing option, exact error, and results before and after the changes. Remove subscription tokens, server passwords, and other credentials from screenshots and logs.
- I’ve distinguished DNS lookup failures, connection timeouts, and TLS errors instead of relying on the latency result alone.
- I’ve confirmed the selected server in Home, the Config file, and the Global Routing option.
- I’ve checked the DNS address format, endpoint reachability, and any initial lookup dependencies.
- I’ve restored temporary changes to On Demand, routing, and IPv6-related options, or noted which changes need to remain.
- I’ve confirmed the issue stays fixed after reconnecting, rather than just loading successfully once.