Shadowrocket Connected but No Internet: Server, Routing, DNS & Rule Troubleshooting

At a glance

Turning on the Shadowrocket connection switch confirms that a local VPN connection has been established. It doesn’t confirm that the selected server, DNS, or destination website is reachable. This guide is for users who already have their own service provider and subscription, can connect, but can’t browse normally. Work through four layers, changing one setting at a time and testing the same destination with a new request.

Before you start: distinguish Connected from reachable

The system VPN status means your device is routing the relevant traffic through a local tunnel. Whether the remote server accepts the connection, the domain resolves, and the request follows the intended policy are separate steps. Toggling the switch repeatedly won’t fix an incorrect server port or a misconfigured rule.

First, save a copy of your current Config. Note the server selected in Home, the current Global Routing value, and whether the issue occurs on Wi-Fi or cellular. During testing, use the same HTTPS website that you regularly visit and know is normally reachable. Changing destinations between steps makes results harder to compare.

4 layers

Server → Mode → DNS → Rules

1 setting

Change one variable per test, then make a new request

443

Common HTTPS port—not necessarily the server’s actual port

Common port for traditional DNS—not all DNS transports

Temporarily disconnect Shadowrocket and check whether your current network can reach a website that normally works without a proxy. On public Wi-Fi, complete any captive portal sign-in first.
If the switch turns itself back on, check Settings → On Demand. Note the current settings, then temporarily turn off On Demand so it won’t interfere with manual testing.
Reconnect and make a new request to the same destination. Quit and reopen the target app before testing to avoid misleading results from reused connections.

Step 1: Check that the selected server is actually working

In Home, check which server is selected rather than just whether a subscription group is present. Successfully importing a subscription means its configuration data can be read; it doesn’t mean every server in it is online. A successful subscription update also doesn’t confirm your account quota, service status, or access to the destination.

Check the selected server

Open Home and confirm the server selected for this test. If you use a policy group, check which member it actually selects so your test matches your notes.
Check the parameters

Open the server’s edit screen and compare Type, address, and Port with the details from your service provider. Use the port they specify; don’t change it to 443 just because the website uses HTTPS.
Run a test

Use Connectivity Test in Home to check reachability, then try opening the website itself. A successful test applies only to its particular method and destination; it doesn’t replace testing a real request.
Compare results

Switch to another server you already have while keeping the network, mode, and destination unchanged. If only one server fails, check its parameters and service status first instead of rewriting the entire Config.

Protocol parameters must match the server. For example, a Trojan password and TLS hostname, or VMess and VLESS identity details, transport, and path can all affect the handshake. Don’t switch protocols based on a single timeout, and don’t hide hostname or certificate errors by disabling certificate verification.

Error: Connection timed out

Cause and fix: If this exact message appears in the connection log, the operation did not complete within the allotted time. It doesn’t by itself show whether the server is down or the network path is blocked. Check the address and Port first, then compare Wi-Fi and cellular using the same configuration and ask your service provider to confirm the server status.

Error: Connection refused

Cause and fix: If this exact message appears in the connection log, the connection to the destination port was usually actively refused. First determine whether the logged destination is the server or the website, then check the corresponding port and whether the service is listening. Reconnecting repeatedly won’t fix an incorrect port.

Step 2: Use Global Routing to distinguish a mode issue from a server issue

Go to Home → Global Routing and note the current value. Proxy, Direct, Config, and Scene serve different purposes. Scene routes traffic according to its configured conditions, so selecting Scene alone doesn’t tell you which path a particular request will take.

Option	What to check	How to interpret the result
`Proxy`	Temporarily test the proxy route	If the destination loads, the selected proxy route handled this request. Next, check how Config routes the request.
`Direct`	Compare with a direct connection	If a destination that should work directly still fails, check your local network and DNS too; don’t assume the server is the only cause.
`Config`	Follow the current configuration rules	If only this mode fails, focus on the active Config, rule order, policy groups, and related DNS settings.
`Scene`	Apply scene conditions	Check which scene matches the current network and what configuration it uses. For comparison, temporarily switch to an explicit Proxy or Config mode.

After switching modes, reconnect the target app before testing. Existing long-lived connections may still reflect the previous mode, and a single page refresh may use cached data. For a Direct comparison, choose a destination that normally works without a proxy; one unreachable destination doesn’t prove your entire local network is down.

Takeaway: If Proxy works, leave the server settings alone for now

With the same server, network, and destination, if Proxy works but Config doesn’t, check the policy actually matched and the DNS settings in Config. Don’t change the protocol, server port, and rules all at once.

Step 3: Check DNS resolution and the connection made afterward

DNS resolution happens before a destination can be reached. If the server address is a domain name, that name must be resolved first too. A DNS issue can affect the destination website or prevent the proxy connection from being established at all. In the logs, identify which domain failed to resolve.

Open Config, confirm which configuration file is active, then check its DNS settings and the [General] section in the raw text. The common dns-server setting specifies a resolver. System DNS, custom traditional DNS, and encrypted DNS use different network paths; matching address strings alone doesn’t mean they behave the same way.

[General]
dns-server = system

This is only a DNS configuration snippet, not a complete configuration file. To temporarily test system DNS, edit the existing dns-server entry in a backed-up copy of your configuration. Don’t add multiple entries with the same name or overwrite existing rules. System DNS depends on the current network and isn’t a universal fix for every destination.

Check the resolution result: For the new request you just made, check the log for a domain resolution failure or an A/AAAA address. Getting an address means the resolution step returned a result; it doesn’t mean the address is reachable.
Check the resolver path: Traditional DNS commonly uses UDP or TCP port 53; DoH typically uses HTTPS on port 443. Being able to open regular websites doesn’t prove that a custom DNS service is reachable.
Check for IPv4/IPv6 differences: If DNS returns an AAAA record but the current network has no working IPv6 route, some requests may time out. Compare Wi-Fi and cellular first, then adjust the relevant settings.
Rule out cached results: Save the configuration and reconnect, then have the target app establish a new connection. Keep the before-and-after resolution results so you don’t mistake an old cached address for the result of the new settings.

Step 4: Check the active Config and the rule that actually matched

Confirm that Home → Global Routing is set to Config, then check which file is active in Config. Editing a copy doesn’t make it the active configuration. Rules are usually evaluated in order, and the first matching rule determines the request’s policy. Look for the rule that actually matched, not just whether the domain appears somewhere in the file.

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

This example illustrates rule order only: example.com and its subdomains match DOMAIN-SUFFIX and go to PROXY; unmatched requests fall through to FINAL,DIRECT. Here, PROXY must refer to a proxy policy available in the active configuration. If you use a custom policy group, put its defined name at the end of the rule. Don’t use this snippet as a replacement for a complete Config.

Check the domain scope: DOMAIN-SUFFIX,example.com,PROXY won’t match a completely different resource domain. If the main page loads but images or sign-in fail, check the actual hostname of the failed resource.
Check for an earlier match: Look for a rule before the target rule that sends the request to DIRECT or REJECT. Adding a domain rule after FINAL won’t override it as intended.
Check IP rules: GEOIP and IP-CIDR match against IP addresses; they aren’t domain suffix rules. Check the request’s resolved address and the configuration’s DNS options to determine which rule matched. Don’t infer the result from the website’s name alone.
Check where the policy routes traffic: If the log shows a policy group match, check which member is currently selected. A match for the correct group name doesn’t mean its selected server is working.

A webpage may connect to its main domain, static assets, and authentication domains separately. If the main document loads but the page keeps spinning, note the failed request and its policy. Don’t immediately route all traffic through Proxy as a long-term fix. Temporarily switching modes helps isolate differences; the permanent fix should target the specific rule that needs adjustment.

Common questions: Where should you look next?

Connectivity Test shows a result. Why won’t the website load?

The test reflects only its own method and destination. Make a new request to the same website and check the destination’s DNS resolution, the policy actually used, and any connection errors. In particular, distinguish server reachability, a successful protocol handshake, and access to the destination website.

Wi-Fi fails but cellular works. What should I change first?

Keep the server, Global Routing, and Config unchanged, and test by switching networks. Complete Wi-Fi sign-in and check that network’s DNS and IPv6 behavior. If the same server fails only on one network, investigate that network path first rather than rebuilding the subscription.

Still no internet after updating the subscription. Should I refresh it again?

First, check the item actually selected in Home after the update, then compare it with the parameters and account status provided by your service provider. Refreshing retrieves configuration data; it can’t restore a discontinued service or automatically fix unsuitable routing rules in your local Config.

The connection turns back on after I switch it off. How can I compare results?

Go to Settings → On Demand, note the current settings, then temporarily turn off On Demand and control the connection manually. After troubleshooting, restore the original settings and check automatic connection behavior on your usual Wi-Fi and cellular networks.

Wrap up: Save reproducible notes and restore your usual settings

After troubleshooting, restore the Global Routing and On Demand settings you need and confirm that the corrected Config is active. One successful visit doesn’t guarantee every app will work. Retest at least the page that originally failed, its key resources, and a request from another app you use regularly.

Record the conditions: Network type, your local note for the selected server, Global Routing value, active Config name, and test time.
Record what changed: For example, “The same destination works in Proxy but times out in Config” is more useful for diagnosis than simply saying “It won’t connect.”
Record the error: Keep the destination domain, matched policy, and exact error message for the relevant request. When contacting your own service provider, share only the information they need.
Remove sensitive information: Before sharing logs, remove subscription tokens, passwords, UUIDs, private keys, and other credentials. Don’t share a complete subscription link.

For more configuration steps, see the setup guide. To understand each setting, read the settings reference. The client purchase and any service plan you already have are managed separately; buying the client doesn’t include a service plan.