Turning on the connection in Shadowrocket only enables the connection on your device; it does not confirm that the remote server, DNS, or destination website is working. This guide is for users who already have a configuration from their own service provider. First establish a baseline with the connection off, then check the server, Global Routing, DNS, and Config rules in Home. Change one setting at a time, retest the same webpage, and keep notes on what helps explain the problem.
1. Separate local network issues from connection issues
Save your current Config and note the selected server and Global Routing mode in Home. Don’t start by deleting all your configurations. Rebuilding a configuration can erase your existing rules, policy selections, and DNS settings, making before-and-after tests difficult to compare.
Choose two HTTPS pages you can normally access, hosted by different websites. Use each page’s full domain name, not its IP address. Certificate validation and virtual host selection depend on the domain, so an error from visiting an IP directly does not, by itself, indicate a DNS problem.
-
Save the current settings
Note the current selection under Home → Global Routing, the selected server name, and the Config in use. If screenshots or notes include a server address, password, or UUID, keep them somewhere you control.
-
Pause On Demand
Go to Settings → On Demand and note whether it was enabled. Temporarily turn it off during troubleshooting to prevent the connection from coming back automatically after you disconnect it manually. Restore the original setting when you’re done.
-
Test with the connection off
Turn off the connection in Home, then use Safari to visit the two pages you prepared. If neither loads, first check Wi-Fi sign-in, your router, or cellular data. Don’t change your rules yet.
-
Switch networks and test again
Switch between Wi-Fi and cellular data, then visit the same pages again. Keep an eye on cellular data usage. If the problem occurs on only one network, note which one and check for port or transport restrictions.
Networks at hotels, schools, and similar locations may require you to sign in through a webpage first. Disconnect, complete the network sign-in, then turn Shadowrocket back on and test again. If another network extension is managing connections, pause it during troubleshooting to avoid interference between network settings.
2. Check the server; latency doesn’t guarantee websites will load
Go back to Home and make sure the selected server is the one you intend to test, not an old entry with a similar name. Check its Type, address, port, and authentication details against the settings provided by your service provider. The protocol and its parameters must match: don’t change VMess to VLESS while keeping only the address and port, or use Trojan authentication settings for Shadowsocks.
Run Connectivity Test in Home and review the result. A latency reading only means that the specific probe succeeded; it doesn’t prove that all HTTPS requests, UDP traffic, or destination websites will work. Test the same webpages to see whether browsing actually works.
- All existing servers time out: First switch networks, then check your service account and whether the server is under maintenance. Don’t change several unrelated settings at once.
- Only one entry fails: Compare it with another working configuration of your own. Check the entry’s port, authentication, TLS, and transport settings.
- The subscription updates, but the connection fails: Fetching a subscription and connecting to a server are separate request paths. A successful update doesn’t mean every server in the list is available.
- Using Hysteria2: Check whether UDP is restricted on the current network. If it fails only on a particular Wi-Fi network, keep the settings unchanged and test on another network before attributing the problem to DNS.
Bottom line: confirm one working path first
If the same server works on cellular data but not on Wi-Fi, investigate Wi-Fi access restrictions first. If it fails on both networks, check the server settings and service status. Changing DOMAIN-SUFFIX or FINAL usually won’t fix a failed server handshake.
3. Use Global Routing to distinguish server issues from routing issues
Go to Home → Global Routing and note the current selection before changing it. Proxy is useful for temporarily isolating the effects of complex rules; Direct tests the direct connection path; Config applies the routing rules in the current configuration. If you use Scene, also check the settings actually applied by the current scene. Don’t assume the request path based on the option name alone.
| Option | Use it to | What the test result tells you |
|---|---|---|
| Proxy | Test through the proxy to reduce interference from Config routing rules. | If it still fails, check the selected server, DNS, and destination website first. |
| Direct | Check whether the current network can connect directly, without forwarding through a remote proxy. | A successful direct connection doesn’t prove the server is working or that every destination can be reached directly. |
| Config | Process requests according to the rules and policies in the current Config. | If Proxy works but Config fails, focus on rule matches and policy selection. |
| Scene | If you use scene-based settings, check which settings the current scene actually applies. | Use the scene conditions and request records together; a scene isn’t a fixed connection route. |
Test in this order: Proxy, then Config. Start a new request after each change. If needed, turn the connection off and back on so the next test uses the updated settings. Existing browser connections may keep using the old path, so don’t rely on a page that was already loaded.
4. Check DNS to distinguish lookup failures from connection failures
DNS translates domain names into IP addresses. If the remote server address is a domain name, it may need to be resolved before a connection can be established. If DNS is unreachable, this can look like a server connection failure. If the destination website can’t be resolved, the connection may appear to be on while the page keeps loading.
Go to Settings → DNS and check the current settings. Also check whether the Config in use includes DNS-related settings. Changing Settings alone may not change all DNS behavior for the current connection; verify the active configuration and request records. Save the original values before making changes so you can restore them.
- Domain won’t resolve: Check for a DNS resolution error, then verify the DNS address format and whether it’s reachable on the current network. Don’t add multiple DNS addresses from unknown sources.
- Using encrypted DNS: Make sure the DNS service’s domain can be resolved initially. Check whether rules send the request through a proxy path that hasn’t been established yet, creating a startup dependency loop.
- An IP address was returned: Check the subsequent TCP connection or TLS handshake. A DNS result doesn’t guarantee that the destination is reachable.
- Only some websites fail: Note whether the result is an IPv4 or IPv6 address. Test the address family temporarily only when there’s evidence of an IPv6 path issue, and make sure you can restore the original setting.
Error: connection refused
Cause and fix: The destination port explicitly refused the connection, often because the port is incorrect or no service is listening. Check the port in your existing configuration and ask your service provider to confirm the service status. Don’t change DNS first.
Error: i/o timeout
Cause and fix: A network operation didn’t finish within the time limit. Check nearby log entries to see whether it happened during DNS resolution, connection, or data retrieval. First test on another network, then investigate the relevant stage.
Error: no such host
Cause and fix: The domain didn’t resolve to a usable result. Check the spelling, confirm the domain is still valid, and verify that the current DNS server is reachable. If the server domain is wrong, check the original configuration.
These are common snippets from network errors; the full message may include additional prefixes and addresses. Keep the surrounding context, but don’t post authentication details or a full subscription URL publicly. Don’t disable certificate verification to resolve a TLS error. First check the device time, server domain, and TLS settings for consistency.
5. Check Config rule order and the final policy
If Proxy opens a page but Config doesn’t, go to Config and confirm which file is actually enabled. Check which rule matches the relevant domain, which policy the rule points to, and whether the server selected by that policy is available. Files with the same name may have different contents or different active status.
Rules are usually evaluated in order, and the first matching rule determines what happens next. A broad rule near the top can prevent a more specific rule later from taking effect. The examples below demonstrate syntax and order only; they are not a complete Config to replace your existing one. The policy names shown must resolve correctly in your current configuration.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY: Matches the example domain and its subdomains. When troubleshooting a real website, check the actual request domains first; a page may load resources from multiple domains.IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Matches this IPv4 range.no-resolvemeans this IP rule won’t actively trigger a domain lookup; it does not disable DNS globally.GEOIP,CN,DIRECT: Matches based on an IP geolocation database, not webpage language, domain suffix, or server name.FINAL,PROXY: Handles requests that didn’t match an earlier rule. Placing FINAL earlier prevents later rules from working as intended.
If a rule points to a policy group, also check the group’s current selection. A valid rule can still send requests to an unavailable server. Change only the entries related to the affected destination, reconnect, and revisit the same page. Confirm that the new request records match what you expected.
6. Verify the results and keep reproducible notes
Once access is restored, turn On Demand back on if you normally use it, and restore your usual Global Routing mode. Test the webpage first, then the app that originally failed. A cached page that appears normal doesn’t prove the network is working; confirm that a new request completes successfully.
The connection is on. Why can’t I access anything?
A connected status doesn’t prove the entire request path is working. In Home, check the selected server and run Connectivity Test, then compare Proxy with Config, and finally check DNS and rule matches.
One website won’t load. Should I reinstall?
Don’t reinstall yet. Compare with another website, then check the failing site’s actual request domain, DNS result, and rule policy. If only one site fails, consider whether the destination service is down or access through the current route is restricted.
Wi-Fi doesn’t work, but cellular data does. What should I do?
Keep the server and Config unchanged. Complete any Wi-Fi sign-in page, then test again. If it still fails only on Wi-Fi, note the connection stage and transport type, then ask the network administrator or your service provider to investigate further.
Still can’t connect after updating the subscription?
Make sure Home has the updated, working entry selected, then check your account allowance, validity period, and server status. A subscription update refreshes configuration data; it doesn’t fix server-side outages or incorrect local rules.
Keep these four details before reporting the issue
- Note the network in use: Wi-Fi or cellular data, and what changes when you switch networks.
- Note the Global Routing mode, Config name, and the results of comparing Proxy with Config.
- Note the stage where the error occurred: DNS, server connection, TLS handshake, or destination response.
- Keep a redacted copy of the exact error and the steps to reproduce it. Remove passwords, UUIDs, subscription tokens, and other authentication details.
To distinguish between timeout causes, see the timeout guide in Troubleshooting. For rule terminology, see the glossary. These checks assume you already have a service provider and configuration. Purchasing the app and obtaining network service are separate matters.