A latency result doesn’t confirm that a domain resolved or that a webpage connection succeeded. This guide is for users who have installed Shadowrocket and already have their own service provider and subscription. Check DNS, rules, and outbound connectivity separately, then retest the same URL on the same network. Change one setting at a time and keep a restorable copy of your configuration.
1. Tell latency, DNS, and webpage connectivity apart
A latency result in Shadowrocket only confirms that the specific test returned a result for its target and method. Server reachability, successful domain resolution, proxy authentication, and a response from the destination website are separate steps. One latency number cannot verify the entire connection path.
This sequence helps identify which part of the connection to investigate; it doesn’t mean every request is resolved locally first. Domain rules can match a hostname directly, while some proxy routes send the destination hostname to be handled remotely. Rules involving IP addresses, hostnames used by the server itself, and direct connections may still require the relevant DNS results.
In Home, make sure the connection is on and check the current Global Routing setting. Open an HTTPS page that normally works, then the page that’s failing. Note the full domain, network type, test time, and error message. If only one domain fails, check its rules first rather than replacing all DNS settings.
- “Server not found” in the browser: Check the domain spelling, DNS response, and any Host override.
- The page times out after waiting: DNS resolution may have timed out, or the connection or outbound route may have timed out. Check the logs to narrow it down.
- The page reports a certificate error: The request reached the TLS stage. Check the device time, certificate, and destination address; DNS may not be the cause.
- The page returns HTTP 403 or 503: An HTTP response was received. Check access restrictions or the website’s status instead of continuing to change DNS.
2. What DNS settings and ports mean
DNS translates domain names into addresses used for network connections. A records provide IPv4 addresses; AAAA records provide IPv6 addresses. Receiving an AAAA record doesn’t mean the current network has a usable IPv6 outbound route. Likewise, a domain with only an A record isn’t necessarily failing to resolve.
A port describes the transport method; it doesn’t guarantee reachability. The current network may not be able to reach a particular resolver. Encrypted DNS addresses that use a hostname also depend on how the resolver’s own hostname is resolved. Don’t use a regular DNS server’s IP as an arbitrary HTTPS address, and don’t enter a DNS query port in the proxy server’s port field.
| Setting | Purpose | What to check |
|---|---|---|
dns-server | DNS server settings in the configuration file. | In Config, open the active configuration and check whether this setting appears under General. Also check Settings → DNS. |
system | Uses the resolver provided by the system. | Retest on the current Wi-Fi or cellular network. DNS conditions can change when you switch networks. |
Host | Can map a specific domain to a fixed address. | Check whether the failing domain is mapped to an outdated address. A fixed mapping isn’t the same as a live DNS result. |
| A / AAAA | Returns IPv4 and IPv6 addresses separately. | Verify that an address was returned separately from whether it can be reached. |
Global settings in Settings and configuration options in Config may both affect behavior. Check the active configuration and actual logs rather than assuming a saved value on one screen is in effect. If the app’s interface groups change, look for the English labels DNS, Config, and General.
3. Retest in a consistent order and change one variable at a time
Save a copy of the current configuration and note the original Global Routing, DNS, and server selection. Use the same failing URL at every step below. If the page loads again, revisit it and check the logs before deciding whether to keep the change.
- Check the underlying network. Temporarily turn off the Shadowrocket connection and visit a page that normally loads. If Wi-Fi requires sign-in, complete that first. Then reconnect. Changing configuration won’t fix an upstream outage if the network itself is unavailable.
- Confirm the selected server. Return to Home and make sure the selected server belongs to your active subscription. If latency is normal but authentication, transport, or remote outbound access fails, ask your service provider to check the connection details and service status.
- Check the routing mode. In Home → Global Routing, note whether the current mode is Config, Proxy, Direct, or Scene. If you use Scene, confirm the settings that the scene applies so a scene change isn’t mistaken for a DNS change.
- Check the active DNS settings. Go to Settings → DNS and open the active configuration in Config. Check its DNS settings under General and any Host mappings. Change one setting at a time, then reconnect and retest.
- Compare networks. If cellular data is available, switch from Wi-Fi to cellular without changing the configuration or URL. If the page fails on only one network, check that network’s access to the resolver, any required sign-in, and outbound restrictions.
- Check automatic connections. If the connection turns back on after you disable it, check Settings → On Demand. Note and temporarily adjust the relevant conditions while troubleshooting, then restore your original On Demand settings.
4. Use Global Routing to distinguish rule issues from DNS issues
Config routes traffic according to the active configuration’s rules. Proxy and Direct provide routing modes to compare, while Scene follows its configured settings. Temporarily switching modes isn’t a permanent fix; it helps narrow down the cause. Restore your usual configuration after testing.
| Test result | What it may indicate | Next step |
|---|---|---|
| Config fails; Proxy works | The route selected by a rule or related DNS behavior may need investigation; this doesn’t prove the resolver is at fault. | Check which rule and policy match the failing domain, and whether traffic is going Direct or taking another specified route. |
| Direct works; Proxy fails | The proxy route may have an authentication, connection, or remote-resolution problem. | Check the selected server’s settings and determine whether the failure occurs during resolution or connection. |
| All three modes fail | The cause may be a shared factor: the underlying network, the domain itself, or DNS settings used across modes. | Compare with another network and check the domain and its Host mapping. |
| Only one domain fails | The issue is limited in scope and doesn’t show that all DNS requests are failing. | Check the domain’s rules, DNS response, and website status. |
DOMAIN-SUFFIX matches domain suffixes; IP-CIDR matches address ranges; GEOIP matches IP geolocation categories; FINAL is the fallback rule. Rules are evaluated in order, and the matching rule’s policy is applied. The examples below illustrate syntax only; they aren’t a replacement rule set for everyday use.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYexample.com and 192.0.2.0/24 are examples for illustrating syntax. In the example, no-resolve means not to trigger a domain lookup just to match that IP rule; it doesn’t mean resolution will never be needed for a later connection. Removing an IP rule or switching to global Proxy may change the route, but won’t automatically fix an incorrect domain record.
Bottom line: Identify the matched route before changing DNS
If the same domain works in Proxy but fails in Config, check the Config rules and policies first. Change the relevant DNS setting only after confirming a resolution timeout, no usable address, or an incorrect mapping. This avoids masking the original issue by changing the route.
5. Use the exact error to distinguish resolution from connection failures
Browser messages, app logs, and system errors may use different wording. The messages and codes below are examples you may see in a browser or Apple network error log; they aren’t fixed Shadowrocket messages. Note where the error appeared and check whether an address was resolved around the same time.
Error: ERR_NAME_NOT_RESOLVED
Cause: The browser didn’t get a usable result for the requested domain.
Fix: Check the domain spelling, current DNS settings, and Host mappings. Keep the routing mode unchanged and retest the same domain on another network.
Error: NSURLErrorDomain Code=-1003
Cause: In Apple URL loading errors, “cannot find host” means the specified host couldn’t be found.
Fix: Determine whether the unresolved hostname belongs to the destination website or the server, then check the relevant DNS settings. If NXDOMAIN is reported repeatedly, verify that the domain is valid instead of simply waiting longer.
Error: NSURLErrorDomain Code=-1001
Cause: The request timed out. This code alone doesn’t show whether the timeout occurred during DNS resolution.
Fix: Check whether an address and connection entry appeared before the timeout. If an address was returned, check outbound reachability first. If no result was returned, investigate the resolver route.
NXDOMAIN means the resolver returned that the name doesn’t exist. No response is a different condition and may be caused by packet loss, an unreachable resolver, or a timeout. Don’t describe both as “DNS blocked.” If an address was returned but the connection failed, also check the IPv6 route, proxy settings, and destination port. HTTPS commonly uses port 443, but use the port specified by your existing service.
6. Common questions and how to verify a fix
Why won’t webpages load if latency is always normal?
A latency test and a webpage request cover different parts of the connection. In Home, note the selected server and Global Routing mode, then request the failing domain in a browser. Check the resolution result, matching policy, and connection error separately instead of repeatedly testing latency.
The issue persists after changing DNS. Should I try another resolver?
First, make sure you changed the active setting. Check Config → the active configuration → General, and Settings → DNS. Reconnect and try again. If the logs show an address but the connection fails, stop switching resolvers and investigate the outbound route.
What if it fails on Wi-Fi but works on cellular?
Keep the same configuration and server, then check that Wi-Fi sign-in is complete and the resolver is reachable on that network. If you use system DNS, the resolver changes with the network, so the two networks don’t have the same DNS conditions.
Can updating a subscription fix DNS?
Subscription updates generally refresh server entries; that alone doesn’t mean local DNS settings have been fixed. Update your existing subscription only if your service provider confirms that the server address or connection settings have changed, and follow their instructions. Then check which entry is selected.
Once the page loads again, restore your original Global Routing mode and any required On Demand conditions, then test the failing page and a frequently used page. Compare the logs before and after the change to make sure the fix wasn’t caused by a temporary network or rule change. To start a fresh browser request, close the failing tab and open it again; this doesn’t clear all system DNS caches.
- Record the changes you keep: the setting, its old and new values, and the URL used to verify it.
- Make sure the expected Config is active and that Host has no fixed mappings left over from testing.
- Confirm your regular rules still route traffic as expected instead of leaving the app in a temporary test mode.
- If the issue persists, share redacted logs and network comparison results with your service provider. See Troubleshooting for more steps.