Shadowrocket Troubleshooting Guide

The connection switch won’t turn on or turns off by itself

First, identify where the connection process stops

No response when you tap Connect, a brief connection followed by a disconnect, and repeated reconnects are different symptoms. Stay on Home and check whether a system authorization prompt appears after you tap the switch. Then check the VPN status in system settings. System authorization only allows the connection configuration to be created; it doesn’t authenticate the server or confirm access to your destination. If a prompt is still on screen, read and respond to it first. Repeatedly tapping the app switch behind the prompt can make an authorization delay look like a stalled connection.

The first connection requires permission to add a VPN configuration and may require your device passcode or system authentication. If you previously denied permission, try connecting again from the app. The name and location of the system settings entry can vary; search for VPN to find the configuration. Check only entries you can confirm belong to Shadowrocket. Don’t delete configurations that your organization, school or device management requires you to keep. If a managed device blocks VPN configuration, ask the administrator to check the policy; changing server settings won’t remove a system restriction.

Check your local network separately from the connection configuration

Turn off the connection and use a browser to open a site that normally works. Confirm that Wi-Fi or cellular data is available. Public Wi-Fi may require you to sign in through a web page; being connected to the network doesn’t necessarily mean you have internet access. Complete any network sign-in before connecting. If the underlying network is unavailable, check the signal, account status or router connection first. Don’t change your Config at the same time. Try again on another available network to see whether the issue is limited to the current connection.

Once the underlying network is working, check Home to make sure an individual server is selected—not just a subscription group. Open the selected entry and compare its protocol, address, port and authentication details with the information from your existing provider. Save a copy of the current Config before comparing it with a known-working configuration. If enabling one Config immediately ends the connection while others stay connected, check that Config’s syntax and references first. Don’t overwrite your only copy: you’d lose both the diagnostic evidence and a way to revert.

Check automatic connections and repeated starts

If the switch turns off and then back on, check whether On Demand is enabled and whether the current network meets its connection conditions. Temporarily turn off On Demand during troubleshooting, then test the connection manually so automatic rules don’t change its state. Other device features that use a VPN configuration may also affect the connection. Pause related features only if you can identify them and it’s safe to do so, then test again. Record what triggered the change—such as switching Wi-Fi, locking the screen or returning to the app—instead of noting only that it disconnects occasionally.

If the switch turns on briefly and then off, check for any error message or connection log shown in the app. A configuration parsing error, missing required field, interrupted extension startup and remote timeout each need a different fix. Stop the connection, return to the Home Screen, reopen the app and run one controlled test. Restart the device only if that doesn’t help. A restart can clear temporary system state, but it can’t fix an incorrect password, invalid server address or malformed configuration. Afterward, repeat the original steps to confirm the issue hasn’t merely disappeared temporarily.

The connection is on, but there’s no internet access

Set up a repeatable access test

An active switch means the local connection is running; it doesn’t confirm that the remote server, DNS or rules are working. Choose two destinations you can normally access for different purposes. Note whether a page won’t load at all, only its images fail, or one app can’t connect. Turn off the connection and test the same destinations as a baseline. If they still fail, check for an issue with the destination, network sign-in or device connection first. Don’t look for a proxy-rule problem if the underlying network is the cause.

Use the same browser and page at roughly the same time to avoid mistaking a cached result for a fix. If needed, reload the page or try a regular site you haven’t opened before. Don’t judge the whole network by whether an app’s home screen displays content; it may be showing locally cached data. If the browser works but one app doesn’t, check the app’s cellular-data permission, background activity and sign-in connection before treating it as a device-wide problem.

Use Global Routing to separate rule issues from connection-path issues

Check whether Global Routing is set to Config, Proxy or Direct. These are the corresponding interface terms. During diagnosis, change the mode temporarily and note its original value. Direct tests the underlying network path; Proxy tests access through the selected server; Config applies the rules in the active configuration. These aren’t three server types or speed settings. Proxy can help isolate rule issues, but it doesn’t mean every destination should always use the same server.

If Proxy works but Config doesn’t, check whether the destination is routed to DIRECT, REJECT or an unavailable policy group. Read the configuration from top to bottom and look for the matching rule, especially broad DOMAIN-KEYWORD rules, network-range rules and fallback rules that appear too early. If Direct works but Proxy doesn’t, verify the current server before changing domain rules. Restore the original mode after the comparison, then make the next change so temporary test settings don’t remain in everyday use.

Check matching rules and related requests

A page usually requests more than the domain in the address bar; it may also rely on image, script, sign-in and API domains. If the main page loads but sign-in fails, check any connection logs available in the app for requests made when the failure occurred and note their policies. If a request is shown as matching REJECT, confirm the rule’s purpose before making a narrow change in a copy. Don’t delete an entire rule group to fix one image request or guess what a domain is used for based on its name. Use the actual failure log and service documentation where possible.

This snippet shows rule syntax and order only: the example domain uses PROXY, addresses matching the geographic database use DIRECT, and remaining traffic goes to FINAL. It isn’t a complete configuration for general use; PROXY must point to a working policy in the configuration you use. Before testing, confirm you’re editing the active Config. Save it, reconnect if needed and retest the same destination. Changes to an inactive file won’t affect the current connection.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

If both paths connect but domain-based access fails, continue to the DNS section. If only certain servers fail, see the timeout section. Don’t assume every browser network error is a rule issue; certificates, destination maintenance and account sign-in can also interrupt access. A record of the destination, mode, server and result is more useful when asking for help than a screenshot of the switch alone. You can also review the checklist for when the connection is on but there’s no internet.

Server timeouts and authentication failures

Know what each test result tells you

A latency test, a protocol connection and loading a web page test three different things. A response from one test shows only that its particular path worked at that time; it doesn’t mean every web request will work. A timeout may also reflect the test method or destination, so one result doesn’t prove that a server is permanently unavailable. Note the test method, then use the same server to access a fixed destination. Use the actual error to identify whether the issue occurs before connection, during authentication or after the request is forwarded.

If a group of servers all time out, test on another underlying network first. If only one entry fails on the same network, check that entry’s configuration and remote status. Avoid repeatedly running bulk speed tests, which add requests and can obscure the issue. Keep one known-working entry and one failing entry for each round of comparison. Check any maintenance or account-status information from your existing provider. This guide explains configuration use; it doesn’t provide or recommend server sources.

Check address, authentication and transport in order

First check that the server address doesn’t contain an unintended protocol prefix, path, spaces or line breaks, and confirm that the port matches the information you were given. If the field expects a hostname, don’t paste an entire subscription link into it. Copying can also introduce full-width punctuation into a password or identifier, making it look correct while authentication fails. Don’t change the port or encryption method based on guesswork; compare each field with the original configuration. Check sensitive fields on your device, and hide full passwords, identifiers and subscription credentials in public screenshots.

Next, check the authentication and transport parameters required by the protocol. For Shadowsocks, the password and encryption method must match. For VMess and VLESS, don’t mix up the UUID, transport and TLS-related fields. For Trojan, check both the password and TLS details. Hysteria2 and WireGuard also have required fields; don’t apply parameters from another protocol. A shared protocol name doesn’t mean all servers use the same options. Use the configuration for the service you already have.

Check TLS, device time and network differences

For connections using TLS, check the name required by the server. The server address, SNI and transport Host may serve different purposes; don’t make them all match just because they differ. An incorrect device clock can also affect certificate validity checks, so confirm the date and time zone. If you see a certificate error, check the name, time and server configuration. Don’t treat skipping certificate verification as a routine fix: it changes the security checks and can hide configuration or certificate problems that should be addressed.

If Wi-Fi fails but cellular data works, or vice versa, investigate differences between the two networks. Some transports rely on UDP, which network equipment may handle differently from regular web traffic. Compare using a configuration your existing provider has already supplied and confirmed to work. Don’t change the protocol name or adjust MTU blindly. Investigate path or fragmentation issues only after confirming the protocol, authentication and route, and reproducing a case where small packets work but larger requests fail.

Subscription update failures and unexpected imports

Identify the link type and failure stage first

A subscription is a URL used to retrieve a server list; it isn’t a single server or a Config file. First identify which type of information you received from your existing provider, then use the appropriate import method. If you paste a web page, account portal URL or single server share into the subscription field, the app may not retrieve the expected list. Check the URL structure and source instructions, but don’t post the full link publicly. Query parameters often contain access credentials, and exposing them may put your account at risk.

Classify an update failure as one of four types: the request can’t be sent, an error response is returned, the content can’t be parsed, or the list updates but its entries can’t connect. If the request can’t be sent, check the network and DNS. If the app reports an invalid account or link, check the original service account and link status. If parsing fails, confirm that the response is in a subscription format the app supports. If the list changed but the connection doesn’t work, retrieval may have succeeded; check server fields or remote status rather than repeatedly tapping Update.

Isolate the network used for the subscription request

Confirm the underlying network can access the internet, then try one manual update. If the current connection has failed and the subscription request depends on it, you may end up unable to update or restore the connection. Keep the existing list, stop the current connection if needed and retry over an available network. Record the result in both states. Don’t assume every subscription should use the same request path, and don’t overwrite the original link after one failed attempt. Follow your existing provider’s access requirements and the results of your comparison.

On public Wi-Fi without sign-in, a request may return a login page. A service issue may also return a web page instead of a server list. Being able to open that content in a browser doesn’t mean it’s a valid subscription. If parsing fails, check what the response contains first; don’t paste an entire web page into Add Server. If you need help, tell your existing provider the error category shown in the app and share only redacted details. Don’t publicly post a response body that contains account information.

Compare groups and selection before and after an update

Before updating, note the current group, selected server name and manually added entries. Save a separate copy if needed. An update may replace entries managed by that subscription, including fields you edited manually. Don’t rely on temporary edits to subscription-managed entries as a permanent solution. After updating, check that the number of entries and groups look as expected, then confirm the selected entry is still there. Renamed, duplicated or removed servers may mean your familiar selection no longer refers to the same connection.

If only some entries remain after an update, check filters, collapsed groups and display settings before assuming data is missing. If two entries share a name but have different settings, compare their protocol and address instead of relying on the name. A successful subscription update doesn’t guarantee that the account service is active; check the service period, remote maintenance and authentication separately. Repeatedly deleting and reimporting the whole group usually won’t fix the content returned by the server and can erase useful comparison data.

Restore a subscription state you can verify

Keep one subscription group with a known source. Try a manual update first, and consider automatic updates only after confirming the list works. The location and availability of automatic-update options depend on the current app interface; they can’t fix an invalid link. If the app refreshes on launch and overwrites temporary changes, check its automatic update settings before deciding how to save a separate test entry. After testing, remove duplicate imports to avoid selecting an outdated entry later.

The connection works, but speeds are slow or intermittent

Define what you mean by “slow”

A slow first page load, low sustained download speed, intermittent video buffering and lag in a game can’t all be explained by one latency reading. Note whether the delay is in establishing the connection or during transfer, whether all destinations or one app are affected, and whether it happens continuously or at certain times. If only the first visit is slow and later requests work, check DNS, the handshake and caching. If the connection starts quickly but large downloads keep stalling, look at link stability, throughput and remote load—not just the numbers in a test list.

Keep the destination, server and network fixed during testing. Pause system updates, photo sync and other large transfers, then repeat the same task. Don’t run multiple speed tests at once; they compete for bandwidth and make the results hard to compare. Test at similar times to avoid mistaking network load changes throughout the day for the effect of a setting. If your provider lists traffic or speed limits, check your account status; client configuration can’t increase the capacity of the remote service.

Compare the underlying network, server and destination in order

With the connection off, access a fixed destination that should be reachable on your underlying network. Check the Wi-Fi signal, router’s upstream connection and other devices’ network use. A strong signal indicator doesn’t guarantee a stable wireless connection; interference, distance and access-point load can all affect transfer speed. Then keep the destination the same and test with the current server. Compare with another server you already have and know works to see whether only one path is slow. Don’t change DNS while switching servers, or you won’t know which change helped.

If the same server works normally for most destinations but is slow for one, the issue may involve the site’s load, content delivery location or the path between the two. Check whether Config routes the relevant domains as expected, especially if the main site and its image or video domains use different rules. Use Proxy temporarily for comparison if needed, then restore the original mode. One video playing below your expected quality doesn’t prove the whole connection is faulty; the streaming service’s adaptive behavior, account permissions and cache may also matter.

Treat latency, packet loss and throughput separately

Latency measures the wait for a round trip or a test process; throughput measures the amount of data transferred over time. They’re related, but not interchangeable. A responsive path can still be slow during a sustained transfer, while a path with slightly higher latency may download steadily. Connectivity Test can help check reachability, but it isn’t an overall score for every use case. Choose a server based on how it performs for your everyday tasks, not just the lowest displayed value. Frequent switching adds reconnect and handshake overhead.

For intermittent stalls, focus on continuity. If performance fluctuates over a short period, note whether it coincides with Wi-Fi roaming, a switch to cellular, waking the screen or a background transfer. For services that rely on UDP, distinguish web access from access to that service; a working web connection doesn’t prove every type of traffic is handled the same way. Don’t change MTU, concurrency or transport settings just to test. Make changes in a copy only when you have clear evidence and a reference configuration, and use a test you can revert.

Keep a stable configuration instead of stacking optimizations

If the issue is caused by rules routing traffic the wrong way, narrow the rule and then retest other common destinations to catch any new access problems. If it occurs on only one network, keep comparison notes for that network and another one, then investigate the network equipment. If the same server is slow on multiple networks, focus on its status and remote path. Don’t enable a collection of unexplained options; the more settings you stack, the harder it is to determine which one changed connection behavior.

DNS resolution failures and unexpected rule results

Distinguish resolution, connection and certificate errors

DNS converts a domain name into an address for a subsequent connection. A domain that won’t resolve, an address that resolves but won’t connect, and a connection that completes with a certificate mismatch are different failures. First check whether the error specifically mentions name resolution, then compare multiple domains. Don’t replace a domain with an IP address to test the whole process: HTTPS usually relies on the correct hostname and certificate, and a failed direct-IP visit doesn’t by itself prove the network path is unavailable.

If multiple apps wait when opening new domains while existing connections keep working, check the DNS path first. If only one destination is affected, check its status and relevant rules. Browsers, apps and the system may each retain their own cache, so results won’t always change immediately when you update a setting. Record the original setting, reconnect and repeat the same visit. Distinguish a new request from a page reusing an existing connection to avoid mistaking cache differences for an intermittent failure.

Check the active Config’s resolution path

Open the active Config and confirm that its DNS settings belong to the file currently in use. First understand which path the original configuration uses for resolution, then check whether the resolver is reachable. Replacing its address with a familiar one doesn’t guarantee it suits your network and may break a path that was working. Encrypted resolution also requires network access, a correct device clock and the appropriate handshake conditions; encryption doesn’t make a resolver work automatically on every network.

Watch for circular dependencies: the current server address may need to be resolved first, while the DNS request itself depends on a connection that hasn’t been established. This can leave startup stuck. Check the initial resolution path against the instructions for your existing configuration. Don’t change the server hostname and DNS settings at the same time. If your provider specifies separate connection and handshake names, put each in its intended field. Don’t permanently replace a hostname with a resolved address to avoid DNS; the remote address can change and may affect transport requirements.

Understand the boundaries between domain and address rules

DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a specified domain and its subdomains, and DOMAIN-KEYWORD has a broader matching scope. IP-CIDR, IP-CIDR6 and GEOIP match addresses or address databases. Whether a request can use domain information depends on its source, the resolution process and the active configuration. Don’t assume every connection can match a domain rule. Check the actual record first, then interpret the rule; don’t infer the match from the address bar alone.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

The two network ranges in the example are documentation-only addresses; don’t replace them with broad real ranges that haven’t been checked. no-resolve prevents an additional domain lookup for matching the relevant address rule. It doesn’t turn off all DNS or fix an unreachable resolver. Rules are processed in order, so a broad rule near the top can prevent a later, more precise rule from taking effect. Test the smallest relevant scope first, then decide whether to expand it. This helps avoid extending a local issue to other apps.

Check IPv6 and other device-level settings

The same domain may resolve to different address types, and Wi-Fi and cellular networks may have different IPv6 capabilities. If the problem occurs on only one network, check the address type and support along the current path instead of disabling related features outright. Device profiles, network filters and other resolution settings can also affect behavior. Check only settings you can identify; ask an administrator about a managed device. Reconnect after each change to reduce confusion from old sessions.

Increased battery use, heat and unusual background activity

Start with the reporting period and actual usage

The percentage on your system’s battery screen is relative to the selected time period; it doesn’t mean the app always uses the same amount of power. The same connection activity may account for a larger share on a day when you use other apps less. Note the reporting period, screen-on time, actual battery drop and whether data was continuously transferring before deciding there’s a problem. A percentage alone can’t distinguish normal long-running traffic forwarding from a weak network signal or repeated failed connections.

Compare similar conditions: the same network, similar screen brightness, comparable tasks and roughly the same duration. Video playback, cloud sync and hotspot use all affect device load, so don’t compare two days with completely different activities. Don’t compare heat while charging with heat during standalone use. If the device is unusually hot, shows a system temperature alert or loses charge rapidly, stop demanding tasks and let it return to a normal temperature before running a short, controlled diagnostic.

Check for repeated reconnects and background transfers

When a connection is unstable, repeated resolution, handshakes and session setup can increase activity. First check whether the switch and system VPN status keep changing, then see whether the problem occurs with one server or one network. If a server keeps timing out, automatic retries won’t fix its remote status. Pause the connection, check the underlying network and compare with an available entry you already have. The number of failures and what triggers them are more useful than online time alone when explaining unusual battery use.

Check for apps syncing photos, downloading updates or restoring data at the same time. When the connection comes on, background tasks that were waiting for network access may start transferring data; the battery change you see may not be caused by the connection itself. If your system allows it, temporarily pause those tasks and check for a difference. Don’t disable essential security settings just to reduce one battery statistic, and don’t repeatedly erase app data. Compare transfer activity and battery use over the same period to avoid mistaking normal data processing for a fault.

Check On Demand and diagnostic activity

On Demand starts a connection when its configured conditions are met. If the network keeps changing and those conditions repeatedly become true and false, the connection may start over and over. Note the rules, temporarily turn off On Demand during troubleshooting and try to maintain one stable manual connection. If activity drops, investigate the specific trigger conditions and network changes rather than assuming the feature itself can’t work. When restoring it, enable one condition at a time and check behavior when locking the screen, switching networks and returning to the app.

Repeated bulk tests, long-running detailed diagnostics and frequent subscription updates also use network or local processing. After troubleshooting, stop tests you no longer need and keep only the redacted records needed to identify the issue. If you use a complex Config, save a copy, then temporarily disable processing unrelated to the current test and compare the results. Don’t delete every rule: fewer rules don’t necessarily mean lower battery use. Verify which activity or repeated failure is actually causing the extra work.

Use a controlled comparison to confirm a change

Try three rounds: a normal task on the underlying network, the same task on a stable manual connection, then the same task with On Demand restored. Keep each round similar in duration and activity; note battery change and whether the connection restarted. If the problem occurs only on one Wi-Fi network, check its signal and router. If it recurs with the same configuration on multiple networks, keep a copy and note the trigger steps. A brief improvement after restarting isn’t enough; test at least once more under conditions that previously caused the issue.

Issues after an app or system update

First identify what actually changed

A problem that starts after an update isn’t necessarily caused by the update itself. A subscription refresh, server maintenance, network change or Config update may have happened at the same time. List what changed between the last successful use and the first failure. Confirm whether the app or system was updated and whether the subscription was also refreshed. Keep the current configuration. Don’t repeatedly reinstall, clear data and reimport; too many changes make it hard to tell what affected the result and remove useful diagnostic evidence.

After updating the app, open Home and check that the server list, selected entry and active Config are still as expected. A changed interface location doesn’t mean your content is gone; check the groups and current file before reimporting. If only a control’s name or location has changed, follow the current interface rather than guessing from an old screenshot. Get and update the app through the App Store. For purchase or restore steps, see how to restore a purchase; don’t look elsewhere for the app.

Retest system status, configuration and remote access in order

Turn off the connection, check the underlying network, then establish one manual connection. If the system asks for VPN authorization again, read and confirm the prompt. Ask an administrator to check policy restrictions on a managed device. If connection issues started after a system update, stop the connection and restart the device before repeating the same test. Don’t treat a brief success after restarting as a lasting fix. Also repeat the action that previously triggered the failure, such as waking the screen or switching Wi-Fi, and confirm the connection holds under the same conditions.

Next, test the same server in Direct, Proxy and Config under controlled conditions, then restore the original mode. If only Config fails, check its syntax, policy references and rule order. If all server-routed access fails, revisit the address, authentication and transport fields. Older configurations may rely on strict field relationships; compare each field with your existing provider’s current setup instructions instead of adding unfamiliar options or broadly weakening verification.

Check configuration migration and subscription overwrites

If the issue appeared right after a subscription refresh, compare a saved copy from before the refresh with the current entry. Focus on protocol, address, port, TLS and transport fields. An unchanged name doesn’t mean the underlying parameters are unchanged. A refresh may also restore subscription-managed entries after manual edits. Save a confirmed working test configuration separately and ask your existing provider about the differences. Don’t keep editing the same subscription entry and immediately refreshing it; each test may end up using different parameters.

Configuration migration may also affect file selection and policy references. Confirm that the expected file is active, then check whether each referenced policy still exists. Copying a file doesn’t copy all external dependencies, and a successful import doesn’t mean every reference is valid. If parsing fails, keep the specific error and a redacted excerpt around the relevant line; fix only what the error explains. Don’t replace the entire Config with one from an unclear source as a test—that would change routing, resolution and processing at once.

Consider rebuilding or downloading again only as a last step

Rebuild the app’s VPN configuration or download the app again only after saving your server details, subscription source and a copy of the Config—and confirming you know how to restore them. Before downloading again, check that you’re using the original purchase account so you don’t confuse a store-account issue with a connection issue. Confirm that any files saved elsewhere actually open; seeing a filename isn’t enough. In-app history may not be fully restored. If you need it for troubleshooting, make the necessary notes before clearing anything.

iPad connections, purchase restoration and differences across devices

Separate purchase status from configuration status

Getting the app with the same purchase account and setting up server configurations on a device are separate things. Check the app’s purchase status in the iPad App Store. System requirements, compatibility and whether the purchase is universal are as listed on the App Store page. Being able to redownload the app doesn’t mean your iPhone’s subscription, selected server and Config will appear on your iPad automatically. Check what’s actually there after opening the app, then use the quick-start guide to import your own information. A successful purchase doesn’t replace checking your setup before connecting.

If the purchase status shown in the store doesn’t match what you expect, check the account used for the App Store rather than relying only on the account name at the top of system settings. The app ID is 932747118 and the developer is Shadow Launch Technology Limited. See the iPad App Store guide for recovery steps. Resolve purchase issues in the store; check server authentication or access issues using this guide. Neither replaces the other. The one-time app purchase grants use of the app and doesn’t include server service.

Compare the actual configurations on both devices

If iPhone works but iPad doesn’t, connect both devices to the same available Wi-Fi and test the same destination at roughly the same time. Compare the selected server, Global Routing mode, active Config and DNS conditions—not just server names. Different subscription update times, changed settings under the same name or a different active file may explain the discrepancy. Put both devices in the same documented test state, then change one setting on one device per round so you keep a clear reference.

Transfer configurations using a method you control and can verify. After importing, check the address, port, protocol and required authentication fields individually. Don’t share full subscription links in public documents or images, and don’t assume a QR code contains no sensitive information. If a sync method transfers only the Config file, confirm that its server or policy references are also available. An openable file doesn’t mean all its dependencies are in place. If a policy is missing, restore the correct reference instead of renaming it arbitrarily.

Check iPad network access and system restrictions

Some iPads support Wi-Fi only, so you can’t use the same cellular comparison steps; try another trusted, working Wi-Fi network instead. On cellular-capable models, check network permissions and the active data connection separately. When using a phone hotspot, the iPad uses the network environment provided by that hotspot, so verify that the underlying connection works. Don’t assume the iPad has the same access path just because the iPhone works; tethering, signal and session conditions may differ.

An iPad managed by a school, organization or family may have VPN, account or network restrictions. If it can’t add a VPN configuration on first connection, check the system prompt and contact the administrator. Don’t remove managed content that needs to stay in place. On public Wi-Fi that requires sign-in, complete network authentication before connecting. If only one app fails, check its network permission and account status. Check the server, DNS and rules in order only if all apps fail; don’t treat a single-app permission issue as a device-wide problem.

Test after screen lock, during multitasking and over longer sessions

iPad use often involves Split View, multitasking and longer periods of standby. An app running in the background doesn’t mean its connection has stopped. Check the system VPN status and a real request instead of relying on whether the app is in the foreground. If access fails after waking from the lock screen, note the Wi-Fi network before and after waking, On Demand conditions and switch status, then reconnect manually for comparison. If the problem reproduces only with automatic connections, check the conditions; if a manual connection also fails, return to the underlying network and server reachability.