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

1. Distinguish Tunnel Status from Website Connectivity

A VPN indicator on an iPhone or iPad means the system has established the corresponding local network tunnel. A webpage still depends on DNS resolution, policy selection, a remote connection, and a response from the destination. A failure at any stage can leave the connection switch on while the page keeps loading. Toggling the switch repeatedly won’t identify where the problem lies.

First note whether the issue affects every app, every webpage, or just one domain. Also record whether you were on Wi-Fi or cellular when it failed. A page loading in your browser only confirms that particular request worked; it doesn’t prove that other protocols or destinations are reachable. Use the same known test page for comparisons rather than trying lots of different websites.

1. Record the Current Setup

   In Home, note the selected server, the current Global Routing mode, and when the failure occurred. In Config, note the active configuration and save a copy before making changes. Don’t overwrite the original configuration.

2. Test the Local Network

   Go to Settings → On Demand, note the current state, and temporarily turn off automatic connection. Then turn off the connection switch in Home. Try a page that normally works without a proxy. If it still fails, check Wi-Fi sign-in, signal strength, or the local network first.

3. Switch Networks

   Test the same page over Wi-Fi and cellular, then reconnect Shadowrocket. If it fails on only one network, keep the server and configuration unchanged and check that network’s DNS resolution, access restrictions, and connectivity first.

4. Send a Fresh Request

   After each setting change, reconnect and open a new page to trigger a request. Existing connections and cached pages may still reflect the previous settings, so don’t rely on an already-open tab to tell whether a change worked.

2. Check Server Settings and the Outbound Connection

In Home, check which server is selected and open its edit screen. Compare its address, port, Type, and authentication details with the original parameters for your own service. A server appearing in the list doesn’t mean it’s still valid. A latency test result also doesn’t guarantee that the full connection needed to load a webpage will succeed.

If you already have multiple valid servers, compare them by switching servers without changing Global Routing or DNS. If only one entry fails, check its parameters and remote status first. If all entries fail, consider the local network and any shared DNS settings. This guide does not provide, sell, or recommend servers or subscriptions.

3. Use Global Routing to Narrow Down the Issue

Check the current mode under Home → Global Routing. Proxy, Direct, Config, and Scene work differently. When troubleshooting, first confirm which policy is handling the traffic. Proxy can be a useful temporary comparison, but it won’t fix every network issue.

For a comparison, keep the server and destination domain the same. Reproduce the issue in the original mode, briefly switch to Proxy, reconnect, and test again. Then restore the original mode. If Proxy also fails, DNS isn’t ruled out. If Config fails but Proxy works, that alone doesn’t prove FINAL is misconfigured; check whether the matching policy points to a different, unavailable server.

• Only Config fails: Check the active configuration, the rule matching the destination, and the policy group’s actual selection.
• Only one Scene fails: Note the current network environment and check the Scene’s conditions and outcome. Don’t rely on an earlier result after switching networks.
• Both Proxy and Config fail: Continue by checking shared server parameters, the DNS resolution path, and the local network.

4. Check DNS: Successful Resolution Doesn’t Guarantee a Connection

If the server address is a domain name, it must be resolved first. Resolving the destination website’s domain is a separate request. So a successful server latency test and successful resolution of a website’s domain are not the same thing. First identify whether the server domain or destination domain is failing, then check its DNS resolution path.

1. Open Config and check the DNS settings in the active configuration. Also review the relevant settings under Settings → DNS, and make sure you aren’t treating a value from an inactive configuration as the current one.
2. Check the resolver address, how it’s used, and whether it’s reachable. Encrypted DNS still depends on a network connection. Entering an HTTPS resolver address doesn’t guarantee that it’s accessible through the current route.
3. If you changed DNS earlier, note the original value and temporarily restore a setting you’ve verified works. Then send a fresh request to the same destination. Don’t change the server, resolver, and rules all at once.
4. If the log shows that the destination IP was resolved but the subsequent connection timed out, investigate the outbound path and destination service. If the request stopped at DNS resolution, check the resolver connection and the domain itself.

Don’t rely on entering the destination IP directly in a browser as your only test. HTTPS services often depend on the domain name, TLS service name, and virtual host configuration. Visiting an IP directly may cause a certificate error or show different content. IPv4 and IPv6 may also have different reachability. Use the address type shown in the logs to narrow down the issue instead of permanently disabling an address family to mask a network problem.

5. Check Rule Order, FINAL, and Policy References

When Global Routing is set to Config, open the configuration that’s actually active and check the rule order. Standard routing rules are evaluated in sequence, so an earlier match may prevent a later rule from taking effect. FINAL is a fallback rule; it doesn’t replace all preceding rules or fix server authentication failures.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

This is only a syntax example, not a complete configuration to copy as a replacement. example.com is an example domain; PROXY must refer to a valid proxy policy or policy group in the current configuration. If that name refers to something else, check its actual definition rather than guessing the outbound route from the English name alone.

• DOMAIN-SUFFIX: Check whether the destination hostname matches this suffix. A webpage may request resources from multiple domains. Loading the main document doesn’t mean images, APIs, and sign-in requests use the same route.
• IP-CIDR: Matches an IP address range. In this example, no-resolve means the rule won’t actively resolve a domain for matching. Interpret the result in the context of the address information already available for the request.
• GEOIP: Matches against an IP geolocation database. It doesn’t indicate the website’s language, domain suffix, or the user’s location.
• FINAL: Handles requests that didn’t match earlier rules. If it points to an unavailable policy group, pages that didn’t match a preceding rule may fail in batches.

Copy the configuration before making changes. Then adjust only one rule or policy related to the failing destination and test again after re-enabling the configuration and reconnecting. If the issue clears, still check the request log to confirm that the expected rule matched. Don’t replace the entire ruleset or switch permanently to Proxy just because a page happened to load.

6. Retest Using Error Logs and Restore Your Settings

In the app’s connection records or logs, find the request matching the time of the failure and the destination domain. Check the resolution result, policy, and error details. The following are examples of errors that may appear in network logs. Actual messages may include addresses or other context. They help identify the stage of failure but don’t prove that a particular setting is wrong.

If there’s no clear error, record the network, server, Global Routing mode, destination domain, time, and symptoms together. For example, “On Wi-Fi, Config timed out; with the server unchanged, the same page loaded after switching to Proxy” is more useful than “connected but not working.” This is an example of how to record an issue, not a test result from this guide.

1. Restore any Global Routing, DNS, and configuration settings changed temporarily for testing. Keep only changes confirmed to be necessary through comparison.
2. Once a manual connection is stable, restore Settings → On Demand to its original behavior if needed, then verify what happens when the network changes.
3. Test one page that was already reachable and the page that previously failed. Check that the page’s APIs and other resources also work.
4. When contacting your own service provider, include the protocol, port, time, and a redacted error log. Hide the full subscription URL, passwords, keys, and account identifiers.