Shadowrocket Not Connecting? Troubleshoot Servers, Global Routing, DNS & Rules

At a glance

Turning on Shadowrocket’s connection switch means the system tunnel is active; it does not guarantee that the server, DNS resolution, or destination website is working. This guide assumes you already have your own provider and subscription. Narrow down the issue in four steps—server, Global Routing, DNS, and rules—changing one variable at a time and testing the same destination. Restore your original routing settings when you’re done.

Before you troubleshoot: distinguish the tunnel, server, and web request

Don’t start by deleting the app or rebuilding your entire configuration. The VPN indicator, server latency, and webpage loading each reflect a different stage. iOS accepting the VPN configuration doesn’t mean the remote server completed protocol authentication; a latency test returning a result doesn’t confirm that the webpage’s domain, port, and routing rules are correct. Identify the specific symptom before deciding which layer to change.

App sends a request System tunnel takes over DNS resolution and rule matching Direct or proxy routing Destination returns data

This flow helps identify where to investigate; it doesn’t mean every connection must complete DNS resolution before rules can match. Domain rules can match a hostname directly, while IP-based rules may depend on resolved addresses. The steps below use the iPhone / iPad interface. Before you begin, note the server selected in Home, the current Global Routing value, and the configuration file in use under Config.

Turn off the connection switch and visit a website that normally works on your current network. If it still won’t load, first resolve any Wi-Fi sign-in, cellular data permission, or basic network issues.
Choose a destination that actually requires a proxy and use the same address for each retest. Don’t compare results from different websites.
Keep a copy of your current configuration. Screenshots or notes can help you review your setup, but hide subscription URLs, credentials, and keys before sharing anything.

Step 1: Confirm the selected server is actually working

Go to Home and make sure the selection dot is next to the server you intend to test—not just an expanded subscription group. Turn on the connection switch and run Connectivity Test. Note whether it completes and what it reports. This test only reflects the result for that test’s destination at that time; it doesn’t verify every website or prove that DNS and rules are correct.

Check the selected server

On Home, check the selection dot and server name. If your configuration uses a policy group, also check which member is selected within the group. The default selection on Home may not override a fixed policy specified in the configuration.
Run a connection test

Run Connectivity Test on Home, then visit the same test address. Record whether each succeeds. A latency value alone does not prove that a website is reachable.
Check the connection settings

Open the server’s edit screen and compare Type, address, port, and authentication details against your original configuration. For types such as Trojan and VLESS, also verify the TLS and transport parameters. Don’t infer the server type from its name alone.
Update an existing subscription

Use the update action for that subscription on Home. Once the update succeeds, select an entry and test it. If the update fails, keep your existing configuration and ask your provider to confirm that the subscription is valid. Don’t repeatedly delete and re-add it.

Use the port specified in your existing configuration; don’t change it to 443 by default. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different authentication and transport fields. Changing Type won’t convert the configuration automatically. If the server requires UDP but your current network blocks UDP, changing the port alone doesn’t prove the issue is fixed.

Log message: connection refused

What it means and what to do: The target or an intermediate device is usually rejecting the connection explicitly. The port may not be listening, or access may be denied. First verify the server address and port, then ask your provider to confirm the service status.

Log message: i/o timeout

What it means and what to do: An I/O operation did not complete within the allowed time. This alone doesn’t mean the account is invalid. Use the destination address in the log to determine whether the timeout occurred at the server or the website, and test again on a different network.

These are examples of messages that may appear in network logs; not every issue produces them. Refer to the logs from your own device and don’t assume that an example in this guide describes your results.

Step 2: Use Global Routing to isolate routing issues

Go to Home → Global Routing, note the current value, then make a temporary comparison. Proxy, Direct, Config, and Scene are routing modes, not server names. Direct isn’t inherently a problem: it should work for destinations that are reachable directly. If a destination requires a proxy, Direct may not meet that requirement.

4 modes

Global Routing：Proxy / Direct / Config / Scene

2 paths

For each test, record the routing mode and actual outbound path

1 request

Change one variable at a time, then repeat the same request

Proxy: Use this to test the proxy path temporarily. If the same destination loads in Proxy but fails in Config, check the rules and policy selection first instead of immediately changing server credentials.
Direct: Use this to compare the direct connection path. If the site works with the tunnel off but fails with Direct while the tunnel is on, investigate DNS, network settings, and connection logs within the tunnel.
Config: Routes traffic according to the active configuration. Check which file is enabled under Config as well; checking Global Routing alone isn’t enough.
Scene: Depends on the configured scene conditions and actions. Note the current scene before troubleshooting, then temporarily switch to a clearly defined Proxy or Config mode for comparison so changing conditions don’t affect the result.

Step 3: Distinguish DNS resolution failures from connection failures

DNS translates domain names into addresses a connection can reach. If the connection log reports an error before an address is resolved, investigate DNS first. If an address is returned but the connection then times out, check destination reachability, server egress, and rules. A browser’s “website can’t be reached” message alone can’t distinguish between these cases.

Log message: no such host

What it means and what to do: Usually, the domain didn’t resolve to a usable result, or the address may be misspelled. First identify whether the domain in the error is the server, DNS service, or destination website, then check the relevant address and resolution path.

Check the connection records or logs immediately after the failure. Find the entry for the same domain at the same time. Don’t substitute background requests from another app for the request you’re testing.
Check DNS-related settings in Settings. In Config, also check whether the active configuration includes dns-server under [General] or static mappings under [Host]. Values specified in the configuration may be key to troubleshooting.
If you recently added a custom DNS server, note its current value and restore the previously known working setting. Don’t change DNS, the server, and the routing mode all at once, or you won’t know which change made a difference.
If you use encrypted DNS, make sure the DNS service’s own domain, network path, and TLS connection are reachable. Using encrypted DNS doesn’t automatically mean the resolver itself can be reached.

Don’t treat opening a website by entering its IP address as a universal DNS test. HTTPS certificate checks and SNI depend on the domain, and many sites use shared IP addresses or CDNs. Failure to open a site by IP doesn’t prove that the IP is unreachable. Use the resolution result and connection stage in the logs to diagnose the issue rather than drawing conclusions from bypassing the domain.

Step 4: Check rule order, matches, and outbound policy

After checking the server and DNS, open the active file under Config and review its [Rule] section. Rules are generally matched from top to bottom, so a broad rule near the top can take precedence over a more specific rule below it. Check the failed request’s connection record for the destination domain or IP, the matched rule, and the policy actually used. Simply finding the domain in the rule file isn’t enough.

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

This snippet illustrates the syntax; it is not a complete configuration you can use to replace your existing file. example.com is a sample domain. The actual proxy route depends on your active configuration and policy selection. Save the original file before making changes, and confirm that the policy name exists in the active configuration.

DOMAIN-SUFFIX,example.com,PROXY: Matches the domain and its subdomains. If a website uses multiple resource domains, adding only the main site’s domain doesn’t guarantee that all resources will use the same route.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Matches the example private address range. no-resolve means this IP rule won’t trigger an additional domain lookup; it does not disable DNS entirely.
GEOIP,CN,DIRECT: Matches based on the IP geolocation database, not the webpage’s language or domain suffix. Both the resolved address and database contents affect whether the rule matches.
FINAL,PROXY: Handles connections that didn’t match earlier rules. If the active setting is FINAL,DIRECT, destinations not covered by a specific rule may connect directly. Choose the value that matches your existing routing intent rather than changing it to one value across the board.

Still not working? Narrow down the issue by symptom

If the issue persists after all four steps, record these five details: whether the basic network works, the selected server, the Global Routing value, the failed domain, and the log message. Remove sensitive information before sharing. If it fails only on one network, compare the network conditions first. If it fails on every network and the configuration fields are correct, ask your provider to confirm the service status.

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 routes. Run Connectivity Test, then compare the same webpage in Proxy and Config. If it fails only in Config, check the rules and actual outbound route for that webpage’s request.

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

Keep the server, configuration, and destination unchanged, and test again on the other network. First check whether Wi-Fi requires a sign-in page, then whether it restricts the transport in use. Don’t change DNS and the protocol at the same time or you’ll lose a reliable comparison.

What if the connection turns back on after I switch it off?

Go to Settings → On Demand and note the current settings. Temporarily turn On Demand off while troubleshooting, then test again. On Demand controls when connections start automatically; it can’t fix invalid server authentication or incorrect rules. Restore the setting to suit your needs when you’re done.

The connection still fails after updating the subscription. Should I reinstall?

First confirm that the subscription update succeeded and that Home has the updated entry selected. Then check whether a fixed server or policy group in Config still points to an old entry. Updating a server subscription and updating rule configuration are separate tasks. Reinstalling shouldn’t be your first step.