A latency reading in Shadowrocket only shows that the selected test completed at that moment. It doesn’t prove that every domain can resolve or every webpage can connect. This guide is for users who have already configured their own service but can’t load websites. Follow these steps to pinpoint the issue: confirm traffic is routed through Shadowrocket, identify where the request fails, check DNS, review rules, then restore your settings and retest. Back up your current configuration first, change one variable at a time, and keep DNS issues separate from proxy connection problems.
1. A successful latency test doesn’t mean a webpage loaded successfully
Loading a webpage involves resolving the destination domain, selecting a route, establishing a connection, and exchanging application-layer data. DNS retrieves records such as the address associated with a domain. HTTPS pages also require a successful TLS handshake with the destination. A latency test may only check a server port or send a request to a specified test address, depending on the test method. It doesn’t visit every webpage you open or its images, scripts, and login endpoints.
This sequence helps identify which stage to troubleshoot; it doesn’t mean every request must be resolved locally first. Domain rules can match before the destination IP is known. Some proxy protocols and configurations can pass the domain to a remote server for resolution, while IP-based rules may require a resolved address. Distinguish between local device resolution, resolution of the proxy server’s address, and remote resolution of the destination domain. One latency reading can’t rule out every DNS issue.
- Test succeeds, but all websites fail: Check the connection toggle, selected server, and Global Routing before changing DNS.
- Only some domains fail: Check their DNS results, matching rules, and actual outbound policy.
- The main page loads, but images keep spinning: Note the domains of the failed resources separately; they may not use the same rule as the main page.
- You see a certificate error: Check the device’s clock, destination address, and network sign-in status. Don’t assume a DNS timeout is the cause.
2. Record the current state, then run a repeatable comparison
Choose a full URL that reliably reproduces the problem, then note the network type, time, and exact error message. Replace “nothing loads” with a specific URL, and don’t change the server, configuration file, and DNS at the same time. The steps below use Home, Config, and Settings on iPhone and iPad; on other platforms, check the equivalent features. A system VPN indicator only shows tunnel status—it doesn’t confirm that the remote service is working.
-
Save the current state
In Config, confirm which configuration is active and back it up before editing. Note the server selected on Home, the Global Routing mode, and any existing conditions under Settings → On Demand. Don’t delete the original configuration.
-
Confirm traffic is routed
Return to Home and check the connection toggle. Before turning the connection off for comparison, review Settings → On Demand. Existing conditions may reconnect automatically and invalidate an “off” test.
-
Check the routing mode
Check Home → Global Routing. Config applies rules from the configuration; Proxy tests the proxy route; Direct tests a direct connection; Scene uses the configured scene. Select one mode explicitly for each test. Scene isn’t a fixed proxy mode.
-
Repeat the request
Retry the same URL on the same network with the same server, and note whether the error is identical. Then switch between Wi-Fi and cellular and test again. If only one network fails, first check whether DNS is reachable on that network, whether sign-in is required, and whether access is restricted.
-
Restore your settings
After comparing results, restore the original Global Routing mode and On Demand conditions. Record each change and its result. If switching to Proxy temporarily works, that doesn’t mean the rules in your original Config have been fixed.
3. Check the DNS server, transport, and resolution location
When checking DNS, ask three questions: which resolver handles the query, how the query is transported, and which route it takes. Entering a DNS address answers only the first question; it doesn’t guarantee that the address is reachable on the current network. Encrypted DNS also requires a connection to the resolver. If the resolver is specified by hostname, consider how that hostname is resolved initially.
| Check | What it means | What to look for |
|---|---|---|
| System DNS | Uses the resolver settings provided by the current system, which usually depend on the connected network. | Results may change when you switch networks on the same device. Don’t assume success on Wi-Fi means it will work over cellular. |
| Custom DNS | Specifies a resolver or a supported DNS service address. | Check the format and reachability. Don’t enter an HTTPS service URL in a field that accepts only IP addresses. |
| DNS over HTTPS | Sends DNS queries over HTTPS. | Check the full service path, the TLS connection, and whether the resolver’s own hostname can be resolved. A reachable port alone doesn’t prove the service works. |
| DNS over TLS | Sends DNS queries over TLS. | Check the service port, certificate validation, and whether the current network allows the connection. |
| A / AAAA | These records correspond to IPv4 and IPv6 addresses, respectively. | An AAAA record doesn’t mean the current IPv6 route works. Check the connection result as well. |
If your active configuration uses a text-based [General] section, check its dns-server setting. For example, the following uses the system DNS; it isn’t a universal “best” setting. Use it only for a controlled comparison: back up first, then edit the existing field. Don’t append another field with the same name at the end of the file, and don’t assume this setting overrides Secure DNS in your browser.
[General]
dns-server = system4. Tell DNS failures, connection timeouts, and certificate errors apart
The exact error message is more useful for diagnosis than “it won’t load.” The examples below are real messages a browser or network tool may display. They aren’t Shadowrocket menu names, and wording varies by platform. Use the error together with where it occurred and what the logs show; don’t change settings based on a single word.
Error: ERR_NAME_NOT_RESOLVED
Cause and fix: The browser couldn’t get a usable DNS result. Check the spelling of the domain, then compare system resolution with the DNS settings in the active configuration. Check whether the browser’s own Secure DNS path is failing.
Error: DNS_PROBE_FINISHED_NXDOMAIN
Cause and fix: The diagnostic indicates that the domain doesn’t exist, but a misconfigured resolver can also return an incorrect negative result. Confirm the full domain and check it using a trusted, known resolver path. Repeatedly refreshing the page won’t help.
Error: ERR_CONNECTION_TIMED_OUT
Cause and fix: The connection didn’t complete in time; this doesn’t point specifically to DNS. Check the destination address, matching policy, and remote connection. Compare Config and Proxy using the same URL.
Error: ERR_CERT_DATE_INVALID
Cause and fix: Certificate date validation failed, possibly because of the device clock or the site certificate’s validity period. Check the system date and time zone, then confirm the site’s status. Don’t disable certificate validation.
If a DNS lookup tool explicitly returns NXDOMAIN, that response says the domain doesn’t exist. SERVFAIL means the resolver couldn’t complete the query. Both differ from a timeout, where no response was received. Record the response type, queried domain, and resolver used; this is more useful than simply noting “DNS error.”
5. Check the rules: a correct DNS result can still take the wrong route
When Global Routing is set to Config, rules are generally processed from top to bottom, and the matching rule’s policy is applied. DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an IP range, and GEOIP checks an IP geolocation database. FINAL handles requests that didn’t match an earlier rule. A correct DNS result only confirms that resolution completed; it doesn’t mean the policy applied next is suitable for that request.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
FINAL,PROXYThis snippet is for illustrating syntax only: example.com is a sample domain, and 192.0.2.0/24 is a documentation-only network range. Don’t use them as everyday rules. no-resolve means this IP rule won’t trigger a domain lookup; it may still match if the request already has an IP address. The example’s PROXY policy requires an available proxy selection in the current setup; it won’t create a working route by itself.
- Config fails, Proxy works: First check whether an earlier DIRECT or REJECT rule matches the domain. This is only a clue; compare the resolution paths used by both requests, too.
- Direct works, Proxy fails: Check the selected server and proxy route. A successful local DNS lookup doesn’t prove that the domain can also be resolved remotely.
- The main domain works, but resource domains fail: Check the rules for each resource domain separately. A match for the main domain doesn’t cover the whole page.
- Changing FINAL has no effect: Check whether an earlier rule already matched the request, or whether Global Routing is set to something other than Config.
If the logs show the request domain, destination address, and policy, save all three. Redact credentials, private addresses, and subscription tokens before sharing diagnostic information. Don’t publish your full configuration just to troubleshoot. This guide assumes you already have your own service; this site doesn’t provide, sell, or recommend nodes or subscriptions.
6. Common questions about IPv6, caching, and browser DNS
Why is the error unchanged after I switched DNS?
First confirm that you edited the file currently in use in Config and saved it. Reconnect, close the old page, and make a new request. Your browser, system, or remote server may cache results, and changing DNS won’t necessarily clear every layer immediately. Note the time of the new request so you don’t mistake an old tab’s error for a new result.
The site loads when I turn off IPv6. Should I leave it off?
This only indicates that the IPv6 route or address selection needs further investigation. Record the AAAA lookup result, test IPv4 and IPv6 reachability separately on the same network, and check the route and server support. Temporarily disabling the relevant option can help with comparison, but it isn’t a universal fix for DNS problems.
How do I troubleshoot a site that won’t load in just one browser?
On the same device, try the exact same URL in another browser. Check the affected browser’s Secure DNS, built-in proxy settings, and extensions. Temporarily switch to system DNS for comparison, then restore the original settings. A private window may help rule out some site data, but it doesn’t necessarily bypass DNS caching.
If a site opens by IP but not by domain, is DNS the problem?
Not necessarily. HTTPS sites typically rely on the domain name for SNI and certificate validation. Opening an IP directly may reach a different site or produce a certificate error. Use DNS lookup results together with a connection test that uses the correct domain; whether a bare IP loads isn’t conclusive.
Why can my subscription update if webpages still won’t load?
A subscription update only tests whether its URL was reachable at that moment. It doesn’t test every server or destination website. Return to Home and confirm the server actually selected, then check Global Routing and the failing domain. Repeatedly updating the subscription isn’t a substitute for checking DNS and rules.
7. Retest the same URL and keep changes to a minimum
You’re done when the URL that failed loads repeatedly on the intended network and routing mode, and its key resources also load—not just when a latency number appears. If small requests work but large resources stall, investigate link MTU or transport-layer issues next. In particular, when using WireGuard, don’t change MTU at random just because a page won’t load; that can mix another layer of failure into DNS troubleshooting.
- Restore the Global Routing mode you normally use, then retry the original URL and the resource domains that failed.
- Test on both Wi-Fi and cellular, and note whether the issue occurs on only one network.
- Restore the original On Demand conditions and confirm that the connection behaves as expected when you switch networks.
- Keep only changes proven to help by comparison. Revert DNS, IPv6, or rule changes that made no difference.
- If the issue persists, collect the exact error, time, network type, policy, and comparisons you’ve already run, then contact the provider of your existing service.