Shadowrocket Connected but No Internet? Check Server, Global Routing, DNS & Rules

At a glance

An enabled Shadowrocket connection only confirms that the local connection is active. It doesn’t guarantee that the remote server, DNS, or destination website is reachable. This guide is for users who have imported their own configuration but can’t load webpages. First check your baseline connection with Shadowrocket off, then verify the server, routing option, DNS resolution, and matching rule in order. Change one thing at a time, note the result, and restore your usual routing setup when finished.

1. Narrow down the issue and preserve your configuration

Before troubleshooting, save a copy of your current configuration. Note the server selected in Home, the current Global Routing option, and the configuration in use under Config. The steps below use the Home, Config, and Settings menus on iPhone and iPad; on other platforms, check the corresponding options rather than relying on menu locations as proof of a successful connection. These steps assume you already have your own provider and subscription.

Record the current state

Note the URL that fails, when the issue occurred, whether you were on Wi-Fi or cellular, and the browser error. Don’t refresh your subscription, change DNS, and rewrite rules all at once—you won’t know which change made a difference.
Pause automatic connections

Go to Settings → On Demand, note the current settings, and temporarily turn off automatic connection triggers. Then return to Home and disconnect. This prevents a condition from automatically reconnecting while you test your baseline network.
Check your baseline connection

With Shadowrocket disconnected, try a website that normally opens directly. If it still fails, first check for a Wi-Fi sign-in page, router issues, or cellular data problems. On public Wi-Fi, complete network authentication first.
Compare results

Reconnect and test both the site that failed and another site you know is reachable. If only one domain fails, check its rules, DNS resolution, and website status before reinstalling the app.

If switching to cellular fixes the issue while the same configuration continues to fail on Wi-Fi, that points to a network-path difference; it doesn’t prove the protocol settings are correct. For the next checks, use the same server and destination so you don’t change two variables at once.

2. Check the server: a successful Connectivity Test doesn’t guarantee webpages will load

In Home, confirm which server is actually selected, then run Connectivity Test. A server appearing in the list doesn’t mean it’s the default; check your selection again after updating a subscription. If the test times out, first verify the server address, port, and authentication details rather than changing routing rules. A response only confirms that the specific test path works—not that every website or transport will work.

Address and port: Open the server editor and compare Address and Port with your connection details. The server port is set by the server configuration; don’t change it to 443 just because the website uses HTTPS.
Authentication and protocol: The Shadowsocks encryption method and password, VMess / VLESS UUID, or Trojan password must match the server configuration. Don’t change only Type while leaving parameters from another protocol in place.
TLS and transport: For connections that require TLS, check the server name and relevant transport settings. Don’t hide a name mismatch or incorrect device time by turning off certificate verification.
Subscription changes: If your provider changed an address or credential, update your own subscription and select the server again. A successful import only means the configuration was read; it doesn’t mean the remote server is accepting connections.

Error: `connection refused`

Cause: The destination explicitly refused the connection, often because the port isn’t listening or a network device actively rejected it. Fix: Check Address and Port against your server details, then ask your provider whether the service is running. Changing DNS repeatedly usually won’t fix a refused port.

Error: `i/o timeout`

Cause: An operation didn’t finish in time. The timeout may occur during connection, handshake, or data transfer. Fix: Check the destination address and stage shown near the error, then repeat the test on another network. A timeout alone doesn’t prove that DNS is at fault.

3. Check Global Routing: compare Proxy and Config

Go to Home → Global Routing and check the current option. Direct sends ordinary destination requests directly; a destination that requires a proxy may fail in this mode, which doesn’t mean the server is unavailable. Config routes traffic according to the active configuration. Proxy is useful for temporarily testing the proxy path. For Scene, check the selected scene’s settings—its name alone doesn’t tell you where traffic is going.

Option	How it helps with troubleshooting	Next step
Proxy	Temporarily sends ordinary destination requests through the proxy, reducing interference from routing rules.	Retry the same failing URL. If it still fails, continue checking the server and DNS resolution.
Direct	Check whether the destination can connect directly.	Don’t treat a failed direct connection as a failed proxy server.
Config	Applies the policy defined by the active configuration’s rules.	If only this option fails, check which rule matches and where its policy sends traffic.
Scene	Uses the selected Scene’s settings.	Check the active Scene’s settings; for comparison, switch to an option with a clearly defined routing behavior.

If Proxy works but Config doesn’t, check the rules first

Keep the same server and network, switch Global Routing from Proxy back to Config, and try again. If the issue consistently returns with Config, first check the policy matching the destination domain rather than reimporting the entire subscription. DNS resolution may also differ by configuration path, so check the resolved addresses too.

4. Check DNS: distinguish a resolution failure from a connection failure

DNS resolves domain names to addresses. If your browser says it can’t find the server, DNS may be the issue, but check the logs: Was an address returned? Was it IPv4 or IPv6? Did a connection attempt follow? Don’t rely on entering the website’s IP address as your only test. HTTPS certificates and virtual hosts often depend on the domain name, so an error after entering an IP doesn’t prove DNS is working—or failing.

Traditional DNS commonly uses UDP, and can also use TCP, on standard service ports.

A / AAAA

These records correspond to IPv4 and IPv6 addresses; the two paths may behave differently.

1 item

Change one DNS-related setting per test and retry the same domain.

Go to Config, open the currently active configuration, and check dns-server under [General]. Also check whether a [Host] mapping affects the same domain. Editing an inactive configuration won’t change the test results.
If you use a custom DNS server, first confirm it’s reachable on your current network. Switching to another DNS address that’s also unreachable won’t help. Don’t change the proxy server and DNS at the same time.
If your configuration uses encrypted DNS, check its hostname, certificate, and network path. If the DNS service itself can’t connect, many unrelated websites may fail—not just one domain.
After making a change, save it, reconnect, and reopen the page that failed. The browser, system, and app may all cache results, so don’t rely on the error in an already-open tab.

If the log shows a destination IP but the connection then times out, check the network path to that address, IPv6 reachability, and the final policy instead of repeatedly switching DNS servers. If you suspect an IPv6 path issue, note the AAAA result and connection address, then run a temporary comparison. Restore the original settings afterward; disabling IPv6 globally isn’t a universal fix.

5. Check rule order: find the first matching policy

In Config, check the configuration that’s actually active—not just its filename. Standard routing rules are evaluated in order, and the first matching rule determines the policy; a correct rule lower down may never run. Pay particular attention to broad DOMAIN-SUFFIX rules, IP-CIDR rules covering the destination address, and the fallback FINAL rule.

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

This example is only to illustrate rule structure; you don’t need to replace your existing configuration. example.com is a sample domain, and PROXY and DIRECT are policy names. If your configuration uses a custom policy group, make sure it contains a working server and isn’t set to an inactive entry.

DOMAIN-SUFFIX: DOMAIN-SUFFIX,example.com,PROXY matches the domain and its subdomains. Put specific destinations that need special handling before any broader rules that might match first.
IP-CIDR: Matches an IP address range. In this example, no-resolve means the client won’t proactively resolve a domain just to match this IP rule; it doesn’t mean DNS is never needed during the connection.
GEOIP: Matches based on geographic data for the destination IP. It doesn’t determine location from a website’s language or domain suffix. Changes in the resolved address can affect the match.
FINAL: Handles requests that haven’t matched any preceding rules and is usually placed last. If the fallback is DIRECT, an unclassified destination that requires a proxy may fail to connect directly.

When retesting, check the rule and final policy for the same domain. A page may also request images, APIs, and login domains. If the main page loads but sign-in fails, check the failing subrequests rather than adding a rule only for the homepage domain. When you’re done, restore Config and remove any temporary diagnostic rules.

6. Common questions: subscription updates, automatic connections, and partial failures

The subscription updated successfully. Why can’t I connect?

A successful update only means the subscription content was retrieved. In Home, confirm the default server again and run Connectivity Test. Then check your account status and connection details against your provider’s information. Don’t assume an updated entry works just because an older one did.

Why does it reconnect after I turn it off?

Go to Settings → On Demand and check whether a trigger condition matches your current network. Temporarily turn it off during troubleshooting and note the original settings. Restore them after checking your baseline connection to prevent automatic reconnections from affecting the results.

Web pages load, but video or calls don’t. What should I check?

First check whether the failing feature uses different domains or UDP. Then check the relevant request’s policy and server support. A successful TCP connection for a webpage doesn’t mean UDP is available. Hysteria2 and WireGuard rely on UDP, so check for network restrictions on that path.

I’ve tried everything and it still fails. Should I reinstall?

Restore your saved configuration first, then retest in order: server, Global Routing, DNS, and rules. Keep the failure time, network type, destination domain, and redacted logs, and ask your provider to check the remote server. Reinstalling won’t fix a remote port that isn’t listening or expired credentials.

7. Restore your usual setup and save reproducible results

Once the issue is resolved, identify which change fixed it before reverting temporary changes. If it works only after switching to Proxy, don’t conclude that the problem is fixed; switch back to Config and verify the routing rules you need. If changing networks resolves the issue, record which destinations failed on the original network so you don’t mistake a network restriction for a broken configuration next time.

Restore your usual Global Routing option and confirm the active Config and default server.
Restore Settings → On Demand using your notes, then check that it connects as expected when you switch networks.
Test a destination that connects directly, one that requires a proxy, and the specific feature that originally failed.
Save a copy of the repaired configuration and note the changes and comparison results. Don’t save or share public logs that contain credentials.

To get the app again, choose your platform on the download page. The iPhone / iPad developer is Shadow Launch Technology Limited; check the App Store listing for system requirements. The app’s purchase price is separate from any network service you already have; buying the app doesn’t include a service plan.