Shadowrocket: Ping Works but Websites Won’t Load—How to Troubleshoot DNS Resolution Failures

1. A Normal Latency Reading Doesn’t Guarantee Websites Will Load

First, identify which test produced the latency reading. A test that connects to a server port and one that requests a webpage cover different parts of the connection path. If the server address is an IP, the test may not need to resolve that server’s domain at all. A browser still needs to resolve a website’s domain before connecting. So a latency reading in Home alone does not rule out a DNS issue.

A page that keeps loading does not necessarily indicate a DNS failure. Resolution may have succeeded while the subsequent connection was blocked, the destination server failed to respond, or the TLS handshake failed. Note the exact error and when it occurs before changing DNS. Don’t attribute every access problem to the same setting.

These port numbers help explain transport differences. They don’t mean your network allows those connections, or that you should change the server port to one of these values. Proxy server ports and DNS service ports are separate settings; the former must match your existing server configuration.

2. Establish a Repeatable Troubleshooting Baseline

Don’t start by changing the server, DNS, and rules all at once. Choose one affected website and note the current network, selected server, Global Routing mode, and active configuration. Use the full domain for comparisons. Don’t replace the domain in an HTTPS URL with an IP to “test DNS”: that changes certificate validation, SNI, and virtual host selection, so the results aren’t directly comparable.

1. Record the current setup

   In Home, note the selected server and connection status. Open Home → Global Routing and record the current setting. In Config, note the active configuration and save a restorable copy before making changes.

2. Check the underlying network

   Disconnect temporarily and try a website that the current network normally allows. If public Wi-Fi requires a web-based sign-in, complete it first. If the site still won’t load while disconnected, check the Wi-Fi or cellular connection first.

3. Keep the test conditions consistent

   Reconnect, then temporarily select Proxy in Home → Global Routing. Keep the same server and retry the target domain. This provides a comparison with Config; it is not a recommended permanent setting.

4. Retest on another network

   Keep the server and configuration unchanged, then compare Wi-Fi with cellular. If the issue occurs on only one network, note the DNS requests and connection errors on that network. Don’t overwrite the configuration right away.

5. Restore the original settings

   After comparing results, restore the original Global Routing setting. If the connection comes back automatically after disconnecting, check the enabled conditions in Settings → On Demand. Temporarily disable the relevant conditions before testing again.

3. Check Which DNS Configuration Is Active

Open Config, confirm which configuration is active, and review its DNS settings. Editing an inactive file won’t affect the current connection, and a remote configuration update may overwrite local changes. Save a copy first, then reconnect after making changes and retest the same domain. Updating the server subscription in Home alone does not mean the DNS settings in Config have also changed.

This is a syntax example, not a general fix. It uses the system resolver as one variable in a controlled comparison. If the system DNS is faulty on your current network, this setting may fail too. Change only the corresponding field in your existing configuration; don’t delete other rules, policies, or server settings just to test.

[General]
dns-server = system

With DoH, also check the dependency on resolving the service address first. If the DoH endpoint uses a hostname, its address must be resolved before an HTTPS connection can be established. The query may stall if the endpoint is unreachable, certificate validation fails, or its hostname cannot be resolved. Encryption changes how queries are carried; it does not guarantee endpoint reachability or replace checking the current network.

4. Check Rule Matches Separately from DNS Results

Direct, Proxy, Config, and Scene under Global Routing are not four DNS protocols. Direct and Proxy define different traffic-handling modes; Config follows the active configuration, while Scene depends on the settings for the selected scene. During troubleshooting, don’t change the scene and DNS settings at the same time. Otherwise, the same website may take a different path between tests.

In Config, check the order of the rules too. Domain rules and IP rules match different things, and IP-based matching may require resolving the target domain. If the logs already show an address but the request uses the wrong policy, changing DNS again may not help. The reserved domains and documentation addresses below illustrate syntax only; they are not connectable services.

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

• DOMAIN-SUFFIX checks the domain suffix. If a broader rule above it already matches, a later rule won’t be selected for that request.
• IP-CIDR checks the address range. In this example, no-resolve means this rule won’t actively trigger domain resolution; it does not disable DNS for the entire app.
• GEOIP matches based on the IP’s geographic data. Don’t infer whether a rule matches from the domain’s language or the website’s name alone.
• FINAL is the policy used when no earlier rule matches. Check which policy it actually points to rather than just confirming that the keyword appears in the file.

Also distinguish A and AAAA records: the former returns an IPv4 address, the latter an IPv6 address. If resolution succeeds but connections fail only with one address family, that points to an address reachability issue. Keep the DNS response and subsequent connection results for comparison. Don’t treat the presence of an AAAA record as a fault, and don’t change IPv6, DNS, and rules all at once.

5. Choose the Next Step Based on the Exact Error

The following error identifiers come from Apple’s networking error domain. Use them as clues when the exact text appears in error details or diagnostic information; this does not mean Shadowrocket always displays these messages. The browser may show only a localized error. Record the full message you actually see rather than guessing based on “won’t load.”

If only one website fails while other domains load reliably, note that domain and any related resource domains separately. A page’s main document, images, and scripts may come from different domains. If the page appears but its images keep loading, the main domain may already have resolved successfully. Check the rules for the failing resource domains to pinpoint the issue more easily than replacing DNS across the board.

• Record the network type, Global Routing mode, active configuration, and target domain associated with the error.
• Distinguish “no resolution result” from “IP obtained, but connection timed out,” and keep the exact error text.
• Before sharing diagnostics, redact subscription tokens, passwords, UUIDs, and personal network addresses. Share only the information needed to locate the issue.

6. Common Questions and How to Verify a Fix

Verify the fix using your original setup, not the temporary Proxy test mode. Restore the intended Global Routing and On Demand settings, reconnect, and revisit the website that first failed along with a comparison site. Confirm that the main page and required resources load, and that access doesn’t depend on temporarily switching networks.

1. Keep a copy of the final configuration and note the DNS source you chose. Revert temporary changes that aren’t supported by the evidence.
2. Retest on your usual networks. If you use both Wi-Fi and cellular, record the result on each.
3. If the issue is still reproducible, continue troubleshooting with the redacted error text, target domain, and rule match information instead of repeatedly importing the same subscription.