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

1. Normal latency doesn’t mean web requests are working

First, distinguish between connecting to the selected server and reaching a website. A latency test may cover only the server connection or a specific test address. Safari must also resolve the site’s domain, select an outbound route, establish a connection, and complete the TLS handshake. A response at the first stage does not guarantee success at any later stage. If latency is normal, check DNS early rather than assuming the server or the entire network is working correctly.

This sequence helps identify which stage to investigate; it is not a fixed internal order for every connection. Domain rules may be evaluated first, while some IP rules require an address. During troubleshooting, note separately whether an IP address was returned, which policy was ultimately used, and where the connection failed. A certificate error or HTTP status code usually means the issue goes beyond a simple DNS timeout.

These ports describe common service traffic; they do not mean you need to open inbound ports on your router. An A or AAAA record only confirms that an address was returned. A wrong address, an unreachable IPv6 route, or a blocked port later in the connection can still prevent a webpage from loading.

2. Establish a baseline for your network and active configuration

Before making changes, save a copy of the current configuration and note the full domain that fails, whether you’re on Wi-Fi or cellular, the current Global Routing option, and the time of the error. Test the same webpage each time, and choose another site that already works on your current network as a control. Testing just one site can make a problem with that website look like a general DNS failure.

1. Temporarily pause automatic connections

   Go to Settings → On Demand and note the current enabled state and conditions. Temporarily turn it off while troubleshooting. Then disconnect from Home to prevent On Demand from reconnecting immediately.

2. Check the underlying network

   After disconnecting, use Safari to open the control site. If public Wi-Fi requires sign-in, complete its login first. If the site still won’t load, troubleshoot Wi-Fi, cellular data, or network authentication before moving on.

3. Verify the active configuration

   Open Config and confirm which configuration file is selected, then inspect that file. Editing a different, inactive file won’t change how current requests are handled.

4. Retest while connected

   Return to Home, connect using a server you already have, then retry the same webpage in Safari. Note the difference between disconnected and connected results. Don’t change the server, DNS, and rules at the same time.

5. Test on another network

   Keep the configuration and server unchanged, switch between Wi-Fi and cellular, and try again. If the issue occurs on only one network, first check that network’s DNS reachability, authentication, and access restrictions.

If the server address you already have is a domain name, it may need to be resolved before the connection can be established. The target website’s DNS and the initial lookup for the server’s domain are two separate things to check. A problem with the former may occur while the connection remains active; a problem with the latter can prevent the connection itself. A connection indicator in the status bar alone does not confirm that both lookups succeeded.

3. Check dns-server in [General]

In Config, inspect the [General] section of the active file and find dns-server. First check whether it uses system DNS, an explicit DNS address, or DNS over HTTPS. Then verify the entry’s spelling and whether the current network can reach the specified service. Don’t combine settings from different sources or mistake another provider field for a DNS address.

[General]
dns-server = system

The example above is a minimal snippet showing how to use system DNS; it is not a complete configuration. If you want to run a comparison test, back up the file and replace the existing entry with the same name. Don’t add another [General] section or stack multiple dns-server entries. Save, reconnect, and make a new request. If the issue clears, the change in resolution path helped; compare it with the original setting to find out why.

• System DNS: system uses the DNS settings provided by the system. The actual resolution environment may change when you switch between Wi-Fi and cellular, making this a useful baseline for the current network.
• Explicit DNS address: Verify that the address is correct and that the current network allows access to the resolver. Setting an address does not guarantee that requests can reach it; server latency alone cannot confirm reachability.
• DNS over HTTPS: Check the full HTTPS endpoint path, hostname, and TLS connection requirements. The resolver hostname’s initial lookup may also affect connectivity. Using HTTPS does not guarantee that the service is reachable.
• Local domain names: Names used on a company or home network may resolve only through local DNS. Switching to an external resolver may restore access to public websites while preventing internal names from resolving.

4. Use Global Routing to distinguish rule issues from DNS issues

Go to Home → Global Routing and note the current option. Config handles requests according to the active configuration’s rules; Proxy and Direct can help compare outbound paths. If a webpage loads after switching to Proxy, don’t assume that DNS has been fixed. The domain may have resolved all along, while the original rule sent the connection through an unsuitable outbound policy.

Rules are matched in order, and the corresponding policy is used when a rule matches. Check whether DOMAIN-SUFFIX covers the target domain, whether GEOIP or IP-CIDR sends the resolved address through another path, and whether FINAL is at the end of the rules section. The snippet below shows syntax and order only; example.com is a documentation example, not a webpage connectivity test target.

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

no-resolve means an IP rule won’t trigger a DNS lookup just to match that rule; it does not disable all DNS. Whether the target IP is already known and whether an earlier domain rule matched both affect subsequent matching. If your configuration uses named policies, check where each policy ultimately points. A name in a rule line alone doesn’t confirm that the expected server is being used.

5. Identify DNS, connection, and TLS issues by the error stage

Safari’s messages may vary with the system language. If the error details or diagnostic logs include a system error identifier, use the names below to distinguish stages. These are Apple URL Loading System error names; they are not necessarily displayed verbatim by Shadowrocket. Check the request logs around the time of the failed visit, focusing on resolution failures, the target IP, the matched policy, and the connection result.

If the logs show a target IP but the subsequent connection to that IP times out, check the server’s outbound route, target port, and IPv4 / IPv6 paths instead of repeatedly changing DNS. If a DNS query is sent but receives no response for an extended period, focus on whether the resolver is reachable. If an older webpage still works but a new domain fails, cached data may be masking the issue; test again with a new request.

6. Restore On Demand after confirming the issue is resolved

After making a change, save the current configuration, disconnect and reconnect, then open the target webpage again. Safari or an app may keep existing connections and cached data, so a successful refresh once isn’t enough to confirm the cause is gone. Likewise, an old connection that still fails doesn’t mean the new setting had no effect. Retest the original webpage, the control site, and another network, and note whether the results are consistent.

• Confirm resolution: The target domain returns a reasonable address, and the resolution failure seen during reproduction no longer appears in the logs.
• Confirm routing: Restore your usual Global Routing setting and check that the target request matches the expected rule and policy.
• Confirm network switching: Test on your usual Wi-Fi and cellular networks, paying particular attention to resolver reachability issues that appear only after switching.
• Restore automatic conditions: Go to Settings → On Demand, restore the conditions you noted earlier, and check that connections are triggered as expected.
• Save the working configuration: Keep copies from before and after the change. If a remote configuration update may overwrite local edits, review the update rather than treating a temporary fix as permanent.

If the issue persists, give your provider or network administrator only the information they need: the time it occurred, network type, target domain, Global Routing setting, matched policy, and a redacted error excerpt. Don’t send a full subscription URL, authentication password, or configuration containing access tokens. Explaining whether DNS received no response or returned an address before the connection failed is usually more useful than sharing a latency test alone.