A latency reading in Shadowrocket (Shadowrocket) doesn’t mean the destination domain resolved successfully. This guide assumes you already have your own service provider and subscription and can view your current configuration. It walks through checks for your network, Global Routing, DNS, rules, and connection logs. Change one setting at a time and retest the same failing URL to distinguish DNS failures from connection timeouts and TLS errors.
1. A successful latency test doesn’t mean websites will load
Loading a webpage involves several steps. The client first resolves the domain to an address, then selects a connection path based on its configuration, establishes a transport connection and TLS session, and finally requests the page. Resolution may happen locally or remotely. A failure at any stage can leave the browser waiting.
Connectivity Test on Home reports the result of the selected test method. Its target and protocol may differ from those used to load a webpage. A returned value doesn’t prove that every domain, port, or request is reachable.
For example, a test might report 80 ms while the browser says it can’t find the server. That number records only the result of that test; it doesn’t tell you whether the failing domain resolved. Note the domain in the URL, the exact error, and when it occurred instead of repeatedly comparing latency figures.
- Only one website fails: Check the domain spelling, its DNS result, and which rule it matches.
- Several unrelated websites fail: Start with the network connection and shared configuration.
- The page loads but images don’t: Check the domains requested by the images or scripts, not just the domain in the address bar.
- You get an HTTP
403or502: An HTTP service returned a response. Investigate its source rather than assuming the problem is DNS.
2. Check Home and Global Routing before changing DNS
First, make sure the device can access the current network. Complete any required Wi-Fi sign-in. Then open Home and check the connection switch, selected server, and Global Routing. Selecting a server and establishing a connection are separate states.
- Note whether you’re on Wi-Fi or cellular, and keep one URL that consistently fails for retesting.
- Check the connection status on Home. If it still says
Not Connected, troubleshoot the connection first; don’t treat the failure as a DNS issue in the configuration. - Go to Home → Global Routing and note the current selection. In particular, check whether it’s set to
Direct. - Run Connectivity Test once and record the method and result, then open the same URL that failed.
- To compare routing modes, note the original setting, switch it temporarily, and run one test. Restore it afterward. Don’t change DNS, the server, and rules at the same time.
| Mode | What to check |
|---|---|
Proxy | Use this to observe behavior over a proxy route. It doesn’t mean all DNS requests necessarily use the same resolution path. |
Direct | Traffic connects directly. If you expected to use a proxy, correct the mode first. |
Config | Traffic follows the rules in the current configuration. Check which rule and policy match the failing domain. |
Scene | Routing follows the configured scene. Check the active scene, not just the selected server. |
Tip: Compare modes to narrow down the cause
If the same website opens with Proxy but fails with Config on the same network and server, check the rules and configuration-related DNS path next. Don’t immediately replace all your connection details.
3. What the DNS settings do
DNS translates domain names into addresses. An A record provides an IPv4 address, while an AAAA record provides an IPv6 address. Getting an address means resolution returned a result; it doesn’t mean the device can reach that address. If a connection still fails after an AAAA record is returned, distinguish between “an IPv6 address was returned” and “IPv6 connectivity works.”
Check the relevant options under Settings → DNS, and review the configuration file currently in use under Config. Global settings and the configuration file can both affect behavior. Don’t assume a file is active just because you can see it in the editor. The table below explains the options; you don’t need to change every setting to a custom value.
| Setting | What it does | What to check |
|---|---|---|
| System DNS | Uses the DNS settings provided by the current system network. | DNS behavior may change when you switch between Wi-Fi and cellular. |
| Custom DNS | Specifies DNS servers. | A valid server address doesn’t guarantee it’s reachable on the current network. |
| DNS over HTTPS | DNS over HTTPS (DoH) | Sends DNS queries over HTTPS. |
| DNS over TLS | DNS over TLS (DoT) | Sends DNS queries over TLS, usually on TCP port 853. Network restrictions may differ from those affecting standard DNS. |
[Host] | Host mapping | An outdated address may still be in use. Check whether the failing domain has a manual mapping. |
Traditional DNS usually uses UDP port 53 and may also use TCP port 53 in some situations. Encryption changes the query transport; it doesn’t fix a website outage, an incorrect rule, or an unreachable address. Don’t enter several DNS addresses from unknown sources just to “encrypt” DNS.
To compare against system DNS, first back up your existing configuration. Then edit a test copy under Config and check dns-server in its existing [General] section. The example below shows only the relevant field; it isn’t a complete configuration and shouldn’t replace other sections in the original file.
[General]
dns-server = systemIf a [General] section already exists, edit the relevant field rather than adding duplicate sections. After saving, make sure the test copy is active, reconnect, and retest. If you also have a custom DNS setting, record it so you don’t mistake changes to two variables for a single result.
4. Troubleshoot one variable at a time
The goal is to identify which layer changes the outcome. First save a copy of your configuration and note the current settings. Then follow the steps below in order, using the same failing domain each time so your results are comparable.
- Check how many sites are affected. Open two sites that usually work, then the failing one. Note whether all sites fail, only one site fails, or only static resources fail.
- Switch networks. If possible, compare Wi-Fi and cellular with the same configuration. If the issue occurs on only one network, check its sign-in status, DNS reachability, and access restrictions.
- Confirm which configuration is active. Check the active file in Config and the mode under Home → Global Routing. Editing a file doesn’t mean it’s the one currently in use.
- Compare DNS sources. Record the current value, then temporarily compare system DNS with your existing custom DNS. If the result changes, check whether the DNS server is reachable and whether it returns a different address.
- Check host mappings and rules. Search the active configuration for the failing domain and its parent domains. Check
[Host]and[Rule]as well; a broader rule may match first. - Reconnect and retest. After saving your settings, disconnect and reconnect, then reload the page. Apps may keep old connections or cached data, so close and reopen the relevant app if needed.
- Undo changes that don’t help. If a step makes no difference, restore the original setting so you don’t end up with several unexplained changes.
Don’t use entering a website’s IP address directly in the browser as your only DNS test. HTTPS uses the domain for certificate validation and site selection. Visiting an IP directly may cause a certificate error or open a different site, even when DNS is working correctly.
If the connection automatically comes back in the background, also check Settings → On Demand. On Demand controls when connections start; it doesn’t resolve domain names. When comparing results while disconnected, note whether it’s enabled so an automatic reconnection isn’t mistaken for a direct-connection result.
5. Tell DNS errors, timeouts, and rule matches apart
The exact error is more useful than simply saying a site won’t load. The messages below are English descriptions that Apple’s networking framework may provide; a browser or Shadowrocket may not show them verbatim in every view. If a log includes an error domain and code, record those along with the message.
Error: A server with the specified hostname could not be found.
Cause and fix: NSURLErrorDomain -1003 means the specified host couldn’t be found. First check the domain spelling, then check its DNS result, DNS server reachability, and any host mapping.
Error: The request timed out.
Cause and fix: NSURLErrorDomain -1001 means the request timed out, but that alone doesn’t prove DNS failed. Check in order whether resolution, connection establishment, or the server response is where the request stalls.
Error: A server with the specified hostname could not be found.
Cause and fix: If the error refers to the hostname of a custom encrypted DNS service, the initial lookup for the DNS service itself may be failing. Note the service address and compare it with system DNS instead of changing rules for the destination website.
Error: An SSL error has occurred and a secure connection to the server cannot be made.
Cause and fix: NSURLErrorDomain -1200 indicates that a secure connection couldn’t be established. Check the device’s date and time, the destination host, and certificate details. Don’t hide the problem by disabling certificate validation.
Rules can also affect what happens in Config mode. Rules are generally evaluated from top to bottom, and the matching rule determines the policy. The examples below use reserved example domains to illustrate rule order. They’re for reference only, not a complete configuration to paste in.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,DIRECTmatchesexample.comand its subdomains. When this rule appears first, a later FINAL rule won’t determine the policy for those requests.IP-CIDRmatches an IP address range.192.0.2.0/24is a documentation range, not an address range for a service you need to add.no-resolvemeans this IP rule won’t trigger a domain lookup to match it. It doesn’t mean the request will never need DNS.GEOIPmatches based on IP geolocation data, not the language a website uses or its domain suffix.FINAL,PROXYis the fallback when no earlier rule matches. Also check which outbound connection PROXY uses.
Tip: If DNS returned an address, check the connection stage next
If the log shows a destination address followed by a connection timeout, check the matching policy, destination port, and outbound route first. Don’t keep changing DNS just because the page won’t load.
6. Frequently asked questions and what to include in a report
Connectivity Test shows a result. Why won’t Safari load the page?
First, note the test method on Home, then check Home → Global Routing. The test and webpage may connect to different destinations. Check the DNS result and matching policy for the same failing URL; one latency reading doesn’t prove that every site is reachable.
It works on cellular. Do I need to change all my DNS settings?
Keep the configuration unchanged and reproduce the difference once. Check whether the Wi-Fi network requires sign-in and whether the current DNS service is reachable on that network. Change the relevant setting only after confirming that the DNS source affects the result.
I changed DNS, but the old result still appears. What should I do?
First confirm that Config is using the configuration you edited, then reconnect and reload the page. Check Settings → DNS and the configuration’s [Host] section for any remaining manual settings. Don’t keep adding duplicate dns-server fields.
Only subscription updates fail. Does that mean it’s DNS?
No. Subscription requests can also be affected by link validity, authentication, and the server’s response. Record the exact error and ask your own service provider to confirm that your existing subscription is still valid. Don’t share the full subscription URL in your troubleshooting notes.
If you need further help, gather the information below. Clear steps to reproduce the issue are more useful than an entire unredacted configuration. Hide subscription credentials, passwords, private keys, and complete access tokens.
- The failing domain, when the issue occurred, and the exact error shown by the webpage.
- Whether the device was on Wi-Fi or cellular, and whether switching networks changed the behavior.
- The connection status on Home, the Global Routing selection, and the Connectivity Test method and result.
- The name of the active configuration, relevant DNS fields, and whether there’s a matching [Host] entry.
- Relevant rules and their order, plus any destination address, matching policy, or connection error shown in the logs.
- Each individual change you tried, its result, and which settings you restored.
Shadowrocket is a closed-source commercial app for iPhone and iPad, available exclusively on the App Store. Purchasing the app and having a connection service are separate; the one-time purchase doesn’t include your own connection service. Check the App Store listing for system requirements.