01 / CONNECTION SWITCH
Connection switch turns off unexpectedly
A switch that turns off immediately, incomplete system authorization, and a connection that appears briefly before dropping are three different symptoms. Open Shadowrocket, stay on Home, and make sure the selected item is a server with complete settings—not an empty subscription group. Note any message shown when the switch turns off and check the VPN status in Settings. Don’t start by changing DNS or editing multiple rules: the tunnel has not been established yet, so those settings are unlikely to explain the failure.
Check system authorization and the selected item first
When you connect for the first time, iOS may ask permission to add a VPN configuration and require you to authenticate using your device passcode or other unlock method. Canceling, leaving the prompt, or not completing confirmation can prevent the connection. Return to the app and try again, reading the full system prompt before deciding whether to allow it. If a configuration is already saved, search for VPN in Settings and check that the configuration exists and belongs to the app you’re using. Settings paths can vary by system version; follow what your device displays rather than relying on a fixed menu path.
If no authorization prompt appears, first make sure you haven’t left the app on an unsaved editing screen. Return to Home, select an existing server, and try connecting again. One failed attempt is not enough to conclude that the configuration is damaged. Also note the network type, whether you recently switched networks, and whether the device clock is set automatically. A significantly incorrect clock can interfere with certificate validation, but don’t work around it by disabling certificate checks.
Rule out automatic connections and configuration conflicts
Temporarily turn off On Demand, then test the switch manually. On Demand starts a connection when its conditions are met. If it remains active while you troubleshoot, the connection may come back after you manually disconnect, making the switch appear broken. Also check for other active VPN configurations or organization-managed network policies. Stop only connections you recognize and are allowed to change. Don’t remove management profiles from unknown sources; on a managed device, ask your administrator which network configurations are permitted.
Next, keep the current server unchanged and try again on Wi-Fi and cellular data, both with working internet access. If the issue occurs only on Wi-Fi that requires a captive-portal login, disconnect Shadowrocket, sign in or accept the network terms, then reconnect in the app. If every network fails at the same stage after authorization is complete, focus on the server settings, configuration parsing messages, and app logs. Don’t treat switching networks by itself as a fix.
Rebuild the system configuration only as a last resort
Disconnect fully, then reopen the app. If the issue persists, restart the device and test again. If you need to remove and re-add the VPN configuration, first make sure your server and configuration details are safely saved and that you can complete authorization again. Removing a VPN entry from Settings does not restore a subscription or fix a server-side issue. Don’t reinstall as a first step: local data may not return automatically, and reinstalling can erase useful troubleshooting evidence.
You’ve resolved this issue when a manual connection no longer turns off immediately, the corresponding connection status stays active in Settings, and authorization prompts do not keep reappearing. If it still fails, briefly record how long it takes for the switch to turn off, the exact prompt, network type, and whether automatic connection is enabled. The same error on two networks is more useful for diagnosis than “the switch won’t turn on.” For questions about the app’s purchase or source, check the authenticity verification guide.
02 / CONNECTED BUT OFFLINE
Connected, but no internet access
If the system says VPN is connected but websites won’t load, distinguish “tunnel established” from “request succeeded.” A web request may involve DNS lookup, rule matching, connecting to a server, and a response from the destination. Failure at any stage can look like a page stuck loading. Choose one site you can normally access as a consistent test, and record the exact error. Avoid switching between sites, since different destinations and access conditions make results harder to compare.
Compare direct and proxy connections
Disconnect Shadowrocket first and confirm that the current network can open your test page. If it still fails, check Wi-Fi sign-in, cellular data access, your router, or the destination service before troubleshooting the app. If the base connection works, reconnect and check Global Routing. For a temporary test, keep the server unchanged and change only this setting. Restore your usual mode afterward so you don’t leave a diagnostic setting in place.
| Option | What it does | What it helps you check |
|---|---|---|
| Config | Applies request handling according to the active configuration’s rules | Whether the rules, policy groups, and selected configuration are correct |
| Proxy | Routes the test request through the proxy | Whether the current proxy route works |
| Direct | Routes the test request directly | A supplementary comparison of route differences |
If Proxy works but Config doesn’t, check which Config is active, which rule matches, and which policy is applied before assuming the server has failed. If Direct works but Proxy fails, investigate the selected server, protocol settings, and proxy route. Note that testing Direct while connected is not the same as fully disconnecting the app: DNS settings and other conditions may differ. Treat it as supporting evidence, not a substitute for testing the base network.
Check which rule actually matches
In the Config list, confirm that the expected file is active—not merely imported but left unselected. Rules are generally evaluated in order, and an earlier match can affect what happens next. Adding a rule to the end of a file may not change the result if an earlier rule already matches. In request logs, check the destination domain, matched rule, and final policy. If the configuration uses policy groups, check the group’s current selection too; the group name alone doesn’t mean it points to a working server.
This abbreviated rule snippet illustrates ordering only. It is not a complete configuration and should not replace the file you’re using. The first rule matches only the example domain, the second handles a specified private address range, and the final rule is the fallback when no earlier rule matches. Troubleshoot in a backup copy with minimal changes, and confirm that the edited file is the active configuration.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYTell whether everything fails or only one service
If every site fails, check the shared route first: server, DNS resolution, and default policy. If only one service has a problem, check its domain, sign-in status, destination restrictions, and other connections it uses. A single site may load resources from several domains; the homepage working doesn’t mean its images, sign-in API, or media requests use the same route. Don’t assume all rules are correct just because the main page appears.
For each test, start a fresh connection to the destination. If needed, close and reopen the page to avoid misleading results from a reused connection. Consider the issue resolved when the page and its key features work, the logged policy matches expectations, and a repeat test also succeeds. If the problem occurs in only one app, check its network permissions and cache before investigating Shadowrocket. See the FAQ for common concepts, and avoid mistaking an app sign-in problem for a connection failure.
03 / SERVER TIMEOUT
Server timeouts and protocol settings
Read Connectivity Test results in the context of how the test was run. A timeout means the expected response wasn’t received under the test conditions; it does not prove the server is permanently unavailable. A response from the test also doesn’t guarantee that real websites will work. Keep the test method and error message, then try an actual request using the same server. If the test succeeds but the request fails, check the destination, rules, and DNS. If both fail, verify the server endpoint and protocol settings one at a time.
Start with the address, port, and authentication
Open the relevant item for editing and compare its address, port, and protocol type with your original server details. The address field should not contain an unrelated path or extra spaces, and the port must match the port the server actually listens on. Subscription entries can also become outdated when a link expires or details change. Confirm that the original details are still valid instead of repeatedly changing client settings until one attempt happens to work.
Make sure each authentication field matches the protocol in use. Shadowsocks requires the correct encryption method and password. For VMess and VLESS, check the user ID and transport settings required by the server. For Trojan, verify the password and secure-connection parameters. Fields that look similar across protocols are not interchangeable. Watch for full-width characters, line breaks, and leading or trailing spaces when copying. Don’t share full authentication details; just report whether the fields match.
| Parameter | Check | Common symptom |
|---|---|---|
| Endpoint | Address, port, and current resolved address | Unable to connect or connection times out |
| Authentication | Password, user ID, and encryption method | Server reached, but request cannot complete |
| TLS | Server-required name, certificate, and device time | Secure connection validation fails |
| Transport | Transport type, path, and related host fields | Handshake fails or connection closes immediately |
Separate TLS issues from transport errors
The server address, the name used for TLS, and any host field required by the transport may differ, but each must come from your server details—not a guess. If you see a certificate error, correct the device clock first, then check the name and the server’s certificate status. Don’t routinely skip verification. Even if that changes the error temporarily, it won’t fix an identity mismatch and will make secure connections less reliable.
If the server uses a specific transport, the client’s path, host fields, and related options must match. A missing field may let the connection reach the endpoint but cause the handshake to fail. Restore the values from your original server details before testing; don’t try several paths and security options at once. A change from a timeout to a clear authentication or handshake message is useful progress: it means the failure is occurring at a different stage.
Check the network route and server-side factors
Keep the server entry unchanged and try another network. If it fails on only one network, note the network type and transport characteristics. Some protocols rely on UDP, and networks may handle that traffic differently, but one failed test doesn’t confirm the cause. Read Hysteria2 protocol basics for background; base troubleshooting on repeatable network comparisons and actual error messages.
If your other valid server entries work on the same network but this one fails across multiple networks, ask the original service provider to check the listening port, authentication, and service status. Client logs alone cannot tell you whether the remote process is running or fix its server configuration. Share only the redacted failure stage, conditions, and test results—not the full subscription. After a fix, retry a real request and confirm that reconnecting works too; one successful test may be a fluke.
04 / SUBSCRIBE
Subscription import and update failures
A subscription update usually involves fetching the link, recognizing its format, and replacing local entries. A fetch failure, unrecognized content, and an update that succeeds but leaves servers unusable are different problems. Check the message first, then troubleshoot the relevant stage. Your subscription link should come from your own original details. A subscription provides configuration data, not proof of app purchase; updating a subscription is also separate from updating Shadowrocket.
Check the link without exposing credentials
Check that the address in the Subscribe item is complete, especially the parameters after the question mark. Sharing tools can truncate a link or append punctuation, explanatory text, or line breaks. Copy it again from the original source and compare it with the saved address section by section. Matching domains alone is not enough: a different path or parameter can point to entirely different content. The address below is illustrative only—not a working service or a link to obtain one.
https://example.com/sub?token=xxxxA complete subscription link may grant access, so handle it like a password. Don’t submit it to an unfamiliar conversion page or show it in screenshots you share. To check whether it has expired, use your own service management page or contact the original provider. After copying the link again, update the existing subscription and verify the result. Avoid creating several groups with the same name, which can make it hard to tell old data from new or identify the active selection.
Narrow it down: fetch, format, then entries
If fetching fails, check the base network, DNS resolution, and link access requirements. Some links are reachable only over a particular network route; note whether you updated while disconnected or connected, and compare while keeping other conditions unchanged. Opening a sign-in page in a browser doesn’t mean the subscription endpoint can return the content the app needs. If the response is a webpage, error message, or authentication page, retrying won’t turn it into a server list.
If the format isn’t recognized, make sure you copied a subscription URL, not a management dashboard or web-sharing URL. Don’t change the response encoding or delete fields you don’t understand. First check whether the original provider’s format is compatible with Shadowrocket. If import succeeds but only some entries appear, the cause may be the data format, entry validity, or parameter parsing. Keep the old data and compare entries individually instead of deleting the whole group.
After an update, check selections and references
An update may change server names, group contents, or available entries. The selected item may refer to an entry that has been removed, making it seem as though the update broke the connection. Check the current selection on Home, then look in Config for policies or groups that refer to entries by name. Test directly with a valid updated entry first, then restore complex rules to distinguish changed data from broken references.
Once manual updates work consistently, consider options such as updating when the app opens. Automatic updates don’t guarantee that fresh data will be available each time; they still depend on the network, link validity, and returned content. Repeated updates may also trigger request limits from the original service. Follow its refresh guidance, keep the error message, and wait a reasonable interval instead of repeatedly tapping. See the subscription update guide for details.
To verify the fix, complete the full sequence: save the correct link, update manually, confirm the entries changed, select a server again, and access a real destination. If old entries still work but the update fails, keep the working setup and troubleshoot the update process. If the update succeeds but all connections fail, go to the server timeout section. Reporting “fetch failed,” “format not recognized,” or “connection failed after update” is more useful than simply saying “the subscription is broken.”
05 / PERFORMANCE
Slow speeds and unstable connections
“Slow” might mean a long wait before a page opens, slow transfers, intermittent video playback, or a brief loss of connection after switching Wi-Fi. These are different symptoms. Describe what happens in one sentence—for example, “The first page load is slow, but transfers are normal once they start”—then choose the relevant checks. Response time, throughput, and stability are different measures; one Connectivity Test cannot summarize the whole experience.
Set up a fair comparison
Keep the device, network, server, and test content the same. Stop heavy background transfers, then repeat the same action. Test the base network with Shadowrocket disconnected first. If it’s slow too, check signal strength, router load, and the network itself. When comparing different times of day, record what changed; destination services and remote routes can also be under varying load. Don’t judge the same server by comparing different websites at different times.
If Wi-Fi alone is slow, move closer to the access point and check whether the signal is weak or the environment is congested. If cellular data is stable but the same Wi-Fi frequently drops, focus on the access network first. If the reverse is true, check cellular signal, device data settings, and when the network switches. Don’t reset all network settings as a first step: that changes too many variables and may erase saved network information, making comparisons harder.
Branch based on where the delay occurs
If the first page load is slow but later loads are normal, look at DNS resolution and connection setup. If every new domain takes a while but refreshing the same page is quick, DNS or the initial handshake may be involved. Caching can cause a similar pattern, so test more than once. If a page starts loading quickly but large transfers remain unstable, look at packet loss, remote load, destination throttling, and local traffic—not just DNS settings.
If only one app is slow, check the destinations it actually requests and which rules match them. Media, images, and sign-in APIs may use different domains, so different policies can make the experience inconsistent. When briefly comparing Global Routing modes, start a new connection to the destination so an old session doesn’t keep using its previous route. If Proxy is stable but Config varies, check whether a policy group switches automatically and whether related domains use different routes.
Use traffic statistics as clues, not conclusions
Data can help show traffic from different server or app-related views, but the reporting scope, connection reuse, and system behavior all affect the numbers. It can help verify whether a request went through the expected route, but one number can’t establish the remote bandwidth. See how to read statistics on the Data page. Note the test window when recording traffic so you don’t mistake a cumulative total from earlier connections for the current test.
Don’t change protocol settings just because they “might be faster.” The transport, encryption method, and security settings must first match the server’s requirements. For protocols involving UDP, consider whether the current network can reliably carry that traffic; there is no single best option for every network. If a specific protocol repeatedly fails on one network, keep the comparison with other working connections on that network and check with the original provider.
Verify performance in a real-use scenario: browse similar pages, complete an actual file transfer, or reconnect after switching networks. Success shouldn’t depend on a single brief spike in the readings; repeat the task and confirm there’s no obvious slowdown. If the issue is limited to a particular time or destination, record the time or destination category. Don’t keep adding client settings indefinitely. Once the cause is a remote service or base-network limitation, changing local rules usually won’t fix it.
06 / DNS AND ROUTING
DNS resolution and rule routing
DNS translates domain names into addresses, but a resolved address may still be unreachable, and a reachable address does not guarantee that a secure connection or app request will succeed. Symptoms can include DNS errors, a long wait on first access, failures limited to certain domains, or unexpected rule matches. First note whether the error explicitly mentions DNS. Then check the active configuration and where its DNS settings come from; not every page-loading failure is a DNS problem.
Identify the active DNS source
Check the active Config and related DNS settings. Confirm whether requests use system DNS, custom DNS, or a setup that includes DNS over HTTPS. Don’t just inspect a file you recently edited—make sure it’s actually enabled. If DNS settings appear in multiple places, understand how they interact before changing anything. Also check for organization-managed DNS settings on the device. When sources are combined, changing one visible setting may not change the actual request route.
Save the original settings first, then establish a baseline with the simplest DNS method you’ve confirmed works. DNS over HTTPS must reach its own service endpoint, so it also depends on a working connection and valid name verification. Routing DNS traffic through a proxy that hasn’t been established can create a dependency loop. Don’t keep adding DNS addresses to fix one failed domain; doing so makes timeouts and fallback behavior harder to diagnose.
Distinguish domain rules from IP rules
Rules such as DOMAIN and DOMAIN-SUFFIX match domain information; IP-CIDR, IP-CIDR6, and GEOIP involve address matching. They apply at different stages. An IP rule matching doesn’t mean an earlier domain rule is correct, and a domain rule matching doesn’t guarantee that the resolved address is suitable for the current route. Check the actual match in the request log first, then determine whether the issue is the DNS result or a rule sending the request to the wrong policy.
[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYThis example illustrates rule types and ordering; it isn’t suitable for every setup. Here, the exact-domain and suffix rules overlap, so keep only the entries your configuration needs. FINAL is a fallback policy, not a DNS repair switch. Troubleshoot in a copy by reducing the rules to the fewest relevant to your destination. Check where the request goes, then restore rules one at a time and retest to identify conflicts.
Avoid drawing conclusions from non-equivalent tests
Typing an IP address into a browser is not a reliable substitute for visiting the original domain. Secure connections usually require the correct host name, and a website may use that name to select a service. Failure when entering an IP address alone does not prove the network is unreachable. Don’t permanently add an address resolved on another device to your configuration either: remote addresses can change, and different networks may have different working routes. Check errors and DNS records from the actual request first.
Old connections and cached results may affect tests after changing DNS. Disconnect and reconnect, then close and reopen the destination page; restart the relevant app if needed. Don’t assume a change failed just because a single refresh looks the same, and don’t keep clearing settings across the whole device. If only one domain fails, check its spelling, destination service status, and behavior on other networks. If all domains fail, check whether the DNS service is reachable and where the active settings come from.
For local network names, device discovery, or workplace domains, consider whether they require DNS provided by the current network. Sending all DNS requests through a different route may restore external browsing but break internal services. Add the smallest exception that meets the need instead of disabling all rules. For a comparison of system DNS, custom DNS, and DNS over HTTPS, see DNS settings compared, then return to this section and test the same destination.
07 / BATTERY AND BACKGROUND
Unexpected battery drain and background connections
When troubleshooting battery drain, distinguish ongoing transfers, repeated reconnects, and simply keeping a connection active. The app’s percentage in the system Battery view is relative to a reporting period; it doesn’t mean a particular switch uses a fixed amount of power. Screen time, signal quality, and background activity all affect the result. Note when the issue occurs, whether the device feels warm, and whether a large sync just finished. Then check whether Shadowrocket’s connection activity coincides with the drain.
Compare under similar conditions
Use similar conditions and note the device’s behavior with the connection on and off. Keep screen brightness, network, background tasks, and usage time as consistent as possible. Don’t compare idle time with watching video continuously. If the device stays noticeably warm after disconnecting, check other activity such as post-update processing, photo syncing, or large file transfers. A VPN carries traffic, but that doesn’t mean the proxy client itself generated it.
Check Data and request logs for heavy traffic while idle or the same destination failing repeatedly in a short period. Auto-refreshing pages, cloud sync, and background tasks from other apps can keep the connection busy. Identify the source before changing that app’s background behavior. Don’t delete a configuration you’re using just to lower a statistic; you’ll lose the information needed to understand the traffic route.
Fix repeated reconnects instead of hiding them
If logs show the connection repeatedly coming up and dropping, check network signal and server stability first. Retries in a weak-signal area hurt the experience and make the device work harder. Keep the configuration unchanged and observe it on stable Wi-Fi. If the problem stops, check the original network’s signal and handoff behavior. If it continues across networks, follow the server timeout checks for authentication, transport, and remote status instead of treating it as only a battery issue.
On Demand may start a connection again when its conditions are met, so reconnecting after you manually disconnect isn’t necessarily a fault. For comparison testing, temporarily turn off the relevant automatic connection conditions and note the original settings. Restore them afterward. Conditions that keep switching between states can trigger repeated connections. Decide clearly which networks should connect and which should stay disconnected rather than using conflicting conditions.
Reduce diagnostic overhead and unnecessary requests
Detailed logging is useful for short-term diagnosis, but there’s no need to keep intensive diagnostics enabled after the issue is resolved. If you turned on extra logging or ran frequent tests, restore normal usage once you have the evidence you need. Also check whether automatic subscription updates, policy tests, or scheduled actions you configured yourself are running too often. These features should provide useful information—not run more frequently in the hope that they’ll improve stability.
If data is transferred after the screen locks, the system may be maintaining a necessary connection. If you don’t expect any activity but see many repeated failed requests, investigate their source or a faulty retry loop. A few retries after a single failure are not the same as continuous abnormal activity; judge by observing over time. Don’t conclude that the app uses excessive battery over the long term based on one temperature reading or a brief drop in charge.
After making changes, observe another period under the same network and usage conditions as your baseline. Confirm that reconnects have decreased, unexpected requests have stopped, and browsing still works. If the same drain continues with the client disconnected, look at the system or other activity. When reporting the issue, include the reporting period, screen usage, network type, and redacted activity patterns. You don’t need to share full browsing history, and you should never publish a configuration with authentication details.
08 / CHANGE AND RECOVERY
Issues after an update and configuration recovery
First clarify what “it stopped working after an update” means: the app from the App Store, the operating system, subscription contents, or a Config file. These changes may happen on the same day but affect different layers. Updating the app doesn’t renew an expired subscription, and updating a subscription doesn’t guarantee that rule references still work. List what actually changed between the last successful use and the first failure. Don’t assume a change caused the issue just because it happened around the same time.
Preserve the current state, then test a minimal configuration
Before making more changes, save a copy of your current configuration, the selected server name, and the Global Routing mode. A backup may contain sensitive information, so store it somewhere you control. Check when it was created and what it includes. A server list, rules file, and system VPN authorization are different kinds of data; backing up one does not guarantee that the whole setup can be restored.
Restart the app and reconnect to confirm the issue persists. Keep the current valid server unchanged, then test a real request using a simplified route. If Proxy works but the original Config fails, focus on parsing, rule order, and policy group references. If every route fails, check the server, authorization, and base network. The purpose of a minimal test is to reduce variables—not to create a permanent configuration that replaces everything you need.
Check the change that actually occurred
If the issue followed a subscription update, first confirm that the selected entry is still in the updated list and that the original policy group doesn’t refer to a name that changed. If it followed a Config update, check the import message, active file, and fallback rules. Make sure the new file wasn’t saved as a separate, inactive copy. If the configuration comes from your own existing source, keep old and new versions for comparison. Restore settings in small groups rather than overwriting everything with potentially broken content.
After an app or system update, check whether VPN authorization in Settings still works and whether the device is doing other post-update processing. Don’t clear all network settings after one failed connection. If you can reproduce the issue, note the steps and exact error message, and check the App Store page for current app details. Get and update the app through the App Store. For source verification, see the App Store & Purchase page.
Restore and verify settings one at a time
Before restoring a backup, confirm that its server details are still valid. An old configuration may be syntactically correct but contain an outdated address, authentication details, or references. Restore essential servers and test them first, then restore core rules, followed by automatic connection and other optional behavior. Record the result after each step. If the next step fails, you can focus on what you just restored instead of guessing at every setting.
| Recent change | Check first | How to verify recovery |
|---|---|---|
| Subscription update | Current entries, name references, authentication details | Updated entry can access a real destination |
| Config replacement | Active file, rule order, policy groups | Destination request matches the expected policy |
| App or system update | System authorization, connection logs, network conditions | Reconnect and reopen the app; both work normally |
Only consider reinstalling after saving essential data, understanding how to restore it, and exhausting ordinary troubleshooting. Reinstalling won’t fix an unavailable remote server or make an expired link valid again. Treat restoring a purchase and restoring local settings separately: the former depends on your App Store purchase history; the latter depends on your own backup. Getting the app again does not guarantee that local configuration will return automatically.
If the issue persists, write a minimal reproduction summary: device type, network type, last known working state, what changed, and the result with a simplified configuration. Remove credentials and unrelated history; don’t send a complete log of everyday traffic. Recovery means reopening the app, reconnecting after a network switch, confirming that the destination works, and verifying that automatic connection conditions behave as expected. A temporary fix in the current session isn’t enough.
09 / IPAD CHECKLIST
iPad-specific troubleshooting and verification
The basic connection flow is the same on iPad as on iPhone, but common scenarios include multitasking on a larger screen, different Wi-Fi networks, local network devices, and moving between devices. Don’t assume another device’s results apply: the same subscription working elsewhere only shows that some conditions may be correct, not that this iPad has the same configuration enabled. Check the App Store page for system requirements, compatibility, and purchase eligibility; don’t infer support from a device’s appearance.
Separate app access from configuration transfer
First confirm that the correct version of Shadowrocket is installed on your iPad. To verify authenticity, check the developer, Shadow Launch Technology Limited, the official icon, and app ID 932747118. See how to get Shadowrocket on iPad for details. Getting the app from your purchase history doesn’t mean another device’s subscription, selection, rules, or automatic connection conditions have synced. Check each item after transferring; an empty list doesn’t mean the purchase failed.
If you import your own backup, confirm that the file is complete and check which items are actually enabled on this device. A server name appearing in the list doesn’t mean it’s selected, and an imported Config isn’t necessarily active. On iPad, repeat the basic flow: select a valid entry, connect manually, open a consistent test destination, then restore your rules and automatic connection settings. Complete authorization on the iPad itself; authorization on another device does not replace it.
Check network and permission differences on this device
Some iPads connect only over Wi-Fi, so cellular data may not be available as a comparison. You can test another network you’re authorized to use, but first confirm that the network itself works. On campus, workplace, or public Wi-Fi, disconnect Shadowrocket before completing any required web sign-in. Managed devices may also have organization settings; ask the administrator rather than removing them yourself.
If websites work but local network devices are unreachable, check that the destination address belongs to the current local network and that the relevant app has the local network permission it needs. Printing, screen mirroring, and device discovery may require more than a typical web request, so testing an external website isn’t enough. Check whether the rules route the relevant private addresses appropriately. Adding an IP rule alone may not cover discovery protocols or device permissions.
Check multitasking and network changes
If an issue appears after using Split View or switching apps, return to Shadowrocket and check the current connection status rather than relying on an old page. The page may show cached content, and the destination app may reuse an existing session. Start a new request, check whether it appears in the logs, and verify the policy. If there’s no new request, check whether the destination app is still loading or has been suspended; don’t mistake a request that was never made for a proxy forwarding failure.
If access briefly fails after waking the iPad, switching Wi-Fi, or moving away from an access point, wait for the network to stabilize before starting a new request. If the connection drops every time the device wakes, note whether On Demand is enabled, whether the original network requires another sign-in, and whether basic access works on that network. Temporarily turn off automatic connection for a manual comparison, then restore the original conditions. Don’t leave a setting that doesn’t fit your needs just for troubleshooting.
Complete the test on this iPad before returning to normal use
First verify basic access using a consistent test page in Safari, then test the app where the problem occurs, and finally check local network or multitasking scenarios. Record what works at each step. If one type of request fails, keep the earlier successful baseline and continue from there instead of changing everything again. For definitions, see the glossary. To repeat the full setup flow, return to the quick-start guide.
Final verification should include reopening the app on this iPad, reconnecting manually, accessing the actual service, and testing again after switching between your usual networks. If only this iPad fails, record differences in local authorization, network, configuration, and permissions. If several of your devices fail with the same server, focus on the server or subscription status. Following this order helps avoid repeated imports and reinstalls, and keeps any follow-up report focused on the layer that can be fixed.