The Shadowrocket connection switch shows the device's local connection status; it doesn't confirm that the server, DNS, or destination website is reachable. This guide assumes you already have your own service and configuration. Check the basic network, server settings, Global Routing, DNS, and rules in order. Change one thing at a time, retest the same address, then restore your usual settings.
1. Distinguish the Local VPN Tunnel from the Actual Request
A VPN status in iOS means the device has established a local network tunnel. Whether the remote server accepts the connection, the domain resolves, and the rules route the request still needs to be checked separately. An active switch doesn't mean the browser is necessarily at fault, and not every page that fails to load has a DNS problem.
This flow helps narrow down what to check; it doesn't mean every request resolves and routes in exactly the same order. A domain rule can match first, while some IP rules may require a resolved address. Start with these checks to see whether the basic network is working.
- Note the server selected in Home, the Global Routing mode, and the active configuration in Config. Keep a restorable copy before making changes.
- Temporarily turn off Shadowrocket and open a website in Safari that normally works without it. If that still fails, complete the Wi-Fi sign-in process or check cellular data access and the current network status.
- Once the basic network is working again, turn the connection back on and open the same website. Note whether everything fails, only some domains fail, or just one app is affected.
- If possible, retest once on Wi-Fi and once on cellular data. After switching networks, start a new request; don't treat a cached page as a fresh result.
2. Check the Server in Home and Your Existing Subscription
In Home, make sure the selected server belongs to your own valid configuration, not an outdated entry. Connectivity Test can provide a clue about reachability, but its target and method may differ from the website you're trying to open. A latency result doesn't mean every site will work, and a timeout needs to be considered alongside the actual connection logs.
- Address and port: Check the server's domain or IP address and port character by character. Don't enter a subscription webpage address as the server address. For example, if the service specifies port
443, the client must use the same port. A familiar-looking port doesn't guarantee the service is available. - Authentication: A Shadowsocks password and encryption method, a VMess/VLESS UUID, and a Trojan password are not interchangeable. Check the values against your own service parameters; don't guess other fields from the protocol name.
- Transport and TLS: If the configuration uses WebSocket, TLS, or other transport settings, check the corresponding fields, such as path, Host, and SNI. When connecting to an IP address, the server name required for TLS may not be that IP.
- Protocol differences: Hysteria2 and WireGuard use UDP. A working TCP request on a network doesn't prove that UDP works on the same network. Retest with the correct parameters you already have rather than switching protocols at random.
If the entry comes from a subscription, check that it updated successfully and that the list doesn't still contain outdated details. To update it, refresh the existing subscription in Home, then review the relevant settings under Settings → Subscribe. A subscription update fetches configuration; a server connection is an outbound request. They are different requests. A successful update doesn't prove the entry works, and a failed update doesn't mean every existing entry is invalid.
Error: connection refused
Cause and fix: This usually means the destination address or an intermediary explicitly refused the connection. First check whether the connection log points to the server or the destination website, then verify the address, port, and remote listener status. Don't change DNS as a first step.
Error: i/o timeout
Cause and fix: An I/O operation timed out, but this line alone doesn't identify where the failure occurred. Check the surrounding log entries to see whether it happened during DNS resolution, the server connection, or access to the destination, then compare results on another basic network.
These are examples of error snippets that may appear in connection logs; not every device shows the same messages. When sharing details for troubleshooting, keep the original error text and note when it occurred. Hide passwords, UUIDs, private keys, and subscription tokens, and never share your full configuration.
3. Use Global Routing to Compare Modes and Rules
First check the current mode under Home → Global Routing. Proxy, Direct, Config, and Scene work differently. An active connection doesn't mean every request uses the selected server. In particular, Direct doesn't automatically send requests through a remote proxy just because the connection is on.
| Mode | What it does | How it helps troubleshoot |
|---|---|---|
Proxy | Routes requests through a proxy | Briefly test the selected proxy route and rule out routing by Config rules |
Direct | Routes requests directly | Compare direct access on the current network; this doesn't verify that a remote server works |
Config | Applies the policy specified by the current configuration's rules | Check the matching rule, policy group, and final outbound route |
Scene | Selects routes according to configured scenes | Check which scene applies to the current network and which settings are active |
Keep the server and destination address unchanged, then briefly compare Proxy and Config. If the site works in Proxy but fails in Config, focus on the rules and policy groups, while keeping in mind that DNS or request paths may differ between modes. If both modes fail, continue by checking the server, basic network, and DNS rather than deleting the entire configuration.
Evaluate Scene against the scenes you already have; don't assume it works like Config. Restore the original mode after testing. Proxy is useful for comparison, not as a universal replacement for your everyday settings.
4. Change DNS Only When the Evidence Points to It
DNS translates domain names into addresses. If the server address is itself a domain name, it may need to be resolved before connecting to the remote server. The domain used by a webpage may require a separate lookup. Record failures to resolve the server's domain separately from failures to resolve the destination website's domain.
- Narrow down the scope: Test two domains you use regularly. If only one domain fails, check that domain and its DNS records first instead of changing global settings right away.
- Check the active configuration: In Config, confirm which file is in use and review its DNS settings. Cross-check them against the DNS options enabled in Settings. An inactive configuration file won't help diagnose the issue.
- Check upstream reachability: A custom DNS address must be reachable over the current route. With DoH, the HTTPS connection, certificate validation, and resolution of the DoH service's domain may all be prerequisites.
- Revert one change at a time: If the problem started after a DNS change, restore the previous settings, reconnect, and try the request again. Don't change DNS, the server, and rules all at once, or you won't know which change made a difference.
If the logs report a certificate name mismatch or an expired certificate, first check the device's date and time, the server name in your service parameters, and the remote certificate. Don't hide the problem by disabling certificate validation, and don't treat a TLS error as an ordinary DNS timeout.
5. Check FINAL, REJECT, and Rule Order
If the problem mainly occurs in Config mode, open the active Config and check which rule matches the destination domain, in order. Rules are generally evaluated from top to bottom; once an earlier rule matches, later exceptions aren't considered. Adding an allow rule at the end won't override an earlier REJECT.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECTThis example is for syntax illustration only. example.com and 192.0.2.0/24 are sample values; don't replace your active configuration with this entire snippet. In the example, FINAL,DIRECT sends requests that don't match an earlier rule directly. It isn't a recommended policy for every user.
DOMAIN-SUFFIXmatches the specified domain suffix and its subdomains. Check that the scope isn't too broad, especially for shared resources or login-related domains.IP-CIDRmatches an IPv4 range.no-resolveprevents this rule from triggering a domain lookup solely for the match; it doesn't turn off all DNS.GEOIPmatches based on an IP address's geographic location. The result depends on the address; a website's display language doesn't tell you which region will match.REJECTis a reject policy, not a protocol. Check whether a domain rule, rule set, or other entry sends a request the webpage depends on to it.FINALis the fallback policy when no earlier rule matches. If it points to a policy group, check which option is currently selected in that group; don't stop at the last line of the rules.
If a page loads but its images, login, or API calls fail, check the domains used by the failing resources, not just the main domain in the address bar. If a rule is confirmed to be the cause, back up the configuration before adjusting its scope, order, or policy. Keep the smallest change that fixes the issue; don't delete all reject rules to fix one page.
6. Retest Based on the Symptoms and Keep a Minimal Record
After each change, retest the original address. Record the network type, server entry name, Global Routing mode, failed domain, exact error text, and test time to distinguish intermittent failures from repeatable ones. The questions below cover common scenarios.
“Why won't the website load if the latency test shows a result?”
A successful test only confirms the target and route that it tested. In Home, check the selected entry, then compare the same website in Proxy and Config. If it fails only in Config, inspect the rules and final policy for that domain.
“Why does it work on cellular data but not Wi-Fi?”
Turn off the connection first and make sure Wi-Fi sign-in is complete, then retest without changing the server or configuration. If the issue persists only on that Wi-Fi network, check its DNS and the reachability of relevant ports and UDP paths. This alone doesn't mean the entire configuration is wrong.
“The website works, but one app keeps spinning. What should I do?”
Reopen the app and check which domains it actually requests. See whether its API, media, or login requests are blocked by REJECT or routed to a different policy. A working main website doesn't prove that every domain the app depends on is reachable.
“The subscription update failed. Do I need to delete all my servers?”
You don't need to clear the list first. Keep the existing entries, check the subscription link status, then review the update settings under Settings → Subscribe. Update entries using your own valid service details only after confirming that the current parameters are no longer valid.
If you still can't identify the cause, send your service provider's support team redacted error snippets and the comparison results above. Purchasing the Shadowrocket app and the status of a remote service are separate matters; reinstalling the app won't fix an unavailable server or incorrect rules. This site does not provide, sell, or recommend servers or subscriptions.
- Restore any Global Routing and On Demand settings you changed temporarily for troubleshooting.
- Keep the smallest verified fix and save copies of the configuration from before and after the change.
- Never share a full subscription link, password, UUID, private key, or usable QR code.