A normal latency result in Shadowrocket doesn’t prove that the full path to a website is working. If you already have a provider and subscription, keep the network, URL, and outbound entry fixed, then check DNS resolution, Global Routing, and connection errors. This guide follows a reproducible sequence to distinguish DNS failures, rule mismatches, and outbound connection failures. Change one setting at a time so repeated DNS changes don’t hide the actual cause.
1. Normal latency only means the tested part of the connection responded
Loading a webpage involves DNS resolution, establishing a connection, a TLS handshake, and a content request. DNS maps a domain name to an IP address, but the connection can still fail because of the destination port, network path, certificate, or server status. Latency tests use different targets and methods, so they cover different parts of the process. A single result in milliseconds cannot tell you whether a webpage will load.
This sequence helps narrow down a problem; it doesn’t mean every request follows the same order. A domain rule may match before an IP address is obtained, and some outbound methods may resolve the domain remotely. Check the active configuration and request records rather than assuming every domain is resolved by the same DNS server.
- Server address is reachable: This only shows that the address and port tested responded. It doesn’t mean every website will be reachable.
- A test website loads: This only shows that the specific site was available at that time. Other domains may match different rules or use a different address family.
- A webpage keeps loading: The delay could be DNS, the connection, the handshake, or a timed-out page resource. Check the error before drawing a conclusion.
2. Understand the DNS settings: a port is not a resolver
In Config, confirm which configuration is selected, then check its DNS settings. The [General] section of a configuration file may include dns-server; system means the system DNS resolver is used. If the configuration already specifies another resolver, save its current value before making changes. Don’t overwrite the entire section.
[General]
dns-server = systemThis example is only for identifying the field. It isn’t a complete configuration or a recommendation to switch every network to system. System DNS depends on the network you’re connected to; a custom DNS resolver must be reachable at its specified address and over its transport. Encrypted DNS protects queries in transit, but it doesn’t guarantee a connection to the destination website.
These are standard protocol ports, not values to enter one by one on the Add Server screen. The outbound server’s Port must match the details provided by your service provider. DoH uses an HTTPS request URL; a string containing only an IP address is not a complete DoH URL.
Bottom line: check the resolution result before changing DNS
If the same request has already obtained the destination IP and then times out while connecting, check the outbound path and destination port first. Continue investigating DNS only when there is evidence such as a failed query, an unexpected address, or a difference between address families.
3. Keep a reproducible troubleshooting record in five steps
Choose a URL you can normally access and use to reproduce the problem reliably. Record the full domain, test time, network, and exact error text. Don’t change the network, outbound entry, DNS, and rules at the same time. Even if the page starts working, you won’t know which change made a difference.
- Confirm that network access is complete. On a trusted network, complete any required web authentication. Record the results with the connection switch off and on. This comparison helps narrow down the problem; it doesn’t mean every destination must work in both states.
- Check the current outbound entry. Return to Home and confirm the connection switch and selected entry. If the entry comes from a Subscribe link, get that link from your service provider. Check the subscription status and entry parameters; a successful update doesn’t prove the server is reachable.
- Record the routing mode. Go to Home → Global Routing and note whether Config, Proxy, Direct, or Scene is selected. For Scene, also check its activation conditions; don’t infer the actual route from its name alone.
- Make one request under the same conditions. Visit the same URL and check the available request records or logs for the domain, resolved address, matched rule, outbound policy, and error text. Mark any unrecorded field as unknown rather than guessing.
- Change one setting, then test again. For example, keep everything else fixed and compare Config with Proxy, or the current DNS setting with a resolver you’ve confirmed is reachable. Record each result. If there’s no improvement, restore the original setting before testing the next hypothesis.
4. Distinguish DNS, connection, and certificate errors
The examples below are common error snippets from network logs, but they may not appear exactly this way in every interface. The same problem may show up as a browser message, a brief error in a request record, or a lower-level log entry. Identify the domain associated with the error: it may belong to the destination website, the outbound server, or a DNS endpoint.
Error: no such host
Cause: The current lookup couldn’t find the required host address, or the domain name may be misspelled.
Fix: Check the domain shown in the error, then verify that the current DNS resolver is reachable. If it’s the outbound server’s domain, fix its resolution first instead of changing rules for the destination website.
Error: i/o timeout
Cause: A network read or write exceeded its time limit. This can happen during a DNS query, while establishing a connection, or during later data transfer.
Fix: Check the address and operation stage shown before the error. For a query timeout, check the resolver path. For a connection timeout, check the outbound address, Port, and current network.
Error: connection refused
Cause: The connection attempt received a refusal. This commonly happens when no service is listening on the destination port or a network device actively rejects the connection.
Fix: Determine whether the refusal came from the website or the outbound server, then check the relevant port. If the outbound settings came from your service provider, ask them to confirm the service status.
Error: certificate has expired or is not yet valid
Cause: The certificate’s validity period doesn’t match the current time. The issue may involve the device clock, the website certificate, or the outbound TLS endpoint.
Fix: Check the system date and time, then identify the domain associated with the error. Keep certificate verification enabled; disabling it isn’t a fix.
If a website returns HTTP 403 or HTTP 404, the request usually reached an HTTP service. Don’t treat that response as a simple DNS lookup failure. Check whether the destination address is correct, the website’s access requirements, and the server status. If you suspect DNS resolved to the wrong service, check the returned address.
5. If resolution succeeds, check rules and the IPv6 path
In Config mode, requests are affected by the rules in the active configuration. DOMAIN-SUFFIX matches domain suffixes, while IP-CIDR matches IP address ranges. GEOIP rules depend on the IP address, and FINAL is the catch-all rule at the end. A successful DNS lookup doesn’t guarantee that a request uses the outbound route you expect.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXYThis only illustrates rule order: example.com and its subdomains match DIRECT, while all other requests fall through to FINAL and use the PROXY policy. It isn’t a complete configuration or a recommended rule set for everyone. If an earlier REJECT rule matches a domain, changing DNS usually won’t change that match.
| What you see | Check first | Next step |
|---|---|---|
| Proxy works, but Config doesn’t | Rules, policies, and related overrides in the active configuration | Check which rule matches the domain and which outbound route is used. Don’t assume DNS is the cause. |
| The same configuration behaves differently on different networks | Network authentication, resolver reachability, UDP, and address-family paths | Keep the URL and outbound entry fixed. Switch only the network and record the difference. |
| A and AAAA records are returned, but some connections time out | Actual IPv4 and IPv6 reachability | Check the address family used by the failed connection, then compare one variable at a time. |
| The main page loads, but images or sign-in fail | Resource subdomains, their rules, resolution, and outbound routes | Record the domain of each failed resource and check it individually; don’t test only the main site’s domain. |
A records provide IPv4 addresses, and AAAA records provide IPv6 addresses. A valid AAAA response doesn’t guarantee that the current network has a working IPv6 path. Likewise, an IPv6 address in the results doesn’t prove that IPv6 caused the problem. Check the relevant IPv6 settings only if comparisons point to an address-family difference, and make sure you can restore the original settings.
Caching is another easy-to-miss factor. Browsers, the system, and intermediate resolvers may retain results, so refreshing once after a DNS change doesn’t necessarily trigger a new query. Try reconnecting and reopening the page, then check the new request records. Don’t start by clearing all browsing data.
6. Common questions and recovery checks
Why check the outbound connection if latency is only a few dozen milliseconds?
A latency result doesn’t cover the complete request to every website. Return to Home, confirm the selected entry, and check the connection stage for the failed URL. The test target can be reachable while port 443 on the destination website is not.
Can I confirm a DNS problem by replacing the domain in the URL with its IP address?
Not reliably. HTTPS uses the domain for certificate verification and virtual host selection. Visiting an IP address directly may show a certificate error or a different website. Check the DNS and connection records instead of treating a failed IP visit as proof of a DNS problem.
The site still won’t load after changing DNS. Should I keep trying other DNS servers?
First check whether an address was returned. If the request timed out after getting an address, restore the original DNS setting and check Global Routing, the actual outbound route, and the Port. If the query itself timed out, check the resolver’s transport path.
Only subscription updates fail, but websites load. Should I change DNS?
First distinguish a DNS lookup failure for the subscription domain from an HTTP status error. Get the link from your service provider and check that it was copied in full and is still valid. Websites loading doesn’t prove the subscription URL works, but it also doesn’t prove that DNS is generally broken.
After recovery, return to the Config and policy you normally use, restore the original On Demand conditions, then test the main page and essential resources such as images and sign-in. If the site works only after temporarily switching to Proxy, continue fixing the rules. Don’t treat a temporary comparison as proof that DNS was the cause.
- Keep a backup of a verified working configuration and record the one setting you ultimately changed.
- When contacting your service provider, include the time, network type, protocol, destination domain, and exact error text.
- Before sharing logs, redact subscription tokens, UUIDs, passwords, and other credentials. There’s no need to share the full subscription URL.