Shadowrocket Connected but No Internet? Check the Server, Routing Mode, DNS, and Rules

At a Glance

The connection switch in Shadowrocket indicates that the local VPN tunnel is active; it doesn’t mean the destination website is reachable. For users who have imported their own service configuration, this guide walks through checks for the server, Global Routing, DNS, and rules. It helps distinguish local network, remote connection, name resolution, and routing issues. Change one setting at a time, test, then restore the original value.

Before You Start: Keep Test Conditions Consistent and Confirm Your Internet Connection

Note the selected server and Global Routing setting on Home, along with the active configuration in Config. Use the same device, network, and destination domain throughout troubleshooting. Changing Wi-Fi, servers, and configurations at the same time makes it impossible to tell what affected the result. This guide assumes you already have your own service provider and subscription. We don’t provide, sell, or recommend servers or subscriptions.

Turn off the Shadowrocket connection switch and try a website that normally opens directly. If it still won’t load, check whether Wi-Fi requires a sign-in, whether cellular data works, and whether the device is on a restricted network. Changing proxy rules won’t help at this stage. Restore basic internet access first, then turn the connection back on and test again.

Note the Original Settings

On Home, note the selected server and Global Routing setting. In Config, note the active configuration name. Keep a copy of the configuration before editing; store the original file and subscription credentials only on your own device.
Check On Demand

Go to Settings → On Demand and note the current setting. If the connection turns back on automatically after you switch it off, temporarily disable On Demand during testing so it doesn’t affect the comparison.
Establish a Baseline

Turn off the connection switch and test a website you know you can access directly. If the network requires authentication, complete its sign-in process first; don’t mistake an incomplete login for a server problem.
Choose Consistent Test Sites

Choose one domain that works when accessed directly and one that’s having problems. Note what happens with the connection switch off and on. Revisit both sites after each change.

Check 1: Make Sure the Server Selected on Home Can Handle Requests

Go to Home and make sure the selected server is the one you intend to test—not an older entry with a similar name. Open its edit screen and check the server address, port, protocol, and authentication details. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields. Compare each one with the details from your own service provider; changing Type while leaving the other fields untouched won’t work.

When you run Connectivity Test on Home, distinguish between a test that reports a latency value and a successful browser request. Different test methods check different parts of the connection. A successful TCP connection only confirms that the relevant port is reachable; it doesn’t prove that authentication, the TLS handshake, UDP traffic, or access to the destination website is working. Make a real browser request to check the rest of the connection.

Address and port: Check that the server’s domain or IP address and service port match the original details. Port 443 is commonly used for HTTPS, but not every service uses it, and entering it doesn’t guarantee a connection.
Authentication and transport: Check fields such as the password, UUID, and TLS Server Name only when the protocol uses them. Don’t turn off certificate verification just to clear an error. First confirm the server name, device time, and server certificate.
Existing subscription: If the configuration comes from your own subscription, update that subscription on Home, then select an entry from the refreshed list. A successful update means the list was retrieved; it doesn’t mean every server in it can reach the destination website.
Network differences: If the same entry works on cellular data but fails on Wi-Fi, first check whether that Wi-Fi network restricts the relevant port or UDP traffic. Switching networks is useful for comparison, but don’t change the protocol and DNS at the same time.

The following are generic error strings that may appear in network logs; not every protocol displays the same text. Use the surrounding log context to identify what failed: the server, a DNS resolver, or the destination website.

Error: connection refused

Cause: The connection was actively refused. This commonly happens when no service is listening on the destination port or the connection is explicitly rejected.

What to do: Check the address and port in the log. If the destination is your own server, ask your service provider to confirm its status and the correct port.

Error: i/o timeout

Cause: A read or write operation didn’t finish in time. Possible causes include packet loss, an unreachable port, or no response from the remote host.

What to do: Keep the server settings unchanged and test on another working network. Then check the server connection or DNS request, based on when the error occurs.

Error: no such host

Cause: The hostname couldn’t be resolved to a usable address. It may be the server’s hostname or the destination website’s domain.

What to do: Check that the domain is spelled correctly and still valid, then troubleshoot DNS. If the server’s hostname itself can’t be resolved, changing the proxy policy alone won’t fix it.

Check 2: Use Global Routing to Separate Proxy Connection Issues from Configuration Problems

On Home, check the current selection under Global Routing. Proxy sends eligible requests through the proxy path; Direct uses a direct connection; Config applies the active configuration; Scene uses the selected scene to determine what happens. Scene doesn’t automatically mean Proxy or Config, so check the settings used by the current scene.

With the same server and network, temporarily select Proxy and retry the problem domain. Then switch back to Config and try again. If the site works with Proxy but not Config, the issue is more likely in the rules, the selected policy, or another part of the configuration—not a completely unavailable server. Restore the original mode after testing; don’t treat a temporary comparison setting as a permanent fix.

Mode	What It Tests	How to Interpret the Result
Proxy	Test the selected proxy path	If the request works, it can use the proxy under the current conditions. That doesn’t mean every domain will work.
Direct	Establish a direct-connection baseline	Test only a website known to work with a direct connection. If the destination doesn’t support direct access from your current network, a failure won’t identify the cause.
Config	Test the active configuration	If the result differs from Proxy, check rule matching, the selected policy, and DNS or other configuration differences.
Scene	Check the selected scene	Confirm the scene’s active settings before comparing it with a fixed mode. This avoids introducing extra variables when the scene changes.

Bottom Line: Check the Rules After Confirming Proxy Works

If the same destination works with Proxy but fails with Config, keep the working server and check the active configuration and matched policy. Don’t rebuild the server entry at the same time, or you’ll lose a useful comparison.

Check 3: Distinguish Server DNS from Website DNS

DNS may be involved at two points: first, resolving the server’s hostname to an address; then, resolving the destination. A failure at the first step can prevent the server connection. A failure at the second can leave the connection established while webpages fail to load. When checking logs, identify the full domain that failed to resolve. Don’t replace all DNS settings just because you see a DNS-related message.

In Config, open the active configuration and check dns-server in [General]. Also look for [Host] mappings that affect the destination domain. An old private-network DNS server, an unreachable resolver, or a domain mapped to an outdated address can affect the result. If DNS is set in multiple places, check the configuration that’s actually active so you don’t edit an unused file.

2 places

Check resolution for the server hostname and destination domain separately

Traditional DNS commonly uses UDP or TCP ports

443

DoH typically uses an HTTPS port; this isn’t the port used by all DNS

First, check that the domain in the error is spelled correctly. Make sure it isn’t an outdated server hostname or an incorrect webpage address.
After saving a copy of the configuration, you can temporarily set dns-server = system to compare system DNS resolution. This isn’t a universal recommendation; system DNS can also be affected by the current network.
Check whether [Host] contains an outdated address for the problem domain. Remove only mappings confirmed to be incorrect; don’t delete unrelated entries.
Save the configuration and confirm it’s selected. Reconnect, request the same domain, and compare the result with the one you recorded before making changes.

Check 4: Review Rule Order and the Selected Policy in Config

If Proxy works but Config doesn’t, confirm the selected file in Config, then check its [Rule] section. Rules are generally evaluated from top to bottom, and the matching rule’s policy is applied. A broad rule near the top can take precedence over a more specific one below it. Editing a different, inactive file won’t change the rules used by the current connection.

DOMAIN-SUFFIX matches a domain and its subdomains; IP-CIDR matches an IP address range; GEOIP classifies requests using an IP geolocation database; and FINAL handles requests that didn’t match earlier rules. Domain and IP rules match different kinds of targets. For IP-based rules, consider whether an address has already been resolved; rule order can’t be treated as completely independent of DNS.

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

This configuration is for syntax illustration only: example.com is an example domain, and 192.0.2.0/24 is a documentation-only network range. Don’t use them to test real service availability or replace your production configuration with this entire example. no-resolve means the IP rule won’t trigger a resolution attempt; it doesn’t disable DNS globally.

Matched DIRECT: The request uses a direct connection. If the destination isn’t reachable directly on your current network, check whether an overly broad domain or IP rule matched first.
Matched REJECT: The rule rejected the request. Find the specific rule and check its purpose. If it’s blocking the request by mistake, make a precise change rather than deleting every reject rule.
Matched PROXY: Check which proxy destination is being used. If the rule points to a custom policy group, confirm which member is selected; the indicator on Home alone isn’t enough.
Fell through to FINAL: None of the earlier rules matched. Check that the final policy is what you expect, and place any necessary specific rules before broader rules that could take precedence.

When testing again, look up the same destination domain in Shadowrocket’s request history or logs, and check the matched rule and final policy. A webpage may also request images, scripts, and sign-in endpoints. If the main domain works but the page is blank, check which resource domain failed instead of repeatedly adding duplicate rules for the main domain.

Common Questions: Choose the Next Check Based on What You See

Why does the test show latency if the browser still can’t open websites?

First, check which method Connectivity Test used, then try an actual webpage. A port may be reachable even though authentication fails, causing this symptom. On Home, verify the protocol and authentication details, then check whether the failure occurs during connection, handshake, or request handling.

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

Keep the server and Global Routing settings unchanged. First check basic Wi-Fi access and any sign-in page, then compare DNS and port reachability. If the service uses UDP, check whether the network restricts it. A network difference alone doesn’t mean the account is invalid.

Only one website won’t open. Should I reset all settings?

First compare Proxy with Config, then check DNS resolution and the matched policy for that domain. If other sites work, at least part of the connection is available. If the same destination fails in both modes, also consider the destination site’s response and access restrictions.

I changed the configuration, but nothing changed. What should I check?

In Config, confirm that the edited file is selected. Go to Home and make sure Global Routing is set to Config, then reconnect and test again. If you’re using Scene, check its active settings first. After testing, restore the original Settings → On Demand setting.

If you still can’t identify the cause, note when the issue occurred, the network type, protocol name, Global Routing setting, failed domain, and a redacted excerpt of the error. Share these details with your own service provider. Don’t disclose complete subscription links, passwords, UUIDs, private keys, or screenshots containing access tokens. Keep these sensitive details separate from your troubleshooting notes.