01 · System connection
Connection switch won’t turn on or disconnects immediately
First check whether the system established a tunnel, then investigate the server used through it.
Distinguish “won’t start” from “starts but doesn’t connect”
Turn on the connection switch on Home. Check whether it stays on and whether the system shows VPN Connected. If the switch immediately resets, the issue is usually with system authorization, tunnel startup, or configuration loading. If it stays on but pages won’t load, continue to the next section. A failed server test doesn’t mean the system can’t establish a tunnel; conversely, a system connection indicator doesn’t prove the remote server is available. Note exactly what happens instead of repeatedly refreshing the subscription when the issue may be permissions-related.
The first time you connect, your iPhone or iPad will ask for permission to add a VPN configuration. Make sure the prompt was triggered by opening Shadowrocket yourself, then follow the system steps to authorize and verify the device. If you previously dismissed the prompt, return to the app and connect again. If no prompt appears, open system Settings and check whether a VPN configuration exists and whether device management restrictions apply. Check the App Store listing for system requirements; don’t infer compatibility from a device’s appearance or model name alone.
Check for configuration conflicts and automatic triggers
Temporarily disconnect other active VPNs and disable filtering features that may use a similar network extension, then start Shadowrocket by itself. This is not an assumption that any particular feature is faulty; it simply reduces the number of components controlling the system’s network path. If your device is managed by a school or employer, don’t remove management profiles yourself. Check whether the organization allows a personal VPN. System restrictions you can’t change must be handled by the device administrator; changing server settings won’t bypass them.
If the connection turns back on after you switch it off manually, check On Demand before assuming the switch is broken. On Demand conditions may reconnect when the network changes or an app makes a request. Note the original conditions, temporarily disable automatic triggers, and try one manual connection. If the VPN indicator remains after you disconnect, check which configuration the system is using; the same status icon doesn’t necessarily mean Shadowrocket established the current connection.
Use a minimal configuration to locate startup failures
Keep a copy of your current Config and compare it with a simple configuration from a known source that has worked before. If the connection drops immediately with only one Config, check recently added rules, script references, or incomplete configuration content. If no Config starts, focus first on system permissions and extension status. Change only one Config or SERVER at a time; otherwise, even if the issue is resolved, you won’t know what fixed it. Don’t update a remote configuration and restart the system at the same time.
If the app stops responding, close it and reopen it, then try once more. If that makes no difference, restart the device to clear a temporary system extension issue. Don’t rapidly toggle the switch; starting and stopping take time, and repeated actions make it harder to determine the current state. If the system displays a specific error, save its exact wording, when it appeared, and the steps to reproduce it. That information is more useful for diagnosis than simply saying “it won’t connect.”
Verify the connection after recovery
After restoring authorization or a configuration, keep On Demand off. Connect and disconnect manually once each, then revisit a page that previously failed. Restore automatic conditions one at a time only after the manual process is stable. If the switch works but you then see access errors, timeouts, or resolution errors, continue to the relevant section instead of repeatedly deleting the VPN configuration. Record which Config starts successfully and which paused system features made a difference so you can restore your previous setup later.
02 · Request routing
No internet after connecting
Start with the baseline network while disconnected, then compare the three Global Routing modes.
First confirm the underlying network works
Disconnect Shadowrocket and confirm that your current Wi-Fi or cellular network can access the internet normally. Public Wi-Fi may require you to open a sign-in page, accept terms, or log in again. Without completing that step, access may fail even when the server settings are correct. Finish network authentication before starting the app. If access also fails while disconnected, check your router, signal, data limits, and system network status first; don’t start by editing rules.
Once the underlying network works, reconnect and visit one known working test page. Note whether all apps fail or only a browser, a specific app, or a particular domain. If one app is affected, check its cellular data permission, network settings, and cache. If all requests are affected, check SERVER, Global Routing, and Config. A cached page isn’t proof of a working connection. Refresh it or open a new page to get a more useful comparison.
Narrow down the issue with three routing modes
| Mode | How requests are handled | What to check |
|---|---|---|
| Config | Uses the policy selected by the active configuration rules. | Check rule matching and policy references. |
| Proxy | Routes most requests through the selected proxy path. | Limit the effect of rules during testing. |
| Direct | Sends most requests directly. | Compare against the current underlying network path. |
If Proxy works but Config doesn’t, at least one proxy path is available. Focus on rule order, policy names, and the final fallback in Config. If Direct works but Proxy fails, check the selected server and remote connection; don’t change DNS right away. These three modes are diagnostic tools, not a complete test for every setup. Local network addresses, DNS requests, and system traffic may still be affected by other settings. Restore your usual mode after testing.
Check whether rules use the right policy
Open Config and make sure the expected file is active, not merely downloaded to the list. Rules are usually checked in order, so a broad rule near the top may prevent a more specific rule below it from matching. The snippet below illustrates rule order; it isn’t a complete configuration for every network. PROXY must refer to a policy available in the active Config. If the file uses a custom policy name, check that it exists and is spelled consistently.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYIf only one domain is affected, check which rule the request matched and which policy was ultimately selected. A request matched by REJECT is blocked according to the configuration; that doesn’t indicate a server failure. For testing, add a narrowly scoped rule rather than deleting all rules. Decide whether to change the original rule only after testing. For more on rule order, see the rules section in Proxy mode, and avoid leaving temporary test rules in place.
Finish with a reproducible comparison
If both Proxy and Config fail, test another server you already have and have confirmed is configured correctly, then try a different underlying network. If the issue occurs on only one network, check its authentication, UDP availability, or local restrictions. If the same server fails across networks, continue to the server timeout section. If only domains fail to load, see the DNS section. After each finding, restore unrelated settings so temporary changes don’t accumulate into a new source of problems.
03 · Remote connection
Server timeouts and handshake failures
Distinguish transport failures, authentication errors, and target access problems instead of treating every error as a timeout.
Verify the endpoint before interpreting test results
Get current server details from your provider and verify the address, port, protocol, and authentication fields. A subscription’s display name is only a label; it doesn’t identify the server address or prove that the server is still available. When entering details manually, check for leading or trailing spaces, full-width characters, and missing text. Don’t paste accompanying instructions from a web page. If you use a subscription, confirm the subscription was updated and that the server belongs to the group you’re using, so you don’t edit an unselected entry.
Connectivity Test results depend on the test method and target. A failed test may indicate a remote connection problem or an inaccessible test target. A successful test only confirms that particular test completed; it doesn’t verify sustained downloads or every app. Check which test method is selected in settings, then verify access by opening an actual page. Don’t compare values from different test methods or judge a connection’s long-term quality based on one result.
Check the required fields for each protocol
For Shadowsocks, verify that the encryption method and password match the server. For VMess and VLESS, check the relevant identity fields and transport settings. For Trojan, verify the password and TLS details. Hysteria2 relies on UDP, so a network that can’t carry UDP reliably may prevent it from working even if TCP pages load normally. For WireGuard, check the keys, addresses, and allowed routing ranges. Changing the protocol name alone won’t work; all fields must match the server.
| Symptom | Check first | Don’t assume |
|---|---|---|
| Connection timed out | Address, port, network path, and server availability. | It doesn’t prove the password is wrong. |
| Authentication failed | Identity fields, password, and subscription status. | Changing DNS won’t fix authentication. |
| TLS handshake error | System time, SNI, certificate name, and transport settings. | Don’t disable certificate verification by default. |
Don’t bypass certificate checks to hide TLS errors
The server address, the name used for TLS, and the transport-layer Host may differ. Use the values provided by the server; don’t guess based on a display name. An incorrect system date or time can also cause certificate validity checks to fail, so enable automatic time and verify the time zone. If the certificate name doesn’t match, check the SNI and server certificate instead of routinely bypassing verification. Doing so changes the connection’s trust boundary and may not fix the underlying configuration error.
If the same server times out on Wi-Fi but works on cellular, keep SERVER and Config unchanged, switch networks, and test again to see whether the result is reproducible. If the protocol relies on UDP, compare with another transport method you already have, but don’t randomly change ports or switch to a protocol the server hasn’t been configured to support. The client and server must be configured to match; changing one side can’t create capabilities the server doesn’t provide.
Gather evidence for your provider
If the connection still fails across networks, give your provider the protocol, approximate time range, error type, and comparison tests you’ve completed. Ask them to check server status and account permissions. Don’t share your full subscription URL, password, private key, or identity fields publicly. If you need to identify a server, provide its display name or a redacted part of its address. Share full details only when necessary through a trusted support channel. This site provides client usage guidance, not server-side diagnostics, and doesn’t recommend alternative services based on timeouts.
After fixing the issue, revisit the same target and make sure more than the test button works. If the handshake succeeds but pages remain slow, continue to the speed section. If a remote domain can’t be resolved, start with the DNS section. Keep a record of the source of the final working settings and what changed. If a subscription update later overwrites a manual change, you’ll be able to tell whether the server settings changed or a local fix was reverted.
04 · Import and updates
Subscription update failed or list is empty
Treat download failures, parsing errors, and servers that stop working after an update as separate problems.
Verify the link type and where it belongs
Get subscription links from your provider. The link should be intended for a client, not an account sign-in page, order page, or bookmarked browser management page. Follow the import steps in the guide to add your existing subscription, and check that the link and input field match. Watch for line breaks, spaces, and truncated text when copying. Don’t remove parameters from URLs containing special characters. A QR code may contain a single server rather than a subscription; check what was imported instead of judging by the QR code alone.
Subscription URLs often contain access credentials and should be treated like passwords. Don’t paste them into public comments, screenshots, or unfamiliar online conversion tools, and don’t include the full URL in a bug report. If you need to show its structure, retain only the domain and path format and hide sensitive query parameters. If the URL has been exposed, ask your provider to reset the relevant credentials. Deleting the local record won’t revoke access that’s already been exposed.
Separate download errors from parsing errors
An update error such as connection failed, domain resolution failed, or timeout means the app hasn’t received the expected content. First check the underlying network, DNS, and access to the subscription server. If the app receives a response but can’t import it, check whether the content is in a supported subscription format. Expired account notices, web verification pages, and access-denied pages may be returned as text, but they aren’t server lists. Repeatedly refreshing won’t turn them into a valid configuration.
Interpret HTTP status codes alongside the response. Permission-related errors usually require checking the link or account status. If too many requests were made, stop refreshing and try again later. Server errors require the server to recover. Don’t group every error under “incompatible format.” If your provider offers subscription options for different clients, choose content explicitly intended for Shadowrocket. Don’t use another configuration format just because its name looks similar, and don’t alter URL parameters at random.
Keep the old list before trying one update
Before updating, note whether the old list still works and back up any manually added servers if needed. A failed update doesn’t necessarily mean saved servers have also stopped working. Likewise, a successful update doesn’t mean every server will connect. Try one manual update and check whether the number of servers, groups, and names changed as expected. Then select one entry and test it. Repeatedly tapping refresh isn’t a useful test; it may trigger server rate limits and make the original issue harder to diagnose.
If the list is empty after an update, check whether the account is active, whether the server returned empty content, and whether a filter is hiding entries. If only some entries disappeared, the server may have changed its content or the import may have failed to parse it. Ask your provider to check the response type and error message. Don’t delete the entire subscription group first; you’d lose both the old list and useful comparison data. Manual server changes may also be overwritten at the next refresh, so check whether an entry belongs to the subscription or was added locally.
Verify the connection path before restoring automatic updates
If your provider’s subscription page is available only through a particular network path, use an existing working connection to update once and note the Global Routing mode. Without a working server, don’t force the only available subscription update path through a proxy that’s already failing. Config settings can affect how subscription requests are routed. Check actual logs and results instead of assuming all subscription requests always go direct or always use a proxy.
Once manual refresh works reliably, check the setting and timing for automatic updates when opening the app. If automatic updates fail, note what differs from a successful manual update—for example, the network wasn’t ready, a sign-in page hadn’t been completed, or the app had just returned to the foreground. For more details, see how to update a Shadowrocket subscription. To confirm the fix, check all three steps: the list was retrieved, its contents were parsed, and a server actually connects.
05 · Performance and transport
Slow speeds and intermittent stalls
Measure response time, throughput, and stability separately instead of using one latency result to explain every issue.
Describe “slow” in terms you can test again
A page that takes a long time to start loading, a slow download, repeated video buffering, and a connection that occasionally stops are different issues. Waiting for the first response may involve DNS resolution, the handshake, or the destination server. Sustained transfer speed also depends on bandwidth, packet loss, and device conditions. Record one fixed target, one consistent action, and an approximate time window, then compare. Don’t combine results from different websites, file sizes, or times of day and conclude that a server suddenly got faster or slower.
Pause system updates, cloud syncing, and other high-bandwidth tasks. Check that the device isn’t overheating, then test the same target. Speed tests also use bandwidth, so don’t run several at once. If only one app is slow, check its content server, cache, and background downloads. If other apps work normally, the client may not be the bottleneck. Record Global Routing and SERVER for each test so you don’t mistake direct access for evidence of proxy performance.
Compare the local network, remote route, and protocol in turn
Keep the same server and configuration while testing on Wi-Fi and cellular. If Wi-Fi alone is slow, move closer to the access point, check router load and interference on the current band, and compare with ordinary access on the same network. If cellular alone is slow, check signal changes, data throttling, and mobility. If the connection is just as slow with the client disconnected, troubleshoot the underlying network first. A proxy can’t restore capacity already lost on the local link or stabilize a congested access network.
Once the underlying network is stable, compare with another server you already have. If only one endpoint is slow, the cause may be that server’s load, its outbound route, or its connection to the destination. If all endpoints are slow only for one website, consider the destination service itself. A region label in a server name isn’t an actual routing map, and a closer location isn’t necessarily faster. Record the differences and ask your provider about route status instead of judging by the name.
Understand the difference between latency, packet loss, and throughput
Low latency can improve responsiveness, but it doesn’t directly mean faster downloads. Packet loss causes retransmissions, while jitter can make real-time communication and video buffering worse. A short test may not reveal these problems. Repeating a test with a normal, consistent task is more useful than checking a single value in the list. Don’t switch servers repeatedly during a download: existing connections may still be active, making it hard to tell which path produced which result.
Hysteria2 uses QUIC-related transport and may behave differently from TCP on some networks, but it requires reliable UDP access. The protocol name alone doesn’t guarantee speed, and encryption isn’t the cause of every slowdown. When adjusting transport settings, follow the server requirements and client options. Save the original values and test one change at a time. For protocol background, see the Hysteria2 protocol guide; don’t copy settings that don’t apply to your server.
Adjust settings only after identifying the affected layer
An unsuitable MTU may allow small requests but stall larger transfers, though it isn’t the default explanation for every slowdown. Adjust it slightly only when the issue is consistently reproducible and other layers have been ruled out, following your server or network requirements and noting the original value. Setting MTU too low adds overhead. Changing DNS, MTU, and protocol together makes it impossible to attribute any improvement. For occasional mobile-network jitter, results from several time windows are more useful than a single adjustment.
Verify the actual task: does the same page load reliably, does the same content transfer continuously, and does access recover when you switch networks? A temporary speed increase doesn’t prove the root cause is fixed; retest the original failure scenario. For a layered diagnosis, see how to troubleshoot Shadowrocket slowdowns layer by layer. If most of the delay occurs during domain resolution, continue to the next section instead of replacing all your servers.
06 · Name resolution
DNS failures and domain issues
Check resolution separately for the destination domain, server domain, and encrypted DNS endpoint.
First identify which domain is failing
DNS converts domain names into addresses needed to connect. The domain that needs resolving might belong to the website you’re visiting, the proxy server itself, or the endpoint used by DNS over HTTPS. If the server domain can’t be resolved, the proxy hasn’t connected yet. If the destination domain fails to resolve, the proxy connection may already be established. Use error details to identify which domain is involved, then check the underlying network’s DNS, DNS settings in the current Config, or the remote resolution path as appropriate.
“The domain won’t load, but the IP works” is a clue, not proof of a DNS issue. HTTPS sites also rely on the correct domain and certificate name, so opening an address directly may show a different page or a certificate error. A more reliable diagnosis checks the request’s resolution error, resolution time, and response status, then compares them with the same domain on a working network. Don’t disable certificate verification to test, or permanently add a temporary IP to every access rule.
System DNS, custom DNS, and DoH: where each applies
System DNS usually follows the current network settings, which helps with local networks and sign-in pages, but results may change when you switch Wi-Fi networks. Custom DNS sends lookups to a specified service, which must be reachable on the current network. DNS over HTTPS sends lookups over HTTPS but still needs a network path to its endpoint. Enabling it doesn’t mean the remote proxy is available, and it won’t necessarily resolve internal local network names.
If a DoH endpoint’s domain depends on a proxy that isn’t connected yet, you can create a dependency loop: connecting to the proxy requires resolving the server, while DNS resolution is set to go through the proxy. During troubleshooting, first restore a path that allows initial name resolution, then test encrypted DNS one setting at a time. Don’t replace a server address with an IP found online. The endpoint address, certificate name, and SNI must still meet the server’s requirements, or a resolution error may turn into a handshake error.
Check how rules interact with DNS
DOMAIN and DOMAIN-SUFFIX match domain information from a request; IP-CIDR, IP-CIDR6, and GEOIP match address-related conditions. Rules that require an address may involve DNS resolution, so changing rule order can affect results. The snippet below is an example only. Its address ranges are for documentation and don’t represent a real service. Interpret it in the context of the current Config’s policies and actual rule matches; it isn’t a complete DNS configuration to copy as-is.
[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXYno-resolve on a related IP rule means not to actively resolve a domain for that rule. It does not disable all DNS. To route by domain, prefer clearly scoped domain rules, then check whether address rules are still needed. Don’t send every domain to a broad keyword rule to work around one resolution failure; it can match unrelated requests and route them incorrectly.
Check caching, IPv6, and local network names
After a DNS change, apps, the system, or the client may still retain old results and existing connections. Disconnect the affected connection, make a new request, and check fresh logs rather than just refreshing a page on an existing connection. If a domain returns both IPv4 and IPv6 addresses, an unreachable path for either family may cause intermittent failures. Check which address family the failing request used before changing settings for the current network. Don’t treat disabling IPv6 as a universal optimization for every device.
Printers, router admin pages, and workplace domains may rely on local DNS. Public DNS isn’t guaranteed to resolve these names. If local network access fails, check whether proxy settings changed the local subnet or resolution path. Restore one DNS setting at a time, and confirm that both regular domains and internal names work before ending the test. For more detail, see Shadowrocket DNS settings. Evaluate DNS choices separately from troubleshooting the issue.
07 · Background activity and resources
Unexpected battery drain and background activity
Compare real activity under similar conditions, and look first for repeated reconnects or heavy data transfers.
Understand the system’s battery statistics
The system’s Battery page shows usage as a proportion of activity during the selected time period, not an app’s fixed power consumption. When other apps are used less, a background network component may account for a larger share even if its absolute power use hasn’t increased. Compare under similar conditions for screen use, signal, charging, and network activity, and note whether the device gets warm. Don’t assume one percentage proves an update caused the drain, and don’t draw conclusions immediately after a system migration or photo sync.
While the proxy is running, it handles network traffic from other apps. The system may attribute that activity differently than you expect. Check for ongoing cloud backups, video playback, app updates, or hotspot sharing, then review Data and connection records in the client. System statistics and client records may cover different time periods, so subtracting their totals won’t reliably identify unusual traffic. To compare them, start at a clearly defined time and use the same observation window.
Rule out repeated failures and automatic reconnects
When a remote server can’t be reached, repeated handshakes, lookups, and reconnects can use extra resources. If the same error appears repeatedly in the logs, fix the server, DNS, or authentication issue rather than looking for a “battery-saving protocol” to hide the failure. Weak signal can also increase wireless activity. Compare using the same configuration on stable Wi-Fi. If only one server repeatedly reconnects, save the error details and test another working server you already have.
Check whether On Demand conditions repeatedly conflict with the current network. Switching between access points or a changing authentication state can trigger frequent connection starts and stops. Note the original conditions, pause automatic triggers during testing, and observe a manual connection for a while. Restore conditions one at a time to identify what causes the repeated activity. Don’t force-close the app repeatedly before confirming what triggers the automatic behavior; that won’t explain the cause and may restart the entire connection process next time.
Keep diagnostic features separate from everyday settings
Detailed logs, extensive connection records, and frequent tests enabled for troubleshooting shouldn’t be left on without a reason. They may increase processing and storage activity, especially when request volume is high. When you’re done, restore a logging level appropriate for everyday use, turn off temporary scheduled tests, and keep only the necessary redacted results. Don’t claim to have fixed battery drain by disabling everything. Record which feature you disabled and whether the difference can be reproduced.
Frequent subscription refreshes can also generate extra network requests, but whether to adjust them depends on how often they run. Check whether the app updates on every launch or repeatedly retries after failures, then reduce unnecessary activity if it suits your needs. Scheduled remote Config updates and subscription refreshes are separate processes and should be checked separately. If a configuration includes scripts or processing you don’t understand, back it up and compare with a simple configuration before deciding whether to keep it. Don’t leave unknown processing running in the background without review.
Set up a comparable observation window
Compare your current configuration with a simpler one on similar networks and with similar everyday tasks. Keep screen brightness, hotspot status, and downloads consistent; don’t compare idle battery use with video playback. Start with a short test to confirm there are no repeated errors, then extend it to a representative period of everyday use. If the device gets noticeably warm or battery drain coincides with underlying network issues, check other system background activity too. Don’t focus only on Shadowrocket.
After restoring settings, check network switching, waking the device after locking the screen, and whether On Demand behaves as expected. Stable foreground tests don’t confirm that background behavior is working. If you need to report an issue, include the battery statistics time range, network, ongoing traffic, and repeated error types. Hide subscription and server credentials. If the device still overheats or drains its battery when the client is off, check system and hardware status rather than attributing an unrelated issue to the proxy connection.
08 · Changes and recovery
Issues after updating and restoring settings
List all changes that happened around the same time, then test the app, system, subscription, and Config separately.
Timing alone doesn’t prove cause and effect
A failed first connection after an app update may coincide with an OS upgrade, an expired subscription, changed server settings, or a remote Config update. List recent changes and note the environment from your last successful connection before the update. Don’t delete configurations just because the problem started “right after an update”; a server-side change around the same time can cause the same symptoms. Retest the current configuration on another network, then try a simple configuration to help distinguish an app startup problem from a remote connection problem.
First verify that the active Config and SERVER are as expected. Check whether Global Routing changed and whether On Demand was triggered again. If the app opens but can’t access the internet, follow the request-routing checks above. If the app won’t open, the system extension reports an error, or the app keeps crashing, save any available diagnostic information before attempting system-level recovery. Don’t reinstall repeatedly before recording the error; you could lose useful details and manually entered settings.
Back up more than the subscription URL
A subscription can retrieve server entries again, but it may not include manually added servers, policy selections, rule changes, or other personal settings. Check what’s included before backing up, and keep original materials you’re entitled to retain along with a copy of Config. Backups may contain passwords, identity fields, or subscription credentials, so store them securely and don’t upload them publicly. A screenshot showing only server names usually isn’t enough to restore all settings.
To restore, import just one basic server or subscription first and test the connection. Restore Config and other settings afterward. Restoring a full backup at once may reintroduce the setting that caused the problem. If the issue returns immediately after restoring one setting, keep that difference and investigate it before importing anything else. For remote configuration changes you can’t identify, check with whoever provided the configuration rather than deleting fields you don’t understand.
Update safely on each platform
For iPhone / iPad, verify the app on the App Store product page. The developer is Shadow Launch Technology Limited, and the app ID is 932747118. Check the App Store listing for system requirements. Get Shadowrocket installers for Mac, Windows, Android, and Linux from the all-platform downloads page on this site. The actual installers are hosted under this site’s /dl/shadowrocket/ path. Don’t follow update prompts from unknown sources.
If the system blocks an installation, first confirm the file came from this site and matches your device architecture. On Mac, check About This Mac to identify Apple Silicon or Intel. If macOS says the developer can’t be verified, check Privacy & Security in system settings for the “Open Anyway” option. On Windows, after confirming the source, select More info and then Run anyway in SmartScreen. On Android, allow installs from the current source when prompted by the system, then revoke that permission when you’re done. Managed devices must still follow administrator policies.
On Linux, choose the deb, rpm, or AppImage package that matches your system. AppImage files need execute permission before they can run. If Mac says the app is damaged, confirm the source and move the app into Applications, then follow the download page’s instructions to use the command below to remove the quarantine attribute. This applies only to the specified app; don’t apply it to an entire directory. See installation guidance for platform-specific details. There’s no need to disable your system’s overall security protections to update.
xattr -cr /Applications/Shadowrocket.appAfter recovery, retest the original failure scenario
After updating or restoring, check more than whether the app opens: verify connections, subscription refreshes, rule matches, and network switching. The iPhone / iPad version costs $2.99 as a one-time App Store purchase; the Mac, Windows, Android, and Linux versions are free. App purchase costs and any existing service plan are separate. Restoring the app doesn’t restore account permissions from your provider. If the issue still reproduces with a minimal configuration, keep the system environment, exact error message, and steps to reproduce, then submit redacted details through the support option provided in the app.
09 · Tablets and network switching
iPad-specific checks and cross-device testing
Check iPad purchase history, configuration data, and network conditions separately.
Installing the app doesn’t automatically add your configuration
If you’re using the same purchase on iPhone and iPad, check your purchased items while signed in to the correct App Store account. Purchase history and configuration data are separate, though. A subscription on another device doesn’t mean this iPad automatically has the same server settings and Config. When setting up an iPad for the first time, follow the quick-start guide to check importing, Global Routing, and connection authorization. An empty list doesn’t mean the app is broken or the purchase failed.
The iPhone / iPad version costs $2.99 as a one-time App Store purchase; the Mac (Apple Silicon and Intel), Windows, Android, and Linux versions are free. A one-time app purchase is separate from a service plan. Check with your provider about limits on accounts, devices, or simultaneous connections. If your phone works but your iPad doesn’t, first check whether simultaneous connections are allowed. Don’t purchase the app again or mistake an account permission issue for an iPad-specific network problem.
Check what “the same network” actually means
Your phone may be using cellular data while your iPad is on Wi-Fi. They may appear to access the internet at the same time but use different routes. For a cross-device test, note each device’s network, selected SERVER, and Config, and use the same test target where possible. Differences are meaningful only when those conditions are similar. If the iPad is using your phone’s hotspot, traffic also passes through hotspot sharing and the phone’s network connection; it isn’t the same path as an app running directly on the phone.
On campus, hotel, or office Wi-Fi, your iPad may need to authenticate separately. Disconnect the proxy and open a regular page to confirm you’re signed in before reconnecting. If you can access local devices but not the internet, check whether sign-in is still required. If external sites work but a printer or shared device doesn’t, check local network routing and name resolution. Don’t permanently route all requests through Direct to fix access to one printer; keep local rules narrowly scoped.
Assessing lock screen, multitasking, and foreground transitions
No new traffic while the screen is locked doesn’t necessarily mean the tunnel disconnected. When you wake the screen, check the system VPN status first, then make a new request to distinguish a maintained connection from an automatic reconnect or slow app recovery. Split View and Stage Manager change how foreground apps are arranged; Shadowrocket not being the active window doesn’t prove the proxy stopped. If access fails only after waking, note whether Wi-Fi changed, whether On Demand was triggered, and what step restores access.
For Wi-Fi + Cellular iPads, check the relevant app’s cellular data permission and whether your current data plan is active. For Wi-Fi-only models, focus on the wireless network and hotspot path. System version, device management policies, and power-saving settings can also make two devices behave differently. Don’t copy every system setting from another device. Identify differences related to the symptom and change one setting at a time. Check the App Store listing for system requirements rather than inferring support from screen size.
Turn cross-device comparisons into actionable findings
| Comparison result | Check first | Next step |
|---|---|---|
| Only the iPad fails | Local authorization, Config, date and time, and device restrictions. | Retest with a minimal configuration. |
| Both devices fail on the same Wi-Fi only | Authentication, router, and current network path. | Try a different network while keeping the server unchanged. |
| The same server fails across devices and networks | Server status and whether its settings are valid. | Check with your provider. |
If only some apps stop working after transferring a configuration, check for missing custom policies, manual rules, or DNS settings. A QR code or single-server share usually doesn’t represent an entire Config, and a successful import doesn’t mean the rules were transferred. Check the active content on both devices before comparing results. Screenshots with credentials hidden can help identify screens, but they can’t replace checking configuration differences. Don’t share a full exported file just to make comparison easier if it contains sensitive data.
Before you finish troubleshooting, restore any temporarily disabled automatic connection conditions, remove test rules you no longer need, and keep one verified configuration with a brief record. Note the conditions that caused the issue, what worked, and what remains unresolved instead of writing only “restarting fixed it.” For more help, return to the first two sections of this guide for connection issues or the subscription section for update problems. For common usage questions, see frequently asked questions for new users. This gives you evidence to work from if the same symptoms return, rather than having to try every switch again.