Shadowrocket DNS Troubleshooting: Latency Is Normal but Websites Won’t Load

Normal latency only means the test destination responded

Shadowrocket’s latency test and opening a webpage in a browser are different operations. They test different parts of the connection: a response from the server’s port doesn’t confirm that proxy authentication, target-domain resolution, the TLS handshake, and webpage resources all work. Even an HTTP-based test only confirms that its test destination was reachable at that moment; it doesn’t replace checking the website that actually fails.

This flow shows the main stages involved in a request, but not every protocol follows them in exactly this order. If the proxy server address is a domain name, it must also be resolved first; the destination website’s domain may instead be resolved remotely. Identify whether the problem involves the server address or the website address before deciding what to change.

• No websites load: First check whether a connection is established, whether the proxy server address resolves, and whether the current network requires a sign-in.
• Only one domain fails: Record the full hostname, check its spelling and DNS response, and see which rule matches it.
• Text appears but images don’t: Check the other domains used for images and page resources, not just the domain in the address bar.

Record the conditions first, then run a controlled comparison

Keep your existing configuration during troubleshooting; don’t change the server, DNS, and rules at the same time. The steps below use iPhone as an example; the same approach applies on iPad. Test with a server and subscription you already have. A successful subscription update only means the subscription URL could be read; it doesn’t confirm that every server in it or every destination website is reachable.

1. In Home, note the selected server, connection toggle state, and Global Routing selection. In Config, note which configuration is currently enabled.
2. Record the failing URL’s hostname, when the issue occurred, whether you were on Wi-Fi or cellular, and the browser’s exact message. Remove subscription URLs, passwords, and tokens before sharing your notes.
3. Turn off the connection and try a website that is usually accessible directly on your local network. If it still won’t load, check the local network or any required sign-in first.
4. Reconnect using the same server and try the same website again. After each change, close the old browser tab and test in a new one to reduce the effect of existing connections.
5. If needed, compare Wi-Fi with cellular without changing DNS. Differences after switching networks can help identify issues with the local router or mobile network.

What the DNS settings control

Review the DNS settings available in Settings → DNS, then check the active configuration’s [General] section in Config. Depending on the configuration, DNS servers, resolution strategies, and domain-specific mappings may all be involved. Check the configuration that’s actually enabled; seeing an address in a field doesn’t prove that every request uses it.

For example, the following line in a configuration indicates that system DNS is used. It illustrates syntax; it isn’t a complete file to replace your existing configuration with. Save the original value before making changes. If the configuration comes from your own provider, check its DNS requirements before testing a single setting.

[General]
dns-server = system

Use the response status to identify three types of DNS failure

A browser message such as “server not found” usually isn’t enough to identify the cause. If connection logs or diagnostic output are available, look for a DNS response status, the queried domain, and timeout details. The terms below are general DNS statuses or diagnostic messages; they may not appear verbatim in every Shadowrocket interface.

Also distinguish “no AAAA record” from “domain doesn’t exist.” AAAA records provide IPv6 addresses, while A records provide IPv4 addresses; a domain having only an A record isn’t necessarily a problem. If an address is returned but the connection then stalls, check address-family reachability, routing, and TLS instead of repeatedly changing DNS.

• Note whether the query is for A, AAAA, or another record type; don’t compare different query results as if they were the same.
• If a private or unexpected address is returned, first check how it’s used on the local network and whether a static mapping is in place. Don’t draw conclusions from the address alone.
• Don’t rely on replacing an HTTPS URL with an IP address as your only test: certificates, SNI, and virtual hosts may depend on the original domain.

Use Global Routing to distinguish DNS issues from rule issues

In Home → Global Routing, Config processes traffic according to the current configuration, Proxy sends applicable traffic through the proxy, and Direct connects applicable traffic directly. Switching modes can help isolate an issue, but it isn’t a DNS-only switch: the destination’s connection path and the opportunity for remote resolution may also change.

1. Reproduce the failure under Config first, and note the domain and the rule or policy that matches it.
2. Keep the same server, briefly switch to Proxy, and revisit the same domain. If it works, check the routing rules and selected policy in Config first; this alone doesn’t prove that DNS is working properly.
3. For a destination that’s usually reachable directly on your local network, briefly compare with Direct. If the destination itself can’t be reached locally, failure in Direct doesn’t prove that DNS is misconfigured.
4. Restore the original mode after the comparison. If you use Scene, first check which connection behavior the active scene selects so that a scene change doesn’t skew the comparison.

The following illustrates rule syntax. example.com is an example domain, not a diagnostic service. DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an address range, GEOIP matches by IP geolocation, and FINAL handles requests not matched by earlier rules. Rules are checked in order. Address-based rules may also depend on resolution results, so don’t focus only on the last line.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

no-resolve avoids triggering an additional domain lookup just to match the corresponding address rule; it isn’t a setting that “fixes all DNS.” If an earlier rule sends a domain through an unavailable path, changing DNS alone may not help. Check which rule matched, then adjust its policy or position.

Common questions: caching, subscriptions, and restoring connectivity

Retest under the same conditions after recovery

One successful page load only confirms that it worked once. After recovery, retest on the network where the problem first occurred, using the original destination domain and your usual mode. Check that the page’s supporting resources load too. The key is to record which variable changed when the issue cleared, not how many settings you changed.

• Restore connection settings: Revert any temporary Global Routing changes and restore Settings → On Demand as needed.
• Check the configuration: Confirm that the correct file is enabled in Config. Remove any static mappings or temporary rules added just for testing if they’re no longer needed.
• Keep a record: Note the network type, failing domain, DNS response status, changes made, and retest results. Remove credentials before sharing the details with your provider.
• Identify the next layer: If the correct address is returned and DNS responds normally but the connection still can’t be established, check server availability, the destination port, and TLS instead of attributing every failure to name resolution.