Shadowrocket
Troubleshooting Guide

01 / Establishing a connection

Unable to turn on the connection

First determine whether the issue occurs before the system connection is established or immediately after it comes up. The first case often means system authorization is incomplete, the configuration was not saved or the device is restricted by management settings. The second calls for checking the error message and connection logs. Not every connection toggle issue is a server failure: an unreachable remote server may affect requests without preventing the local connection from starting. The behavior immediately after tapping the toggle is more useful than repeatedly tapping it.

Complete system authorization first

The first time you enable the connection on an iPhone or iPad, iOS asks for permission to add a VPN configuration. Confirm that the prompt corresponds to the action you just took, then follow the system instructions and authenticate on the device. If you dismissed the prompt, return to Shadowrocket and try again. Then check the VPN section in system settings to see whether the configuration was added. Settings paths can vary by OS version, so search Settings for VPN rather than relying on a particular menu path.

On a device managed by a school or organization, management policies may prevent adding network configurations. Check the device management guidance and ask the administrator whether the feature is allowed instead of repeatedly deleting configurations. System restrictions, parental controls and organization policies are not server parameter issues. If the device has other network connections configured, disconnect the one currently in use before starting Shadowrocket so the two connection states are not confused.

Check local configuration and conflicts

Return to Home and confirm that a selectable server is available, with all required settings entered—not just a label. Then open Config and make sure the active file exists and has not been edited recently. Invalid configuration syntax, references to missing policy names or an incomplete import can all trigger startup errors. Restore a pre-change copy if possible. If no backup is available, keep the original file and test with a smaller configuration rather than deleting everything.

If the toggle turns on briefly and then switches off, read the exact error before deciding whether the cause is a configuration load failure, a system service startup failure or an external connection condition. Temporarily disable On Demand and test a manual connection to rule out automatic triggers. Restore the original conditions after testing. Avoid enabling automatic connection while removing the system configuration; it may be recreated and make it appear that the removal did not work.

Rebuilding the system connection configuration should come after making a backup. Disconnect first and confirm you have recoverable copies of your subscription, manual servers and Config. Then remove only the old connection configuration you can positively identify as belonging to Shadowrocket in system settings. Reopen the app, authorize it when prompted and test. Do not remove organization-managed settings or reset all network settings as a first step; a network reset may also erase saved network information.

Startup checks for desktop and Android

If the app itself will not open, follow the installation and security approval instructions rather than troubleshooting the connection. On Mac, make sure the installer matches your Apple Silicon or Intel processor. If macOS says the developer cannot be verified, check the source in Privacy & Security, then choose Open Anyway. If Windows SmartScreen appears, verify that the download came from this site, select More info, then Run anyway. Do not disable system-wide protection.

During Android installation, follow the system prompt to allow the current download app to install unknown apps; you can revoke the permission afterward. This is separate from VPN authorization when connecting. If the app has not started on Linux, check the package format, execute permissions and desktop environment error messages. Installers for all platforms are available from this site's download page at /dl/shadowrocket/. Do not replace the app with an untrusted file.

02 / Request routing

No internet after connecting

Start with a baseline test while disconnected. Turn off Shadowrocket and use a browser to open a website that normally works without it. If that still fails, troubleshoot Wi-Fi sign-in, mobile data access or the router first. Public networks may require completing a sign-in page before other requests can work. Compare Config, Proxy and Direct only after the underlying network is available; otherwise, a basic connectivity failure may look like a rules problem.

Narrow it down with three modes

Keep the same network, device, server and destination while comparing the three Global Routing modes. Send the request again after each change; fully quit and reopen the target app if needed to avoid reusing an existing connection. These tests help locate differences, not identify one mode as a permanent fix for every situation. If the destination is not directly reachable, a Direct failure alone does not prove that the underlying network is broken.

If Proxy works but Config does not, check which Rule matches the destination before changing the server. A broad DIRECT or REJECT rule earlier in the list may override a more specific rule below it. Rules are generally matched from top to bottom, so place specific exceptions before broader rules. Before editing, confirm which Config is active so you do not change an inactive file and mistake that for a rule change having no effect.

Check policies and rule order

This rule snippet illustrates match order; it is not a complete configuration file and does not create a server. The example domains are for explaining syntax only. Adapt them to your actual destinations and existing configuration. Do not overwrite the whole file just to test, especially if it contains policy groups or other required settings. The active configuration determines which policy is used, so make sure that policy exists and points to a working server.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP checks an address's geographic location, and FINAL handles requests that do not match earlier rules. Each operates on a different kind of input, so a rule name alone cannot tell you whether a request matched. A target app may connect to separate domains for sign-in, resources and content delivery; a rule for its homepage may not cover sign-in or image requests. Identify the destination of the failed request before deciding how broadly to extend a rule.

If every mode fails but access works when disconnected, check DNS used by the connection, conflicts with system networking and general settings in Config. Restore the most recent working copy first, then stop other services that are also routing network traffic and retest. Do not change DNS, routing and server settings all at once; even if service returns, you will not know why. For a separate check of domain resolution, see DNS issues.

Separate system-wide and app-specific issues

If a browser works but one app fails, inspect that app's sign-in, media or real-time traffic separately. First check whether the app is allowed to use the current network, then quit it fully and reopen it. If only sign-in fails, check the device time, system certificate errors and account status. If only local network devices are unreachable, check whether a rule is incorrectly routing local addresses through a remote server. Do not switch the entire configuration to Direct just to mask the problem.

To verify a fix, repeat at least the action that originally failed rather than relying on the connection icon. Opening a webpage does not prove that images, sign-in or file transfers work; a single success may also be served from cache. Record the configuration change that worked and undo temporary changes unrelated to the problem. For more on rule types, see DOMAIN-SUFFIX, GEOIP and FINAL explained.

03 / Remote connection

Server connection timeout

A timeout means a test did not finish within its allotted time; it does not identify which layer failed. DNS lookup, connecting to the server port, the protocol handshake and reaching the test destination can all take time. Note whether the error appears in Connectivity Test or during an actual app request, then compare the same server across different networks. Reimporting the entire subscription just because you saw a timeout often destroys useful comparison conditions.

Check the address and protocol fields first

Open the server's edit details and compare each field with the original settings from your existing service. The server address should not include a webpage path, spaces or an extra protocol prefix, and the port must match the server configuration. QR codes and share links may contain additional fields that are easy to miss when copying manually. A label is only a local name; two entries with the same label may point to different addresses. Compare the actual settings, not just the displayed name.

The protocol must match the server; do not switch protocols at random to make a test pass. Shadowsocks encryption methods and passwords, VMess or VLESS identity fields, and Trojan passwords and TLS requirements all serve different purposes. WireGuard also requires correct keys, addresses and peer settings, while Hysteria2 requires the right authentication and transport settings. Ask the administrator of your existing service to confirm missing fields rather than piecing together settings from unrelated entries.

Cross-test on different networks

Keep the server settings unchanged and test on available Wi-Fi and mobile networks. If only one network fails, first check its sign-in status, port accessibility and transport conditions instead of assuming the account is invalid. If other existing servers work on the same network, the issue is more likely limited to one remote service. If all servers fail, return to the basic network, system authorization and DNS checks.

Connectivity Test results apply only to the selected test method and destination. A successful port connection does not guarantee protocol authentication, and a successful test webpage does not guarantee access to another site. If the test fails but the app works, the test destination may be unreachable or the method may not suit the service. Verify with a specific real request first; do not keep changing existing server settings just to improve a test result in the list.

The server name and connection address can differ, but both must match the original configuration. When connecting by IP, TLS may still require the correct server name; replacing a domain with an IP can cause a certificate mismatch. An incorrect device date or time can also affect certificate validation. For certificate errors, correct the time and verify the name rather than routinely disabling verification.

Decide who should take the next step

If the same entry keeps failing on multiple available networks while other existing entries work, ask the administrator of your existing service to check the address, port, authentication status and server availability. Share the redacted error and reproduction steps, not a full share link or subscription URL. If the remote service recently changed its settings, update that entry and make sure the new entry is actually selected; an old entry may still be in use.

If webpages load but large downloads or a particular app keep getting interrupted, do not classify the issue as a simple server timeout. Transport routing, UDP support or packet fragmentation may also be involved. Compare the same operation on a stable network. Base advanced network settings on the server's requirements, back up first and change one setting at a time. Without clear evidence, changing transport and several low-level settings together can introduce new incompatibilities.

04 / Subscription updates

Subscribe update failed

Break a subscription failure into three checks: can the URL be fetched, can its contents be parsed, and is the imported result being used correctly? Each requires a different fix. When the update button reports an error, keep existing working entries and do not delete the subscription immediately. A working server proves only that the connection still works; it does not prove that the subscription endpoint is reachable. Conversely, a successful update does not guarantee that every server in it can connect now.

Check the URL and access conditions

Copy the full subscription URL again from the management page for your existing service. Make sure you have not copied a page title, explanatory text or a truncated link. Query parameters may contain access credentials, and omitting one can make the link fail. Check for leading or trailing spaces and line breaks, and do not remove parameters just to shorten the URL. Subscription URLs are sensitive connection information; do not post them in public comments or screenshots.

Compare the network path used for the update. If updating works while disconnected but fails while connected, the current request route or DNS may not be suitable for the subscription endpoint. If the reverse is true, try updating through an existing working connection. Change only the connection state and keep the same subscription URL to isolate the route as the difference. Repeatedly tapping Update will not fix an incorrect URL and may trigger rate limits.

For authentication, permission or rate-limit errors, check the link status and access restrictions on the page for your existing service. Being able to open a webpage does not mean you have permission to access the subscription endpoint; management pages and subscription URLs may use different authentication. A browser check can help confirm that a response is available, but do not forward the returned page to others. If the page asks you to sign in, pasting its URL into Subscribe is not a substitute for the actual subscription URL.

Separate a successful fetch from a successful parse

If content arrives but import still fails, check whether it is subscription data supported by the app rather than a sign-in page, error message or full configuration file. Some endpoints return a displayable webpage even when a link is no longer valid, so seeing text in a browser does not prove the format is correct. Use the exact error to distinguish a format problem, an empty result or missing fields, then describe it to the administrator of your existing service. Do not guess at the encoding.

The server list managed by Subscribe and the rules configuration managed by Config are different kinds of data. Importing a full rules file as a server subscription, or enabling server share details as a configuration file, can cause parsing errors. Identify what the data is for before choosing an import option. After importing, check that entries appear in the expected group, the count is reasonable and manually added records are still present.

1. Keep the old subscription and currently working servers; note the exact update error.
2. Copy the full URL again and try once on the same network to see whether the error repeats.
3. Choose the next step based on whether the failure occurred during fetching, authentication or parsing.
4. After a successful update, check the group and actual settings, select the server you want to use and test a request.

Handle changes to the list after an update

If duplicate labels appear after an update, check the source subscription and actual address before deleting anything. Different subscriptions may use the same naming scheme, and a manual entry may share a label with a subscribed entry. Before cleanup, confirm which source the selected entry belongs to and whether policies in Config still reference a valid item. If a server was removed on the remote end, the old selection may no longer work; explicitly select an available entry again.

If an update succeeds but you are still using old settings, first confirm that you updated the right subscription, then check whether another manually added copy is selected. Reimporting the same URL repeatedly makes it harder to identify duplicate sources. Instead, keep source labels identifiable, update one subscription at a time and compare changed addresses or fields. Delete entries only after confirming that the new ones work.

Subscription availability and server usage depend on services you already have; the client does not provide them. A one-time client purchase is not a service subscription. This site does not provide, sell or recommend servers or subscriptions; it explains how to import existing details and troubleshoot them. For the correct import sequence, return to the Getting Started guide. For short questions about concepts and usage, see Frequently Asked Questions.

05 / Performance checks

Slow connection

Describe “slow” as something you can reproduce: a long wait for a webpage to open the first time, images loading one by one, slow file transfers or intermittent video pauses. These symptoms involve different stages. If the first load is slow but later loads are normal, check DNS resolution and connection setup first. If transfers remain slow, compare the underlying network, remote server and destination service. A single Connectivity Test does not represent every usage scenario.

Make a fair comparison

Compare on the same device, in the same place and at a similar time, using the same destination. First pause other high-traffic tasks, system updates and cloud sync so their bandwidth use is not mistaken for the request being tested. Record performance while disconnected, then compare your existing servers. Keep the target file, app operation and network type the same; otherwise, different content delivery servers or cache states may explain the results.

A strong Wi-Fi signal does not guarantee a stable connection. Distance, interference, router load and upstream traffic can all affect performance. Retest near the router, then compare once on mobile data. If the same server improves significantly on another network, check the local network first. Keep an eye on mobile data usage; you do not need to repeatedly download large files when a smaller action can reproduce the issue.

Use the same method when comparing multiple existing servers. A fast connection setup does not guarantee better sustained throughput, and a quick response from one destination says nothing about every other destination. Choose two existing entries with known settings that connect successfully and perform the same operation on each. If all entries are slow only for one destination while other requests work, focus on that destination service and its request path.

Determine whether the issue is with rules or transport

Compare Config with Proxy to see whether the slowdown occurs only when rules are applied. If Proxy is normal but Config is slow, check whether the destination is incorrectly going Direct, whether a different policy is being used than expected, and whether related resource domains take another route. A page may request content from several domains. If the main page loads but images are slow, locate the delayed resources before concluding that the entire server is slow.

If every request is slow to open initially but works normally afterward, use connection logs to see whether time is spent on resolution, the handshake or waiting for the destination. Do not change DNS and server settings at the same time to improve speed. Keep the server fixed and compare resolution settings first, then restore them before testing another change. A setting that helps one destination may not work for the whole configuration. Keep comparison results and avoid accumulating undocumented “optimization” settings.

Real-time communication, some games and other UDP-using apps may have different requirements from ordinary webpages. A page loading successfully does not prove that those transports work. Confirm that your existing service supports the relevant transport, then check the server entry and related Config settings. A protocol name does not guarantee speed, and low-level settings such as MTU should not be changed without a specific symptom and repeatable test.

Recover with minimal changes

If the server specifies particular transport settings, compare them with the current entry rather than copying settings from an unrelated service. For noticeable TLS or other handshake delays, first check the device time, server name and network stability. Disabling certificate checks is not a performance fix. If the target app remains slow after a network change, quit and reopen it to rule out an existing connection still using the previous route.

If long transfers pause periodically, check whether the device enters power-saving mode, background activity is restricted or the wireless network changes. On a computer using a system proxy, confirm that the target app actually follows that route; the client being active is not enough. State the result precisely—for example, “works on this network, for this destination, in this mode”—rather than claiming a setting is faster on every device.

06 / Domain resolution

DNS issues

DNS troubleshooting is about confirming whether a domain resolves to a usable address and whether requests use the expected resolution path. A domain failing to load does not necessarily mean DNS is the problem; connection, TLS and rules can also cause failures. First determine whether the error occurs during resolution or connection, then compare system network behavior with behavior while connected. Switching to a familiar DNS address alone does not identify the cause and may break local network names that currently work.

Distinguish the server domain from the destination domain

At least two kinds of domains may need resolving: the proxy server's own domain and the destination domain requested by a browser or app. If the server domain fails, no proxy requests may connect. If a destination domain fails, only some sites may be affected. Identify which name appears in the error before changing the server address. When checking spelling, use the full domain and do not mistake a path in a subscription URL for a server name.

On a working underlying network, first check whether the server domain resolves, then check the destination domain from within the connection. A server address entered as an IP may still require TLS name validation, so replacing a domain with an IP is not a general workaround. Opening a site by IP is not a universal test either: many sites rely on the correct host name and certificate, so an IP request can fail normally without indicating that the network is unreachable.

This General snippet shows how to use system DNS as a baseline; it is not a complete configuration or a fit for every network. Before editing, check whether the current file already defines the same setting to avoid conflicting entries. Keep a backup, change only the setting you want to compare and recreate the request. If your network requires a specific resolution method, follow the instructions for that network and your existing service.

[General]
bypass-system = true
dns-server = system

Check resolution alongside your rules

Rules that match domains and rules that match addresses rely on different conditions. DOMAIN, DOMAIN-SUFFIX and DOMAIN-KEYWORD inspect names; IP-CIDR, IP-CIDR6 and GEOIP inspect addresses. Do not assume every failure is caused by rule order, or that DNS is irrelevant just because a domain rule exists. Check the actual request log for the destination, matched rule and selected policy before deciding which layer to investigate.

If only internal names or local devices fail on a particular Wi-Fi network, first check whether that network relies on its own DNS. Routing all resolution externally may make local names unavailable. For printers, storage devices and other local resources, also check the address range, network isolation and relevant DIRECT rules. If a device is visible but its service cannot be reached, the port or device permissions may be the issue; changing DNS again may not help.

If IPv4 and IPv6 behave differently, DNS may return an address while the route to that address is unreachable. First check whether the issue occurs only on a particular network, destination or address type. Do not disable an entire address family globally without evidence. Network changes, router settings and remote services can all affect the result. Keep the system defaults as a baseline and make limited changes only for a clearly identified failure.

Handle caching and retest carefully

After a change, the browser, target app, system or remote service may still be using an old result. End the existing request, close and reopen the target app, and if needed disconnect and reconnect before checking new logs. Refreshing a page once may reuse an existing connection and tell you nothing about whether the new DNS setting took effect. Repeatedly restarting the device is no substitute for diagnosis: it may clear state temporarily without identifying the setting that caused the issue.

If a domain fails on only one device, compare its clock, system network settings and active Config before changing the router for everyone. If multiple devices on the same network fail in the same way, check the network's DNS conditions first. Record the network type, destination name, failure stage and routing mode, but do not expose full subscription or authentication details. Redact internal names as needed.

07 / Background activity

Battery drain and background issues

First distinguish an app's share of battery use from the device's actual power consumption. An app's percentage may rise simply because other apps were used less; it does not necessarily mean the app suddenly consumes more power. Compare under similar screen brightness, signal strength, usage time and network conditions, and account for device temperature, background tasks and system updates. When the connection carries requests from other apps, their activity may also appear in usage statistics. One percentage alone does not prove a client issue.

Look for repeated reconnects and background requests

Repeatedly rebuilding a session on an unstable connection can increase wireless and processing activity. Check for frequent disconnects, network changes or authentication failures, then compare on a stable network. If the same server keeps reconnecting on a fixed network, troubleshoot the remote connection first. Reducing test frequency can limit extra activity but will not fix the cause. Note separately if the device is in a weak-signal area.

On Demand can establish a connection automatically when its conditions are met, so a connection that returns after you manually turn it off does not necessarily mean the toggle is broken. Check for conditions tied to the current network and overlapping automatic rules. Record the original settings, temporarily disable automatic connection and compare with a manual start. Once you understand the behavior, restore only the conditions you need; do not treat every automatic reconnect as a fault while asking the app to stay connected automatically.

Check whether an app is continuously uploading photos, syncing files, refreshing messages or downloading offline content. Background requests from other apps can keep the connection active even when no browser is open. Pause those tasks temporarily and observe idle behavior on the same network, then restore them one at a time. Do not disable a large number of system features at once and declare the problem fixed; you will not know which one mattered and may disrupt notifications or sync.

Reduce interference from troubleshooting tools

Connectivity Test, repeated refreshes and verbose logs create additional requests and writes. When troubleshooting is complete, stop tests you no longer need and restore the normal logging level using the options available in the app. If logs are needed, capture only the reproduction window and note when it starts and ends. Long-running logs are harder to review and may contain destination and connection details that should not be shared publicly.

When assessing battery use, choose an observation period that covers similar activity instead of comparing an instant reading just after connecting. Charging, device heat and system background tasks can skew results. First compare normal usage, then idle behavior. If battery use rises only during high-volume transfers, consider the amount of data involved. If it stays unusually high with almost no requests, focus on reconnects, background tasks and diagnostic activity.

Android battery management may limit background activity, causing the connection to drop after the screen locks and return when the device is unlocked. Check whether the system is restricting Shadowrocket's background activity, then adjust only the relevant setting if needed. You do not need to relax restrictions for every app. Option names vary by system, so follow your device's instructions. Afterward, compare notifications, idle behavior and connection continuity—not just a webpage in the foreground.

Check temperature and sleep separately

After a computer wakes from sleep, its network may not be ready yet and the connection may briefly reconnect. Wait for the system network to come back, then retry the original request and see whether the issue is limited to wake-from-sleep. If the app must be reopened after every sleep, note the network type and error before and after sleep and check whether the network interface changed. Do not disable sleep indefinitely to mask the issue; that changes the power baseline without fixing connection recovery.

If the device is noticeably hot, stop high-load transfers and let it return to normal temperature before assessing performance. Thermal management can affect processing speed, so slow performance and battery drain may be two effects of the same workload. If the device remains hot when disconnected, check system activity and other apps rather than changing rules. Battery health, charging conditions and wireless signal can also affect results and should be considered separately from client settings.

08 / Recovering from changes

Problems after an update

A problem that appears after an update does not necessarily mean the app update is the only cause. Subscription content, Config, the OS or the network may have changed around the same time. List the changes between the last successful use and the first failure, then decide what to check first. Do not delete the app, clear subscriptions and reset network settings all at once. You will lose the original state needed for comparison and may turn a limited issue into a full reconfiguration.

Keep your data, then identify the scope

Back up the current Config, manual servers and any subscription details you need, and make sure the copies are saved locally. Backups may contain passwords, identity fields or full subscription URLs, so store them securely and do not upload them publicly. Then identify whether the app will not start, the connection drops immediately, all requests fail or only one destination fails. These point to different startup, authorization, connection and rules checks; reinstalling is not a universal fix.

If a new system authorization prompt appears the first time you open the app after an update, verify its source and complete the required authorization before testing again. An OS update may change existing permissions; a saved connection configuration does not guarantee that permissions are unchanged. If only one Config will not load, keep the exact error and try enabling the most recent working local copy. If that works, compare the configuration contents instead of changing servers.

If Subscribe and the app have both been updated recently, first check whether the selected server's actual settings changed, then confirm that policies in Config still reference valid items. Removed names, changed groups or replaced entries can look like a post-update connection failure. Test with a clearly identified entry you already have to reduce the impact of list changes, but do not delete an entire subscription source without a backup.

Check installation and security approval by platform

App updates for iPhone and iPad are handled through the App Store. Check the App Store listing for system requirements. Before reinstalling, confirm your backup and original purchase account; deleting the app may also delete local configurations, and an App Store purchase record is not a configuration backup. To verify the genuine app, check the official icon, developer Shadow Launch Technology Limited and app ID 932747118. See Authenticity verification for the steps.

Download the latest installers for Mac, Windows, Android and Linux from this site's download page; its dynamic download links point to /dl/shadowrocket/. On Mac, check About This Mac to identify Apple Silicon or Intel. On Windows, choose the installer specified on the page; on Linux, select the format for your distribution. Do not use a different architecture or an untrusted file just because an update failed; that can cause a separate startup issue.

If the app is blocked on first launch, Mac users can verify the source in Privacy & Security and choose Open Anyway. On Windows, verify the file through More info in SmartScreen, then choose Run anyway. On Android, follow the prompt to allow the current download app to install unknown apps; revoke permission afterward if appropriate. If Mac reports that the app is damaged, first verify the download and its source, then follow the installation page's instructions for that specific alert. Do not disable system-wide security settings.

xattr -cr /Applications/Shadowrocket.app

The command above is only for removing the extended file attribute from a Mac app whose source is verified and whose path matches the one shown. It is not a general fix for every startup error. Quit the app first and confirm the path matches the actual installation location. On Linux, AppImage files also need execute permission; check dependencies for deb and rpm packages using the corresponding package manager. Once installation issues are resolved, return to connection and request testing rather than mixing the two problems.

Verify recovery and prepare a useful report

After making one change, repeat the action that originally failed and compare the result with the previously working copy. If only the new configuration fails, preserve the difference for review. If all configurations fail on the same network, check system networking and permission changes. Do not assume the issue is fixed just because the main screen opens; test the connection, domain resolution and target app. Keep temporary test files separate from the active configuration so you do not select the wrong copy next time.

Include the device OS, installation source, stage where the issue occurs, exact error and shortest steps to reproduce it. If version details are needed, read them from the current app rather than guessing from an old screenshot. Redact server credentials and subscription URLs before sharing relevant logs. For Mac and Windows processor selection and first-launch steps, see Desktop installation and security approval.

09 / Device-specific checks

iPad-specific troubleshooting

Troubleshoot an iPad in the same order—network, server, configuration, then request—but account for Wi-Fi-only models, models with mobile data and app behavior during multitasking. Do not assume the iPad is at fault just because an entry with the same label works on an iPhone. The devices may use different networks, Config files or actual server settings. Align the test conditions before comparing them so environmental differences are not mistaken for an iPad issue.

Make the two devices comparable

To compare with an iPhone, connect both devices to the same working Wi-Fi, select an existing server with matching settings, confirm that they use identical Config contents and choose the same Global Routing mode. Then send the same browser request on both. Matching server labels are not enough: similarly named entries may come from different subscriptions or update batches. Config filenames alone are not enough either; check the actual rules and recent changes.

A Wi-Fi-only iPad cannot be tested on mobile data simply by turning Wi-Fi off. If possible, connect it to another known working network. A phone hotspot is a new network path, not a repeat test of the original Wi-Fi. On models with mobile data, check that data service works and that the target app is allowed to use it. Confirm the underlying network is available before starting the connection.

In Split View or other multitasking modes, the target app may keep an existing session. After changing Global Routing, end the current request and reopen the target page; quit and relaunch the app if needed. Do not assume the network is working because an old page still shows content in Split View—it may be cached. Likewise, an app that has not refreshed in the background is not necessarily disconnected; verify with a new request.

Check screen lock and network changes

If the issue occurs only after the screen locks, note whether system networking has recovered by the time you unlock, whether the client connection is still active and whether reopening the target app restores access. Some apps pause in the background; that is different from the system connection being unavailable. First verify with a new browser request, then determine whether the issue is limited to one app's session recovery. Repeatedly toggling the connection may interrupt a recovery already in progress.

School, office and public Wi-Fi networks may require periodic sign-in or authorize each device separately. An iPhone that has signed in does not mean the iPad is authorized too. Disconnect and open the sign-in page to confirm network access, then reconnect Shadowrocket. Organization-managed iPads may also restrict VPN configurations or network behavior; ask the administrator what is allowed rather than deleting management settings you cannot identify.

To access a local printer, storage device or other LAN service, confirm that the iPad and target are on a network that allows them to communicate, then check how Config handles local addresses. Local network permissions, network isolation and rule routing can all affect access. First test while disconnected, then compare Config and Direct. Do not permanently route every request directly just to restore access to one local device; a targeted change is easier to maintain.

Restore purchases and move your data

The iPhone and iPad app costs $2.99 as a one-time App Store purchase. Use the same purchase account on either device to restore the app. The Mac, Windows, Android and Linux versions are free. Keep the two pricing and download paths separate; desktop versions are not part of the mobile App Store purchase. Check the App Store product page for iPad system requirements rather than inferring them from another device.

When changing devices or reinstalling, first confirm that you are signed in with the original purchase account, then find the app in your purchased items. Restoring the app does not automatically restore every manual configuration, so save your existing subscription details and Config before migrating. If the app is restored but the list is empty, treat it as a data migration issue rather than buying it again. See Restore from purchased items for details, and follow the Getting Started guide to import your settings again.

Finish by testing the original scenarios: make a new web request after connecting, open the app that originally failed, test again after locking and unlocking the screen, and check local network services if needed. A record of which step recovered and what still triggers the issue is more useful than saying “iPad doesn't work.” For general questions, see Frequently Asked Questions. For a specific error, return to the relevant section and follow the same evidence trail instead of resetting everything.