Shadowrocket
Troubleshooting Guide

01 The connection switch won’t stay on: check system permissions first

This section covers symptoms such as the connection switch in Home turning itself off immediately, repeated requests to add a VPN configuration, or the app showing that it is connecting without reaching a stable state. Don’t start by changing rules or assume the server is at fault. Whether the switch stays on depends first on system permission to create a network extension, a valid configuration, and whether another connection task is taking over the same system channel.

Note what happens before the switch turns off

Make a note of the device model, current network, selected server, and Global Routing setting, then try connecting once. Check whether a system prompt appears, device authentication completes, how long it takes for the switch to turn off, and whether an error appears. One careful observation is more useful than repeatedly toggling the switch. Rapid repeated taps can start another attempt before the previous one has finished, obscuring the actual failure stage with a waiting state.

Disconnect, then use a browser to visit a site you can normally access directly. This confirms that Wi-Fi or cellular data is working. If the Wi-Fi network requires web-based authentication, complete that first. Seeing a Wi-Fi signal does not mean you have network access. Before authentication, subscriptions, server handshakes, and ordinary web pages may all fail, which can look like a problem with the app’s connection switch.

Check VPN permission and system status

When you connect for the first time, the prompt to add a VPN configuration is the system’s authorization process for changing network settings. Confirm that Shadowrocket initiated the request, then approve it as prompted by the system. Next, search for VPN in system settings, find the corresponding configuration, and check its status. Menu paths vary by system version; follow what appears on your device. Don’t rely only on the status icon at the top of the screen, which may not appear consistently across devices and views.

If you previously denied permission, try connecting again from the app and see whether the system prompts you again. If you manually deleted the corresponding configuration, recreate it from the app rather than entering a similarly named system configuration yourself. If the configuration is present but errors keep occurring, first save your servers and Config in the app. Then, if needed, remove only the system VPN configuration that belongs to Shadowrocket and authorize it again. Don’t delete managed configurations unless you know who they belong to.

Check permission limits on managed devices

Devices managed by a school or employer may restrict VPN configuration changes. If the system explicitly reports a management restriction, ask the device administrator to check the policy. Don’t try to bypass the restriction by repeatedly recreating the configuration.

Rule out competing connections, then run a minimal test

Check whether another VPN configuration is enabled in system settings or a network extension is providing filtering. Temporarily pause only features you recognize and are permitted to pause, then test Shadowrocket. This checks for competition over the connection; it does not mean those features are necessarily incompatible. If pausing one restores connectivity, re-enable features one at a time and retest to identify the specific combination. Don’t leave all protection settings disabled.

Next, confirm that a valid server is actually selected in Home; its presence in the list alone is not enough. Use the current settings supplied by your service provider, select a complete server entry you are entitled to use, temporarily turn off On Demand, and try connecting manually. If the switch stays on but pages won’t load, the issue is in the data path. Continue to the next chapter rather than deleting the system configuration.

If the app stops responding, quit it normally, reopen it, and repeat the same test. If it still cannot connect, restart the device. A restart can clear temporary system state, but it won’t fix an incorrect password, expired subscription, or server-side issue. After reopening, confirm that the selected item hasn’t changed and wait for each connection attempt to finish before starting another. This prevents a background task that is still running from being mistaken for a new failure.

How to confirm the issue is fixed

The test passes when the connection switch stays on, the system shows the corresponding VPN as connected, and a test request completes. If the switch still turns off, note the full error text and when it occurs, then see VPN configuration prompt explained. When reporting the issue, provide only the device and error details needed. Don’t send passwords, full subscription URLs, QR codes, or configuration files containing account credentials.

02 Connected but no internet access: separate routing from the exit path

A connection switch that stays on confirms only that the system tunnel is established; it doesn’t prove that requests have a working exit path. Break the issue into three layers: whether the device’s underlying network can reach the internet, whether the selected server can forward traffic, and whether the current Config sends requests to the expected policy. Save a copy of the current configuration and note the selected item before testing against a fixed page. Don’t change servers, DNS, and rules all at once; even if that fixes things, you won’t know why.

Use Global Routing for a brief comparison

In Global Routing, Config, Proxy, and Direct represent configuration-based routing, proxy routing, and direct connections. They help isolate issues; they aren’t interchangeable “fix” buttons. Define the purpose of each test: Direct checks the underlying network path, Proxy checks the selected proxy path, and Config checks the rules in use. Compare the same request briefly in each mode, then restore the Config you normally need.

If familiar pages also fail in Direct, disconnect and check Wi-Fi authentication, cellular data permission, and the current network. If Direct works but Proxy fails, check the server settings and reachability next. If Proxy works but Config fails, focus on the matching rule, policy name, and DNS settings in the configuration. These findings apply only to the test target; one website’s result can’t be generalized to every app.

Rules are matched in order, not by which one looks most specific

Rules are generally checked from top to bottom. Once a request matches a rule, later rules don’t choose a different policy for that same request. A broad DOMAIN-KEYWORD placed first may take effect before a later exact-domain rule. FINAL should handle requests that haven’t matched any earlier rule. Check the destination and policy in the connection log, then inspect the actual order in Config. Don’t just search to see whether a rule exists.

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

This demonstrates rule syntax and order only; it isn’t a complete configuration to replace your existing settings. PROXY must correspond to a policy supported by your current configuration and selected server. Any custom policy name must also exist. example.com is a documentation domain, not a recommendation for how to route any particular service. Before copying a snippet, understand which requests it changes. In particular, don’t replace an active Config with an unfamiliar configuration in its entirety.

Change one rule, then check one new connection

If only one domain fails, check whether the request also depends on login, static assets, or media subdomains. The main page going through the expected route doesn’t mean all its resources use the same policy. Use the connection log to find the failing destination, then make the smallest change needed for the domain you’ve confirmed. Retry the request after changing the rule. Existing long-lived connections may keep using their original route, so don’t use an old connection to judge whether the new rule is working.

For a local network device, check its address and whether it’s reachable from the current Wi-Fi network. A private-address DIRECT rule doesn’t mean a guest network allows access to other devices, or that cellular data can reach an address in your home. Verify basic local network connectivity before checking the rules. Sending all traffic through Proxy usually won’t fix local network isolation and can make the issue harder to diagnose.

Document the conditions for restoring the configuration

When you find a problematic rule, keep a record of its order before and after the change, along with one matching connection log. Restore Config, then retest the page, login, and any necessary local network access. This helps ensure that fixing one page hasn’t changed the route for other services.

If the issue persists after changing a rule, but the same target works in Proxy, check name resolution and policy references in the configuration. See the glossary for terminology, and the setup guide for the full steps to select Global Routing for the first time. Don’t keep adding rules without recording your changes; duplicate or conflicting entries make future troubleshooting harder to reproduce.

03 Server timeouts: distinguish reachability, handshake, and settings

A timeout means a step didn’t receive the expected response within the allotted time. It doesn’t prove that the server is down. The request may be stuck at name resolution, connection setup, the protocol handshake, or forwarding traffic to its destination. First determine whether one server is timing out, several servers in an existing subscription are timing out, or only one destination is affected. Defining the scope helps you decide whether to check the device network, provider details, or app configuration.

First, confirm what the test actually measures

Connectivity Test results depend on the test method, target address, and network conditions. A failed probe doesn’t necessarily mean real web traffic will fail, and a successful probe doesn’t guarantee that login, video, or sustained transfers will work. Check the test method and target, then try an actual request. Don’t keep switching servers based on a single test value in the list, or compare results from different test methods directly.

Keep the network, target, and selected server fixed during a test, and wait for it to finish. Then switch between Wi-Fi and cellular data and try again; if your iPad doesn’t have an active cellular connection, use another network you trust. If the issue occurs on only one network, check that network’s routing, port reachability, or protocol requirements instead of immediately changing the server password. If all networks fail, verify the server details.

Check the required fields for the protocol

Open Add Server or the selected server’s edit screen. Compare each field with the information from your service provider: address, port, protocol, authentication details, and transport parameters. Extra spaces around an address, the wrong port, or an incomplete identifier can all cause a timeout or handshake failure. Check each field rather than relying on a matching display name; the name is for identification and doesn’t prove the connection settings are correct.

Transport, Host, path, and server name are distinct fields and can’t be substituted for one another. When the server uses a specific transport configuration, the client must match it. Don’t change the server name at random because of a TLS error, and don’t delete unfamiliar parts of a shared link. Start by importing the original details currently provided by your service provider, then compare them with the manual entry. Keep the old entry so you can track the differences.

Handle TLS errors separately from timeouts

If the log explicitly reports a certificate, name, or time-related error, first check that the device’s date and time are correct, then confirm that the server name matches the server’s requirements. A certificate validation failure isn’t just a slow test, and disabling certificate verification isn’t a general fix. The server administrator should resolve expired or mismatched certificates. Keep validation enabled rather than hiding a configuration error by weakening verification.

If the same server used to work but now all requests fail, check your provider’s account status, server change notices, and current settings. Buying the app doesn’t guarantee that a remote service will remain available, and updating a subscription doesn’t mean the remote service has recovered. When contacting your provider, include the failure time, network type, protocol, and a redacted error message. These details are more useful for diagnosing a port, authentication, or upstream issue than simply saying “timeout.”

Use a known alternative to narrow down the issue, not to rotate blindly

Use another server as a comparison only if you already have your own known working option. If the comparison server works and the original doesn’t, focus on the original server. If all options fail, revisit system permissions, the underlying network, and DNS. If you don’t have a reliable comparison, narrow things down by switching networks and checking the failure stage. There’s no need to import entries from an unknown source or use public configurations for diagnosis.

After resolving the issue, verify three things in sequence: the connection is established, the target opens, and a short transfer completes. A successful probe shows only that one probe path worked at that moment. If the connection drops soon after it starts, note whether this happens while idle, when switching networks, or when a transfer begins. These conditions point to connection maintenance, network switching, or the data path; continue to the chapter on slow speeds and intermittent disconnects.

04 Subscription failures: check retrieval, parsing, and import separately

Updating a subscription retrieves remote content and parses it into entries; it isn’t a server connectivity test. Existing servers may still work when an update fails, and newly returned servers may be unreachable due to authentication, network, or remote service issues. First identify whether the failure occurred while retrieving content, recognizing its format, or saving entries. Then decide whether the link needs attention. Get your subscription URL from your own service provider; this site explains import and settings only.

Preserve any existing working entries

Before making changes, note the subscription name, current number of entries, selected item, and the latest error message. If existing entries still work, don’t immediately delete the entire subscription group or overwrite the old link before you start checking. You can create a comparison entry using a safely preserved copy of the original details, then confirm that the new link imports correctly before removing the old entry. Deleting a group may remove its entries and selection, making the previous working state difficult to restore.

Distinguish a single-server share link from the subscription URL required by Subscribe. A single-server link describes one server; a subscription URL generally retrieves a set of entries that can be updated. Using one in the other’s import field may result in an empty list or a parsing error. When copying, check for chat instructions, line breaks, punctuation, or a page title that got included. Don’t remove the query portion of the URL; it may carry account identification or format information.

Check whether the subscription content was actually retrieved

A URL being present doesn’t mean it currently returns the right content. The server may return an account expiry notice, login page, maintenance page, or error instead of data the app can parse. If there’s a clear status message, check your account against your provider’s instructions. Don’t treat a web page with a login form as server configuration, and don’t keep changing the protocol type to parse content that isn’t a subscription.

Retrieval can also depend on the request path: the network route used to update a subscription may differ from the route used to load a particular page. Once the underlying network is working, try a manual update and note the result. Then check whether your provider’s instructions call for using an existing working connection. Don’t leave all traffic in a different routing mode just to retrieve a subscription. Restore your usual configuration afterward and record which conditions allowed the request to succeed.

Treat subscription URLs as credentials

Full URLs, QR codes, and exported entries may contain authentication details. Don’t post them in public comments, enter them on unfamiliar parsing sites, or include them in public screenshots. When reporting an issue, share only the error type and the necessary fields with sensitive details removed.

Update succeeds, but the list is empty or incomplete

If the app reports that content was retrieved but expected entries don’t appear, check whether the provider’s format is supported by Shadowrocket and whether the account currently returns servers. Don’t guess how to convert another format based on its field names. A subscription and Config are different resources: a rules configuration may not include servers, and a server subscription may not include complete rules. Import each using the appropriate option.

If only some entries remain after an update, check for name filters, unsupported or incomplete fields, and changes to the content returned by your provider. A change in entry count alone doesn’t prove that the app lost data. Compare the original subscription details with the updated names to see whether servers were renamed or groups changed. Don’t import duplicates just to restore the previous count; duplicate entries make later selection and testing more confusing.

Automatic updates don’t replace a clear manual test

First confirm that a manual update completes reliably, then enable the automatic update option currently available in the app. Check the in-app settings for when an automatic update is triggered; it doesn’t mean the device will keep refreshing in every background state. If an automatic update doesn’t happen, note when you opened the app, the network at the time, and the result of a manual update. Don’t jump to the conclusion that the system blocks all subscription access.

After a successful update, check the selected server again. If an entry’s name or identity changed, the previous selection may no longer apply. References to groups or policies in Config must still match as well. Verify with an actual request rather than relying on the update notice. For more details, see how to update subscriptions manually and automatically and server link formats explained.

If the new subscription keeps failing while old entries still work, keep the old entries for now and ask your provider whether the URL was reset, the account is active, and the format changed. Resetting the URL repeatedly can stop other configured devices from updating too, so don’t make that your first step. After resolving the issue, check whether your other devices need the same change and remove unused copies of old URLs to avoid confusion.

05 Slow speeds and intermittent disconnects: make a repeatable comparison

Describe slow performance as an observable symptom first: a long wait on the first page load, a low transfer rate after a download starts, video buffering, or needing to reconnect after being idle. These can occur at different stages. A probe time in the connection list isn’t sustained bandwidth and doesn’t represent how quickly a particular website responds. Keep the target, network, and server fixed before drawing conclusions; don’t compare experiences from different times or with different content.

Distinguish delays in resolution, handshakes, and data transfer

If the first visit is slow but the same page loads faster afterward, check name resolution, connection setup, and caching. If a transfer starts quickly but a large file remains slow, focus on network quality, remote server load, and limits on the destination service. If only one app is slow, check its domains, whether background downloads are enabled, and whether its requests use the expected policy. A video buffering issue doesn’t mean every network request is affected by the same cause.

For a comparison, choose content you’re allowed to access and can test repeatedly. Keep file size and steps similar, and pause large sync tasks on the device. Before testing, confirm that Wi-Fi and cellular signal conditions haven’t changed significantly. Don’t run repeated speed tests; they use bandwidth, add server load, and consume battery, changing the conditions you’re trying to measure. A few repeatable tests with clear results are more useful than a large collection of screenshots.

Compare networks and servers, but change only one at a time

Keep the server fixed and switch networks first. If the same server works noticeably better on another network, check the original network for Wi-Fi interference, upstream congestion, or transport restrictions. Then keep the network fixed and select a known working alternative from your own existing entries. If that alternative works, the issue is more likely with the original server or its exit path. Re-establish the connection after each switch and test the same target so an old connection doesn’t affect the results.

On Wi-Fi, distance from the access point, interference on the same frequency, or other devices transferring data can all cause instability. Move to a more stable location and check that direct network access works normally before testing the proxy path. If the issue occurs only on cellular data, check the app’s cellular data permission and the current signal. Don’t assume that differences between mobile networks prove the app is misconfigured; keep the comparison conditions for the relevant service provider to assess.

For intermittent disconnects, record what triggers them

Disconnects after idle time, after locking the screen, and after switching networks are different symptoms. An idle disconnect may involve connection maintenance or a server-side timeout. After a network switch, the old connection may not have been re-established. Behavior after locking the screen also depends on how the app handles background tasks. Note whether all apps fail or only one long-lived connection. If a new page loads but an existing session stalls, first let the affected service reconnect; you don’t need to reset the entire configuration right away.

For services that depend on UDP, ordinary web access doesn’t prove that their network path is working. If only certain calls, real-time transfers, or protocols fail, check whether the server supports that traffic, whether the protocol settings are complete, and whether the current network allows the required transport. Don’t change MTU blindly or apply a fixed value found online. These settings depend on the actual path and server requirements. Record the original value before changing it, then verify with the same service.

A speed test reflects its testing conditions

The target, time, network, and server all affect the result. A low probe time doesn’t guarantee sustained transfers, and a slow test during peak hours doesn’t prove that the device configuration has permanently failed.

Separate destination service issues from local configuration

If only one destination is slow while similar requests work, check the destination service, account status, and how its resources load. In-app browsing and a standalone browser may use different caches, login states, and connection reuse. Don’t attribute that difference to routing without evidence. Check the connection log for failed resources, and see whether they’re waiting for a response, repeatedly retrying, or using an unexpected policy. Then make the smallest necessary change in the rules.

After making a change, verify the first page load, a short period of normal use, and behavior after one ordinary network switch—not just the fastest test. If you need to contact your provider, include the destination type, network type, time of the issue, and comparison results. Don’t send full authentication details. If slow performance also comes with heat and battery drain, check background transfers, repeated retries, and how often you’re running tests; these may be closer to the cause than simply changing servers.

06 DNS issues: check the domain, resolution path, and rules

DNS resolves domain names to addresses, but not every web failure is a DNS issue. First check whether the error explicitly occurs during resolution. Then check whether the proxy server’s domain and the destination website’s domain can each be resolved. If the proxy server’s domain can’t be resolved, the connection may fail before it’s established. If the destination domain can’t be resolved, the failure may occur after the tunnel is active. Both can look like a loss of internet access, but they require checks in different places.

Start with the failing domain, not a different DNS service

Note the exact destination and error message. Check whether one domain, a group of subdomains, or all domains are affected. If only one domain fails, check its spelling, whether the service is available, and whether you need to sign in. The home page loading doesn’t prove that all its resources resolve correctly; images, authentication, and APIs may use different domains. Connection logs can identify the actual failure and are more useful than changing all DNS settings at once.

If the server address is a domain name, check that it hasn’t expired, been mistyped, or been replaced by your provider. Don’t replace it with a fixed address from a lookup without a good reason: the server may use dynamic routing, and TLS may still require the original domain name. If you need to use an address for comparison, follow your provider’s instructions and keep related fields such as the server name. Otherwise, a temporary test could create new certificate or routing issues.

Check resolution settings together with the access path

In Config, check for custom DNS settings, imported configuration that changes how names are resolved, and whether those resolution requests need a particular exit path. If the DNS service can’t be reached, correct configuration syntax alone won’t produce a result. If there are also network resolution settings at the system level, check each as a separate variable. Don’t delete everything at once. First determine which layer is actually in effect, then check for overlap or conflict.

Some encrypted resolution methods must first reach their own server and establish a connection. If the current network can’t reach that endpoint, or reaching it depends on resolution that hasn’t happened yet, the request can get stuck waiting. Check the full design of the current configuration and its initialization path rather than adding more DNS addresses. Restoring a previously verified copy of your own configuration is usually easier to troubleshoot than combining DNS settings from different sources.

Domain rules and address rules behave differently

DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD match domain conditions; IP-CIDR, IP-CIDR6, and GEOIP make decisions based on addresses. The result of the latter may depend on whether an address has already been obtained and on the type of request the app made. Don’t assume an address rule will match based on the domain’s apparent location. Servers may return results through different regions, address families, or content delivery paths, so check the actual logs.

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

Here, no-resolve illustrates that an address rule won’t trigger a DNS lookup just to check for a match. It does not turn off DNS for the entire app. This is only a rule snippet; it doesn’t define a complete server or DNS setup. Don’t add this option to every rule as a speed fix. Changing whether resolution occurs changes the information available for matching, so use it according to the rule’s purpose and the syntax supported by the app.

Verify IPv4, IPv6, and caching separately

A network providing IPv6 doesn’t mean every server and destination has the same network path. If the issue occurs only on a particular network, check whether errors are limited to one address family and confirm what your provider currently supports. Don’t permanently disable an address family as a blanket fix. Identify the failing path first, then test according to the configuration instructions. Device discovery and local domains on a local network may also depend on resolution provided by the current Wi-Fi network.

After changing resolution settings, cached entries and existing connections may affect results for a while. Disconnect and reconnect, reopen the target app, and make a new request; if necessary, wait for the cache to expire naturally. Don’t claim that any one refresh action clears every layer of cache: browsers, the system, apps, and remote services may all cache results. When verifying the change, check a new connection rather than repeatedly refreshing a request that’s still in progress.

If a printer, home device, or internal domain can’t be reached, first test direct access on the same Wi-Fi network. Confirm that the device allows local network access and that the network doesn’t isolate clients. A private-address rule can’t replace local domain resolution. Verify the server domain, an ordinary destination domain, and any local destinations you actually need. DNS troubleshooting is complete only when these real-world requirements work—not just when a test lookup returns an address.

07 Unexpected battery drain: consider traffic and On Demand

A high percentage for Shadowrocket on the system battery screen doesn’t mean the app is generating the same share of traffic on its own. When the tunnel carries requests from other apps, related processing may count toward its usage. The percentage also depends on how much power other apps used during the same reporting period. Check usage time, screen activity, and actual network activity before deciding whether the drain is unusual. Don’t turn off every connection feature based on one relative percentage.

Compare similar usage periods

Choose two periods with similar usage and note the network type, connection time, main apps, and whether there was substantial uploading or downloading. Background tasks after a system update, photo syncing, media playback, and weak signal can all affect battery use. A period on strong Wi-Fi and another on weak cellular data aren’t a fair comparison for evaluating a setting. Control the conditions first to see whether the setting made a real difference.

Also check whether the device is noticeably warm, the connection keeps dropping and reconnecting, or the logs show persistent failed requests. A misconfiguration that causes repeated retries can increase wait time, traffic, and processing. Fix the server, DNS, or rules issue first rather than simply turning off the connection. If a background task is transferring data, pause that task and observe the result; this can reveal the traffic source more clearly than changing the tunnel alone.

On Demand triggers connections; it doesn’t guarantee lower battery use

On Demand requests a connection when configured conditions are met. Its behavior depends on those rules and the system triggers. It can’t infer what you intend to do in every app, and it doesn’t guarantee lower battery use than leaving a connection on manually. Broad conditions may trigger repeated connections for ordinary background requests. Conditions that don’t match how you use the device may prevent a connection when you need one. Decide when you want to connect before choosing the conditions.

For troubleshooting, record the existing conditions, temporarily turn off On Demand, and connect manually once to observe what happens. If manual mode is stable but On Demand repeatedly connects and disconnects, check whether the conditions keep matching and unmatching as the network changes, and whether another automatic connection setting is enabled. Don’t change conditions while rapidly switching networks. After each change, let the system disconnect and reconnect, then test during normal use rather than judging only by the switch’s immediate state.

Choose a connection approach for the way you use the device

When you use the same set of services for long periods, repeatedly connecting and disconnecting may not help. For occasional use, you can disconnect after finishing or use On Demand with conditions you understand. There’s no single setup that works for every device. The connection approach should fit your needs and avoid repeated failed connection attempts that generate more network activity just to make the icon disappear.

If the connection comes back every time you turn it off manually, check On Demand and the on-demand status of the corresponding VPN in system settings. Don’t assume the switch is broken. Disable the automatic trigger you’re testing, disconnect, and see whether the connection stays off. If the device is managed, check whether the administrator requires a connection. Don’t remove management settings you don’t recognize; system policies and app settings are separate and may require different permissions to change.

Troubleshooting also uses resources

Frequent speed tests, keeping detailed logs on for a long time, and repeatedly refreshing pages that won’t load all add activity. Once you have the evidence you need, stop extra tests and restore diagnostic settings according to your needs.

Separate client-side processing from remote connection issues

If battery drain occurs alongside slow speeds, check for repeated retransmissions, frequent handshakes, or unreachable DNS endpoints. Keep the same service and briefly compare it using another known working server from your own existing entries. See whether stability and device temperature improve together. If all servers have issues on a weak-signal network, improve the underlying network conditions first instead of trying more configurations. The app can’t eliminate the power cost of a weak wireless connection.

To assess an improvement, compare actual battery use, device temperature, and task completion over similar periods—not just a lower app ranking. An app’s percentage can fall because other apps use more power. Don’t promise a fixed percentage of battery savings, and don’t sacrifice a stable connection just to minimize the app’s share. A useful change makes the connection stable, reduces failed retries, and keeps power use reasonable for your needs.

For more on choosing an approach, see background connections and On Demand. If the issue persists after turning off extra diagnostics and fixing the cause of repeated retries, keep a record of how you use the device, system battery data, and a redacted error summary before considering an update or restoring your settings. Don’t reinstall without a backup; you could lose both troubleshooting evidence and your existing servers and rules.

08 Post-update issues and iPad: preserve differences before restoring

“It started after an update” describes timing; it doesn’t prove the app update was the only cause. The system may have been updated, a subscription refreshed, the server changed, or the network environment shifted around the same time. List what happened between the last time the app worked and the first failure, then identify the simplest steps that reproduce it. Keep a copy of the current configuration and the error details. Reinstalling immediately removes your basis for comparison, while carrying an old issue into new settings can make it happen again.

Determine whether the change came from the app, system, or configuration

Check whether the issue affects every server, network, and destination, or just one Config. If the same server works in Proxy but fails in the updated Config, compare the rules, policy references, and resolution settings. If only entries refreshed from a subscription fail, check the returned server details first. App updates, subscription updates, and Config updates are separate operations. Record each one separately rather than calling all of them “an update.”

Get app updates and redownloads through the App Store; refer to the App Store listing for system requirements. To verify the listing, check the developer, Shadow Launch Technology Limited, the official icon, and app ID 932747118. See how to verify the App Store listing for details. A purchase record confirms the app’s acquisition, not that your configuration is correct or your remote server is currently available.

Restore settings in reversible steps; don’t erase everything first

Quit and reopen the app normally, then check that the selected server, Global Routing, and Config haven’t changed. If needed, restart the device and test again. If the issue persists, compare with a known working copy of your own configuration rather than importing a complete setup from an unknown source. Keep the original configuration and change only the active item. Once you identify a difference, migrate the rules you need one at a time and confirm that the policy names and server references still exist.

Reauthorize the system configuration using the steps in the first chapter only if you have good reason to suspect that the system VPN configuration is damaged. Reauthorization fixes the system configuration layer; it won’t restore a deleted subscription, password, or custom rule. Reinstalling should come later. First confirm that your original subscription URL, server details, and necessary configuration are safely saved, and check what the app currently supports exporting. Exported files may contain credentials, so store them somewhere secure that you control.

On iPad, check the account, selection, and network differences first

If Shadowrocket works on iPhone but not iPad, confirm that both devices use the same valid details, server, and Global Routing setting. Matching display names don’t guarantee identical underlying parameters, and a migration may not have activated the expected Config. Check the selected item, matched rules, and failure stage on each device, then compare the differences. Don’t assume that using the same Apple Account automatically syncs and keeps all in-app settings identical.

On iPad, the window layout may show a sidebar or different amounts of information depending on the screen and display mode. Find controls by their interface names—Home, Config, Settings, and so on—not by matching their screen coordinates to a screenshot. A smaller visible area in Split View doesn’t mean settings are missing. Close anything that’s obscuring the view or expand the relevant area. Confirm whether you’re editing a server, selecting a configuration, or granting system permission before importing anything again.

An iPad with Wi-Fi only can’t use its own cellular network for comparison, so try another network you trust. An iPhone on cellular data and an iPad on Wi-Fi that requires authentication aren’t a valid like-for-like comparison. Also check whether the Wi-Fi network restricts communication between devices and whether local network permission is enabled for the activity you need. Opening an ordinary web page doesn’t prove that the device can reach a printer or internal domain.

Restoring a purchase and restoring settings are separate tasks

To redownload the app, use the Apple Account associated with the purchase to find it in the App Store. Availability and compatibility are as shown on the App Store listing. After restoring the app on iPad, check whether your subscription and Config are still there; restoring the app doesn’t restore all your service settings. See how to restore a previous purchase for the steps.

Keep a reproducible summary of the outcome

Record the symptoms, trigger, single change made, and retest result. If the issue persists, include device and network details plus a redacted error summary. Don’t share the full subscription, keys, or a complete exported configuration.

After recovery, follow the setup guide to verify each step: importing, selecting Config, authorizing the connection, and accessing a real destination. Then check On Demand and any local network services you need. If the issue returns, go back to the relevant symptom in this guide and narrow it down; don’t keep wiping settings. A reliable resolution means the same steps work consistently without compromising your original needs through a temporary workaround—not that things happened to look normal after one restart.