Turning on Shadowrocket’s connection only starts the connection process on your device. It does not confirm that the remote server, DNS resolution, or policies for individual requests are working. This guide assumes you already have a service provider and subscription. Starting with your basic network connection, it checks the server, Global Routing, DNS, and rules one at a time. Change only one setting per test, and verify the result using the same webpage and request logs.
Establish a baseline: Can you browse with Shadowrocket disconnected?
Don’t delete your subscription or reinstall the app yet. First check whether the problem only occurs when Shadowrocket is connected. If you still can’t open webpages that normally work without a proxy when disconnected, troubleshoot your network connection, Wi-Fi sign-in, or system network permissions first. The connection icon is no substitute for this check.
-
Note your current settings
Record the server selected in Home, the Global Routing option, and the configuration currently in use in Config. Keep a copy of your existing configuration. Do not include passwords, full subscription URLs, or authentication details in your notes.
-
Disconnect
Disconnect from Home, then use Safari to open an HTTPS webpage that normally works without a proxy. If it still fails, check whether Wi-Fi requires a sign-in and whether cellular data works before continuing with in-app troubleshooting.
-
Choose test websites
Pick one webpage that works without a proxy and one that normally requires a proxy. Use the same URLs throughout testing, and retry each one after every change. Don’t compare results from different websites.
-
Pause automatic connection
If the connection turns back on after you disconnect manually, check Settings → On Demand. Note the current setting, then temporarily turn off On Demand. Restore it after testing so automatic connections don’t affect your results.
Distinguish between a webpage that won’t load and a specific feature in an app that fails. A single site may be experiencing an outage. If webpages load but video or calls don’t work, check whether the affected traffic uses UDP before concluding that the entire connection is down.
Step 1: Check server connectivity and authentication details
Go to Home, confirm that the server you want to test is selected, then run Connectivity Test. Check first for repeated timeouts, then see whether responses are consistent. A successful test only shows that the test’s route or target is reachable; it doesn’t guarantee that every website, UDP traffic, or server authentication will work. A low latency reading also doesn’t guarantee that webpages will load.
Open the selected server’s edit screen and compare its address, port, and authentication details with the original information from your provider. Shadowsocks encryption methods and passwords, VMess or VLESS identity parameters, Trojan passwords, and server names and transport parameters for TLS are not interchangeable. Don’t change the server port to 443 just because webpages commonly use that port.
- All server tests fail: Compare with your disconnected network baseline, then check your subscription status, account validity, and whether the server address has changed.
- Only one server fails: Try another known-working server from your existing list. If that works, focus on the original server instead of rewriting all your rules.
- The test succeeds but the service still fails: Check Global Routing and DNS next. Also confirm whether the test covers only TCP while the service relies on UDP.
- The problem started after a subscription update: Compare server addresses and protocol parameters before and after the update. A successful refresh only means the data was retrieved; it doesn’t mean every server in it is working.
Bottom line: Isolate the server first
If access works after switching to another server you already have, while keeping the same network, webpage, and Global Routing option, check the original server’s status and settings first. Don’t change DNS and FINAL at the same time.
Step 2: Use Global Routing to distinguish mode and rule issues
Check the current option in Home → Global Routing. Proxy, Direct, Config, and Scene are not protocols; they’re different ways to decide how traffic is handled. Switch temporarily for diagnosis, then restore your usual setting. In particular, a successful Proxy test doesn’t prove that all your routing rules are correct.
| Option | What it does | What to check |
|---|---|---|
| Proxy | Routes traffic through a proxy; bypass settings still need to be checked separately | Can the selected server handle the request? |
| Direct | Routes traffic directly | Can the target be reached over your current network without a proxy? |
| Config | Uses rules in the current configuration to decide how requests are routed | Which rule matched, and which policy was ultimately used? |
| Scene | Routes traffic according to the configured scene | What settings the current scene actually uses—not just its name |
Note your original option, then temporarily select Proxy and retry the same webpage that failed. If Proxy works but Config doesn’t, check the current configuration and rule matches first, while keeping in mind that the DNS route may differ between modes. If both fail, check the server and DNS before focusing on rules.
Step 3: Check DNS resolution and reachability
DNS resolution happens during a request, and DNS failures can look like server connection failures: the webpage just keeps loading. Check the request logs to see whether the failure occurred during DNS resolution or after an address was returned, when connecting to the destination. Don’t assume it’s a DNS issue based only on Safari’s generic error message.
In Config, open the configuration currently in use and check for [General] and dns-server in the text. If you entered a resolver manually, verify that its address is correct, reachable on your current network, and not dependent on a proxy connection that hasn’t been established. Don’t layer several unfamiliar DNS settings on top of each other. Restore a copy of a previously working configuration first, then test one change at a time.
- No address returned for the domain: Check DNS reachability, the address, and the resolver settings in your current configuration.
- An address was returned, but the connection times out: Check the route to the destination, server status, and rule policy. Changing resolvers alone may not help.
- Only one domain fails: Check the domain itself, related rules, and whether the site depends on other resource domains.
- The problem started after switching networks: Test on both Wi-Fi and cellular to see whether the current network blocks access to the resolver or server.
Error: Could not resolve host
Cause and fix: This commonly indicates a domain resolution failure, though the exact wording depends on the diagnostic tool. Check the domain and DNS configuration first, then see whether the resolver is reachable on your current network. Don’t change server authentication details right away.
Error: Connection timed out
Cause and fix: The connection did not complete within the time allowed. The failure could be on the server or destination route. Check the failed target and port in the logs, then test another server you already have on the same network to distinguish a server-specific failure from a broader network issue.
Error: Connection refused
Cause and fix: The destination or an intermediate device typically refused the connection. Check whether the logs point to the proxy server or destination website, then verify the relevant port and service status. Reloading the webpage won’t fix an incorrect port.
Step 4: Check rule order, policy references, and FINAL
When Global Routing is set to Config, the current configuration’s rules determine how requests are routed. First, confirm the selected file in Config, then check [Rule]. Rules are generally evaluated from top to bottom; once a request matches an earlier rule, later, more specific rules are not considered. A rule can be correct but still cause access problems if it’s in the wrong place.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis example illustrates syntax; it is not a general-purpose replacement for your existing configuration. example.com is a sample domain. PROXY must refer to a policy or policy group that exists and works in your current configuration; copying the name without defining it won’t work. The actual effect of FINAL,PROXY also depends on which server that policy ultimately selects.
| Keyword | What it matches | What to check |
|---|---|---|
| DOMAIN-SUFFIX | A domain and its subdomains | Whether an earlier, broader rule takes precedence and whether resource domains are missing |
| IP-CIDR | A destination IP range | Whether the network range and mask are correct, and whether no-resolve is appropriate |
| GEOIP | The geographic database entry for a destination IP | Check the resolved IP in the database rather than inferring its location from the brand’s headquarters |
| FINAL | Fallback when no earlier rule matches | Whether it’s at the end and whether the referenced policy exists and works |
no-resolve avoids triggering an additional domain lookup to match the IP rule; it doesn’t turn off DNS across the app. REJECT blocks matching requests. If the main page loads but images or login APIs fail, check whether those resource domains matched a reject rule instead of deleting all your rules.
Bottom line: Adjust rules based on match logs
Move or edit a rule only after confirming that the failed request matched the wrong policy. If the request never reached FINAL, changing FINAL won’t fix it. If it matched the expected proxy policy, trace which server that policy actually selected.
Common questions: Some things still fail after a successful test
Why won’t webpages load if Connectivity Test succeeds?
The test and webpage may use different targets, and the test may not cover authentication, TLS, DNS, or every connection the webpage needs. Temporarily select Proxy in Home → Global Routing and retry, then check whether the failed request stopped at DNS resolution, connection, or policy selection.
Proxy works, but Config fails. What should I check first?
First confirm which file is selected in Config, then check the failed request’s rule match and policy group selection. See whether it went through DIRECT, matched REJECT, or referenced an unavailable policy. Keep in mind that the DNS route may differ; don’t send every request through the same policy as a quick fix.
Wi-Fi works, but cellular doesn’t. Does that mean the protocol isn’t supported?
Retry using the same server and URL, and check cellular data permissions, Settings → On Demand, and Scene settings. Different networks may handle ports or UDP differently. One failed test doesn’t prove that the protocol itself is unsupported.
Webpages work, but calls or video don’t. What should I check?
Check whether the service uses UDP, then confirm that the current protocol, server, and service permissions support the required forwarding. Hysteria2 relies on UDP for transport. UDP support in other protocols also depends on the server configuration; the protocol name alone isn’t enough to tell.
Does a successful subscription update rule out a service issue?
No. A successful update only confirms that the subscription data could be retrieved and processed. Go to Home and check the current server’s address, authentication details, and connectivity. If you need to contact your provider, share the error stage, network type, and reproduction steps with sensitive details removed.
Wrap up: Restore settings and keep reproducible notes
Once you’ve found the problem, keep only changes you’ve verified are necessary. Turn On Demand back on if you disabled it temporarily, restore your usual Global Routing option, and test both a basic webpage and the original failing destination. If the problem only occurs on one network or server, note that condition rather than generalizing it to the whole app.
- Record the environment: Wi-Fi or cellular, whether you completed network sign-in, and whether basic webpages worked while disconnected.
- Record your selections: The server’s custom name, Global Routing option, and Config file name. Don’t record passwords or subscription credentials.
- Record the failure stage: DNS resolution failure, connection timeout, authentication failure, or an unexpected policy match. Keep the original error message with sensitive details removed.
- Record your changes: What single setting you changed, whether the same target worked afterward, and whether the problem returned when you restored the original setting.
To check individual configuration fields, see the configuration field reference. If you’re importing a configuration for the first time or aren’t sure where the current one came from, follow Getting Started to confirm the steps. Buying the app does not include a service plan; check the app purchase and the validity of your existing service separately.