Shadowrocket Troubleshooting Guide

Establish a troubleshooting baseline: the switch will not turn on or immediately turns off

First distinguish a switch failure from a server connection failure

The Shadowrocket Home switch asks the system to establish the VPN configuration. If the switch will not stay on, the failure usually occurs before traffic reaches the server. A server timeout means the system tunnel was established, but the subsequent server connection did not complete. The troubleshooting paths differ. When observing the problem, do not check only whether a webpage opens. Record the Home switch state, the VPN indicator in the system status bar, the selected server, and the state shown by Global Routing. If the switch immediately resets, check system authorization and configuration conflicts first. If it stays on but webpages fail, continue to the next section and check the server, DNS, and rules.

When the app is opened for the first time, or when the system asks for authorization again, the device may show a permission prompt to add a VPN configuration. Shadowrocket can create the corresponding configuration only after device authentication is completed. If authorization was previously denied, open system Settings to check whether the VPN configuration exists, then return to Shadowrocket and try again. Repeatedly deleting the app is unnecessary here; confirming the permission chain first helps avoid misdiagnosing a system authorization issue as a server problem. Device management, content restrictions, or parental controls may also limit VPN configuration changes. In that case, follow the system’s specific message and ask the device administrator to confirm the policy.

Clear simultaneous connection conflicts

On Apple platforms, only one network extension that meets the system conditions can take over the relevant traffic at a time. If another VPN configuration in system Settings is connected or repeatedly triggered automatically, the Shadowrocket switch may remain at “Connecting” and then turn off. For troubleshooting, disconnect other VPN configurations, temporarily disable Shadowrocket’s On Demand, and manually operate the Home switch once. If the On Demand conditions do not match the current Wi-Fi, cellular network, or domain conditions, the system may reconnect immediately after you turn it off, or reassess the conditions after you turn it on manually.

Disabling On Demand is only a way to establish a baseline; it does not mean the feature itself is faulty. After manual connection works again, check each trigger condition: whether the current network name is assigned to the correct branch, whether cellular conditions match expectations, whether conditions require all criteria or any one criterion, and whether a rule references a configuration that has been deleted. After changing one item, switch networks once or wait for the system to reassess. Do not change several conditions at once, or you will not know which change restored the connection.

Restore the connection using the minimum-variable method

For a baseline test, keep only one server whose information is known to be complete, disable On Demand, and avoid changing protocol parameters. Connect first on a stable Wi-Fi network. If it fails, switch to cellular data for comparison. If the same configuration behaves differently on the two local networks, the router, network access, or DNS environment is more likely involved. If both networks fail, then check the server address, port, authentication details, and protocol parameters. Do not change the server, DNS, Global Routing, and rules file in the same test, because changing multiple variables can hide the real cause.

If you need to recheck the purchase record, app ID, or developer information in the App Store, visit the three-point authenticity check. Shadowrocket is a one-time purchase client, but a one-time app purchase is not a service plan. The subscription or server information needed for connection must come from a service source you already use; the app purchase status does not determine whether any particular server is available.

The switch is on, but webpages and apps cannot access the internet

Use three Global Routing states to narrow the scope

Global Routing’s Config, Proxy, and Direct states are the main dividing line when diagnosing “connected but no internet.” Config determines the route for each request according to the rule order in Config. Proxy sends traffic through the current server. Direct connects directly. Record the original state, then switch briefly to Direct. If Direct also fails, the issue may be in the system tunnel, local network, or DNS rather than the proxy server. If Direct works but Proxy fails, check server reachability and parameters. If Proxy works but Config fails, focus on rule order, policy names, and the FINAL result.

Switching states is for diagnosis only; Proxy should not be left on permanently as a way to work around a rule problem. If Config behaves incorrectly, fix the rules themselves. Rules are evaluated from top to bottom, and evaluation stops after the first match. Therefore, narrower DOMAIN, DOMAIN-SUFFIX, and IP-CIDR rules usually belong before broader rules, with FINAL at the end. An early REJECT, DIRECT, or broad DOMAIN-SUFFIX can prevent later rules from ever matching.

Build a readable minimal rule set

The following snippet demonstrates rule order and does not represent real service information. Policy names must match existing policies in Config or result names supported by the app. During testing, replace PROXY with the correct policy name from your own configuration and make sure FINAL is last. Use DIRECT for LAN addresses to avoid routing access to routers or local devices through a remote server. Put explicit domain rules before GEOIP and FINAL so you can verify matches in Data or request records.

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

If importing a Config file produces a missing-policy error, invalid rules, or failure for an entire traffic group, check that comma-separated fields are complete, policy-name capitalization is consistent, invisible characters have not been included, and referenced policy groups actually exist. Do not assume a configuration is valid merely because the file imports successfully. Importing only means the text was accepted; it does not prove that every server, policy group, and rule can execute. Keep a small number of rules first, verify them, and then restore complex rules section by section.

Check system time, network sign-in pages, and IPv6 differences

If the device date and time are significantly incorrect, TLS certificate validation may fail. Most HTTPS pages may not open while a few local pages remain accessible. Enable automatic date and time in system Settings, then reconnect. Hotel, campus, and public Wi-Fi networks often require a sign-in page first. Before connecting Shadowrocket, temporarily turn off the switch, use a browser to open an ordinary page and trigger the sign-in page, complete the login, and then turn Shadowrocket on. If Wi-Fi works but cellular data fails, or vice versa, check DNS and IPv6 reachability separately on each network. Do not treat a restriction on one access network as evidence that all servers are unavailable.

Some apps cache old connections. After changing Config, DNS, or the server, disconnect and reconnect in Shadowrocket, then fully quit and reopen the affected app. If it still fails, toggle Airplane Mode once so the system can rebuild the network interface. Restarting the device should come after checking permissions, state, rules, DNS, and network comparisons. It can clear temporary state, but it cannot fix incorrect server parameters or rule order.

If the issue occurs only when the switch is on, continue with the step-by-step checklist for server status, Global Routing, DNS, and rules for a shorter field checklist.

Server timeouts, handshake failures, and Connectivity Test issues

Break a timeout into address, port, and protocol stages

A timeout does not have a single cause. First, the server address must resolve to an IP address. Next, a transport connection must be established to the port. Finally, authentication and the handshake must complete using protocols such as Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, or Hysteria2. If an earlier stage fails, later stages cannot occur. Connectivity Test is useful for comparing multiple existing servers at the same time and on the same local network, but one failure does not prove that a server is permanently unavailable. Local network instability, temporary DNS failures, server maintenance, or inconsistent parameters can produce similar symptoms.

First verify SERVER, the port, the password or identifier, the protocol type, and transport-related fields in Add Server or the existing entry. Common copying errors include spaces before or after the address, a missing port, changed capitalization, mistaking a note for the server address, and expired QR code or clipboard content. Each parameter should match the information from your existing service source. Do not replace encryption methods, transport types, or TLS values based on assumptions. Matching protocol names do not mean the parameters are interchangeable.

Use network comparisons to distinguish local blocking from a remote issue

When a timeout occurs on Wi-Fi, disconnect Shadowrocket and confirm that ordinary webpages work, then switch to cellular data and test the same server. You can also retest on another known-working Wi-Fi network. If the same server fails only on one access network, check the router’s DNS, IPv6, guest-network isolation, organizational network policies, or a sign-in portal first. If it times out on different networks while other servers in the same subscription work, the server address, port, or remote status is more likely at fault. If all servers fail on all networks at the same time, check the subscription content, system time, DNS, and whether the configuration was replaced as a whole.

Keep the test order fixed: test the current server first, then another server in the same configuration, then change the local network, and only afterward change protocol parameters. This creates two comparison dimensions. If changing only the server restores the connection, the system tunnel and app permissions are probably working. If changing only the local network restores it, the server is reachable from at least one other network. If every combination fails, check shared factors such as incorrect DNS, an expired configuration, the system VPN state, or an overall change from the service source.

Understand the limits of latency tests and real-world availability

A latency value reflects the round trip of a specific test request under the network conditions at that moment. It does not equal webpage loading performance, video transfer speed, or large-file throughput. A server that returns a test result is not guaranteed to reach every target domain under the current rules. Conversely, a remote restriction on the test request does not mean real traffic cannot respond. Combine Connectivity Test with actual request records: check whether the request was sent, which policy it matched, and whether the result was a timeout, connection refusal, or name-resolution failure. Different errors point to different layers and cannot all be handled by simply changing servers.

Protocols such as WireGuard and Hysteria2 may also depend on specific keys, addresses, MTU, or transport parameters. If the connection works but some pages stall, do not immediately raise or lower every setting. First confirm the complete fields provided by the service source, then test with default or explicitly specified values. An unsuitable MTU may appear as small requests working while large responses stall, but the same symptom can also come from DNS, path quality, or server-side limits. Cross-check by changing the local network and comparing other servers.

If the server information has been changed by the service source, update the existing entry or subscription with its latest information. This guide explains importing, testing, and troubleshooting in the client; it does not provide servers or subscription content.

Subscribe import or update failed

Distinguish an unreachable address, invalid content, and an update that did not take effect

Subscription failures fall into at least three categories. First, the Subscribe address cannot be reached, often resulting in a timeout, DNS failure, or abnormal HTTP status. Second, the address returns content, but the format is not recognized by Shadowrocket. Third, the interface reports that the update finished, but the server list does not change as expected. Identify the failed step before deleting and adding the entry repeatedly. Use the complete subscription address supplied by your existing service source, and remember that query parameters in the link are usually part of the address and must not be truncated when copied.

In the Subscribe entry, first check whether spaces were added at either end of the address, whether the scheme is complete, whether a chat app inserted line breaks, and whether the service source has replaced the link. A sample address can explain the structure but cannot create real servers:

https://example.com/sub?token=xxxx

If the same address used to update successfully but suddenly fails, test on another local network first, then check the system date and DNS. A public Wi-Fi sign-in page, router filtering, or a temporary resolution problem can affect subscription requests. If the address returns a clear error on different networks, contact the original service source to confirm its status. Do not convert subscription content through unknown pages, and do not submit links containing access credentials to unfamiliar tools.

Check the relationship between update behavior and local entries

A subscription update may add, modify, or remove servers managed by that subscription. During troubleshooting, observe manually created Add Server entries separately from entries managed by Subscribe, so a local entry is not mistaken for an update result. Counting the servers in a subscription before every update is not a reliable long-term check because the service source may change its content. A better method is to record a specific server name or update-status message, check the subscription entry after updating, and confirm that the currently selected server still exists.

If Home still selects an old entry that was removed or had its parameters changed after an update, select a valid server from the subscription again and run Connectivity Test. If a policy group in Config references servers by name, a name change may also leave the policy incomplete. Check not only the server list but also the Config policy-group members and rule results. A successful subscription update proves only that data was written; it does not prove that the existing Config still references the new data correctly.

Handling format errors and partial data issues

If only some fields in the returned content are invalid, the app may skip part of the content or produce an unexpected import result. Do not guess missing fields manually. Keep the original Subscribe entry and currently working configuration, then ask the original service source whether its format is suitable for Shadowrocket. If the service source also provides a QR code, use Scan QR Code to import it, but verify the server address, protocol, and note afterward. Being scannable does not prove that the parameters are correct.

Import from Cloud JSON is suitable for importing corresponding data saved by the user, but a cloud file may predate the current configuration. Before importing, distinguish restoring a backup from updating a subscription: a backup returns the local structure from a particular point in time, while a subscription update retrieves current content from the original address. After an old backup replaces existing data, recheck the Subscribe address, server selection, Config, and On Demand conditions. Do not verify only that the server list appears.

A subscription is not part of the Shadowrocket purchase. A one-time app purchase is not a service plan. The App Store purchase provides the client; data in Subscribe is supplied by the user’s existing service source. To move to a new device, you can also read the configuration backup and device-migration steps: restore the app purchase first, then verify the local configuration and subscription status.

Slow speeds, loading stalls, and inconsistent behavior across apps

Measure layer by layer: local network, server, path, and protocol

Start by defining exactly what “slow” means: a long wait before a page opens, low sustained transfer speed, stalling images or video, or an issue limited to one app. Different symptoms point to different layers, including DNS, connection establishment, throughput, packet loss, and rule matching. Before troubleshooting, stop large sync or download tasks, fix one test target and time period, and measure the local network with Shadowrocket off before turning it on and testing the current server. Comparing subjective impressions across different times and websites cannot produce a reliable conclusion.

The first layer is the local Wi-Fi or cellular network. If the local network already has clear packet loss, frequent network changes, or weak signal with Shadowrocket off, later connections will amplify the instability. Move closer to the router, leave a poor-quality Wi-Fi network for cellular data, or retest on another stable network to determine whether basic access is the main cause. The second layer is the current server and path. Use Connectivity Test to compare several servers in your existing configuration and open the same target page in practice. Do not choose solely from one latency result; low latency does not mean stable sustained throughput.

The third layer is the protocol and its parameters. Different protocols may behave differently under different network conditions, but parameters must come from existing server information. Do not change authentication, transport, or TLS settings arbitrarily to pursue speed. If the service source provides multiple suitable entries, compare them on the same network, at the same time, against the same target. The fourth layer is rules: domains used by one app may be assigned to different policies. If the main page uses PROXY while image domains use DIRECT or REJECT, text may appear first while resources remain blank for a long time.

Identify split routing from request records

In Data or the relevant request records, inspect the domains, matched rules, and final policies when the problem occurs. Pay particular attention to whether the main domain, static-resource domains, login domains, and content-delivery domains take consistent routes. If DOMAIN-KEYWORD matches too broadly, replace it with a more precise DOMAIN or DOMAIN-SUFFIX. If GEOIP matches too early and produces an unexpected result, move explicit domain rules before it. After changing rules, disconnect and reconnect, then reopen the target app so old connections do not continue using the previous path.

Do not mask a speed issue by routing all traffic through Proxy permanently. Use Proxy to confirm whether rules are involved. Once Proxy works but Config is slow, return to Config and fix the rules. If both are slow while Direct works, check the server and path. If all three states are slow, check the local network, DNS, and device state first. This three-state comparison is the same as in the previous section, but here the focus is performance differences within a usable connection rather than complete inaccessibility.

Handle large-response stalls and MTU clues

When small webpages work but large images or sustained transfers often stall, MTU or path-fragmentation issues can be considered, but not assumed. First compare different local networks and servers. If the issue appears only in one network combination, the path characteristics are more suggestive. If it appears in every combination, also check protocol parameters, the device’s power-saving state, and the target service. For configurations that explicitly provide an MTU setting, use the user’s existing service information or protocol requirements as the baseline. Change one value at a time and record the same test before and after. Repeated blind changes create more instability.

Cover at least two time points during testing to avoid treating temporary congestion as a stable conclusion. Record the local network type, server name, Global Routing state, target app, and stage at which the symptom occurs, then compare the results. If the same server varies greatly by time, remote load or path changes may be involved. If all servers are slow only on one Wi-Fi network, address the router and access network first. For a fuller four-layer check, see the step-by-step guide to servers, paths, protocols, and local networks.

DNS resolution failures, abnormal results, and domains that will not open

Recognize a DNS issue instead of broadly calling it a network outage

DNS converts domain names into addresses that can be reached. Typical DNS failures include a domain that will not open while a known IP responds directly, some domains continually reporting that the server cannot be found, the same domain recovering after switching Wi-Fi, or a very slow first request followed by normal behavior while the result is cached. TLS failures, REJECT rules, and server timeouts can look similar, so use the error type in request records. If the record shows name-resolution failure, handle DNS first. If the target IP has already been obtained but the connection times out, move to the server or path layer.

DNS behavior in Shadowrocket is affected by Config, the system network, IPv4, IPv6, and rule settings. Record the current DNS configuration before troubleshooting; do not immediately clear every field. Temporarily test with a DNS method confirmed to suit the current configuration, separately observing Wi-Fi and cellular data. If failure occurs only on a particular Wi-Fi network, router-provided DNS, a sign-in page, or LAN hijacking may be involved. If every network fails, check whether Config references an unreachable address, a malformed configuration, or a resolution path inconsistent with the current rules.

Understand the relationship between no-resolve and IP rules

IP-CIDR, IP-CIDR6, and GEOIP make decisions based on the destination IP. When a rule includes no-resolve, it means not to trigger an additional domain lookup to evaluate that rule. This can reduce unnecessary queries, but it also means the rule can match only when IP information is already available. Assuming that every IP rule actively resolves domains can lead to an incorrect explanation for why a rule did not match. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD match directly against the domain and usually belong before IP-based rules that require precise routing.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

The LAN rules above illustrate matching behavior. If the device needs to access a router, storage device, or printer on the local network, DIRECT usually prevents traffic from being sent to a remote server, but actual access still depends on Wi-Fi isolation and LAN permissions. An unreachable LAN IP is not necessarily a DNS issue because no domain lookup occurs when the IP is used directly. First determine whether the target is a domain or an IP, then identify the layer at which access fails.

Handle cache, IPv6, and encrypted DNS interactions

After changing DNS, old results may remain in the app, system, or connection cache. Disconnect Shadowrocket, reconnect, then fully quit and reopen the target app; toggle Airplane Mode once if necessary. Do not change several DNS options in succession and immediately draw a conclusion, because the cache can mix the before-and-after results. If a domain provides both IPv4 and IPv6 while the current network’s IPv6 path is unstable, resolution may succeed but the connection may be slow or time out. Compare different access networks and check which address type the failed request used instead of assuming that DNS returned no result.

When configuring encrypted DNS, also consider how the DNS server’s domain is resolved initially and whether the path to that DNS endpoint is affected by the current rules. If the endpoint itself can be reached only through a path that has not yet been established, startup dependency can occur. Temporarily return to a basic method explicitly supported by the configuration, confirm that ordinary resolution works, and then restore encrypted DNS settings gradually. After each change, test one domain that previously failed consistently and one domain that worked normally to determine whether the issue affects resolution generally or only one domain’s result.

Unusual battery drain, background activity, and post-update issues

Determine whether battery use comes from continuous traffic or connection retries

When Shadowrocket is connected, it processes traffic through the system network extension. Battery use is affected by device signal, transfer volume, protocol, rule complexity, logging, and connection stability. Start in the battery-usage page in system Settings and compare Shadowrocket’s foreground and background activity during the observation period. Also check for photo sync, cloud backups, media playback, or other apps transferring data continuously. When other apps generate the traffic, Shadowrocket may show background activity because it is processing those connections, so its percentage alone does not prove that the client is malfunctioning.

If the device becomes warm while servers repeatedly time out, the Home state switches frequently, or On Demand keeps triggering, focus on connection retries. Disable On Demand first, select a server already confirmed to work, connect manually on stable Wi-Fi, and observe. If the issue resolves, check whether On Demand conditions conflict when switching between Wi-Fi and cellular networks. Weak signal increases cellular power use while maintaining a connection. If the same configuration works normally on stable Wi-Fi but causes obvious heat in a weak-signal environment, the access network is an important variable.

Reduce the impact of logs, rules, and background tasks

During troubleshooting, reduce unnecessary long-term detailed logging and check Data for an app that is producing a large number of requests continuously. A domain involved in abnormal retries may recur at short intervals, increasing traffic and repeatedly waking the network. Identify the app, matched rule, and returned error before changing the rule or the app’s background behavior. Do not block every similar domain with a broad REJECT, because an overly broad DOMAIN-KEYWORD can break normal functions and create new retries.

A complex rules file is not usually the only cause of battery drain, but many duplicate, overlapping, or poorly ordered rules make diagnosis harder. Copy the current Config and create a minimal version containing only necessary LAN rules, explicit domain rules, GEOIP, and FINAL. Observe connection stability during the same period. If the issue disappears, add the original rules back section by section to locate the part causing repeated requests or incorrect routing. This is safer than deleting the entire configuration at once and preserves a recovery path.

After an update, check state migration before rebuilding the entire configuration

If an App Store update is followed by a failed switch, unavailable servers, changed rule behavior, or an abnormal interface state, restart the Shadowrocket connection first: turn off Home, wait for the system VPN indicator to disappear, and turn it on again. Then confirm that the selected server, Global Routing, Config, DNS, and On Demand are still the items used before the update. A system update may also reassess network-extension permissions, so check in system Settings that the VPN configuration exists and is available. System requirements and compatibility always follow the App Store listing.

If the configuration remains but only one subscription or server fails, follow the subscription and timeout sections rather than blaming the app update. If every configuration shows the same problem, export or record important settings first, then restart the device and network. Consider a broader rebuild only after confirming that local data has a recoverable backup, the purchase can be restored through the App Store, and the subscription address is still saved by the user. Clearing data hastily can turn a temporary system-state issue into a configuration-recovery problem.

The only official way to get Shadowrocket is the App Store product page. On the page, verify the developer, Shadow Launch Technology Limited, and app ID 932747118. App updates are also managed by the App Store; information found online should not replace the store listing.

iPad-specific issues: split view, keyboard, LAN access, and device migration

Confirm the purchase and configuration sources on iPad first

Shadowrocket on iPad uses the same App Store product page as on iPhone. If the same Apple ID has already made the purchase, find and restore it in the App Store’s purchased items. Exact compatibility and system requirements follow the App Store listing. The first launch still requires system authorization to add the VPN configuration. If the switch works on iPhone but will not turn on on iPad, check the iPad’s VPN permission, device-management policy, On Demand conditions, and current network separately. Do not assume the two devices have identical system network states.

After restoring a configuration through iCloud, Config export, or Import from Cloud JSON, verify “the file is present” separately from “the configuration can connect.” First check server entries and the Subscribe address, then select the current server, check Global Routing and DNS, and turn on Home last. If the backup is old, subscription-managed entries may need to be updated again. If a policy group references a server whose name changed, check Config as well. See the configuration backup and device-migration guide for the complete order, which also applies when moving from an old device to iPad.

Handle interface differences caused by split view, multiple windows, and the keyboard

iPadOS split view and multiple windows change the available width, so Home, Config, Settings, or Data may use different list and detail layouts. If a button is not visible, exit the narrower split-view state or expand the sidebar instead of looking for its fixed iPhone position. The connection is maintained by the system network extension; closing a Shadowrocket window does not necessarily disconnect Home. Return to the app or check the system VPN status. With multiple windows open, after changing Config confirm that you are viewing the same configuration and its latest state.

When using an external keyboard to paste a Subscribe address, SERVER, password, or rule, watch for full-width punctuation, smart quotes, automatic spaces, and line breaks. Rule syntax requires English commas, and policy names must match existing names. Content copied from formatted text may contain invisible characters. If something looks identical but cannot connect, verify it again in plain text and compare each field. Also check the result after using Scan QR Code; do not rely only on the scan completing.

LAN access and Wi-Fi scenarios

iPad is often used to access LAN storage, printers, or home services. If LAN resources stop working after turning on Shadowrocket, test with an IP address first to distinguish name resolution from reachability. Make sure common LAN ranges have DIRECT rules placed before FINAL. If the IP is reachable but the local name fails, check the router’s DNS or local name resolution. If the IP also fails, check whether Wi-Fi guest isolation is enabled, whether the devices are on the same subnet, and whether the target device allows access from the current network.

[Rule]
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

On school, conference, or hotel Wi-Fi, iPad may need to complete a sign-in page first. Turn off Home, open a browser to trigger the network login, and reconnect only after ordinary pages work. If the browser in split view does not show the login page, temporarily open it full screen or rejoin the network from the system Wi-Fi details. When the login expires, Shadowrocket may still show as connected while every request fails. Check the network portal again instead of immediately changing server parameters.

Create an independent iPhone-to-iPad comparison

When the same configuration works on iPhone but fails on iPad, connect both devices to the same Wi-Fi, select the same server, the same Config, and the same Global Routing state, then compare the results. If only iPad fails, check its system time, DNS, VPN configuration, device management, and private-network-related settings. If both devices fail, the common issue is more likely the server, subscription, or current Wi-Fi. Do not test one device on cellular data and the other on Wi-Fi, or the access networks will affect the conclusion.

If the iPad supports cellular data, test Wi-Fi and cellular data separately and check whether On Demand uses different actions for the two networks. After switching networks, wait for the system state to stabilize before testing; do not repeatedly tap Home while the VPN indicator is still changing. If only Wi-Fi fails, check the router and sign-in page. If only cellular data fails, check cellular signal, data permissions, and the corresponding On Demand conditions. If both fail, return to the server parameters, DNS, and system VPN configuration.

If you need to recheck App Store access, purchase restoration, or first-time authorization on iPad, see the iPad access guide. Compatibility information for Mac, Apple TV, and Apple Vision also follows the same App Store listing. This page focuses on troubleshooting on iPhone and iPad.