Shadowrocket Connected but No Internet: Check Servers, Routing, DNS, and Rules

1. Separate Network Issues from Proxy Connection Issues

Don’t start by deleting the app or resetting all settings. Turn off the connection switch on Home and check whether your current Wi-Fi or cellular network can reach a website that normally works without a proxy. If public Wi-Fi requires sign-in, complete network authentication first. If ordinary webpages still won’t load with the connection off, troubleshoot the device’s network access first.

If browsing works with the switch off but fails when it’s on, the issue is related to the active traffic path—but that doesn’t automatically mean the server is at fault. Incorrect DNS, a REJECT rule, outdated server settings, or a conflict with another network extension can all cause similar symptoms.

1. Record the current settings

   On Home, note the selected server and Global Routing mode. In Config, note which configuration file is active. Keep a copy of the configuration before editing, and never share passwords, subscription links, or access tokens publicly.

2. Check direct access

   Turn off the connection switch and use a browser to open a website known to work directly. If public Wi-Fi displays a sign-in page, complete authentication, then return to Home.

3. Choose a test page

   Pick the full URL of a webpage that fails. After each change, reload that same URL to distinguish a timeout, a DNS lookup failure, and a normal HTTP error response.

4. Compare networks

   If cellular data is available, compare Wi-Fi with cellular while keeping the server, mode, and configuration unchanged. If only one network fails, first check its restrictions and DNS resolution conditions.

2. Check the Server and Connectivity Test on Home

On Home, confirm that the selected server matches your own valid service details, then run Connectivity Test. A response only confirms that the path used by that test received a response; it doesn’t guarantee that browser DNS, rule matching, or access to the destination website is working. Likewise, a single timeout doesn’t prove the server is down. Check actual requests and compare results on another network.

Open the selected server’s edit screen and compare its type, address, port, and authentication fields with your service details. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields; don’t change Type just to see what happens. If your original details enable TLS, check the relevant server name and certificate validation settings. Disabling validation is not a routine fix.

• Address: Check for extra spaces and typos in the hostname. A server specified by hostname also depends on DNS resolution.
• Port: Use the port in your existing service details. For example, if they specify 443, verify that the port is 443. Don’t change your port to 80 or 443 just because those ports are common.
• Authentication: The password, UUID, key, and encryption settings must match the server. Establishing a lower-level connection doesn’t mean authentication succeeded.
• Subscription: If your provider has changed the server details, update the existing subscription on Home, then check the selected server again. A successful update doesn’t mean every server in the subscription is usable.

Use the exact error message to guide your checks—not just the word “timeout”

If the connection log or diagnostic result shows one of these English errors, check the corresponding causes. The exact message depends on where the failure occurs; a webpage failing to load won’t always display one of these errors.

If only subscription updates fail while existing servers can still load webpages, treat this as an issue accessing the subscription URL. Don’t clear a working configuration. Subscription URLs may contain sensitive tokens; when reporting the issue, describe the error and where it occurs without sharing the full URL.

3. Compare Modes with Global Routing

On Home, open Global Routing and check the selected mode. Config applies the rules in the active configuration; Proxy is useful for testing proxy mode; Direct tests a direct connection. Scene depends on your own scene settings and shouldn’t be treated as equivalent to Config. Switch modes only for troubleshooting, then restore the mode you normally use.

4. Check DNS and the dns-server Setting

DNS resolves domain names to IP addresses. If the server itself uses a hostname, DNS resolution may also be needed before the proxy connection can be established. A failure to resolve the server hostname and a failure to resolve the destination website are different issues. Record them separately rather than treating both as an unavailable server.

Open Config, confirm which file is active, then open it for editing and check dns-server under [General]. The example below tests the system resolver as a single diagnostic change; it isn’t a recommendation to replace everyone’s existing configuration. If system DNS is already failing on your network, changing this setting to system won’t fix it automatically.

[General]
dns-server = system

1. Save the original dns-server line and related DNS settings so you can restore them if needed.
2. Look for typos, unreachable addresses, or leftover text from copying. The DNS server must be reachable under your current network and routing conditions; a correctly formatted address alone doesn’t prove it will work.
3. To compare with system DNS, change only this setting and save. Confirm that you’re using the edited configuration, then reconnect and reload the webpage.
4. If nothing changes, restore the original value and continue checking rules and the server. If access returns, check why the original resolver wasn’t reachable on your network.

5. Check REJECT, Rule Order, and FINAL

If only some websites fail—especially when Proxy works but Config doesn’t—check [Rule] in the active file under Config. Rules are matched in order, and the policy for the first matching rule is applied. A broad rule placed too early can prevent later, more specific rules from matching.

DOMAIN-SUFFIX matches a domain and its subdomains, IP-CIDR matches an IP range, and GEOIP matches using an IP geolocation database. These rules don’t work the same way. IP-based rules may also depend on DNS results. First identify the failing domain and the rule it actually matched; don’t substitute one rule keyword for another.

[Rule]
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT

This example rejects example.com and its subdomains, then sends requests that don’t match to DIRECT. It illustrates a possible cause of failure; it isn’t a recommended configuration. If a similar rule catches a real website by mistake, the page may not load even when the connection switch is on and the server test responds.

• Check REJECT first: Make sure the rejection rule doesn’t match too broadly. A website may also rely on login, image, or API domains. If the main page loads but sign-in fails, check the specific requests that are failing.
• Then check the target policy: A rule ending in DIRECT connects directly. If it uses PROXY, confirm the current proxy selection works. Custom policy group names must match a defined policy.
• Finally, check FINAL: FINAL,DIRECT and FINAL,PROXY send unmatched traffic in different directions. Put FINAL at the end of the rule list, after all rules that need to be matched.
• Confirm which file you’re editing: The saved file you change must be the active configuration. If it came from a remote update, keep a local copy first so a later update doesn’t overwrite your diagnostic changes.

After correcting the rules, retest the same URL with Global Routing → Config. If the main page loads but some resources still fail, identify the domains of the failed resources instead of repeatedly changing FINAL. Websites that rely on multiple domains may need more than the main domain to be allowed.

6. Check On Demand and Unexpected Reconnection

If the connection turns back on soon after you switch it off, or test conditions keep changing when you switch networks, open Settings → On Demand and note its current state. During troubleshooting, you can temporarily turn off enabled On Demand settings and control the connection manually from Home to keep comparisons consistent. Restore your usual settings when you’re done.

• Connection turns back on automatically: Check whether On Demand is triggering it before assuming the server keeps disconnecting.
• Other network extensions are enabled: Check your device’s system settings for other VPN or network-filter configurations. If it’s safe to pause them, pause and test one at a time rather than removing several configurations at once.
• Only one app fails: Use a browser to access the same service for comparison, then check the app’s network permissions and the service status. Don’t immediately route every request through the same policy.
• Need to report the issue: Note when it occurred, the network type, Global Routing mode, whether only some domains failed, the exact error, and the comparisons you’ve tried. Hide server passwords, UUIDs, private keys, and subscription tokens.

Reinstalling shouldn’t be the first step; you could lose configurations and logs needed for comparison. Check with your provider if server details are no longer valid. Correct rules that match the wrong traffic, and fix network access issues before troubleshooting the app. Pinpointing the failing component is usually more useful than repeatedly toggling the connection.

7. Common Questions and Final Checks