This guide is for users who have imported their own server or subscription into Shadowrocket but still can’t access websites after turning on the connection switch. Work through these checks in order: confirm your basic network connection, test the selected server, compare Global Routing modes, check DNS, then review rules and On Demand settings. Change one variable at a time and retest the same destination to distinguish a started tunnel from a successful request.
1. Identify the scope of the problem—don’t assume the connection switch means you’re online
The connection switch on Home and the system VPN status show that the tunnel has started. They don’t confirm that the remote server is reachable, the credentials are valid, or every website can respond normally. A browser that keeps waiting, an immediate “server not found” message, and a failure on just one website are different symptoms; they don’t all point to a server problem.
First pause automatic connections, then compare what happens with the connection off and on. If regular websites still won’t load with the connection off, resolve any Wi-Fi, cellular data, or network sign-in issues first. Repeatedly updating rules usually won’t help at this point. On public Wi-Fi, complete any required sign-in before testing.
-
Pause automatic connections
Go to Settings → On Demand, note the current settings, and temporarily turn off On Demand. Then return to Home and turn off the connection switch. This prevents an automatic reconnection after a manual disconnect from affecting your comparison.
-
Check your basic network connection
Open a website in your browser that normally works, and confirm that your current Wi-Fi or cellular data connection is available. Don’t rely on a destination that may not be accessible without a proxy as your only test.
-
Confirm the selected server
On Home, check which server has the selected indicator and note its name and protocol. A server appearing in the list doesn’t mean it’s the one currently selected.
-
Run a connection test
Turn on the connection, then go to Home → Connectivity Test and note the test method and result. If the test succeeds, try the website that failed before. The test request and the website request are not the same.
-
Keep retest conditions consistent
Note your network type, current Global Routing mode, test destination, and exact error text. Change one setting at a time, retest the same address, and then decide whether to keep the change.
2. Check server settings and subscription status
The server address, port, protocol, and authentication settings must all belong to the same valid configuration. On Home, open the current server’s edit screen and check each field against the original details from your service provider. Don’t change every port to 443 just to see if it works, or reuse fields from a different protocol.
- Address and port: Don’t enter a path, spaces, or a full subscription URL in the address field. The port must match the server’s listening configuration; a website using HTTPS doesn’t mean the proxy listens on port 443.
- Shadowsocks: Check the encryption method and password. A correct address and port alone may not be enough to establish a working proxy connection.
- VMess / VLESS: Check the UUID, transport, and corresponding Host, Path, and TLS settings. Mismatched transport settings can also cause timeouts or handshake failures.
- Trojan: Check the password, TLS settings, and server name. If the server name is used for certificate verification or the handshake, don’t replace it with a value unrelated to the certificate.
- Hysteria2 / WireGuard: Also check whether UDP is reachable on the current network. A successful TCP test doesn’t confirm that the UDP path or protocol authentication is working.
If the server list comes from a subscription, update that subscription first, then check whether any servers were removed, renamed, or replaced. Get subscriptions from your service provider. A failed update only means the subscription content couldn’t be retrieved this time; it doesn’t prove that every imported server is no longer working. A successful update doesn’t mean every server has passed a connection test.
A one-time app purchase ≠ a service plan. Shadowrocket is a closed-source commercial app. Buying the app doesn’t create a provider account, add service credit, or extend a subscription. Contact your service provider about your account status and server maintenance.
3. Use Global Routing to distinguish mode and rule issues
On Home → Global Routing, check the current mode. Config applies the rules in the active configuration; Proxy routes traffic through the proxy for comparison; Direct routes traffic directly for comparison. If you’re using Scene, check the selected scene’s settings too—the scene name alone doesn’t tell you where traffic will go. These three modes are comparison settings for troubleshooting, not a complete list of modes.
| Comparison setting | What you observe | What to check next |
|---|---|---|
| Direct | Websites that normally work without a proxy also fail | Basic network access, DNS, and related settings that remain active in the tunnel |
| Proxy | Multiple test destinations fail | Selected server, authentication, transport settings, and network reachability |
| Proxy vs. Config | The same destination works in Proxy but fails in Config | Rule matches, policy targets, the active configuration, and DNS differences |
| Config | Only a few domain names fail | Match results for the specific domains and their dependencies; don’t replace the entire configuration first |
Keep the server, network, and destination address the same when comparing modes. If you also change servers, you won’t know which change fixed the website. Send a new request after switching modes; existing long-lived connections may continue using the old route, so close and reopen the test page if needed.
4. Check DNS: distinguish resolution failures from connection failures
DNS resolves domain names to IP addresses. If resolution fails, the request may never reach the destination server. Even when resolution succeeds, the connection, TLS handshake, or application response can still fail. If the server itself is specified by a domain name, resolving that address is also part of the connection path, so a DNS problem can make the proxy server appear unreachable.
This flow shows the stages to check; it doesn’t represent a fixed internal order for every request. Some domain rules can match first, address-based rules may require a DNS result, and remote resolution can change where resolution happens. Check actual request records when troubleshooting rather than assuming the client follows the diagram’s sequence.
- Check the configuration source: In Config, confirm which configuration is active and review its DNS settings. If you’ve changed related options in Settings, note those changes too. Don’t replace the configuration file, resolver, and server all at once.
- Check resolver reachability: A custom DNS address must be reachable through the intended route. Even when DoH uses port 443, it can still fail because of problems resolving its domain, TLS, or the connection path.
- Restore the original value: If the problem started right after a DNS change, restore the value you recorded and retest instead of adding multiple unverified resolvers.
- Distinguish IPv4 from IPv6: If a domain has an AAAA record but the current network’s IPv6 route is unreliable, some destinations may take longer to load or fail to connect. Check the actual connection address rather than attributing every timeout to IPv6.
Don’t use entering a website’s IP address directly in a browser as your only HTTPS test. HTTPS usually relies on a certificate and server name associated with the domain. Visiting an IP directly may trigger a certificate error or open a different site. A better approach is to keep the original domain and check the resolution result, connection address, and handshake separately.
5. Check Config rule order and the resulting policy
If a destination works in Proxy but not Config, first check the rules actually active in Config—not just which files are saved. Standard rules are evaluated in order, and the first match determines the policy. A broad rule near the top can prevent more specific rules below it from taking effect. FINAL is the fallback rule, so check where it points.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis snippet illustrates the syntax; it isn’t a complete file you can use to replace your current configuration. example.com and 192.0.2.0/24 are documentation examples. Verify the actual target for PROXY in your configuration. Don’t assume the policy name in the snippet points to a tested, working server.
- DOMAIN-SUFFIX: Matches a domain suffix. This example covers example.com and its subdomains, but a page may also request images, scripts, or sign-in endpoints from other domains.
- IP-CIDR: Matches an IP address range. In this example, no-resolve prevents this address rule from triggering a DNS lookup; it doesn’t disable DNS for the entire client.
- GEOIP: Matches based on IP geolocation data—not the webpage’s language, domain suffix, or the location of the website operator.
- FINAL: Handles traffic that didn’t match an earlier rule. If it points to an unavailable policy, requests not covered by earlier rules may all fail.
After reproducing a failed request, check available request or log records for the domain, matched rule, final policy, and error. If the home page loads but sign-in fails, check the sign-in endpoint’s domain separately. If page text appears but images don’t load, check the image requests. A website makes multiple connections, so one successful request doesn’t confirm that the whole page works.
6. Use the exact error text to choose your next step—don’t jump to conclusions from one phrase
These are common snippets from network logs, but they won’t appear with every problem and aren’t fixed messages shown by every screen. Save the complete text and its context, then identify whether the failed connection was to the proxy server, DNS resolver, or destination website before choosing what to check.
Error: connection refused
Cause: The connection was explicitly refused, often because nothing is listening on the port or access was actively denied. What to do: Check the address and port mentioned in the error, then ask your service provider to confirm the server’s listening status. Don’t assume the password is wrong.
Error: i/o timeout
Cause: A step didn’t finish within the allowed time. Possible causes include packet loss, an unresponsive server, or a stalled connection later in the process. What to do: Identify which stage timed out, then compare Wi-Fi and cellular data using the same server and destination.
Error: no such host
Cause: The domain didn’t resolve to a usable address, possibly because it was entered incorrectly or there’s a DNS issue. What to do: Check the full domain in the error and determine whether it belongs to the server, resolver, or destination website. Then check the relevant DNS path.
Error: certificate has expired or is not yet valid
Cause: The certificate’s validity period doesn’t match the current time. The remote certificate may have expired, or the device clock may be wrong. What to do: Check the device’s date and time and the server name. If the remote certificate is invalid, contact the party responsible for maintaining it; disabling certificate verification is not a routine fix.
If there’s no specific error text, collect a minimal reproduction record: which network you used, the selected protocol, the Global Routing mode, the Connectivity Test method, the destination that failed, and whether it worked with the connection off. Before sharing, remove passwords, UUIDs, private keys, and tokens from subscription URLs. Don’t share configuration credentials in full.
7. Retest, restore On Demand, and keep useful findings
After access is restored, test again on the current network, then switch to another network and test there too. If cellular data works but Wi-Fi doesn’t, check the access requirements of that Wi-Fi network. If only one server fails, focus on that server’s settings or status. These results are more useful for diagnosing the issue than simply saying that toggling the connection fixed it.
- Restore the Global Routing mode you normally use, and confirm that the active Config and selected server are the ones you expect.
- Test a regular website, the destination that failed before, and that destination’s sign-in and resource loading. Don’t check only the home page.
- Go to Settings → On Demand and restore the original settings. After switching networks, check for unexpected reconnections or changes in routing mode.
- Record the changes that worked and any symptoms that remain. If you need help from your service provider, share redacted errors and reproduction steps instead of continuing to change multiple settings at random.
To verify the client’s source, Shadowrocket is available only on Apple platforms, primarily iPhone and iPad, and App Store is the only place to get it. The developer is Shadow Launch Technology Limited, and the app is sold as a one-time purchase. Check the App Store listing for system requirements. Reinstalling the app won’t replace troubleshooting your server, DNS, or rules; make sure your configuration is safely preserved before taking action.