This guide covers cases where Shadowrocket (Shadowrocket) shows connected and the status indicator looks normal, but websites or apps still cannot reach the network. Establish a local network baseline first, then verify the server, Global Routing, DNS, and Config rules separately. Compare the results to identify the failing layer instead of changing several settings at once.
Establish a repeatable network baseline first
“Connected” only means that Shadowrocket has established a network tunnel in the system. It does not mean that every part of the tunnel is transferring traffic correctly. An unreachable server, invalid credentials, failed DNS queries, or a Config rule selecting the wrong policy can all leave the switch on while requests receive no response.
Before troubleshooting, note the current server name, Global Routing mode, and active Config. Change one item at a time and revisit the same test page after each change. If you replace the server, DNS, and rules together, you cannot tell which change actually restored connectivity.
Verify the original network
Turn off the Shadowrocket connection switch, then use the current Wi-Fi or cellular network to open two websites you have not visited before. If they also fail, address the local network, router sign-in page, or cellular-data permission first.
Record the current settings
In Home, record the selected server and Global Routing mode. In Config, note the enabled configuration name. In Settings → DNS, record the current DNS entries so you can restore them after troubleshooting.
Reconnect
Return to Home, turn the connection switch off, wait a few seconds, and turn it on again. If the system asks you to approve a network configuration, follow the system prompt, then check whether the connection remains stable.
Run comparison tests
Test with Direct, Proxy, and Config in sequence. Change only Global Routing and keep the same server. The differences between the three results can quickly separate local-network, server-path, and rule issues.
Layer 1: Confirm the server status and parameters
If the local network works with Shadowrocket off but every request fails when Global Routing is set to Proxy, check the current server first. A latency result in Home only shows whether the test request returned within the time limit; it does not by itself prove that real traffic will work. Still, repeated timeouts, missing latency results, or a sudden spike are important signs of a server-path problem.
Open the server list in Home and run an availability or latency test for the current server. Then compare it with another server from a service configuration you already have. If only one fails on the same network, the issue is usually that server, its port, or its credentials. If all fail, check whether the subscription updated successfully, whether the local network restricts the target port, and whether DNS can resolve the server hostname.
Error: Request timed out
Cause and fix: No response arrived within the waiting period. Common causes include an offline server, packet loss, or an unreachable target port. Switch to another server from a configuration you already have. If only the original server fails, ask your own service provider to verify its status and port.
Error: Failed to resolve hostname
Cause and fix: The server address uses a hostname, but the current DNS did not return a usable address. Open Settings → DNS, review the DNS settings, and make sure the server hostname has no extra spaces or spelling errors.
Error: Network is unreachable
Cause and fix: The device has no usable network route, or Wi-Fi has not completed portal authentication. Turn off the connection and open a regular webpage to verify the original network. If necessary, complete the Wi-Fi sign-in first, then turn Shadowrocket on again.
Error: Failed to load subscription
Cause and fix: The subscription URL may be invalid, the request may have timed out, or the server may not have returned valid content. Check your own link, such as the clearly illustrative format https://example.com/sub?token=xxxx, confirm its status with your own service provider, then return to Home and pull down to update.
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different parameter structures. Do not apply one protocol’s port, authentication fields, or transport settings to another. A successful subscription update does not mean every server is online; it only means Shadowrocket successfully retrieved and parsed the configuration.
- When the server address uses a hostname, first confirm that DNS can resolve it.
- When the server address uses an IP address, DNS has less impact on establishing the server connection, so check the port and credentials first.
- If the same server fails on Wi-Fi but works on cellular, check the current Wi-Fi route and router policies.
- If every server fails on both networks, verify the subscription update time, account status, and service-side status.
Layer 2: Use Global Routing to trace where traffic goes
Global Routing determines whether requests use one uniform policy or are matched by Config. Proxy sends requests through the proxy policy, Direct connects directly, Config evaluates rules in order, and Scene selects behavior based on a preset scenario. For troubleshooting, the most useful comparison is between Proxy, Direct, and Config.
| Test result | Primary conclusion | Next step |
|---|---|---|
| Direct works, Proxy fails | The local network works; the server path or server parameters are likely at fault | Test another existing server and verify the hostname, port, and authentication fields |
| Proxy works, Config fails | The server works; a Config rule or policy name is incorrect | Check rule order, policy-group names, and FINAL |
| Proxy and Config work, Direct fails | The target is unreachable over the current direct network, or the direct DNS result is abnormal | Check the DNS result and the policy assigned to the target in Config |
| All three modes fail | The local network, system network permissions, or basic DNS settings are more likely causes | Turn off the connection to verify the original network, then check Settings → DNS |
| Fails in Scene, works with manual Config | The Scene trigger or selected configuration does not match the current network | Check Scene conditions for Wi-Fi, network status, and configuration |
Conclusion: Lock the server first, then compare modes
With the same server, if Proxy works but Config does not, a server failure is no longer the leading suspect. Repeatedly switching servers only adds variables; check rule matches and policy-group names instead.
If you are using Scene, temporarily switch to manual Direct, Proxy, or Config while troubleshooting. After the basic path works again, return to Scene and check its trigger conditions. This prevents scene switching and rule matching from affecting the diagnosis at the same time.
Layer 3: Check whether DNS resolution is failing
DNS converts hostnames into addresses. When DNS fails, a server latency test may still return a result while a webpage entered by hostname hangs for a long time. A few apps with established connections or cached results may continue working temporarily, so partial access does not rule out a DNS problem.
Open Settings → DNS. Record the current entries first, then check for unreachable DNS addresses, an incorrect encrypted-DNS URL, or duplicate settings. Traditional DNS usually uses UDP or TCP port 53, while DNS over HTTPS usually uses HTTPS port 443. Their network paths differ, so test them separately when troubleshooting.
Record DNS
Open Settings → DNS and save the current addresses, protocol type, and related switch states. If you need to roll back, you should be able to restore the configuration used before troubleshooting.
Check the format
Traditional DNS should contain a valid address; DNS over HTTPS should use a complete HTTPS URL. Remove leading and trailing spaces and check that the path was not truncated.
Reduce variables
Temporarily keep only one DNS entry confirmed to be reachable. Do not stack several entries with unknown results. Reconnect after changing the setting so it takes effect in the current network session.
Compare resolution
Test both a hostname you have never visited and one you have visited before. If the new hostname fails while a cached page opens, prioritize checking the DNS query path.
Review request results
In the request or log information visible in Shadowrocket, look for messages such as resolve, DNS, and timeout, and record the failed hostname. Do not rely only on the browser’s generic error page.
Traditional DNS:
Server address → UDP/TCP 53 → return A or AAAA record
DNS over HTTPS:
HTTPS URL → TCP 443 → encrypted query → return resolved recordIf the server itself uses a hostname, a DNS failure occurs before the server connection is established. If the server uses an IP address but the destination website uses a hostname, the server connection may succeed while the webpage request fails because the destination hostname cannot be resolved. Both cases can show the connection switch as on, but the failure occurs at a different layer.
Conclusion: Distinguish the server hostname from the destination hostname
If the log first shows that the server hostname failed to resolve, address DNS before the connection is established. If the server is already connected and only the destination hostname fails, check the destination-resolution path inside the tunnel and how Config handles DNS requests.
Layer 4: Check Config rule order and FINAL
When Proxy works but Config does not, focus on the rules. Shadowrocket usually evaluates Config rules in order, and the first matching rule determines the policy. FINAL handles requests that matched nothing earlier, so it is usually placed at the end.
The following snippet sends matching domain suffixes to PROXY, local-network addresses and addresses matching GEOIP to DIRECT, and passes all remaining requests to PROXY through FINAL. PROXY must match a policy or policy-group name that actually exists in the current Config. If the configuration uses another name, keep the rule and policy names exactly consistent.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX: Matches by domain suffix, for example covering a main domain and its subdomains.
- DOMAIN-KEYWORD: Matches when the domain contains the specified keyword; its scope is usually broader than a suffix rule.
- IP-CIDR: Matches an address range; with no-resolve appended, it does not issue an additional domain lookup for the match.
- GEOIP: Matches according to the geographic database result for the destination IP, so the destination IP usually must be obtained first.
- FINAL: Handles remaining requests that matched no earlier rule. A missing or incorrect policy can make unmatched traffic behave unexpectedly.
The most common rule problem is not too few rules, but conflicting order. For example, a broad DOMAIN-KEYWORD rule placed before a precise DOMAIN-SUFFIX rule may intercept the request early. An IP-CIDR range with broader coverage placed before the target rule can likewise prevent later rules from matching.
Open Config and confirm that the checked item is the configuration currently being edited. Save the change and reconnect, then test in Config mode. If Shadowrocket’s request details show the target matched DIRECT when it should use PROXY, adjust the rule order or content. If the policy name does not exist, correct the rule reference.
Symptom: Proxy works, Config cannot access the network
Cause and fix: The server path has passed a uniform proxy test, so Config may contain an incorrect DIRECT, REJECT, or policy reference. Review the target request’s match result and inspect the order starting with the first related rule.
Symptom: Only some hostnames will not open
Cause and fix: The failed hostname may have matched an overly broad DOMAIN-KEYWORD rule or may not be covered by the expected DOMAIN-SUFFIX rule. Record the complete hostname, add a precise rule, and test it before the broader rule.
Symptom: The result does not change after editing the configuration
Cause and fix: You may have edited a Config that is not enabled, or Global Routing may still be set to Proxy, Direct, or Scene. Return to Home, confirm the Config mode and selected configuration, then reconnect.
Layer 5: Rule out On Demand, subscriptions, and local-network interference
Settings → On Demand can trigger a connection based on network conditions. If the connection comes back immediately after you turn it off, or the mode differs from what you expect after switching Wi-Fi, temporarily disable On Demand for a baseline test. Once manual connection works, restore the trigger conditions one by one.
Subscription updates are a separate step. An app opening normally does not mean the subscription URL is currently valid, and a successful update does not mean every server in it is usable. Use information from your own service provider to verify the subscription, account status, and server maintenance.
Does the connection switch keep turning itself back on?
Open Settings → On Demand and temporarily disable on-demand connection, then return to Home and disconnect manually. If automatic reconnection stops, the trigger came from On Demand. Check the Wi-Fi and network-status conditions, restoring and testing them one at a time.
Does it fail on Wi-Fi but work on cellular?
Turn off Shadowrocket first, then open a regular page on that Wi-Fi and check whether portal sign-in is required. Once the original network works, keep the same server and Global Routing mode fixed and test again to determine whether the Wi-Fi restricts the target path.
The subscription updated successfully—why can’t I connect?
A successful update only means that the configuration content was retrieved and parsed. Return to Home and test the specific server, then verify a real request in Proxy mode. If servers produce different results, record them separately; do not equate subscription-update status with server availability.
Direct works, but Config and Proxy do not—what should I do?
The local network connection is probably sound. Keep one server fixed and use Proxy to verify the server path. If Proxy fails, check the server status, hostname, port, and credentials; do not change Config rules yet.
What if only one app cannot connect?
First confirm whether the app can connect with Shadowrocket off, then review its request hostnames and rule-match results. If other apps work in the same mode, focus on the destination hostname, IP-CIDR, REJECT rules, and the app’s own network permissions.
Also check that the system time is accurate. Some protocols rely on TLS or time-sensitive validation, and a large device-clock offset can cause the handshake to fail. Use the system’s automatic date and time setting, then reconnect. After switching between Wi-Fi and cellular, disconnect and reconnect as well so the route and DNS session are rebuilt.
Consolidate the diagnosis and restore settings
After completing the tests, record the result as a combination of “network conditions + server + Global Routing + DNS + Config.” For example: “On the same Wi-Fi, Direct worked, the fixed server timed out in Proxy, and switching to another existing server restored access.” This identifies a server-path issue instead of vaguely describing it as no internet access.
When contacting your own service provider, provide the time of occurrence, network type, server name, protocol, port, exact error text, and comparison results. Authentication details such as the subscription token, password, and Private Key should not appear in screenshots or public records.
- Original network fails: address Wi-Fi, cellular data, or portal authentication first.
- Direct works, Proxy fails: check the server status, port, authentication, and server-hostname resolution.
- Proxy works, Config fails: check rule order, policy names, FINAL, and the currently enabled Config.
- Hostnames fail while existing connections still work: check Settings → DNS and resolution errors.
- Manual settings work, automatic Scene fails: check Settings → On Demand and Scene conditions.
- After recovery, restore the temporary mode, DNS, and test rules to the confirmed configuration.
Shadowrocket is available only through the App Store. The product page should list the developer as Shadow Launch Technology Limited, and the app ID is 932747118. iPhone and iPad are the primary devices; compatibility and system requirements are as listed on the App Store page. Before reinstalling, confirm how to back up configuration and restore the purchase so reinstalling is not treated as the first troubleshooting step.