Shadowrocket TroubleshootingGuide

Pinpoint when the connection fails

On iPhone / iPad, Not Connected on Home means no connection is currently established; it doesn’t necessarily mean the subscription is invalid. First disable automatic reconnection conditions, then toggle the switch manually and check whether the system asks to add a VPN configuration. If you haven’t approved the permission prompt, return to it and complete the confirmation. If the switch turns on briefly and then resets, note how long it stays on and the error that follows. Don’t keep tapping the switch.

Next, disconnect the client and open a page that normally loads in your browser. If the basic network connection also fails, complete any Wi-Fi sign-in, check cellular data, or reconnect to the network. On public Wi-Fi with a captive portal, authenticate while disconnected before testing the connection. Connecting to a wireless access point confirms a local network connection, not internet access.

Check the VPN configuration and system restrictions

On iPhone / iPad, search for VPN in system settings to check whether the relevant configuration exists and whether another VPN is connected. Stop any conflicting connection, then retry in Shadowrocket. Don’t delete configurations issued by your employer, school, or device management based on the name alone. Managed devices may restrict VPN connections; ask the device administrator which connection methods are allowed. Importing a server again in the app cannot remove a system restriction.

If you previously denied permission, start a new connection and watch for a system prompt. If the system contains an obsolete Shadowrocket VPN configuration, save your in-app data first, remove only the configuration you’ve confirmed belongs to this app, then let the app request permission again. A system configuration and a server entry are separate data; verify what you’re deleting so you don’t also remove subscriptions or rules. Test a manual connection first, before restoring automatic conditions.

Separate permission issues from configuration errors

On Mac, Windows, Android, and Linux, first check that the app launches normally and that the system permissions needed to create a network tunnel have been granted. On Android, check the VPN connection prompt and app battery restrictions. On desktop systems, check the current account’s permissions and any blocks recorded by security software. Change only permissions related to Shadowrocket; don’t disable system protection or broadly loosen app permissions just to troubleshoot.

If the system allows connections but the switch still resets immediately, use a saved minimal configuration with one existing server entry whose parameters are complete. Temporarily disable custom scripts, Rewrite, and complex policy groups, then reconnect. This tests whether the error is caused by configuration loading; it does not prove the server is reachable. If the minimal configuration keeps the connection active, restore extensions one at a time until you find what causes the reset.

Check On Demand and competing connections

On Demand starts connections when system conditions are met, which can make a manually disconnected connection appear to turn back on by itself. Note the current conditions, then temporarily disable On Demand so you can make just one manual connection attempt. Also stop other VPNs, network filters, or tunnel features and test again. Restore them individually afterward. When multiple components manage network traffic at once, it’s harder to identify which one owns the permissions and routes.

If the connection drops only after locking the screen or switching networks, see the battery and iPad sections rather than continuing to delete servers. If a clear configuration parsing error appears every time the app starts, check section names, punctuation, and policy references in the configuration. Comparing the exact error with the last configuration that connected successfully preserves more useful clues than reinstalling the app, and avoids re-entering sensitive authentication details.

Set up a repeatable access comparison

On any platform, if the app says connected but pages won’t load, choose one test page and one browser and keep them fixed. Record the result while disconnected, after connecting, and after switching servers. Don’t change the network and configuration at the same time. If the page also fails while disconnected, the target or basic network may be the problem. If only one app fails, check its cache, sign-in state, and system network permissions rather than assuming all traffic is affected.

On Home, check which SERVER is actually selected; don’t rely only on whether the subscription list has refreshed. When a subscription contains multiple entries, refreshing the list doesn’t necessarily change the current selection. Then check Global Routing: Config, Proxy, or Direct. The connection switch only indicates that the network extension has started. It doesn’t mean every request uses the same server or that the expected rule has matched.

Use Global Routing to isolate rule effects

Temporarily switch to Proxy and retest the same destination. If Proxy works but Config doesn’t, focus on the configuration, rule order, and policy references. If both fail, check server parameters, DNS, and the destination service. Direct can help test the direct route, but it is still a routing mode within the client, not the same as disconnecting it. If needed, also test the basic network while disconnected.

Check rule order and the final policy

Under Config, check rules from top to bottom. The first matching rule can determine what happens next. A broad DOMAIN-KEYWORD rule or an early catch-all may prevent a more specific rule from being reached. Confirm that each referenced policy exists and that the active configuration is the one you edited, not a duplicate with the same name. After making a change, reconnect and send a new request so an existing connection doesn’t keep using its old route.

The snippet below demonstrates rule sections and ordering only; it isn’t a replacement for a complete configuration. PROXY is a policy reference and must match a policy available in your active configuration. Adjust the private-network example to match your actual network. Put FINAL at the end to handle remaining requests; don’t place it before specific rules that still need to be evaluated. Change one rule at a time and keep the original order recorded.

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

Use logs to identify where a request fails

If the app provides connection logs, first check whether the request appears, then review the matched policy, destination, and error. An empty log may mean the request didn’t use the current route, the app reused an existing connection, or logging is disabled; it doesn’t prove the software isn’t working. Close the test page and reopen it to send a new request. Hide domains and authentication details before sharing logs; the error category and timestamp are usually enough.

If the log shows a connection to the server was established but the destination still returns an error, check the destination service, account restrictions, or response from the destination—not the local VPN permission. If only one domain fails, see the DNS section. If all proxied requests time out, see the server timeout section. Before returning to normal use, restore your intended Global Routing mode instead of leaving the temporary Proxy setting in place, then verify behavior under Config.

Tell timeouts, connection refusals, and authentication errors apart

On any platform, preserve the exact error when a server times out. A timeout means the expected response didn’t arrive within the wait period; the failure could occur during DNS resolution, connection setup, handshake, or access to the destination. A connection refusal usually means the target responded but isn’t accepting connections on that port. For an authentication failure, check the user credentials first. Each error calls for a different sequence of checks. Don’t re-enter passwords for every failure or assume they all mean the network is too slow.

Check that the server address has no protocol prefix, spaces, or line breaks introduced during copying, and that the port matches the subscription or server details. Don’t combine the port or credentials from another entry just because its name looks similar. A subscription’s display name is only a label and doesn’t identify the protocol. Renaming an entry doesn’t change its protocol, address, or transport parameters; verify each field in its details.

Check protocol parameters as a set

For Shadowsocks, check the encryption method and password. For VMess and VLESS, check the user ID and any additional parameters required by the server. For Trojan, check the password and TLS settings. WireGuard keys, addresses, and peer details must not be substituted for fields from another protocol. Use the server information you already have. Don’t overwrite an existing entry with “typical” values from an unrelated guide.

Distinguish the TLS name from the connection address

For entries that use TLS, the connection address, server name used in the handshake, and transport-layer Host may serve different purposes. Replacing a domain with an IP can still fail certificate validation, even if the port is reachable. Restore the name required by the server first, then check that the device’s date and time are correct. A significantly incorrect clock can affect certificate validity checks and look like a configuration error.

Don’t use disabling certificate validation as a long-term fix. For certificate errors, check the address, name, system clock, and server certificate status first. If you only have a subscription, update it and import a separate test entry, then compare the fields. Don’t repeatedly guess values in the original entry. Confirm uncertain server-side parameters with the administrator of your existing service rather than trying random combinations until one connects.

Use cross-tests to locate network or server issues

Keep the same entry and test once on Wi-Fi and once on cellular data. Then keep the same network and test another existing, usable entry. If only one network fails, check its authentication, port, or UDP reachability. If the same entry fails on multiple networks, focus on the server status and parameters. When testing UDP-based paths such as Hysteria2, remember that browsing ordinary web pages successfully doesn’t prove that the relevant transport is working.

Connectivity Test results depend on the test method. A reachable result doesn’t mean a real-world request has succeeded. Opening a port, completing a handshake, and loading a destination page test different stages; follow up with an actual request. If server-side logs are available, compare them with the test timestamp to see whether a connection arrived, authentication was rejected, or the destination was reached. Don’t infer every cause from a generic client timeout.

First determine whether the problem is the URL or the network

When an existing subscription fails to update on any platform, first check that the URL is complete, especially the query parameters after the question mark. Line breaks in messaging apps or email, and selecting text manually, can truncate the address. Don’t reconstruct a URL from the subscription label or use a service login page as a subscription URL. Check it only on your own device: subscription URLs often contain access credentials and shouldn’t appear in public screenshots or error report titles.

Note the network and connection status during the update. If the selected server is no longer working and subscription updates are routed through it, you can get stuck in a loop that prevents fetching new entries. Try updating when the basic network is available, or use another existing, working connection path if needed. Don’t tap repeatedly; the remote service may limit request frequency. Wait, then retry under the same conditions to see whether the response failure was temporary.

Check the response, not just the success message

Receiving a response doesn’t mean it contains a parseable server list. The remote service may return an account login page, expiration notice, verification page, or error text. If the app reports a format error, check the response status and details to determine what was returned. Don’t paste the entire response into Add Server. Text appearing in a browser doesn’t mean it’s in a format supported by the selected import method.

If the response says access is unauthorized or denied, check your account status, whether the URL has been reset, and whether any query parameters are missing. If the address doesn’t exist, check whether you copied an outdated URL. For a remote server error, retry later or contact the administrator of your existing service. Updating the client can’t fix remote account restrictions, and repeatedly deleting local configurations won’t change the server’s authorization for the subscription request.

Choose an import method that matches your source

Use Subscribe for a subscription URL and Add Server to enter server details individually. Scan QR Code and clipboard detection depend on the content. A QR code may contain a single entry or just a web address; a successful scan doesn’t mean a working configuration was imported. Import from Cloud JSON isn’t a universal import option: the source data must match its expected format. Don’t switch methods just because their names sound similar.

Subscriptions, server lists, and complete configuration files serve different purposes. A subscription mainly updates entries, while a configuration file may also define rules, DNS, and policies. Importing a rules file as a server subscription may leave the list empty. Importing servers doesn’t automatically enable a new routing configuration. See Subscribe, Add Server, QR Code, and clipboard import guide to compare the import methods, then choose one that matches your source.

# Subscription URL format example only; not for connecting
https://example.com/sub?token=xxxx

Keep the existing entries and verify the update

Before changing a subscription, keep a copy of the old configuration and any entries that still work. Create a test group or duplicate and check the update there. After updating, compare the number of entries, check whether the selected SERVER is still available, and see whether any manually adjusted parameters were overwritten. Some updates recreate entries. Keep a separate record of local edits rather than assuming they’ll survive every remote refresh, and don’t clear everything without a backup.

If the list is empty after import, check whether search terms, collapsed groups, or filters are hiding entries. If only some entries are missing, compare their protocols and required fields to see whether the source omitted them or the parser skipped them. Open a newly imported entry and send a real request first. Confirm that import, selection, and connection are all working before merging the test results into your everyday configuration.

Describe what “slow” means in observable terms

On any platform, start by describing the specific symptom: a long wait before a page begins to load, a consistently slow download, interrupted video playback, or only a slow first visit. The initial wait may involve DNS, the handshake, or connecting to the server. Sustained transfers depend more on path capacity and the destination’s response. A single test number can’t explain all these symptoms, and a server’s name or location label doesn’t establish connection quality.

Use the same destination and similar content sizes. Record the baseline with the client disconnected, then test the same entry. Don’t download a large file while testing a web page, and watch for network use from system updates, cloud sync, or other devices. Record the network, time of day, and server for each test. One unusually fast or slow result doesn’t prove a setting will work over time or justify changing the entire configuration.

Latency and throughput are different measurements

Connectivity Test reflects the result of a specific test, not download speed. An entry with a fast response can still have limited capacity or congestion during sustained transfers. A connection with a slower initial response may maintain stable throughput once established. Test both real web pages and sustained transfers to distinguish a slow first response from slow transfer, rather than sorting entries by a single number.

If only certain destinations are slow, first check other destinations on the same server. The destination’s load, content delivery route, sign-in status, and app retries can all affect performance. If everything slows down at once, check the local network and server-side resources. Don’t route all traffic through the same policy to fix one destination; that can disrupt requests that already work without explaining the original issue.

Check Wi-Fi, cellular, and transport paths

On Wi-Fi, move closer to the access point and pause high-bandwidth tasks to see whether stalls change with signal strength or local network congestion. On cellular, watch for changes in signal and when moving. Testing the same entry on different networks is more useful for diagnosing the local path than repeatedly switching entries on one network. Public networks may handle certain ports or UDP differently; normal browsing doesn’t guarantee stable sustained transfers for every protocol.

If the issue affects only a UDP-based protocol or app, compare results after switching networks and check the UDP path. Don’t blindly increase bandwidth parameters. Server and client settings must match; a larger value won’t create more capacity. Adjust MTU only when you have evidence such as fragmentation or failures with requests of a specific size, and save the original value. Without a repeatable symptom, don’t apply a fixed value from the internet to every network.

Reduce the overhead from rules, retries, and diagnostics

If a simple configuration works but a complex one is noticeably slower, restore policy groups, DNS settings, custom scripts, and Rewrite one at a time to find when performance changes. Frequent health checks, retries, and extensive diagnostic logs can add requests and distort short tests. Keep the features you need, pause high-frequency checks, and retest the same destination. Before deleting a rule, check whether another feature depends on it.

If performance degrades only after extended use, check device temperature, available storage, and background tasks rather than assuming the network path is at fault. Overheating can affect browsing, decoding, and network processing. Pause demanding tasks and retest after the device returns to normal temperature. Once resolved, restore the original diagnostic level and record what actually worked. If the issue isn’t repeatable, keep the logs and test conditions rather than treating a coincidence as a reliable fix.

Separate DNS resolution from connection failures

On any platform, check DNS when only domain names fail, the first visit takes noticeably longer, or logs show a resolution error. DNS translates names into addresses; the connection then uses an address to establish communication. Successful resolution doesn’t prove the destination port is available, and a connection timeout isn’t necessarily a DNS error. Use logs to determine whether the failure occurred during resolution, connection setup, or the TLS handshake rather than treating all failures as the same issue.

Don’t rely only on “it works when I use the IP.” Many HTTPS services use the domain for certificate validation and site selection. Entering an IP in a browser may show a different page or a certificate error. Instead, compare the query result and subsequent connection error in the app logs. Check whether the same domain behaves differently on the basic network and under the current configuration, and keep using the original hostname throughout the test.

Start with the system DNS baseline and restore settings one at a time

Save your current DNS settings first. Check whether the configuration specifies multiple sources, includes a custom Host, or contains old domain mappings. The snippet below shows a troubleshooting baseline using system DNS; it may not suit every network and isn’t a replacement for a complete configuration. If switching to the baseline resolves the issue, restore custom DNS entries one at a time to find the source. Don’t replace every address at once.

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

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

With encrypted DNS, consider how the resolver itself connects. Its hostname may depend on a separate DNS path, and its requests may also be affected by routing policies. If resolution depends on a server that isn’t connected yet, while the server hostname depends on that same resolution, the dependencies can form a loop. Restore a minimal working connection first, then use settings supported by the current app to define how resolution and connections interact. Avoid adding multiple fallbacks without a clear reason.

Check rule types and when resolution happens

DOMAIN, DOMAIN-SUFFIX, IP-CIDR, and GEOIP operate on different kinds of data. Domain rules match names directly; IP rules may need a resolved address before they can match. The no-resolve option on an IP rule avoids initiating a lookup for that rule, but doesn’t mean a real connection will never need DNS. Check both the rule and whether the request already has a destination address; don’t infer the match based on a domain name alone.

Check cached results, IPv6, and local network names

After changing DNS, existing requests may still use cached results or established connections. Close the test page, reconnect the client, and send a new request. Use a cache-clearing option only if the app provides one; don’t clear all configuration to refresh DNS. If IPv4 works but IPv6 doesn’t, check that the server, system, and current network all have a consistent IPv6 path rather than adding a rule for a single hostname.

Printers, local network services, and internal domains may rely on DNS provided by the current Wi-Fi network. Switching everything to remote resolution may make them inaccessible. If external domains work again but internal names fail, check local addresses, system permissions, and the internal DNS path separately. Keep local-only conditions in place and don’t send internal names to an unrelated resolver. After restoring service, test both external pages and the local services you need.

Read system battery statistics correctly

If you’re concerned about battery use on iPhone / iPad or Android, first check the reporting period, screen-on time, and background activity on the system battery page. Battery percentage shows each app’s share of usage during that period; it doesn’t mean the client used the same percentage of the device’s total battery. Don’t compare percentages from periods with very different conditions, such as Wi-Fi versus weak cellular signal or light use versus heavy transfers, and conclude that the configuration is at fault.

A network tunnel processes the data routed through it. System statistics may attribute some network processing to a related process, but they can’t precisely separate the cost of each app’s traffic. Compare two periods with similar usage, noting the network, connection duration, and main tasks. Don’t change the protocol, switch networks, and disable background permissions all at once; even if battery use improves, you won’t know which change helped.

Check for repeated failures and retries

Repeated connection failures deserve more attention than a stable idle connection. Check whether the connection keeps switching, the subscription is updating repeatedly, or a policy group is frequently testing unavailable entries. If the logs show the same errors over and over, fix the basic network, authentication, or resolution issue before investigating battery use. Reducing diagnostic detail won’t stop failing requests and may hide useful evidence.

Make sure On Demand conditions match how you use the app. Moving between Wi-Fi and cellular or repeatedly entering and leaving coverage can trigger frequent reconnections. Temporarily disable automatic conditions and manually maintain one connection on a stable network to see whether the errors stop. Restore the conditions you need after testing rather than leaving all automatic behavior disabled. If only one Wi-Fi network causes problems, check that network first.

Address background restrictions instead of forcing the app to stay active

On Android, check whether system settings restrict Shadowrocket’s background network or battery use, especially if the connection drops only after the screen locks. Adjust the app-level option provided by the system; you don’t need to exempt every app from restrictions. On iPhone / iPad, the system manages VPN connections through its network services, so putting the main app in the background doesn’t by itself mean the connection should stop. Check VPN status, logs, and when network changes occur.

On Mac, Windows, and Linux, distinguish screen-off, sleep, and wake states. When a device sleeps, its network path may be interrupted, and an old connection may not resume after waking. First confirm that the system is back online, then reconnect the client. Don’t disable power saving across the whole device just to keep a test running. If the issue occurs only on battery power, check the power mode and any power-saving settings for the network adapter.

Isolate scripts, logging, and other background tasks

Complex scripts, Rewrite, frequent checks, and detailed long-term logs add processing work, but you can’t identify any one feature as the cause without a comparison. Copy the configuration, pause nonessential features, and test the same scenario before restoring them one at a time. Also check cloud sync, large uploads, system updates, and media processing. These tasks use network traffic and require more processing, which can increase heat and battery use.

If the device gets noticeably hot, pause demanding tasks and let it return to normal temperature before testing again. If overheating coincides with network drops, don’t run repeated stress tests or keep the device under heavy load while charging to chase a stable result. If the minimal configuration still causes repeatable problems under similar conditions, collect the battery page, system status, and redacted logs, including timestamps. Before reinstalling, check whether the same issue occurs on another network.

Distinguish app, system, and subscription updates

If Shadowrocket won’t connect after an update, first identify what was updated: Shadowrocket, the operating system, a subscription, or a configuration file. Changes made around the same time can affect different layers. Note the last network and configuration that worked, then list what changed afterward. Don’t immediately blame the app. Replaced subscription entries, reset system permissions, or changed rules may only become apparent after an app update.

Restart the app once and reconnect, then confirm the basic system network is working. If a system update still needs a restart, complete that first. If only an existing connection fails but new requests work, the network state may not have recovered cleanly. If the same error occurs on every connection attempt, keep the logs and continue troubleshooting. Don’t hide a repeatable clue with repeated restarts or clear app data without a backup.

Use a copy of the configuration to check compatibility

Save the current configuration and any older working copy, then compare sections, policy names, DNS, and additional features. Stricter configuration parsing may reveal spelling or reference errors that weren’t previously reported. Fix errors one at a time based on the message. Don’t overwrite your existing configuration with a complete file from an unknown source. First connect using one existing server and minimal rules, then restore policy groups and extensions after basic functionality is confirmed.

A subscription update may also change entry identifiers, names, or parameters and break references from policies. Check whether the current SERVER still exists, whether policy groups are empty, and whether referenced names match exactly. If duplicate entries have the same name, confirm which one is selected. Restoring an old configuration won’t necessarily restore a remote server’s previous status, so verify an actual request rather than just checking that the configuration loads.

Reinstall the app without weakening system security

If you need to reinstall, choose the right platform under Get the app. Get the iPhone / iPad version from the App Store; refer to the App Store listing for system requirements. Mac, Windows, Android, and Linux installation files are available from this site under /dl/. On Mac, check About This Mac to confirm whether your device has Apple silicon or Intel; don’t choose an installer based on the device’s appearance. A platform or architecture mismatch is not a server configuration error.

Desktop and Android installation packages aren’t code-signed, so the first launch may be blocked by the system. On Windows, after confirming the source, open More info in SmartScreen and select Run anyway. On Mac, if the system can’t verify the developer, find the app under Privacy & Security and select Open Anyway. Take these steps only for the Shadowrocket package you downloaded. Don’t disable system-wide security checks or leave protection settings weakened just to install it.

On Android, allow the browser or file manager you’re using to install apps from unknown sources in system settings. You can revoke that permission afterward if you wish. If WeChat blocks the download, use the system browser instead. On Linux, choose the deb, rpm, or AppImage package for your distribution and follow the installation instructions for permissions. See the Mac and Windows installation guide and the Android installation guide for details.

Restore settings one at a time and keep a record

Before reinstalling, make sure your backup can restore servers, rules, and required settings. Keep sensitive information only in a secure location you control. Don’t assume uninstalling preserves all data, and don’t treat the system VPN configuration as a full app backup. During recovery, import one entry and confirm it connects, then restore subscriptions and rules, and finally restore automatic connection conditions. Test the same destination after each step so you can identify exactly when a problem returns.

If the issue occurs only on a new system or with a specific combination of settings, record the shortest reproduction steps, system details, exact error, and a minimal redacted configuration. Don’t include your full subscription or real password; sharing them publicly creates unnecessary risk. While the cause is unknown, keep a copy of a configuration you’ve verified works and avoid layering on more changes. The goal is to restore functionality in a way you can explain, not to change every setting.

Compare an iPad that fails when the iPhone works

If the same subscription works on your iPhone but not your iPad, connect both devices to the same Wi-Fi, select the same server entry, and check Global Routing and the active configuration on each. Matching subscription names aren’t enough: the devices may have selected different entries, or one may be using old rules. Then send the same request on both devices and compare the actual results, not just the connection icons.

Next, check the iPad’s date, time, VPN permission, and basic network. A Wi-Fi-only iPad has no cellular network to switch to, so phone-specific switching steps don’t apply. If permitted, compare against another available network or a personal hotspot. On a cellular iPad, also check that system settings allow the app to use cellular data. Change only the network source and keep the configuration the same to see whether the issue follows the network.

Public Wi-Fi, hotspots, and local network access

If public Wi-Fi requires authentication, disconnect Shadowrocket and complete the web sign-in before connecting. If the sign-in page doesn’t appear automatically, check the connection on the system Wi-Fi page and follow the network’s normal sign-in process. A hotspot has its own upstream network conditions. A phone’s ability to reach a destination doesn’t mean the path shared with an iPad is identical; test basic access on the iPad itself.

If you can’t reach a printer, casting device, or local network service, first check the system’s local network permission, whether both devices are on the same subnet, and whether the Wi-Fi network has client isolation enabled. Then check whether the configuration incorrectly routes local addresses through a proxy. The snippet below shows common private-address rules; use the subnet for your current network. Local services may also rely on DNS provided by that 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
FINAL,PROXY

Check connections after locking the screen and when multitasking

When using an iPad again after locking the screen, first check whether Wi-Fi has reconnected at the system level, then check the client. A brief failure while the network is recovering doesn’t prove the subscription is invalid. Wait until the basic network is working, reconnect, and send a new request. If the issue reliably returns after every unlock, note the networks before and after locking, On Demand conditions, and error timestamps. Follow the battery section’s steps for background activity and reconnection instead of importing the same subscription again.

Split View, Stage Manager, and an external keyboard change how you interact with the device; they don’t sync the server selection from another device. Open Shadowrocket and the test app in turn, and confirm changes have been saved and applied. Avoid mixing up duplicate configurations across multiple editing windows. If an app keeps an old connection while multitasking, end that request and retry so the old session doesn’t make it look as though the new rules still aren’t working.

Syncing data, device restrictions, and reporting an issue

After transferring a configuration from iPhone to iPad, check server details, policy references, and system permissions on the iPad separately. Copying a file transfers its contents but can’t grant VPN permission on another device. Local domains and addresses that depend on the current network may not work on the new device. If your existing service limits simultaneous connections, disconnect the other device for comparison, then ask the service administrator about the limit. The client can’t change remote account restrictions.

If an app fails but the browser works on the same device, check that app’s network permissions and the destination it’s accessing. A successful browser test doesn’t prove every request will work. If the device is managed by a school or employer, keep its management configuration and ask the administrator rather than removing restrictions yourself. When reporting an issue, include the iPad’s network type, whether it occurred after unlocking, the selected configuration, and the exact error. Hide subscription details, user IDs, and passwords.