When Shadowrocket shows Connected, it means the VPN tunnel on your device is active. It doesn't confirm that the remote server, DNS, or destination website is working. This guide helps you narrow down the cause, step by step: check your basic network, server, Global Routing, DNS, and rules. Change one thing at a time, retest the same URL, then restore your usual settings.
1. Why can't I open webpages when Shadowrocket says Connected?
First, identify which part of the connection is failing. Establishing a VPN tunnel on your device, connecting to a remote server, resolving a domain, and loading a webpage are separate steps. Seeing the connection switch enabled in Home or a VPN icon in iOS doesn't mean a website has successfully loaded through the entire route.
What should I do first? Establish a baseline on your regular network. Note your current network, selected server, Global Routing mode, and active configuration. Temporarily disconnect Shadowrocket and open a website that normally works on that network. If it still won't load, check Wi-Fi sign-in, cellular data access, or the network itself before changing any rules.
-
Record your current settings
In Home, note the selected server and current Global Routing mode. In Config, note the active configuration. Keep a copy so you can restore it after troubleshooting.
-
Pause automatic connections
Go to Settings → On Demand, note your settings, and temporarily turn off On Demand. Then switch off the connection in Home so the tunnel doesn't turn back on while you test direct access.
-
Check the basic network
In Safari, open a website you can usually access directly. If Wi-Fi requires web-based sign-in, complete it first. Then try the same URL over cellular data for comparison.
-
Reconnect and retest
Once the basic network works, return to Home, turn on the connection, and retry the same URL. After each change below, reconnect and make a fresh request.
What does it mean if results differ between Wi-Fi and cellular? It points to a difference in the network path, but doesn't identify a specific protocol problem. Server port reachability, DNS, and network sign-in can all vary between networks. Note the difference and continue with the next comparison.
2. Does a successful server test mean I can access the internet?
No. In Home, run a connectivity test for the current server and check which test method is being used. A test that only checks whether a port accepts a connection covers different steps from a test that requests a URL through the proxy. A latency result alone can't guarantee access to every domain, transport, or destination port.
Which fields should I check first if the test fails? Open the current server's edit screen and compare its address, port, Type, and authentication details with the original information from your service provider. Don't change every port to 443 based on guesswork: 443 is commonly used for HTTPS, but the remote proxy's listening port must match the server configuration.
| Check | What to verify | Common misinterpretation |
|---|---|---|
| Address and port | Full hostname or IP address and the actual listening port | The website's port 443 isn't necessarily the proxy server's port |
| Shadowsocks | Encryption method and password | A reachable address doesn't confirm that authentication and encryption settings are correct |
| VMess / VLESS | UUID and transport settings | A correct UUID doesn't guarantee that the transport settings match |
| Trojan and TLS | Password, required TLS settings, and server name | Connecting by IP may still fail certificate name validation |
| Hysteria2 / WireGuard | Check authentication, keys, and related settings against your service details | A TCP-only test can't verify the UDP path |
Should I edit the server manually or update the subscription? If the server comes from your own subscription, first confirm that it updated successfully and that the selected entry is still within your service's validity period. Updating a subscription refreshes connection details; it doesn't confirm that the remote server is reachable. Don't repeatedly overwrite your configuration without keeping a copy. This guide doesn't provide connection services; check with your own provider to verify the settings.
Error message: Connection timed out
Cause and fix: The connection didn't complete in time. The address, port, or network path may be involved. Verify the server details, then test over both Wi-Fi and cellular. A timeout alone doesn't prove that the service has been disabled.
Error message: Connection refused
Cause and fix: The destination or an intermediate device explicitly rejected the connection. The port may not be listening, or a policy may be blocking it. Check the port and ask your provider to confirm its listening status.
Error message: No such host
Cause and fix: A hostname couldn't be resolved. First determine whether it's the server address or the destination website's domain. Check the spelling and current DNS settings; don't mistake a resolution failure for an incorrect password.
Where can I find these error messages? Check the app's connection log, diagnostic details, or system network errors. Record the exact message and when it occurred; wording can differ between requests. If you don't see a message here, don't assume the examples are diagnostics reported by your device.
3. How do I compare Global Routing modes?
Which modes should I test to narrow down the issue? Go to Home → Global Routing and note the current mode. Then make a fresh request to the same URL in Direct, Proxy, and Config. These are temporary diagnostic comparisons, not recommendations for long-term use. For the Direct test, choose a destination that your current network can normally access directly.
| Mode or result | What it means and what to do next |
|---|---|
| Direct | Use this for a direct-access comparison. It doesn't turn off the entire VPN or rule out the effect of in-app DNS settings. |
| Proxy | Use this to check the current proxy route. Confirm which server or policy is actually selected in case it has changed. |
| Config | Routes traffic according to the current configuration rules. If Proxy works but Config doesn't, check the matching rule and policy first. |
| Scene | Routes traffic according to the current Scene settings. Check the active Scene, then temporarily switch to a clearly defined comparison mode. |
| Direct works, Proxy fails | Check the proxy server, authentication, transport settings, and server hostname resolution. |
| Proxy works, Config fails | Check whether a rule sends the destination over an unsuitable route or refers to an unavailable policy. |
Takeaway: Verify the route before changing rules
If Proxy opens the same URL but Config doesn't, leave the server settings alone and check which rule matches. This avoids changing server settings you've already confirmed are working.
4. How can I tell if DNS resolution is failing?
Does a page that keeps loading mean DNS is definitely the problem? No. A DNS issue needs to be supported by resolution records or a clear resolution error. Also distinguish between two hostnames: if the server address is a domain, it must be resolved first; the destination website may use a separate DNS path. If the server hostname can't be resolved, the proxy connection itself may never be established.
Where should I check? Go to Config and inspect the DNS settings in the configuration you're currently using. Save a copy first, then check dns-server in [General] and look for any DNS settings that apply to specific domains. Changing your system's Wi-Fi DNS may not override the resolution path specified by the configuration.
- Check the address format: Look for typos, missing separators, or a resolver that can no longer be reached. Encrypted DNS also depends on whether its hostname resolves and its HTTPS connection is reachable.
- Check the transport path: Standard DNS commonly uses UDP or TCP on port 53; DoH uses HTTPS, usually on port 443. The port number alone doesn't tell you whether the current network allows access to that service.
- Revert one change at a time: If the issue started after a manual DNS change, restore the saved configuration from before the change. Don't add multiple resolvers, change modes, and replace the server all at once.
- Test a fresh request: Reconnect and reload the page, then check the new log entries. Browsers and apps may retain cached data; one successful or failed request doesn't tell you what happens with every domain.
Can I enter the website's IP address to rule out DNS? Not conclusively. HTTPS uses the domain name for certificate validation and virtual host selection. Visiting an IP directly may produce a certificate error or show a different site. Check first whether the domain resolves to a valid address, then verify that the connection succeeds.
5. Which rule keywords should I check when a rule matches incorrectly?
Only some websites fail in Config mode. What should I check first? In Config, confirm the selected configuration, then inspect the connection log for the failed request: destination domain or IP, matched rule, final policy, and server used. Shadowrocket evaluates rules in order, so an earlier matching rule affects the result. Finding the domain somewhere in the file isn't enough to confirm that the expected rule was applied.
| Keyword | What it matches | What to check |
|---|---|---|
DOMAIN | Full domain | Check the root domain and each subdomain separately. |
DOMAIN-SUFFIX | A domain and its subdomains | Check whether the suffix is too broad or an earlier rule matches first. |
GEOIP | Matches based on an IP geolocation database | It doesn't determine location from a website's language or domain suffix. |
IP-CIDR | IPv4 address range | Check that the CIDR range is correct and that the resolved address falls within it. |
FINAL | Requests that don't match an earlier rule | Check that the final policy is available and matches your expectations. |
How can I check rule syntax? These examples show three rule types and their order; they aren't a configuration to import as-is. example.com and 192.0.2.0/24 are documentation examples. Check the actual proxy route for PROXY in your own configuration.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXYWhy is no-resolve used here? For this IP rule, it means not to trigger a domain lookup just to match the rule; it doesn't disable DNS globally. Also, don't put FINAL before rules that still need to be evaluated, or the later rules won't be able to route traffic as intended.
- Text loads but images don't: check the logs for the page, image, and API domains separately. Adding a rule for the main site alone may not be enough.
- A rule selects a policy group: check which server is actually selected within the group. The group name appearing in the configuration doesn't mean its members are available.
- Things briefly work after a manual change: save a comparison of the settings before and after, then check whether a subscription or configuration update overwrote the local change.
6. After troubleshooting, how do I restore settings and keep useful evidence?
Can I stop as soon as the issue is gone? First restore your usual Global Routing mode and confirm that Config is using the expected configuration. If you normally use On Demand, go to Settings → On Demand and restore the original conditions. Then test over Wi-Fi, cellular, and after switching networks. Don't mistake a temporary diagnostic mode for your final setup.
What should I provide if I still can't identify the issue? Write down steps that someone else can reproduce rather than reporting only “Connected but nothing loads.” Ask your provider to check service settings and status; diagnosing in-app settings requires the mode, configuration, and connection logs. Before sharing anything, redact subscription tokens, passwords, UUIDs, private keys, and other authentication details.
- Test environment: Device type, system information, Wi-Fi or cellular network, and whether the basic network works.
- Routing comparison: Whether the same URL works in Direct, Proxy, and Config.
- Server details: Protocol Type, connectivity test method, and result. Don't share authentication keys.
- Request details: Time of the issue, redacted error message, matched rule, and final policy.
- Change history: Whether the server was changed, the subscription updated, or DNS or configuration settings modified since it last worked.
Takeaway: Confirm the fix with a repeatable comparison
You can attribute the issue to a setting only when restoring it reliably reproduces the failure on the same network and URL, and correcting it restores access. A single successful reload isn't enough to draw a conclusion.