Turning on Shadowrocket starts the system tunnel; it doesn’t confirm that the server, DNS resolution, or destination website is working. This guide is for users who already have their own service provider and subscription details. First establish a baseline for your local network, then check the server, compare behavior with Global Routing using one change at a time, and finally inspect DNS and rule matches. Record the result for the same destination after each change so a configuration change isn’t mistaken for a network fix.
1. Identify the scope before reinstalling
First determine whether all requests fail, only certain domains fail, or the problem occurs after switching networks. Each pattern calls for different checks. A VPN status indicator doesn’t prove that the remote proxy completed its handshake; a latency result in Home doesn’t replace an actual webpage request.
Keep your current Config and server details during troubleshooting; don’t delete the app first. Reimporting afterward changes the configuration, cache, and selection state at once, making it harder to identify the cause. If On Demand is enabled, go to Settings → On Demand and pause it before testing the connection manually. Restore the original setting when you’re done.
-
Establish a network baseline
Turn off the connection in Home and open an HTTPS page that normally works over a direct connection. If it still fails, check Wi-Fi sign-in, cellular data access, or the router connection first. Don’t blame local network access on the rules.
-
Use consistent test destinations
Choose one destination that should connect directly and another that requires an existing proxy. Use the same domains and pages for each test. Count the test as successful only when the page fully loads; an old page still on screen doesn’t confirm a new request succeeded.
-
Record the current state
In Home, note the selected server and Global Routing mode. In Config, confirm which configuration is active. Also note whether you’re using Wi-Fi or cellular, and keep these conditions unchanged when comparing results.
-
Send a fresh request
After connecting, reload the test page and check the newly generated request record. Note the destination domain, time, handling policy, and error. Don’t use an older record from a few minutes ago to judge the current test.
2. Check the server: a tunnel doesn’t guarantee a remote connection
In Home, confirm which server is actually selected—not just that a server appears in the subscription list. Check that its address, port, protocol, and authentication fields match your existing service details. If the server uses a domain name, that name usually has to resolve before the proxy connection can be established. A failed lookup can therefore make the connection appear unavailable.
A port number alone doesn’t identify the protocol. For example, a server listening on TCP 443 won’t necessarily accept every protocol on that port. Trojan authentication and TLS settings, VMess or VLESS transport settings, and the Shadowsocks cipher all need to match the server. Don’t change only Type as a test while leaving other incompatible fields unchanged.
- Test the selected entry first: Run Connectivity Test in Home, then check the next real webpage request. A failed test means more checks are needed; a successful test only shows that the test path worked at that moment.
- Compare servers on the same network: If your existing list contains other valid entries, switch only the server and keep Global Routing and Config unchanged. If only one entry fails, check its settings, validity, and remote service first.
- Then compare networks: Keep the server unchanged, switch from Wi-Fi to cellular, and repeat the test. If it fails on only one network, check that network’s sign-in status, egress restrictions, and whether the selected transport can reach the server.
- Check your existing subscription: If the service details have changed, update your own subscription and select the entry again. A successful update confirms that the configuration could be retrieved, not that every server in it is currently available.
Error: connection refused
Cause: The destination or an intermediary explicitly refused the connection. Check the address, port, and whether the service is listening.
Fix: Compare the port with your existing service details. If they match, give your provider the time of the error, network type, and error message to check. Don’t keep changing DNS settings.
Error: i/o timeout
Cause: A network read or write operation didn’t complete in time. This message alone can’t tell you whether the issue is with the server, transport path, or upstream destination.
Fix: Check the connection destination and stage around the error in the log. Then compare servers on the same network and networks with the same server to narrow down where it fails.
These are underlying errors that may appear in network logs, not fixed interface messages. The surrounding context varies by protocol. When reporting the issue, include the nearby log entries but remove passwords, authentication details, and subscription tokens.
3. Global Routing: use Proxy and Config to distinguish egress from rules
Go to Home → Global Routing to check the current mode. Proxy, Direct, Config, and Scene represent different ways of handling traffic; they don’t indicate server health. Note the original mode, make a brief comparison, then restore it. Switching modes may affect requests in progress in other apps.
| Mode | How it handles traffic | How to use it in this test |
|---|---|---|
| Proxy | Handles traffic through the proxy instead of applying the usual routing rules in Config. | Keep the server fixed and test whether the proxy egress can complete a real request. |
| Direct | Uses a direct connection. | Check local network access and direct reachability to the destination; this doesn’t test the proxy server. |
| Config | Uses the active configuration and its rules to decide how to handle traffic. | Compare with Proxy to identify differences in rules, policies, or DNS settings in the configuration. |
| Scene | Applies routing based on the configured scene conditions. | Check which scene is actually active. For initial troubleshooting, switch to an explicit mode to reduce changing conditions. |
If the same server and destination work in Proxy but fail in Config, check the active configuration and matched policy first—but don’t immediately assume a rule is wrong. Differences can also come from DNS behavior, the policy group’s selected server, or a reject rule. If both modes fail, return to server reachability and DNS checks instead of adding more routing rules.
Takeaway: Save reproducible mode differences
If Proxy works but Config fails, save the comparison and check the rule and outbound connection actually used by the failed request. Find the difference before changing the configuration. Don’t change the server and DNS at the same time.
4. Check DNS: distinguish server names from destination domains
A request may involve two kinds of DNS lookups: one for the proxy server’s address and one for the destination website’s domain. If the first fails, the proxy connection can’t be established. If the second fails, the server may be reachable while the request to the destination still can’t proceed. Whether resolution happens locally or remotely depends on the protocol and configuration; a page that keeps loading doesn’t reveal where it failed.
This flow illustrates the checkpoints; not every protocol performs DNS resolution at the same stage. Open the editor for the active configuration in Config and check resolution settings such as dns-server under [General]. Then check the request log for failed lookups, empty results, or unexpected addresses. If the configuration uses a custom DNS service, also check the network path needed to reach that service.
- Change one source at a time: Save a copy of the configuration, then temporarily replace the current custom DNS settings with a known-working system resolver. Reconnect and retry the same domain. Don’t replace the entire Config at once.
- Check address families separately: If the log shows both A and AAAA results, check whether the final connection uses IPv4 or IPv6. Receiving an AAAA record doesn’t mean the current network has a working IPv6 route.
- Understand the ports: Traditional DNS usually uses UDP or TCP port 53; DoH uses HTTPS and typically involves TCP port 443. An open port doesn’t guarantee that a DNS request will succeed—check the actual response.
- Don’t use an IP address as a DNS test: HTTPS sites often rely on the domain name for certificate verification and virtual host selection. If entering an IP address in the address bar fails, that alone doesn’t prove a DNS problem.
5. Check rules: inspect the first match, not just whether a rule exists
In Config, confirm which configuration is actually active, then inspect the request record for the failing domain. Note the matched rule, final policy, and server actually used. Rules are evaluated in order: once an earlier rule matches, a later rule that seems like a better fit won’t reroute the request.
The example below illustrates rule order and syntax; it isn’t a general-purpose configuration to replace your existing setup. example.com is an example domain, and 192.168.0.0/16 is a private address range. PROXY and DIRECT are rule policy keywords; don’t confuse them with the labels in the Global Routing menu.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT- DOMAIN-SUFFIX: The example matches
example.comand its subdomains. A real webpage may also request login, image, and API domains; a match for the main page doesn’t mean every dependent request matched. - IP-CIDR: Matches a destination IP range. In this example,
no-resolvemeans not to trigger an additional domain lookup for this IP rule; it doesn’t turn off DNS for the entire configuration. - GEOIP: For example,
GEOIP,CN,DIRECTroutes based on the region associated with an IP address. The result depends on the address and database in use; this isn’t a domain-suffix rule. - FINAL: Handles requests that didn’t match any earlier rule. The example uses
FINAL,DIRECT, so requests that don’t match the first two rules connect directly. If a destination requires a proxy, this fallback may not match your expectations.
If a request matched the wrong rule, first confirm that the intended Config is active, then check rule order, domain spelling, and referenced policies. If a policy group matched, check which server is actually selected in the group. Seeing PROXY alone doesn’t prove the request used the egress you intended.
Takeaway: Fix only confirmed routing errors
If the failed request clearly shows that the destination was incorrectly sent direct, add a narrowly scoped domain rule to a copy of the configuration, placing it before any broader rule that would match first. Test the page and its dependent requests before deciding whether to keep the change.
6. Common questions: partial access, auto-reconnect, and subscription updates
Why is there a latency result if webpages still won’t load?
A latency result comes from one specific test; it doesn’t cover every destination, DNS path, or webpage dependency. Keep the same server, visit the actual destination in Proxy, then check whether the failure occurs during resolution, connection, or response.
If only one website won’t load, do I need to replace the entire configuration?
First check request records for the site’s main domain and API domains. If other destinations work, focus on the affected destination’s rules, DNS results, and remote response. Responses such as HTTP 403 or 429 mean a request reached an HTTP service; check where the response came from and the access conditions instead of immediately reinstalling.
The connection turns back on after I switch it off. How can I test it?
Go to Settings → On Demand, temporarily turn off On Demand, then disconnect and test manually. If the device is also subject to management policies, check their connection requirements too. Restore the original settings when troubleshooting is complete so you don’t leave the test state in place.
Is a failed subscription update the same as webpages not loading?
No. A subscription update accesses a configuration URL; a webpage request accesses the destination site. They may use different paths. First check that your subscription URL is complete and still valid, then check its DNS resolution and network path. After an update succeeds, confirm which server is selected in Home.
If switching to cellular fixes it, does that prove the problem is Wi-Fi?
It shows that the issue is related to network conditions, but you still need to control the variables. Keep the server, Config, and destination unchanged. Check whether Wi-Fi sign-in is complete, whether direct access works, and whether the network allows the selected transport. Don’t change the protocol, server, and DNS settings all at once.
7. Restore settings and keep reproducible notes
After identifying the issue, restore the original Global Routing and On Demand settings, keeping only changes you’ve verified are necessary. One successful test doesn’t mean the problem is gone for good. Send a fresh request on the network where it originally failed and confirm the result stays consistent after disconnecting and reconnecting.
- Environment: Device type, network type, time of the issue, and whether direct access works with the connection off.
- Comparison: Results for the same destination in Proxy and Config, and whether they change when switching networks or existing servers.
- Evidence: The failed request’s domain, matched policy, exact error, and surrounding context. Note whether you tested a webpage or Connectivity Test.
- Privacy: Remove the full subscription URL, tokens, passwords, and other authentication details before sharing logs. Keep only what’s needed to identify the issue.
These notes turn “Shadowrocket is on but nothing works” into a specific question: did the server connection fail, did DNS return no result, did a rule select the wrong outbound route, or did the destination return an error? Checking each point in order preserves useful evidence better than repeatedly resetting settings, and helps your service provider investigate the remote side.