Shadowrocket Connected but No Internet? Check Servers, Routing, DNS, and Rules

At a glance

This guide is for cases where Shadowrocket is connected but a browser or some apps cannot reach their destinations. It assumes you already have your own provider and configuration. Establish a direct-connection baseline, check the server, compare Global Routing modes, then inspect DNS and matched rules. Change one setting at a time, test the same pages, and restore your original settings when done.

1. Check VPN connection status separately from website access

Turning on the connection switch in Home starts the device’s VPN connection. It does not confirm successful authentication with the remote server or access to a particular website. The VPN indicator in iOS also cannot verify that DNS, the server’s outbound connection, and routing rules are all working. Don’t diagnose the issue from the switch alone.

Choose one page that normally opens directly on your current network and one page that is failing. Use these same two targets throughout your tests. Reload each page; if needed, close its tab and open it again so a cached page isn’t mistaken for a successful connection.

4 checks

Follow this order: server → mode → DNS → rules

1 setting

Change one variable per test and record the result

2 targets

Keep the test targets fixed: one direct-access page and one failing page

Record the current setup

In Home, note the selected server and Global Routing mode. In Config, note the selected configuration file. Save a copy before editing the configuration and record the current DNS settings.
Check On Demand

Go to Settings → On Demand and note the current settings. If they may trigger a new connection during testing, turn them off temporarily and restore them when you’re done.
Establish a direct-connection baseline

Return to Home, turn off the connection switch, and confirm the connection has stopped. Then open the direct-access test page. If it still fails, check whether the current Wi-Fi network requires sign-in and whether cellular data works.
Reproduce the issue

Turn the connection back on, keeping the original server, mode, and configuration. Visit both test targets and note whether both fail or only a particular domain or app.
Keep test conditions consistent

Check the server and mode on the same network first. If you need to switch between Wi-Fi and cellular data, treat that as a separate test; don’t update the configuration or change servers at the same time.

2. Check the server: test reachability, then verify credentials

In Home → SERVER, verify the selected server and run Connectivity Test. A latency result only shows that a response was received using that test method. Different test methods cover different parts of the connection, so one result cannot confirm that every domain, transport, or full request is working.

If every server times out, revisit the direct-connection baseline and your current network. If only one server fails, verify its address, port, and protocol fields. The address may be a domain name, which also needs DNS resolution, so a server connection timeout doesn’t necessarily mean the remote service is down.

Address and port: Open the selected server’s edit screen and compare each field with the details from your provider. Port 443 is commonly used for HTTPS, but the server’s actual configuration determines the port. Don’t change it to 443 just because TLS is enabled.
Authentication fields: Check the Shadowsocks password and encryption method, the UUID for VMess or VLESS, and the Trojan password. An imported configuration is not complete just because it has an address and port.
Transport fields: For configurations using TLS, WebSocket, or similar transports, verify the TLS server name, Host, and Path. These can differ from the server address; use the values in the original configuration rather than making them match.
Subscription contents: If your provider says the configuration has changed, update your existing subscription. Then check the selected server again. A successful update only means the configuration was retrieved; it does not mean every server in it is available.

The original log text can help identify where a connection failed. These are common network error messages; depending on the protocol and system environment, logs may include an address or error domain before or after them. Apply a diagnosis only when the corresponding text appears in the actual log. Don’t classify a blank browser page as a specific error by itself.

Error: connection refused

Cause and next steps: The destination or an intermediary explicitly rejected the connection. This often happens when no service is listening on the port or the address or port is incorrect. Verify the server address and port, then ask your provider to confirm the endpoint is available. This error alone does not prove the password is wrong.

Error: connection timed out

Cause and next steps: The connection was not completed before the timeout. Possible causes include the network path, port filtering, or an unresponsive server. First test the same configuration on another network, then compare it with another server you already know works, changing only one variable.

Error: certificate verify failed

Cause and next steps: TLS certificate validation failed. Possible causes include the device’s date and time, a mismatched server name, or a problem with the certificate chain. Check the system date and the TLS server name in the configuration, then ask your provider to verify the certificate. Disabling validation is not a routine fix.

3. Compare Global Routing modes to narrow down the issue

Check the current mode in Home → Global Routing. For troubleshooting, Proxy and Direct can help distinguish proxy traffic from direct traffic. For everyday use with Config, also check the specific rules in the configuration. For Scene, inspect the selected scene’s settings rather than guessing where traffic goes from its name.

Mode	What to check	How to interpret the result
Proxy	Route ordinary requests through the current proxy policy as a temporary comparison.	If Proxy works but Config fails, check the rules and selected policy first, while also considering differences in the DNS path.
Direct	Connect directly to the destination to see whether it is reachable on the current network.	If Direct works but Proxy fails, check the server and proxy connection path. This does not mean all destinations should use a direct connection.
Config	Route traffic according to the rules in the currently selected configuration.	Check the selected file in Config, the order of its rules, and whether the policies they reference are available.
Scene	Route traffic according to the current scene settings.	Check which scene is active and how it is configured. To rule out scene-related behavior, note the original settings and temporarily use a clearly defined comparison mode.

If Proxy works, check Config next

If the same server, network, and destination work in Proxy but fail in Config, inspect the rules actually matched in Config and the resulting policy. Don’t rebuild all your servers straight away. Restore the original mode when the comparison is complete.

Start a new request after switching modes. A browser or app may keep an existing connection, so refreshing the screen may not establish a new one. If only one app has the problem, fully quit and reopen it, then test the same service in a browser to distinguish an app cache issue from a connection-path issue.

4. Check DNS: latency does not confirm domain resolution

DNS translates domain names into addresses. A reachable server and a Connectivity Test result do not confirm that a destination domain resolves correctly. Even when an address is returned, an unreachable IPv6 address, an incorrect address, or a result unsuitable for the current network can still cause webpage timeouts.

Open Config, select the active configuration, and check its DNS settings. First note the resolver address, whether encrypted DNS is enabled, and which network path DNS requests depend on. Don’t inspect only a configuration file that isn’t selected, and don’t change DNS and the server at the same time—you won’t know which change mattered.

Check the address format: Standard DNS usually uses port 53; DoH usually uses HTTPS over port 443. If the configuration specifies another port, follow the requirements of the actual service. A reachable port does not guarantee that the protocol and address format are correct.
Check resolver reachability: If the resolver is reachable only through a particular proxy path, while the proxy server’s domain itself depends on that resolver, a startup dependency issue may occur. Check the DNS path against the original configuration instructions; don’t repeatedly toggle the connection.
Check how widespread the failure is: If several unrelated domains fail to resolve, check the resolver first. If only one domain fails, record the full domain and what happens, then check its rules and destination service.
Confirm the change took effect: Save the configuration, reconnect, and reopen the test app. DNS caching can affect what you see, so an existing connection that still works does not prove the new settings have been tested.

5. Check rules: verify what actually matched, not just whether REJECT appears

Return to Home and set Global Routing back to Config, then verify the selected file in Config. Rules are generally checked in order, and the first matching rule determines how a connection is handled. The presence of REJECT in a file does not mean every request is blocked; it matters only if the destination actually matches a relevant rule.

The snippets below demonstrate rule syntax; they are not a complete configuration and should not be used to replace your existing rules. The example domains and documentation-only address are illustrative. The first field is the rule type, the second is usually the matching condition, and the last is the policy. FINAL has no matching-condition field.

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

DOMAIN-SUFFIX: DOMAIN-SUFFIX,example.com,REJECT matches example.com and its subdomains. If a real service domain matches a rule of this type, changing servers alone usually won’t change the rejection.
IP-CIDR: Matches a destination IP range. The example 192.0.2.0/24 is a documentation-only network. no-resolve means this rule won’t trigger a DNS lookup just to match it; it does not mean DNS is disabled for the entire configuration.
GEOIP: Matches based on geographic IP data, not the webpage language or domain suffix. Changes in DNS results may affect subsequent IP-based rule matching.
FINAL: Handles connections that did not match earlier rules. The example points to PROXY. If your configuration uses a custom policy group, also check its current selection—not just the name at the end of the rule.

Use the app’s request records or logs to check the failing domain, matched rule, and final policy. A webpage may contact its main domain, login domain, and static resource domains. If the main page opens but the login button does nothing, inspect the specific failed request rather than checking only the domain in the address bar.

6. Common questions: partial failures, automatic connections, and restoring settings

Why is there a latency result if the webpage still won’t load?

A latency test and a webpage request may use different destinations and connection paths. First check the selected server in Home, then test the failing page in Proxy. If it still fails, check server authentication and DNS. A latency result does not prove that a webpage is reachable.

Should I change servers if only one website won’t open?

First record the specific domain that is failing and compare Proxy with Config. If it fails only in Config, check the rules matched by that domain first. If both modes fail, check the DNS result, destination service status, and proxy egress path.

Why does the connection turn back on after I switch it off?

Go to Settings → On Demand and check whether automatic connection conditions are configured. Note the original settings, temporarily turn them off, then return to Home and confirm the connection has stopped. Restore the original settings after testing so an automatic reconnect isn’t mistaken for a faulty switch.

If it works on cellular data, does that mean the server is fine?

It shows that the same configuration works on at least one other network, so the issue is more likely on the original network path. Return to the original Wi-Fi and check network sign-in, resolver reachability, and port restrictions. Retest with the same server and mode; this does not guarantee a connection on every network.

7. Verify the fix and keep a record

Success means the destination that failed before can complete its request in the expected mode—not simply that the connection switch lights up again. Restore your everyday Global Routing mode, configuration file, and On Demand settings, then test both the direct-access page and the previously failing page. If the issue returns after restoring your settings, the temporary comparison worked around the problem but did not fix it.

Record the network type, selected server, configuration file, and Global Routing mode that work.
Reopen the affected app and check page loading, sign-in, or resource requests—not just whether the homepage title appears.
Confirm that temporary DNS changes, rule exceptions, and automatic connection settings meet your everyday needs. Keep a copy of the configuration from before the changes.
If you need to report the issue to your provider, include when it happened, the protocol, the error text, and the results of your mode comparison. Remove sensitive details such as passwords, UUIDs, and subscription tokens.

Shadowrocket is a paid client for Apple platforms and is available exclusively on the App Store. The developer is Shadow Launch Technology Limited. A one-time app purchase is separate from any service plan. This troubleshooting guide assumes you already have your own configuration; it does not provide, sell, or recommend servers, subscriptions, or providers. Check the App Store listing for system requirements.