Turning on Shadowrocket only enables the connection feature; it doesn’t confirm that the remote service, DNS resolution, and routing rules are all working. This guide is for users who have already imported a configuration from their own service provider but can’t access the internet on any device or in certain apps. First, check your network with Shadowrocket disconnected. Then check the server, Global Routing, DNS, and Config one at a time, changing only one setting per test.
1. Check what’s offline and preserve a way to undo changes
Don’t start by deleting the app or clearing your configuration. You could lose server settings, active rules, and useful diagnostic clues. Note the selected server on Home, the current Global Routing mode, and the active file in Config. Keep any screenshots containing credentials on your device.
This flow outlines what to investigate; it doesn’t mean every connection follows exactly the same internal sequence. Some rules may trigger DNS resolution when matched, and the server hostname may need to be resolved first. Seeing the system VPN indicator does not mean a response has made it back from the destination.
- Turn off the Shadowrocket connection. Visit a website that normally works without a proxy, then try a local address such as your router’s admin page. This helps distinguish an internet issue from a local network issue.
- If you still can’t connect after disconnecting, check Wi-Fi sign-in, mobile data access, your router, or your ISP first. Changing rules usually won’t restore a basic network connection.
- Once your basic connection is working, turn Shadowrocket back on and retry the same URL. Note whether all sites fail or the problem affects just one domain, app, or video call.
- Test on both Wi-Fi and mobile data. If the issue occurs on only one network, first check whether that network can reach the server address and port, and whether it allows UDP traffic.
2. Check the server: a latency result doesn’t mean websites will load
On Home, make sure the server you want to test is selected, then check the result with Connectivity Test. A response only shows that the specific test path responded at that time. It doesn’t confirm that every destination, DNS query, or UDP connection will work. Don’t skip checking the server settings just because you see a latency figure.
- Address and port: Compare the hostname and port with the details from your service provider. Enter the port the remote service actually listens on; don’t use the local proxy listening port.
- Protocol and credentials: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard require different fields. Keep the original protocol and check the password, UUID, key, or other authentication details. Don’t switch protocols at random to see if one works.
- TLS settings: Check the server name, certificate, and device time against the original configuration. A reachable server address doesn’t guarantee TLS verification will succeed. Don’t hide certificate errors by turning off verification.
- Service status: Check that your account is active, you have available usage, and the remote service is running. If you’ve updated an existing subscription, confirm the update succeeded, then select the server again so you’re not testing an outdated entry.
Error: Connection refused
Cause: The destination or an intermediary explicitly rejected the connection. This often means the port isn’t listening or an access policy blocked the request.
Fix: Check the remote port and service status first, then ask your service provider to verify the listener and firewall settings. Changing DNS repeatedly won’t fix a connection that has already been refused.
Error: Connection timed out
Cause: The connection wasn’t established before the timeout. The address may be unreachable, packets may be lost or filtered, or the remote server may not be responding.
Fix: Leave the configuration unchanged. Test the same server on a different network, then compare it with another working configuration you already have to narrow down whether the issue is with the network or server.
Error: certificate verify failed
Cause: TLS certificate verification failed. Possible causes include the certificate chain, server name, or device time.
Fix: Enable automatic date and time on your device, check the original TLS settings, and ask the server maintainer to fix the certificate issue.
These are examples of English errors that may appear in connection tools or lower-level logs. Capitalization and prefixes may vary. When reporting an issue, keep the original text and identify whether it came from a browser, a subscription update, or a proxy connection; each may follow a different request path.
3. Check Global Routing: use a brief comparison to isolate routing issues
On Home, open Global Routing and note the current selection. Proxy, Direct, Config, and Scene describe different routing modes, not four connection protocols. Even with correct server settings, a routing choice can send a request through the wrong path.
| Mode | What to look for | How to interpret the result |
|---|---|---|
| Proxy | Route traffic primarily through the proxy. | If the same URL works in Proxy but fails in Config, check the rules and selected policy. |
| Direct | Use a direct connection instead of routing traffic through the selected proxy server. | If the destination requires a proxy, failure in this mode doesn’t prove the server is faulty. |
| Config | Route traffic according to the active configuration’s rules. | Check whether the destination matches DIRECT, a proxy policy, or a reject action. |
| Scene | Route traffic according to the configured scene conditions. | Check which scene the current network triggers. Selecting Scene alone doesn’t tell you the final route. |
- Keep the same server and test URL, switch briefly to Proxy, and retry the request.
- Switch back to Config and reload the same destination. If needed, close and reopen the test app to avoid reusing an existing connection.
- If only Config fails, check the active configuration’s rule order and selected policy. If both modes fail, continue checking the server and DNS rather than assuming the rules are at fault.
A successful test in Proxy helps narrow down the issue; it isn’t necessarily the right permanent fix. Restore the original mode when testing is complete. If you need to access local devices, also check the actual route used for local addresses.
4. Check DNS: distinguish resolution failures from connection failures
DNS (Domain Name System) resolves domain names to IP addresses. A DNS failure can make a website appear unavailable, but the remote proxy isn’t necessarily the cause. Check Settings → DNS, then the DNS entries in the active Config file. Confirm which settings are actually in effect and whether any override others. Changing an inactive configuration file won’t help.
These are common protocol ports, not instructions to change your server port to one of these numbers. With encrypted DNS, the upstream resolver must also be reachable over the current network path. If resolving the server hostname requires a proxy connection, but the resolver itself depends on that proxy, you may run into a startup dependency issue.
- Save the original values: Note the upstream DNS addresses, resolution-related options, and active configuration so you can restore them after testing.
- Test one change at a time: Temporarily restore the DNS settings that worked before, or use a resolver that’s reachable on your current network. Don’t change the resolver, rules, and server all at once.
- Account for app caches: Reconnect after changing settings, then close and reopen the test app. Browser secure DNS, system encrypted DNS profiles, and app caches can all affect the results.
- Check IPv6: If a domain resolves to an IPv6 address but your current outbound route doesn’t support IPv6, check that DNS and routing are consistent. Don’t assume every dual-stack issue means the server is offline.
5. Check rule order: confirm the matching rule and final route
The active configuration’s rules are the focus only when Global Routing is set to Config. First, check which file is active in Config. Then review the request log for the failing destination and note its domain, destination address, matching rule, and actual outbound policy. If the log doesn’t show a domain, don’t identify a site based only on a shared IP address.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis example illustrates match order; it isn’t a complete, importable configuration. example.com is a sample domain. PROXY must match the name of an available policy or built-in policy. 192.168.0.0/16 covers one private address range, not every local network.
DOMAIN-SUFFIXmatches the specified domain and its subdomains. Put more specific rules before broader rules that might match first.IP-CIDRmatches a destination IP range. In this example,no-resolvemeans the IP rule won’t trigger a DNS lookup; it doesn’t disable DNS globally.GEOIPmatches based on IP geolocation data. It doesn’t categorize website content and can’t guarantee that every connection to a site will use the same route.FINALis the fallback route when no earlier rule matches, so it belongs at the end. If an earlier, broader rule already matches, changing FINAL won’t affect that request.
If the homepage loads but login, images, or video don’t, check those requests separately. A page can load resources from multiple domains; a correct rule for its main domain doesn’t guarantee the other requests will use the same policy. Fix only what the logs support, and check that the selected policy group is working. Don’t route every request through the same exit as a first step.
6. Narrow down the issue by symptom
The switch is on and the VPN indicator is showing. Why is nothing loading?
Turn off the connection to confirm your basic network works, then check the selected server on Home. Compare Proxy and Config using the same URL. If both fail, check service status, authentication, and DNS first. The system VPN indicator alone doesn’t confirm a working connection.
Web pages load, but voice calls or games won’t connect?
Check whether the affected app relies on UDP and whether the configured protocol, remote server, and current network support that traffic. Working TCP connections to websites don’t prove UDP is working. Keep the server unchanged, compare Wi-Fi and mobile data, and check the relevant request logs.
The subscription updated successfully, so why is the connection still timing out?
A successful subscription update only means the configuration URL was reachable and its contents were retrieved. It doesn’t mean every server in it is working. Go back to Home, check the selected entry, and verify its status with your service provider. Don’t enter a subscription URL in a single server’s address field.
It stopped working after the screen locked or you switched Wi-Fi networks?
Note when the problem occurs relative to a network change. Check the conditions in Settings → On Demand and whether Global Routing is set to Scene. Temporarily stay on one network and test with a specific routing mode, then restore the automatic conditions one at a time.
Only one app is affected. Do you need to reinstall Shadowrocket?
Compare how the browser and the affected app access the same service. Check the app’s network permissions, any separate DNS settings, and its request logs. If other apps work, focus on the affected app’s request path. Reinstalling removes useful clues and won’t identify the cause.
7. Restore settings and prepare a reproducible issue report
Once you’ve identified the cause, undo test changes that aren’t relevant. Restore the On Demand conditions and routing mode you need, keeping only verified fixes. Reconnect and test websites, sign-ins, and apps that rely on UDP on your usual network to make sure the fix hasn’t broken other connections.
- Include your platform, network type, when the issue occurred, and whether the network had just changed. Get version information from the app itself rather than relying on memory.
- Describe the steps to reproduce the issue, for example: “Disconnected: sites load; connected in Config: requests fail; same server in Proxy: sites load.” Note whether you reconnected between each step.
- Include relevant English error messages, matching rules, and outbound policies. Before sharing, redact subscription tokens, passwords, UUIDs, private keys, and personal network details.
- If the server is unavailable or your account has an issue, contact your service provider. For help understanding your configuration, see this site’s user guide and FAQ.
This guide assumes you already have your own service provider and subscription. This site covers client configuration and troubleshooting only. Getting the client and subscribing to a network service are separate matters: a one-time app purchase does not include a network plan.