Shadowrocket DNS Settings: What to Check When Connectivity Test Works but Websites Won’t Load

1. Why DNS can fail even when a latency test returns a result

Results in Home → Connectivity Test depend on the test method in use. A test may only check the connection to a server, or it may contact a test target. Neither method confirms that DNS, TLS, and page resources work for every website. If a server address is already cached, the test may not need to look it up again.

When you open a new domain, the usual sequence is to look up its address, establish a connection according to the active policy, then perform a TLS handshake and send an HTTP request. The simplified flow below can help with troubleshooting. Whether and when a lookup happens locally also depends on the rule type and outbound protocol.

So, a successful latency test is only one piece of evidence. If DNS returns an address but the connection times out, check the outbound path next. If DNS returns no address, focus first on resolution. If text loads but images do not, the image host may use a different domain that failed to resolve; checking only the domain in the address bar is not enough.

2. Check the DNS settings in the active Config

Open Config and confirm which configuration file is selected. Editing a different, inactive file won’t change the current connection. Keep a copy before making changes. If the configuration comes from your own remote source, a later update may overwrite local edits.

In Config, open the editor for the active file and check dns-server under [General]. This setting specifies the DNS resolver. The example below shows only the minimal syntax; it is not a complete file to replace your existing configuration with.

[General]
dns-server = system

system means use the DNS provided by the system. This is usually affected by the current Wi-Fi or cellular network and does not mean a specific public resolver is used. If the setting contains one or more addresses, check each address’s source and reachability. Don’t keep adding unverified resolver endpoints just to have a “backup.”

• Configuration value: Check spelling, separators, and duplicate settings. Don’t enter a webpage URL as if it were a regular DNS address.
• Encrypted DNS: DNS over HTTPS and DNS over TLS require the correct format and a reachable endpoint. Use the exact parameters provided by the service you already use; changing the port to 443 or 853 alone is not enough.
• Domain overrides: If the file contains a [Host] entry, check whether the affected domain is pinned to an old address. This mapping can make it seem as though changing the resolver had no effect.
• Endpoint domains: If an encrypted DNS endpoint uses a domain name, that name must also be resolved to establish the initial connection. Don’t overlook this dependency.

3. Retest in a fixed order and change one variable at a time

Choose a fully qualified domain that you can normally access, and pick a different site as a comparison. Keep the server and network unchanged during testing. Don’t switch Wi-Fi, change servers, and edit DNS all at once; even if service returns, you won’t know what fixed it.

1. Record the current state

   In Home, note the selected SERVER, the current Global Routing value, and the Connectivity Test result. Record the affected domain, network type, and the exact browser error. Before sharing a screenshot, hide account and server details.

2. Check the routing mode

   Go to Home → Global Routing and check whether the mode is Config, Proxy, Direct, or Scene. If you use Scene, confirm which scene is actually active. Note the original value before comparing; switching modes is a diagnostic step, not a permanent fix.

3. Check the configuration

   Open Config, select the active file, and check dns-server and [Host]. Change only one setting, save, return to Home, reconnect, and then open the same domain again.

4. Check automatic connection

   Go to Settings → On Demand and note whether it is enabled and which conditions apply. If the connection restores itself during testing, you can temporarily turn off On Demand and repeat the comparison; restore the original setting afterward. On Demand controls when a connection starts, not which DNS server is used.

5. Test another network

   Keep the configuration and SERVER unchanged, then retest on Wi-Fi and cellular. If the problem occurs on only one network, first check that network’s DNS reachability, login status, and restrictions.

6. Restore settings and verify

   Undo any temporary changes you no longer need, reconnect, and test both sites. Success means getting the expected DNS result and loading the webpage—not just seeing a value in Connectivity Test again.

Browsers, the operating system, and DNS resolvers may each cache results. Reconnecting helps establish a clear test boundary, but it doesn’t guarantee that every cache is cleared. When comparing results, note whether the same cached answer may have been reused. Don’t substitute an arbitrary HTTPS IP address for a domain test; certificate and virtual-host differences can affect the result.

4. Identify which of the three types of error you’re seeing

The messages below are examples that may appear in DNS protocol data or diagnostic output; they are not guaranteed to appear verbatim on every Shadowrocket screen. A browser may show only a general error. Use the information actually available and don’t assume every failure to load is the same kind of problem.

A completed query with no record of the requested type is not necessarily an error. For example, a domain may have only an A record, so an AAAA query can succeed but return no matching answer. Check both the response status and record type; the absence of an IPv6 address alone does not mean DNS is failing.

5. If DNS works, check Global Routing and rules

With Config selected under Global Routing, rules in the active configuration determine where connections go. Proxy and Direct provide their respective global routing modes; Scene follows its configured scene. These are not four DNS server options. If switching modes restores access, that shows the connection path affected the result; you still need to identify the specific rule or outbound difference.

In Config, check [Rule] in the active file. The syntax example below uses a documentation domain and a reserved address range; it should not be added to a live configuration as a fix. FINAL,DIRECT is only the fallback policy in this example, not a general recommendation.

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

• DOMAIN-SUFFIX: Matches a domain suffix. If the target domain matches REJECT, changing DNS won’t remove the block.
• IP-CIDR: Matches a destination IP address range. In the example, no-resolve means this IP rule won’t trigger an additional domain lookup. If an IP address is already available, assess it together with the other matching conditions.
• GEOIP: Matches based on IP geolocation data. It evaluates the destination IP rather than the domain suffix, and changes to the returned address may affect the result.
• FINAL: Handles connections that didn’t match any earlier rule. Check whether its assigned policy is what you expect; don’t just check whether the configuration contains the line.

Rules are generally evaluated in order for the same connection, so an earlier block or policy choice may prevent later rules from taking effect. If you use rule sets, check their actual contents and update status too. Don’t search only the main file for a domain and assume there are no matching rules if you don’t find it.

6. Verify the fix and keep a record others can review

A valid fix should be repeatable. With the network, SERVER, and configuration held constant, the affected domain should resolve, the connection should follow the expected route, and the page and its required resources should load. Then restore any On Demand settings you need and check that everything still works after switching networks.

• Configuration: Record the active file name, Global Routing value, and the specific DNS setting changed in this test.
• Test results: Record the time, whether you used Wi-Fi or cellular, the affected domain, the A/AAAA results, and the exact error message.
• Comparison: Check whether the failure before the change and success afterward can be reproduced. If the original setting also works after restoring it, the network or cache may have changed temporarily.
• Protect your information: When contacting your service provider, don’t share a full subscription URL, access token, password, or UUID. Provide only the redacted details needed to troubleshoot the issue.

If two DNS resolvers both return an address successfully but pages still won’t load through the same server, investigate server availability, TLS, outbound restrictions, and rules. Adding more DNS addresses only adds variables; it won’t automatically fix these issues. For further help, see Troubleshooting and Quick Reference.

Shadowrocket is a closed-source commercial app for Apple platforms, primarily iPhone and iPad, and is available exclusively from the App Store. The developer is Shadow Launch Technology Limited, and the app is sold as a one-time purchase; buying the app does not include a service plan. This guide assumes you already have your own service provider and configuration. Check the App Store listing for system requirements.