Turning on the connection in Shadowrocket only means that the relevant network tunnel is enabled. It doesn’t guarantee that the selected server, DNS, or destination website is responding. This guide is for users who already have their own provider and subscription. Start by establishing a baseline, then isolate server, Global Routing, DNS, and rule issues one at a time. Change only one setting per test, and keep the conditions that reproduce the problem.
Check your baseline network before troubleshooting
Don’t start by deleting your configuration or repeatedly updating your subscription. Note the current network, the server selected in Home, the current Global Routing mode, and the configuration file in use under Config. Use the same webpage for each test and send a fresh request each time, so a cached browser page doesn’t look like a restored connection.
Turn off Shadowrocket’s connection and test a webpage that normally loads on your current network. If it still won’t load, troubleshoot Wi-Fi sign-in, cellular data permissions, or the network itself first. If it works with the connection off but fails when it’s on, check the forwarding path in the app. This comparison won’t help with a website that’s already inaccessible without the connection.
-
Record the current state
In Home, note the selected server and Global Routing mode. In Config, note the active configuration name. Keep these notes private; don’t share subscription URLs, passwords, or complete configurations.
-
Rule out automatic connections
Go to Settings → On Demand, note and temporarily disable the automatic connection conditions, then return to Home and turn off the connection. Otherwise, the system may reconnect and invalidate your test with the connection off.
-
Test the baseline network
In Safari, reload the same webpage that’s accessible directly. Test Wi-Fi and cellular data separately. When switching networks, stop the previous request before sending a new one.
-
Turn the connection back on
Return to Home, turn on the connection, and test the same URL again. Check the server, mode, DNS, and rules in that order, recording the result after each test.
Step 1: Check the server and its forwarding capability
A server entry in Home doesn’t mean the server is currently working. First make sure the intended entry is selected, then check its address, port, authentication details, and protocol settings against the information from your provider. A typo in the server hostname, an incorrect port, or invalid credentials can leave the connection on while requests fail.
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields; don’t apply one protocol’s settings to another. Check each entry against the original service parameters. For configurations using TLS, also check the server name and related verification settings. Don’t disable certificate verification as a troubleshooting shortcut. If the device date is significantly wrong, correct it before reconnecting.
- Use the port specified by your service: HTTPS websites commonly use destination port
443, but a proxy server can listen on a different port. Don’t change every port to443. - A latency result isn’t conclusive: A reported delay only shows that the probe received a response. It doesn’t prove that the destination website, DNS, or actual request is working.
- Compare only entries you already have: Keep other conditions unchanged and switch to another existing server. If the issue changes with the server, check the original entry’s settings and service status first.
- Confirm the selection after an update: A subscription update may change server entries. After updating, return to Home and confirm that the expected server is still present and selected before testing again.
A failed subscription update and a server that can’t forward traffic are different problems. A saved server may still work even if the subscription URL is temporarily unavailable. Conversely, a successful update doesn’t mean every server it returned is working. Update only when your provider confirms that the settings have changed; repeatedly refreshing isn’t a substitute for checking the connection.
Step 2: Use Global Routing to isolate mode issues
Go to Home → Global Routing and check the current mode. To narrow things down, briefly compare Direct, Proxy, and Config. Reload the webpage after each change; existing long-lived connections may keep using the old route, so don’t judge by an already-open chat or video. Restore your original setting after testing rather than leaving Proxy enabled as a presumed fix.
| Mode | What to check | How to interpret the result |
|---|---|---|
| Direct | Check the direct connection path | If a webpage that’s directly accessible still fails, check the baseline network and DNS first. This isn’t the same as testing with the app fully disconnected. |
| Proxy | Check the selected proxy path | If the same webpage works in Direct but fails in Proxy, focus on the selected server and its connection settings. Keep DNS on the checklist, too. |
| Config | Check rule-based routing in the current configuration | If Proxy works but Config fails, check rule matches, policy targets, and DNS differences in the configuration first. |
| Scene | Follow saved scene conditions | Check which scene is triggered by the current network and the settings assigned to it. For troubleshooting, temporarily select a specific mode to reduce the impact of automatic switching. |
Takeaway: Find out which path the issue follows
On the same network, webpage, and server, if Proxy works but Config doesn’t, check the matched rules in Config first instead of re-entering server settings. If all modes fail, recheck the server connection and DNS; the connection switch alone can’t confirm that traffic is working.
Step 3: Distinguish DNS failures from connection failures
DNS translates domain names into addresses. If the server itself uses a hostname, its address may need to be resolved before the proxy connection can be established. So a webpage failing to load doesn’t necessarily mean the problem is at the destination website. Check whether both the server hostname and destination hostname resolve as expected, then determine whether the connection succeeds.
Check the DNS settings in the active Config file, then review DNS-related settings under Settings so you don’t change an inactive configuration by mistake. Note the original values and adjust only one DNS-related option at a time. Traditional DNS commonly uses port 53, while DoH uses HTTPS. Whether the current network can reach the resolver matters just as much as the response it returns.
- A hostname resolution failure doesn’t mean the server is offline: If the error occurs during DNS resolution, the connection hasn’t reached the server. Check the hostname spelling and resolution path first.
- Don’t rely on an IP-address URL as your only test: HTTPS usually relies on the hostname for certificate validation and site selection. An error after replacing the domain with an IP address doesn’t, by itself, prove a DNS problem.
- Account for address-family differences: The same hostname can return IPv4 and IPv6 addresses. If the issue occurs on only one network, record the address actually tried and the connection result. Don’t remove all IPv6-related settings without checking.
- Send a fresh request after changing settings: Reconnect and make a new request. Browser and system caches can affect what you see, and one page load doesn’t prove that all DNS results have been updated.
Step 4: Check rule order and the final match in Config
If the issue occurs only in Config, first make sure the active file is the one you just checked, then review the rule order. Rules are generally evaluated in order, and the first matching rule determines where traffic goes. A rule being present in the configuration doesn’t mean the request reaches it; a broader rule above it may have already matched.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis snippet illustrates syntax only. It isn’t a complete configuration and shouldn’t replace the file in use. example.com and 192.0.2.0/24 are documentation examples; write actual rules for the destination you’re troubleshooting and your own policies.
DOMAIN-SUFFIX: Matches the specified domain and its subdomains. A website may rely on other resource domains, so routing only its homepage domain may not restore images or login requests.IP-CIDR: Matches an IP address range. In the example,no-resolvemeans not to trigger DNS resolution specifically for this rule match; it isn’t a switch to disable DNS globally.GEOIP: Matches based on geographic IP data, not the webpage language or website name.FINAL: Handles traffic that didn’t match an earlier rule. Check that its target is what you expect.
Also check that each rule points to an available policy. DIRECT means a direct connection, and PROXY routes traffic through a proxy. If the configuration uses custom policy group names, check that the name is correct and what’s currently selected in the group—not just the domain on the left side of the rule. Note the request’s destination domain, matched rule, and final route before making the smallest necessary change.
Use the exact error text to pinpoint where the failure occurs
The following snippets may appear in network error logs; they aren’t fixed messages shown by every interface. Keep the surrounding context to identify whether the error concerns DNS, the server endpoint, or the destination website. The same timeout message can point to different fixes depending on when it occurs.
Error: connection refused
Cause: The connection was actively refused. This commonly happens when no service is listening on the destination port or the connection is being rejected.
What to do: First identify which endpoint the address refers to. If it’s the server endpoint, check that entry’s port in Home and ask your provider to confirm the service status.
Error: i/o timeout
Cause: A network read or write operation exceeded its timeout. This message alone can’t distinguish packet loss, an unresponsive server, or an upstream connection problem.
What to do: Keep the server and webpage fixed, test Wi-Fi and cellular data separately, then use the destination address shown before the error to identify where the timeout occurred.
Error: no such host
Cause: DNS resolution didn’t return a usable result. The hostname may be mistyped, nonexistent, or affected by a problem with the resolution path.
What to do: Check the full hostname being resolved, then review the DNS settings in the active configuration. Don’t start by changing the server port or authentication password.
Retest and FAQs
After the connection works again, undo temporary changes in the same order and test with your usual Config. Check at least one webpage that failed and one that’s directly accessible, sending a fresh request for each. If On Demand is enabled, restore the original conditions under Settings → On Demand last, then confirm that switching networks doesn’t bring the issue back.
The connection stays on. Why is there still no internet?
The switch doesn’t prove that traffic is being forwarded successfully. Turn off the connection to establish a baseline, then check the selected server in Home. Compare Proxy and Config next, and finish by checking DNS and rules. Avoid changing several settings at once.
Wi-Fi fails but cellular data works. Should I reinstall?
Don’t reinstall yet. Keep the same server and Global Routing mode, check whether the Wi-Fi network requires a sign-in page, and compare server hostname resolution and connection results. If the issue follows the network, start by checking its DNS and access restrictions.
It works in Proxy but not when I switch back to Config. Why?
In Config, check which file is active and whether the destination hostname matches DIRECT or another policy earlier than expected, then check where FINAL routes traffic. Also compare DNS settings in the configuration. Proxy working doesn’t automatically mean that all your rules are wrong.
The subscription update succeeded. Why won’t webpages load?
A successful update confirms only that the subscription was retrieved and processed. Return to Home, confirm which server is selected, check its updated settings, and test its forwarding capability. If only one website still fails, check the domains it relies on and the matching rules.
This is the official Shadowrocket website, with the official manual and setup guides. For more detailed steps, see the tutorial; for explanations of settings, see the settings reference. This site doesn’t provide, sell, or recommend servers, subscriptions, or network services. Contact your existing provider about service status or authentication issues.