A connected status only means the local connection is active; it doesn’t confirm that the remote server, DNS resolution, and webpage request are all working. This guide assumes you already have your own provider and subscription. Check your network, server, Global Routing, DNS, and rules in order. The steps use Home, Config, and Settings on iPhone and iPad as references. On Mac, Windows, Android, and Linux, follow the same diagnostic sequence and check the equivalent settings for your platform.
1. Start with the basics: Is your network working?
If Shadowrocket shows connected but your browser keeps spinning, don’t change the server, DNS, and configuration file all at once. Change one thing at a time and compare the same webpage before and after each change. This helps identify whether the problem is with your current network or with the proxy connection or routing settings.
For testing, try one HTTPS webpage that normally opens directly, then another that normally requires your existing server. Don’t treat a single site’s maintenance, account status, or access restrictions as proof that the entire connection is down. A page still showing from cache doesn’t prove the network is working either.
-
Temporarily disable automatic connections
Go to Settings → On Demand, note the current conditions, and temporarily turn off automatic triggers. Then return to Home and turn off the connection. This prevents network changes from reconnecting automatically after you disconnect manually.
-
Check your network
Reload a webpage that should open directly. If it still won’t load with the connection off, check Wi-Fi sign-in, mobile data permissions, or the network itself before changing Config.
-
Test on another network
If possible, connect the same device to Wi-Fi and Cellular in turn and open the same address. If it fails only on one network, the issue is network-related, but you’ll still need to distinguish among server port, DNS, and authentication restrictions.
-
Record the initial settings
Note the server selected on Home, the current Global Routing mode, and the enabled file in Config. Turn the connection back on before moving to the next check. Don’t update the entire configuration during testing.
2. Check the server: a latency result doesn’t prove webpages will load
On Home, make sure the selected server belongs to your active subscription. A server entry in the list only means the configuration was imported. The list may still show an old entry if the subscription has changed, your account has expired, or the remote address is no longer valid. Update your subscription, then check that the selected entry still works.
Check that the server address, port, protocol, and authentication fields match the details from your provider. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields; don’t reuse a password, UUID, or key from one protocol with another. For TLS connections, also check the server name required by the server and your device’s clock. Don’t disable certificate verification as a workaround.
A latency reading doesn’t prove that a complete request to a webpage will succeed. A test may use a specific probe method and address, while browsing also depends on DNS resolution, the handshake, authentication, and the destination site’s response. Conversely, a timed-out probe alone doesn’t prove your account has expired. Check the actual request records as well.
Error: Connection timed out
Cause: The connection wasn’t established in time. Possible causes include packet loss, an unreachable port, or no response from the remote server.
Fix: Check the destination address and port in the log, try another network, then compare with another active server you own. Don’t change authentication fields based only on this error.
Error: Connection refused
Cause: The destination port explicitly refused the connection. The port may be incorrect, the service may not be listening, or an intermediate device may be rejecting the connection.
Fix: Check the port against your provider’s details. If the settings match and this error persists, ask your provider whether the service on that port is running.
These are examples of English error messages that may appear during network diagnostics. Capitalization and surrounding text may vary by platform and log source. Always check the destination address too: failing to connect to the proxy server and failing to connect to the destination website are different problems.
3. Check Global Routing: test Proxy and Config one at a time
Go to Home → Global Routing to check the current mode. Direct sends requests over a direct connection; it doesn’t automatically select a working server. Config applies the rules in the active configuration file. Scene follows its configured conditions, so don’t assume it works the same way as Config.
| Mode | How it helps diagnose the issue | Next step |
|---|---|---|
| Proxy | Routes general webpage requests through the currently selected proxy, reducing the effect of standard routing rules on the test. | Check the current selection on Home; it may be a policy group rather than a specific server. |
| Direct | Provides a direct-connection comparison without using a proxy server. | If the destination normally can’t be reached directly, failure in this mode doesn’t mean the server is down. |
| Config | Applies the matching rules and policies in the active Config. | Check which rule the failed request matched and the resulting policy. |
| Scene | Selects behavior based on the configured scene conditions. | Check which scene applies to the current network. Don’t add new conditions midway through troubleshooting. |
Temporarily switch to Proxy, keeping the server, network, and test address unchanged, then retry the webpage. If Proxy works but Config doesn’t, check the rules and policy groups first. If both fail, continue checking the server and DNS rather than assuming FINAL is wrong. When you’re done, restore the original mode so temporary diagnostic settings don’t become your permanent configuration.
Takeaway: isolate the difference between modes
Only prioritize rule matching and policy selection if Proxy works but Config fails on the same network, server, and address.
4. Check DNS: distinguish resolution failures from connection failures
When DNS resolution fails, the request hasn’t obtained a destination address to connect to. A server connection can fail after resolution succeeds. Both can make a browser report that a webpage can’t be opened, so check the specific request records instead of relying only on the browser message or connection status.
In Config, check the DNS-related parameters in [General] in the active file. Also check the existing DNS settings in Settings and how they interact. Record the current values first; don’t replace the configuration file and DNS address at the same time. Custom DNS must be reachable too. With encrypted DNS, consider its connection route and initial resolution as well.
- Only requests involving domain names fail: Check for resolution errors and whether the current DNS service is reachable on this network. Accessing an IP address directly can help with diagnosis, but it doesn’t replace testing an HTTPS domain.
- Resolution succeeds, but the connection still times out: Continue checking the destination IP, matched policy, and server connection. Don’t keep switching DNS providers.
- Only Wi-Fi fails: First confirm that network sign-in is complete, then compare with Cellular. DNS restrictions on the network can look similar to a server problem.
- No change after editing settings: Close existing webpage connections, reconnect, and reload the same address. This helps avoid mistaking cached results or reused connections for the effect of the new settings.
Error: Could not resolve host
Cause: The component making the request couldn’t obtain an address for the domain. The failure may be in local DNS resolution or at a remote resolution stage.
Fix: Check the domain spelling and DNS reachability first, then use the request route to determine which side failed to resolve it. If the error comes from a testing tool, account for that tool’s connection path.
5. Check the rules: confirm whether the request reaches FINAL
Switch to Global Routing → Config, open the active configuration file, and check [Rule]. Rules are generally matched from top to bottom. Once a request matches an earlier valid rule, it won’t continue to FINAL. FINAL is the fallback policy when no earlier rule matches; it isn’t a step that all traffic always passes through.
This is a rule-structure example, not a complete configuration file. example.com and 192.0.2.0/24 are documentation-only example addresses; don’t use this snippet to replace your entire Config. Policy names must also match policies available in your actual configuration.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX: Matches the specified domain and its subdomains. If an earlier DIRECT rule matches the domain of the webpage that fails, changing FINAL won’t affect that request.
- IP-CIDR: Matches a destination IP range. In this example,
no-resolvemeans not to trigger domain resolution specifically to match this rule; it doesn’t disable DNS for the entire app. - GEOIP: Matches based on geographic data for the destination IP, not the webpage’s language or domain suffix. Changes in DNS results may affect subsequent matches.
- FINAL: Provides a fallback policy for requests that didn’t match an earlier rule. If it points to a policy group, also check that the server currently selected in the group is valid.
After reproducing a failed request, check its destination domain, matched rule, and final policy in the connection log. A webpage may request resources from multiple domains: if the main document loads but scripts or images fail, the page may appear blank or incomplete. Check the domains of the failed resources individually instead of routing the entire main domain differently.
If the log shows a FINAL match but the resulting policy uses an unavailable server, fix the server or policy group selection. If an overly broad earlier DIRECT rule matched, back up the configuration and narrow that rule’s scope. Change one rule at a time and retest; don’t delete a whole block and lose the evidence you need to diagnose the issue.
6. Common questions and restoring settings after troubleshooting
Why does the latency test show a number while webpages keep loading?
A latency test doesn’t cover every step of a webpage request. Keep the same server, temporarily select Proxy under Home → Global Routing, and revisit the same address. Then check whether the request completed DNS resolution and connected to the remote server. Don’t keep switching servers based only on the latency reading.
It works after switching to Proxy. Should I keep using it?
This points to the rules or policies under Config as the next things to check, but it doesn’t mean you must keep using Proxy. In Config, find the rule matched by the failed request and correct it. Then restore Global Routing → Config and retest the same webpage and its resources.
The subscription updated successfully. Why can’t I connect?
A successful update only means the subscription content was retrieved and processed; it doesn’t guarantee that every server is currently available. Go to Home and check the selected entry, its address and port, and whether the service is still active. Then verify the authentication fields against your provider’s details.
What if the connection turns itself back on after I switch it off?
Go to Settings → On Demand and check the automatic trigger conditions. Temporarily turn them off, then test manually. When troubleshooting is complete, restore the conditions you need and check that behavior is as expected when switching between Wi-Fi and Cellular.
After troubleshooting, restore any temporary changes to Global Routing, DNS, and On Demand. Keep a minimal record that reliably reproduces the issue: device platform, network type, time of failure, destination domain, error text, matched rule, and final policy. When contacting your provider, don’t share your full subscription link, authentication password, or keys publicly.
- Basic network fails: Fix network sign-in, routing, or device connectivity permissions first.
- Both Proxy and Config fail: Check server settings, remote reachability, and DNS resolution first.
- Only Config fails: Check earlier rules, FINAL, and the current policy group selection.
- Only some resources fail: Check requests for each resource domain. Keep valid rules and change only the settings you’ve identified as causing the issue.
If you need to reinstall Shadowrocket or check installation instructions for your platform, visit this site’s all-platform download page. Shadowrocket is closed-source commercial software. Getting the app and obtaining a network service are separate: a one-time app purchase does not include a service plan. Importing and testing require a subscription you already have. For iPhone and iPad, check the App Store listing for system requirements. Mac downloads are available for both Apple Silicon and Intel.