Turning on Shadowrocket’s connection switch starts the local connection feature; it does not confirm that the remote server, DNS, or destination website is working. This guide is for users with their own service and configuration who can’t access the internet after connecting. Start with consistent test conditions, then check the server, Global Routing, DNS, and rules in turn. Change one variable at a time, retest the same destination, and record the results.
Before troubleshooting: distinguish the local connection from remote availability
A VPN indicator in the status bar does not, by itself, prove that the proxy server has authenticated or that web requests are using the expected route. Loading a webpage involves DNS resolution, route selection, a remote connection, and a response from the website. A failure at any stage can leave the browser waiting. Avoid updating a subscription, changing DNS, and rewriting Config all at once after the first timeout; otherwise, it’s hard to tell which change helped.
Choose a familiar HTTPS page that normally loads as a control, then choose the page that’s failing. Record its full domain, whether you’re on Wi-Fi or cellular, the selected server, and the Global Routing mode. This guide does not provide connection services; the steps below assume you already have your own server or subscription.
- It also fails with the connection off: Check the device’s basic network connection first. If the Wi-Fi network requires sign-in, complete that step before testing the proxy.
- It works with the connection off but everything fails when it’s on: Check server reachability, authentication details, and the current routing mode first.
- Only a few domains fail: Keep a note of the exact domains and focus on DNS results and the rules matched by those requests.
- The connection turns back on after you switch it off: Check
Settings → On Demand. You can temporarily turn off On Demand while troubleshooting, then restore the original setting to avoid automatic connections affecting your comparison.
Step 1: Check server connectivity and connection settings
In Home, confirm which server is selected, then use Home’s Connectivity Test to check its reachability. The result reflects only the test destination and method: a latency reading doesn’t mean every website is accessible, and a timeout doesn’t necessarily mean your account is invalid. Assess the result alongside an actual webpage request. A latency result alone doesn’t prove that authentication, TLS, and access to the service all succeeded.
-
Confirm the selected server
Open Home and check the name of the selected server. Open its edit screen and verify that the address, port, protocol, and authentication details match the information from your service provider. Entries with similar labels may use different addresses, so don’t rely on the display name alone.
-
Run a test
Use Connectivity Test in Home and record the result for the selected server, then open the same test webpage. Record “test responds but webpage fails” separately from “both the test and webpage fail”; the next steps differ.
-
Switch networks
Keep the server and configuration unchanged. Switch between Wi-Fi and cellular, then repeat the test. If the issue occurs on only one network, first check its sign-in requirements, outbound restrictions, and UDP reachability rather than changing every protocol setting.
-
Check the original configuration
If your service provider has announced an address or credential change, update your existing subscription and select the server again. Confirm that the update succeeded. A failed subscription update and a failed connection to an existing server are separate issues; repeatedly deleting configurations is no substitute for checking them.
Required fields vary by protocol. For Shadowsocks, the encryption method and password must match. VMess and VLESS identity fields and transport settings must match the server; Trojan’s password and TLS settings must also match. With Hysteria2 and WireGuard, check whether the current network supports UDP. Don’t change the protocol name at random when a connection fails; the server must support the configuration you select.
Error: connection refused
Cause: The destination or an intermediate device explicitly refused the connection. Common causes include no service listening on the port or access being denied.
What to do: Check the server address, port, and transport type. If they match your original configuration, ask your service provider whether that endpoint is still running. Don’t change the device’s DNS without a reason.
Error: i/o timeout
Cause: A network read or write exceeded its time limit. The issue could involve the local network, remote reachability, or the protocol handshake; this message alone doesn’t identify the failing stage.
What to do: Keep the surrounding error context, retry on a different network with the same server, and use the specific failure stage to guide your checks. Don’t assume a timeout means the password is wrong.
Error: no such host
Cause: The current lookup did not return an address for the host. First determine whether the host in the error is the server’s domain or the website you’re trying to visit.
What to do: Check the domain spelling and DNS availability. If the server’s domain can’t be resolved, restore basic DNS resolution first; you can’t rely on a proxy that isn’t connected to handle every prerequisite.
These are common excerpts from network errors; the actual message may also include an address, port, or more complete system details. Use the full error context when troubleshooting. For certificate verification errors, check the device date, server domain, and TLS settings. Disabling certificate verification is not a routine fix.
Step 2: Use Global Routing to separate proxy issues from rule issues
Go to Home → Global Routing and note the current mode. Proxy, Direct, Config, and Scene are routing methods, not connection quality levels. Proxy tests the proxy route; Direct tests a direct connection; Config follows the active configuration’s rules; Scene uses the settings for the selected scene. Don’t guess what’s happening in Scene mode: confirm which scene and configuration are active, or temporarily switch to a mode you can compare directly.
| Test mode | What you see | Next step |
|---|---|---|
| Proxy | The same webpage still fails | Continue checking the server, DNS, or website itself; don’t rewrite the rules yet. |
| Direct | Regular webpages work, but Proxy fails | Focus on the proxy route. A successful direct connection doesn’t prove the server is working. |
| Config | Proxy works, but Config fails | Check the active configuration, rule order, and the policy applied to the request. |
| Scene | Results differ after switching networks | Check which routing settings the active scene selects. Set a fixed mode before retesting. |
Bottom line: check Config after Proxy works
If the same webpage works in Proxy but fails in Config on the same network and server, leave the server settings unchanged and check the active configuration and request records. This helps avoid treating a rule issue as a server failure.
After changing modes, make a new webpage request each time. If needed, disconnect and reconnect to reduce the effect of reused connections. Restore your usual mode after testing. Proxy is a comparison tool, not a permanent fix for every webpage that won’t load.
Step 3: Tell DNS failures apart from connection failures
DNS translates domain names into addresses. If resolution fails, the next connection usually can’t start. But getting an address only confirms that DNS returned a result; it doesn’t prove the address is reachable or that the certificate is valid. Open DNS settings in Settings, note the current configuration, and identify whether you’re using system DNS, custom DNS, or DNS over HTTPS. Check each setting against the configuration you already have.
These are common default protocol ports; they are not a recommendation to change your server port to 53 or 443. Custom DNS requires the device to reach the specified resolver. DNS over HTTPS also requires the corresponding HTTPS service to be reachable. If the DNS service itself uses a domain name, that name may need to be resolved first. Encrypted DNS does not automatically resolve every prerequisite connection issue.
- No domains resolve: First check that the DNS address is entered correctly and compare against the working settings you had before making changes. Also confirm that the device’s basic network connection works.
- Only one domain fails: Check for a typo and whether the issue affects only a particular subdomain. Keep the specific lookup result; don’t replace all your DNS settings right away.
- An address is returned, but the connection times out: Continue by checking the route to that address and the remote connection. This is no longer just a question of whether DNS returned a result.
- The change seems to make no difference: Save the settings, reconnect, and make a new request. Existing connections or app caches may continue using an earlier result.
Step 4: Check Config and the rules actually matched
Once the server and DNS are working, open Config and check which configuration is active. Editing a file doesn’t mean the connection is using it. Confirm the selected configuration, then check the order of rules in [Rule]. Rules are generally matched from top to bottom, and the matching rule’s policy is applied. Put FINAL after specific rules.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTThis minimal example sends example.com and its subdomains to PROXY, and all other requests to DIRECT. It illustrates how matching works; it isn’t a complete configuration for every user and won’t create a working server. If the destination page also requests other domains, those requests may not match the first rule. If the main page loads but images, sign-in, or API requests fail, check the specific failed requests rather than only the main domain in the address bar.
- DOMAIN-SUFFIX: Matches the domain itself and its subdomains, not any string that happens to contain it. First check that the actual request domain ends with the suffix in the rule.
- IP-CIDR: Matches an IP address range, for example
IP-CIDR,192.168.0.0/16,DIRECT. This matches an address range, not a domain suffix. - GEOIP: Matches the geographic database classification of an IP address, for example
GEOIP,CN,DIRECT. Results depend on the resolved address and the database; they don’t indicate a website’s language or where its operator is based. - FINAL: Applies to requests that did not match an earlier rule. If you move
FINAL,DIRECTup, the specific proxy rules below it will never be checked.
In Data, use available request or connection records to check the time, destination domain, destination address, and final policy. The fields available depend on what the current interface displays. If the interface doesn’t show the matched rule, compare the same request in Proxy and Config as supporting evidence. Also check for earlier rules that might match first and whether the policy group still points to the expected server.
If the request matched DIRECT but should use a proxy, adjust the target rule and its position. If it matched PROXY and still fails, go back to the server and destination connection rather than adding duplicate rules. After changing a rule, save it, confirm that Config is using it, then reconnect and retest. Don’t replace multiple configuration entries without recording what you changed.
Common questions: Some websites fail, subscriptions, and automatic reconnection
Why does the browser keep spinning when the test shows a response time?
A Connectivity Test result doesn’t mean the entire webpage request succeeded. Keep the same server, select Proxy in Global Routing, and retry the original page. Then check DNS and connection errors. If only one website fails, check that site and its related domains; don’t assume everything is working just because the test shows a response time.
Why does it work on cellular but not on Wi-Fi?
Keep the other settings unchanged and confirm that the difference is reproducible. Check whether Wi-Fi requires sign-in or restricts the destination port or UDP. Also check whether Scene or Settings → On Demand changes the connection behavior when the network changes. Don’t assume a subscription has expired just because the issue occurs on one network.
Should I delete all entries if a subscription update fails?
No. Keep the existing configuration and confirm that the subscription URL from your service provider is still valid, then update the relevant subscription in Home. Test the subscription URL’s reachability separately from the server’s availability. When reporting the issue, hide any token in the URL to protect your access credentials.
How can I test if the connection turns back on after I switch it off?
Go to Settings → On Demand, note the original settings, and temporarily turn off automatic connections. Then test the basic network with the connection off. Restore the original settings when you’re done. If the switch still behaves unexpectedly, check whether the device has other automatic connection settings. Don’t repeatedly reinstall the app.
If you still can’t pinpoint the issue, put together a concise troubleshooting record: when it happened, network type, a redacted name for the selected server, Global Routing mode, Proxy-versus-Config results, the failed domain, whether DNS returned an address, and the full error context. When checking server status with your service provider, this evidence is more useful than saying the connection switch is on.
After troubleshooting, restore On Demand, your usual routing mode, and any configuration you need to keep, and remove temporary test rules. Confirm that service is restored by checking actual webpages, the expected policy, and several new requests—not just one latency test or the status bar indicator.