Turning on the connection only confirms that the local connection has started. It does not prove that the server, DNS resolution, or destination website is working. This guide is for users who already have their own server details or subscription. Check your base network first, then test the server, Global Routing, DNS, and rules one at a time. Restore your usual settings when you’re done.
01 Understand the difference between “Connected” and a successful request
Shadowrocket’s connection status, server latency test, and the page loading in a browser are three different checks. A VPN indicator in the status bar does not confirm that the remote server has authenticated successfully. A latency result does not confirm that DNS, TLS, and all subsequent page requests are working either. Note what you observe before changing the connection repeatedly; this makes it easier to narrow down the cause.
Before you begin, note the server, Global Routing option, active Config, and domain of the page that fails. Choose one page you can normally open directly as a control, and one page that currently fails. Don’t assume a problem with one website means the entire network is unavailable.
-
Check your base network
First, go to Settings → On Demand, check the automatic connection settings, and temporarily turn them off. Then return to Home and turn off the connection. Open a page in Safari that you can normally access directly. If it still fails, check for Wi-Fi sign-in requirements, cellular data permissions, or a problem with the network itself.
-
Keep test conditions consistent
Use the same network, page, and device throughout the test. Return to Home, select your own server, and turn on the connection. Don’t switch Wi-Fi, servers, and Config at the same time; otherwise, you won’t know which change affected the result.
-
Note which requests fail
Record whether all pages fail, only some domains fail, pages load but images don’t, or only one app fails. Note when it happened and which Global Routing option was selected, so you can compare it with the request log later.
-
Change one setting at a time
Change just one setting, then retry the same request. If needed, turn the connection off and back on. If there’s no improvement, restore the original setting before moving on. This prevents temporary changes from piling up.
02 Check server reachability and your existing subscription
On Home, run Connectivity Test for a server you already have, and make sure the selected entry is the one you intend to test. Results depend on the test method and target: a successful port connection does not confirm protocol authentication, and reaching the test target does not mean every website is reachable. Compare the test result with what actually happens in your browser.
Open the selected entry’s edit screen and check Type, server address, port, and authentication details. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different parameters; don’t switch protocols at random because one entry timed out. For TLS connections, check the server name and other details provided by your service provider. Don’t hide a configuration problem by disabling certificate verification.
- Only one entry fails: If you already have another working entry, switch to it while keeping everything else the same. Comparing the results can help determine whether the issue is specific to that server or its settings.
- Every entry fails on the same network: Check your base network first, then test on another network you can use. If switching networks changes the result, that shows the connection path differs; it does not confirm that the authentication details are correct.
- It worked before but now fails: Check the validity period and traffic status of your existing service, along with any maintenance notices. Then update your existing subscription and confirm which entry is selected.
- The subscription updated, but requests still fail: A successful update only means the subscription content was retrieved; it doesn’t mean every server is working. Check the selected entry after updating instead of relying on the refresh completing.
03 Compare routes with Global Routing
Once the server appears reachable, go to Home → Global Routing and check the selected option. Proxy, Direct, Config, and Scene use different routing methods, so the connection switch alone won’t tell you where traffic is going. Note the original option, briefly compare Proxy and Config, then restore your usual setting.
| Option | What to check | How to interpret the result |
|---|---|---|
Proxy | Routes regular requests through the proxy. Check which proxy is currently selected. | If the same page works here but fails under Config, check the rules and policy selection first. DNS differences may also be a factor. |
Direct | Routes requests directly, without the proxy. | Selecting a server doesn’t mean requests use it. Use a page that you can access directly as a basic comparison. |
Config | Processes requests according to the rules in the active Config. | Confirm that the expected Config is active, then check the rule matched by the failed request and its final policy. |
Scene | Check the active Scene and its associated settings. | A Scene may change the routing settings in use. Don’t assume the selected server determines the final route. |
If both Proxy and Config fail, continue checking the server and DNS rather than adding rules right away. If Proxy works but Config doesn’t, check whether the target domain is routed to DIRECT, REJECT, or an unavailable policy group in Config. This comparison is a troubleshooting clue, not definitive proof that the server is fully working.
04 Check DNS if latency looks normal but pages won’t load
A browser needs to resolve a domain name to an IP address before it can load a page. If the latency test only checks the server’s port or uses a different target from the website, you may see normal latency while pages still fail. Go to Settings → DNS to check the current settings. Also check whether the active Config includes its own DNS settings, so you don’t change one place and overlook another.
Save the original settings first. Then check for a custom resolver that no longer works, one that’s only reachable on certain networks, or an incomplete encrypted DNS address. Don’t keep adding unfamiliar addresses: if the resolver itself is unreachable, adding more may not help and will make comparisons harder.
These are commonly used protocol ports, not values to enter in every server entry. Keep the server port set to the value provided by your service provider. With DoH, an endpoint that uses a hostname also requires an initial lookup of that hostname. If the resolver must be reached through a proxy, an unavailable proxy can also cause DNS resolution to fail.
- First, compare with the previous settings: Temporarily remove any custom DNS settings you added recently, restore the last known working configuration, reconnect, and open the same domain again.
- Then identify where it fails: Check whether the request failed to get a DNS result, or got an address but failed during connection or TLS. Changing DNS alone won’t fix the latter.
- Don’t use an IP address as a definitive test: HTTPS sites may rely on the domain’s certificate, SNI, and virtual host. Failure to open a site by IP does not prove the network is down.
05 Check rule order, policies, and FINAL
If the problem only occurs with Config, open Config and confirm which configuration is active, then check its rules. Rules are generally evaluated from top to bottom, and the first matching rule determines the policy. FINAL handles requests that match none of the preceding rules. So a correct rule placed after an earlier FINAL won’t work as expected.
These examples explain the syntax; they are not a replacement configuration to paste in full. example.com and 192.0.2.0/24 are illustrative values. Make sure any rules you use match your own targets and policy setup.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY: Matches the domain and its subdomains, then routes them through PROXY. It won’t automatically cover other independent domains used to load the page.IP-CIDR,192.0.2.0/24,DIRECT,no-resolve: Matches the destination IP range.no-resolvemeans this rule won’t trigger a DNS lookup; it does not mean the request as a whole never needs DNS.GEOIP,CN,DIRECT: Matches based on the destination IP’s geographic database classification, not the website’s text or domain suffix.FINAL,PROXY: Handles requests that didn’t match earlier rules. If the actual rule uses DIRECT or REJECT, confirm that this is intentional.
Retry the request and check the in-app request log. Use the time and domain to find it, then confirm the matched rule and policy. If it matched PROXY but still failed, check the server or policy group it uses. If it matched REJECT, first check whether an overly broad rule blocked it. Don’t delete all your rules just to make one page load; back up your Config and keep changes targeted.
06 Use the error message to choose your next step
Interpret error messages in context, based on where they appear. The examples below are common English fragments in connection or DNS logs; capitalization and additional details may vary. A generic “Safari cannot open the page” message doesn’t identify the failure stage, so also check the in-app log for the same time.
Error: Connection refused
Cause and next steps: The destination or a device along the route refused the connection. This commonly happens when no service is listening on the port or access is denied. Check your server address and port, then ask your service provider to confirm the listening status. Don’t assume the password is wrong.
Error: Connection timed out
Cause and next steps: The connection wasn’t established within the allowed time. The cause may involve the network path, server status, or a firewall. Keep the settings unchanged, retry on another network you can use, and note whether the issue affects just one server.
Error: NXDOMAIN
Cause and next steps: DNS reports that the domain doesn’t exist. The domain may be mistyped, or the DNS result may be incorrect. Check the full domain, then retry with a DNS configuration that worked before. Refreshing the server list repeatedly won’t fix a misspelled domain.
If the error involves a TLS certificate, check the device’s date and time, the server name, and the certificate configuration provided by your service provider. If the website returns an HTTP status code, it has returned at least one HTTP response. Check the status code against the site or access policy instead of assuming every failure is a DNS issue.
07 Common questions and final checks
Connectivity Test shows a result. Why won’t the page load?
On Home → Global Routing, note the current option and compare Proxy with Config using the same page. A latency test doesn’t cover every request made by a webpage. Check the DNS result, matched policy, and connection error at the time of failure.
If Proxy works, can I just leave it there?
That shows the routing methods behave differently; it doesn’t mean the rules are fixed. Return to Config and check where the target domain matches, along with the policy group and FINAL. Once corrected, restore your usual routing option and test the same page again.
The connection turns back on after I turn it off. How can I test it?
Go to Settings → On Demand, note the current settings, and temporarily turn off automatic connections. Then return to Home and turn off the connection. After troubleshooting, restore the original On Demand settings so the test setup doesn’t become your everyday configuration.
Do I need to select a server again after updating a subscription?
Return to Home and confirm the selected entry. An update may change entry details or names. Check your selection, run Connectivity Test, and then try the actual webpage. A successful subscription update does not prove the server is working.
Should I delete and reinstall the app first?
Work through the checks above first. Reinstalling won’t fix a remote server or network path, and it may remove local settings. If you do need to reinstall, back up your Config and keep your subscription and authentication details safe.
When you’re done troubleshooting, retest the original page on the original network. Restore any temporary changes to Global Routing, DNS, and On Demand. Keep a brief record of the failure time, network type, server used, matched policy, error message, and any changes that helped. If you need further advice, share only redacted information; don’t include subscription tokens, passwords, or private keys in screenshots or public messages.