Shadowrocket DNS Troubleshooting: Ping Works but Websites Won’t Load

At a glance

A successful latency test in Shadowrocket doesn’t mean the target website’s DNS, rules, or HTTPS connection are working. This guide helps users who already have a provider and subscription narrow down the cause: note the symptoms, confirm the configuration, compare DNS settings, check rules, and test IPv6. Change one variable at a time, then retest the same domain to tell a DNS failure from a connection problem that occurs after resolution.

1. Why websites may not load even when the latency test works

The latency result in Home reflects the target and route used by the selected test. A successful test doesn’t prove that every domain your browser visits can be resolved, or that the website’s TCP and TLS connections or subsequent resource requests will complete. Note the exact domain that won’t load, when the problem occurs, and whether you’re on Wi-Fi or cellular. “The network is down” isn’t specific enough.

Loading a webpage usually involves resolving a domain to an address, establishing a connection, and completing a TLS handshake. Depending on your configuration, some domains may be resolved by the proxy, while others may need to be resolved locally first. Not every request follows the same fixed path. The sequence below is a troubleshooting model, not the actual packet flow for every protocol.

Domain request Resolution and routing Address connection TLS handshake Page resources

No address returned for the domain: Check the DNS response, whether the resolver is reachable, and any local mappings.
An address is returned, but the connection times out: Check the matched policy, destination port, and address family. Don’t assume DNS is at fault.
The page returns HTTP 403 or 503: The request reached a service capable of returning an HTTP response. Check the site’s access restrictions or service status.
The homepage loads, but images don’t: Note the domains used by the images or scripts. A working main site doesn’t mean its resource domains use the same rule.

2. Start with a single-variable test

Before you begin, save a copy of your current configuration and note the status in Home → Global Routing and the selected server. This guide uses Config as the baseline for rule-based routing. The behavior of Proxy, Direct, and Scene depends on their settings; switching modes alone does not fix DNS.

Record the baseline

In Home, note the current server and Global Routing status. Reopen the same domain in your browser and record the error message. Don’t update the subscription, switch servers, and change DNS all at once.
Check the configuration

Open Config and confirm which configuration is active. Then check its [General] and [Rule] sections. Make a backup and test changes in a local copy rather than editing your only configuration file.
Switch networks

Keep the server and configuration unchanged while comparing Wi-Fi with cellular. If the issue occurs only on Wi-Fi, first check whether that network requires a sign-in page, then review its DNS and network restrictions.
Compare DNS resolution

In a test copy, change only dns-server, save and activate that copy, then disconnect and reconnect. Test the same domain again and note whether it resolves to an address and whether the page loads.
Restore and verify

If the change doesn’t help, restore the original value and test again. If you need to disconnect, check Settings → On Demand first. If necessary, temporarily disable automatic connection conditions, then restore them after testing so they don’t interfere with your observations.

3. How dns-server, system DNS, and configuration DNS relate

dns-server is in the configuration file’s [General] section and specifies the resolver. system uses the DNS provided by the system. System DNS may come from automatic or manual settings for the current Wi-Fi network; it isn’t necessarily a fixed public resolver. Switching networks may also change the DNS settings in use.

Search the active configuration for dns-server and check for duplicate entries or leftover test values. Then use each of the following options in a separate local test copy. Don’t combine two [General] sections in one file. The public address is for reachability testing only and may not work on every network.

Test A: Use system-provided DNS

[General]
dns-server = system

Test B: Specify a standard DNS address

[General]
dns-server = 1.1.1.1

For the test, keep only one candidate resolver so you can isolate the variable. Multiple resolvers can make results difficult to interpret because of query scheduling, caching, and differing responses. If the specified address doesn’t respond but system works, check the network path to that resolver before repeatedly reimporting the subscription.

Common port for standard DNS over UDP and TCP

443

HTTPS port commonly used by DoH

2 types

Check A and AAAA records separately

A reachable port doesn’t guarantee that the protocol works. Standard DNS may need TCP when a UDP response is truncated; DoH requires a successful HTTPS connection. You can’t use a regular DNS address for DoH just by rewriting it as an HTTPS address. DoH needs a valid service endpoint, and if that endpoint uses a domain name, consider how it will be resolved before the first connection.

Takeaway: Compare one resolver at a time

If changing dns-server restores access on the same network and server, keep that result and investigate whether the original resolver is reachable. Don’t change rules or protocols at the same time.

4. Identify the cause from the DNS error

These are common DNS response codes and network diagnostic messages; Shadowrocket may not display them exactly as written. If you see one in a log or diagnostic result, record the queried domain, record type, resolver address, and time. A single line of error text is usually not enough to identify where the failure occurred.

Error: NXDOMAIN

Cause: The resolver reports that the name doesn’t exist. This is different from a query timeout.

Fix: Check the spelling of the domain, then query the same name with another resolver. If the result is consistent, contact the domain or service administrator to confirm its records.

Error: SERVFAIL

Cause: The resolver couldn’t complete the query. The issue may involve an upstream resolver, an authoritative server, DNSSEC validation, or another step.

Fix: Compare the result with another resolver and note whether only one domain fails. This response code alone doesn’t prove the server is unavailable.

Error: connection timed out

Cause: An operation didn’t finish within the allotted time. It’s evidence of a DNS timeout only if you confirm the timed-out operation was a DNS query.

Fix: Check which target and port the error refers to. If it was a DNS query, check the route to the resolver, the current network, and UDP/TCP connectivity.

Also distinguish between “no record of this type” and “the domain doesn’t exist.” If an AAAA query returns no address but an A query succeeds, the domain may simply have no IPv6 address. If you have a usable address but then see a TLS certificate error, check the system time, certificate name, and connection target instead of switching DNS again.

5. Some domains won’t load: Check rules and Host mappings

If only some sites fail, first check which rule and policy the request actually matched. DOMAIN-SUFFIX can match a domain suffix directly. Matching IP-CIDR and GEOIP by address may involve DNS resolution. Rules are evaluated from top to bottom, so an earlier match affects the rest of the route. FINAL handles requests that didn’t match any preceding rule.

The snippet below illustrates syntax only; don’t replace your existing configuration with it. example.com and 192.0.2.0/24 are documentation examples. In an actual configuration, PROXY must refer to an available policy.

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

Check	What it means	What to do
`DOMAIN-SUFFIX`	Matches the specified domain and its subdomains.	Check whether an earlier rule sends the failing domain to a different policy.
`IP-CIDR`	Matches an IP address range.	Check whether the address falls within an unexpected direct-connection range.
`no-resolve`	Avoid triggering DNS resolution solely to match this IP rule.	Don’t interpret this as disabling DNS for the entire configuration.
`[Host]`	Provides local hostname mappings.	Check for an outdated address. Remove suspicious mappings in a test copy and compare the result.
`FINAL`	Handles requests that haven’t matched an earlier rule.	Confirm that the final policy actually works; don’t rely on the rule simply being present.

If switching temporarily to Home → Global Routing → Proxy restores access, while Config doesn’t, that shows the two routing conditions differ. It doesn’t prove that a DNS setting is at fault. Record the matched policy, connection address, and failure stage in each case, then narrow down the cause under Config. Restore the original mode when you’re done so temporary test settings don’t become your everyday configuration.

6. If an address is returned, check IPv6, caching, and network conditions

A records return IPv4 addresses; AAAA records return IPv6 addresses. An AAAA response shows that the resolver returned an address, but not that your current network can connect to it. If a domain has both types of records, distinguish between three issues: no record, a record returned but the connection timed out, and which address type the app selected.

IPv4 connects, but IPv6 times out: Keep the DNS response as evidence and check IPv6 connectivity on the current network. If you need to adjust a related setting, note its original value and test it temporarily. Don’t change DNS and routing rules at the same time.
The old result still appears after changing the configuration: Confirm the new configuration is active, disconnect and reconnect, then quit and reopen the browser. The browser, app, or resolver may cache results; reconnecting doesn’t necessarily clear every cache.
The problem occurs only on hotel or public Wi-Fi: Complete the network’s sign-in page first. Before access is authorized, DNS responses and HTTPS connections may be affected.
The problem occurs in only one browser: Compare the result in another app using the same domain. Check for app-specific DNS, caching, or connection settings before changing the global configuration.
The server address is a domain name: Check that the server’s domain can be resolved before the connection is established. Don’t rely on a connection that hasn’t been established to resolve everything required to start that connection.

Takeaway: Once you have an address, check the connection

If the same domain consistently returns an A or AAAA record and the failure occurs during connection or TLS, stop switching resolvers. Check the address actually used, the matched policy, and the destination port instead.

7. Restore your configuration and document a reproducible test

After fixing the issue, restore any On Demand conditions you temporarily disabled. Check Global Routing and the active configuration, then test the main site and its resource domains separately. Don’t conclude that the issue is fixed just because a page loads once: caching may mask the problem. Repeat the same test at least once after reconnecting.

A subscription provides and updates server information; it doesn’t fix DNS on your current network. Subscriptions come from your provider. A successful refresh of the server list doesn’t prove that the target website resolves correctly. If you changed the local configuration, check whether a future configuration update will overwrite the change.

Record the failing domain and exact error message. Note whether all sites are affected or only specific domains.
Record whether you’re on Wi-Fi or cellular, the Global Routing status, and the active configuration and server. Remove sensitive addresses and credentials before sharing this information.
Record the dns-server values before and after the change, and whether A and AAAA queries returned addresses.
Record the matched rule, policy, and final failure stage. Distinguish DNS, connection, TLS, and HTTP response issues.
Specify which single change affected the symptoms. Don’t share the full subscription URL, token, or password.

For help troubleshooting connection issues, see Troubleshooting. If you’re unsure what a keyword means, check the Glossary. Keeping a record of each single-variable test makes the issue easier to reproduce and diagnose than changing several settings in succession.