01 / VPN Configuration and Connection Status
Connection switch won’t turn on or disconnects immediately
Distinguish an authorization issue from a failed connection
After turning on the connection switch in Home, check whether iOS asks to add a VPN configuration. Note whether the switch does nothing before authorization or briefly connects and then returns to Not Connected. These symptoms point to different causes: the first calls for checking system authorization; the second may also involve whether the current configuration can start. Don’t delete your server list as a first step. Note when the issue occurred, which network you were using, and the full message on screen. This helps distinguish an unconfirmed system request from a server issue and makes the problem easier to reproduce.
The first time you allow a VPN configuration to be added, confirm the system prompt and complete any authentication required by your device. If you canceled the request earlier, return to Shadowrocket and try again, keeping the app in the foreground. Then search for VPN in system Settings and check whether the configuration is listed and another connection is active. Menu locations can vary by system version; follow what your device displays. Managed devices may also restrict changes through organizational policies, so check with your administrator about your permissions.
Restore the connection environment with minimal changes
Disconnect first, then check for other enabled VPNs or network-filtering features that may compete for the same connection. Pause one feature at a time and restore it after testing. If Shadowrocket connects on home Wi-Fi but not on another network, check whether that network requires a web sign-in. A connection may fail until you complete the public network’s login page. Sign in while disconnected, then try again; a login page that won’t open does not by itself mean your configuration is damaged.
Confirm that at least one server entry has all required fields and that the currently selected entry still exists. A subscription update or deleted group may have changed your selection. If the app reports an invalid configuration field, check the file you edited most recently instead of repeatedly tapping the connection switch. Temporarily revert newly added rules, rewrites, or other optional settings to a backup, keeping the basic connection settings intact. This helps distinguish a startup configuration issue from a remote connection problem without disrupting settings that were already working.
If an old Shadowrocket VPN configuration remains in system settings, back up your in-app configuration, disconnect, and then remove that VPN configuration before returning to the app to request authorization again. This only removes the system connection record; it does not restore subscription contents or guarantee that local data can be recovered. Don’t delete the app as a first step. Without a backup, reinstalling may erase server entries, rules, and diagnostic clues, leaving you with nothing to compare.
Check triggers if the switch changes back automatically
If the connection turns back on after you switch it off manually, or its status changes as soon as you switch networks, check whether On Demand is enabled. It acts according to its configured conditions, so its behavior should not be confused with a single manual switch operation. To establish a baseline, note the conditions, temporarily disable On Demand, and test one manual connection and disconnection. If the status stays stable, restore conditions one at a time, paying particular attention to conflicting actions for specified Wi-Fi networks, cellular networks, and domain triggers. See the On Demand settings guide for details.
02 / Basic Network and Routing
Connected, but there’s no internet access
Establish a baseline while disconnected
The connection icon means the system has established a VPN session; it doesn’t prove that a request to a destination has succeeded. Disconnect and try a website known to open directly on your current network, then check a second domain for comparison. If both fail while disconnected, troubleshoot Wi-Fi sign-in, cellular signal, your router, or the device’s network first. Changing Rule or server settings won’t fix an underlying network outage. Note whether all apps fail or only a browser, a specific app, or one website. The more precisely you can describe the scope, the more useful the next tests will be.
Reconnect and test the same two destinations to avoid changing both the network and test targets at once. If only one website fails, try different pages on that site to rule out sign-in status, an outage, or the app’s cached content. If all destinations fail, check that the server selected in Home is the one you expect and whether Global Routing changed during a recent operation. Check the active selection before inspecting the configuration file. Looking only at the file while overlooking the current mode can make rules that aren’t in use seem responsible.
Isolate the effect of routing with three modes
| Interface label | Description | Useful for checking |
|---|---|---|
| Config | Config | Applies the current configuration’s matching strategy; useful for checking Rule and fallback behavior. |
| Proxy | Proxy | Provides a comparison using Proxy mode to determine whether rule-based routing is involved. |
| Direct | Direct | Shows whether the destination is reachable on the current network using Direct mode. |
Use Proxy and Config as comparisons, not permanent fixes. If a request works in Proxy but fails in Config, check rule matches, policy names, and the active file. If both fail, investigate the server, name resolution, and destination connection. See the Direct mode guide for details. No mode guarantees that the destination service itself is working, and you shouldn’t assume that all traffic bypasses system-level behavior. Base your diagnosis on the actual request record.
In Config, rule order affects the outcome. Check whether an earlier DOMAIN, DOMAIN-SUFFIX, or DOMAIN-KEYWORD rule already matches the destination before checking FINAL. A broad rule near the top may prevent a more specific rule below it from ever running. This example illustrates a minimal routing structure; example.com is not a real service recommendation. Back up the current file before copying anything, and confirm that the app has selected the file you’re editing. Don’t replace a complete configuration with a teaching example that omits other required settings.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTUse request records to identify where the failure occurs
Check the app’s connection or diagnostic records for the destination domain, policy used, and error associated with a request you initiated. If it matches REJECT, confirm that the block was intended. If it uses DIRECT but the destination requires a proxy connection you already have, correct the rule’s direction. If it uses PROXY and still fails, investigate the server connection. If no matching request appears, confirm that the target app actually made a network request and isn’t still displaying a cached page. A loading spinner alone doesn’t prove that data is flowing through the current connection.
To verify a fix, test once while disconnected and once after reconnecting, using at least two different domains. If a browser works but one app doesn’t, check that app’s network permissions, cellular data access, and sign-in status; don’t immediately route every domain through the same policy. If the issue occurs only on one Wi-Fi network, switch networks while keeping other conditions unchanged for comparison. Return to the Config you need for everyday use and confirm that its rules still serve their intended purpose. Success in temporary Proxy mode alone isn’t enough: it bypasses the routing path you needed to verify.
03 / Server and Protocol Handshake
Server timeouts and connection resets
Separate test results from real-world access
A Connectivity Test result is one observation for a specific test method and destination. A timeout may mean the server is unreachable, the test destination isn’t responding, the protocol handshake failed, or the current network is affecting the transport. Check the test method and destination, then compare the result with an actual web request. A single failed test does not prove that a server you already have is unavailable. Conversely, a test returning a value doesn’t prove that sign-ins, video, or other tasks will work. These results answer different questions.
Confirm that the server address and port come from valid information you already have. Check for spaces, line breaks, or non-ASCII punctuation introduced during copying. The address field usually takes a hostname or address, not a complete subscription URL. Also distinguish the connection address, the TLS server name, and the transport Host. These can differ in some configurations, but must match the service’s requirements. Don’t set all three to the same value just to make them look consistent; doing so may break a valid route or certificate check.
Check related parameters as a set for each protocol
| Protocol | Check first | Common considerations |
|---|---|---|
| Shadowsocks | Address, port, encryption method, password | The encryption method and password must match the server settings. |
| VMess / VLESS | Identifier, transport, TLS, and additional parameters | The same address alone does not mean the configurations are equivalent. |
| Trojan | Password, TLS server name, port | The connection address may differ from the certificate name. |
| Hysteria2 | Authentication details, TLS, UDP reachability | The current network may affect the required transport. |
Compare the complete server entry with the original information instead of piecing together fields from different entries. Transport, path, Host, and TLS settings often depend on each other; changing just one can cause the connection to close immediately after it starts. For entries imported from a subscription you already have, first check the corresponding details in the subscription, then decide whether a manual edit is needed. See the protocol glossary for terms such as VMess. This table is a troubleshooting checklist, not a complete protocol configuration reference.
For certificate errors, check that the device’s date and time are correct, that any network sign-in is complete, and that the server name is accurate. Don’t treat disabling certificate validation as a general fix; it can mask an incorrect address, an expired certificate, or a name mismatch. If your existing connection details specify a particular name, verify the exact value with their source. If the error persists after checking the device time and server name, note the error type and network, and ask the server operator to check the certificate chain and listening service.
Compare networks to narrow down remote connection issues
If practical and you can avoid unexpected data charges, keep the same server and test destination while switching between Wi-Fi and cellular. If the connection times out on only one network, the cause is more likely related to that network’s name resolution, transport restrictions, or route. If it fails on multiple networks, check the remote service and authentication details. Some protocols rely on UDP; being able to access a website directly does not mean that transport is available. Don’t change the port or transport without a specific reason; the server must support the changes.
If you already have multiple working entries, compare with another known-good one in a single test. This does not establish the overall quality of a service. Repeated bulk tests can add noise and blur the difference between temporary congestion and a configuration error. When contacting the server operator, provide the protocol, the stage where the error occurs, the network type, and a redacted error message. Don’t include passwords, full identifiers, or subscription URLs in public screenshots. If authentication succeeds but only certain destinations fail, return to the Rules and DNS sections instead of repeatedly re-entering credentials.
04 / Subscribe Retrieval and Content Parsing
Subscription update failed or entries look wrong
Distinguish a retrieval failure from a parsing failure
Updating a subscription you already have involves several steps: the app resolves the subscription domain, connects, receives a response, reads its contents, and adds the recognized entries to the relevant group. When an update fails, first check whether the issue is a connection timeout, an authentication error, or unrecognized content. Each needs a different fix. Don’t delete the existing group just because the list looks empty; its entries may still work, and you may not be able to retrieve them again. First note the number of entries, current selection, and when they last worked before deciding whether to update or roll back.
Confirm that the subscription URL exactly matches the information you already have. Check whether copying truncated the end, dropped query parameters, or added chat text or line breaks. Some URLs contain access credentials, so don’t post them in public forums, online parsing tools, or screenshots. Similar-looking URLs don’t necessarily grant the same access. If the original source issued new credentials, use the complete new URL it provided. Don’t guess paths or parameters, or try to bypass an authentication prompt by appending arbitrary parameters.
Choose the next step based on the response
If you see a permission error, expired authentication, or missing resource message, check with the original source whether the URL is still valid, access permissions have changed, or usage conditions apply. Such a response may mean the request reached the server, so changing local DNS may not help. If the response is a web page rather than subscription content, it may have redirected to a sign-in page, network login page, or notice. Seeing a web page in a browser doesn’t prove that the app can parse it into server entries; consider both the content type and the app’s message.
If the issue occurs before a response arrives, test the basic network and subscription-domain resolution. Check which network path the update request actually uses rather than assuming it is identical to an ordinary web request. If the current configuration is broken, trying to retrieve a subscription through that same configuration may create a loop. Restore a valid, reachable path using conditions available to you, then update. Change one factor affecting retrieval at a time and record the result. Otherwise, changing the URL, server, and DNS all at once may fix the problem without revealing why.
If the content was retrieved but can’t be recognized, ask the original source whether its format is compatible with the import method you’re using. A Subscribe entry, a single server link, and a complete Config file aren’t interchangeable. Putting a configuration file URL in a server subscription field may cause parsing errors or incomplete results. See how to import an existing subscription or server details. Keep a backup of the original content and don’t edit its encoding to troubleshoot; that may turn the original issue into a new format error.
Restore entries missing after an update
After an update, compare entries within the same group rather than looking only at the entire Home list. Filters, collapsed groups, and sorting changes can temporarily hide entries. Confirm that they’re actually missing, then check whether the subscription itself changed. Subscription sync generally follows data provided remotely. Whether local names or edits are preserved depends on the import and management method, so don’t rely on a subscription group as the only backup of manual changes. Store important settings securely elsewhere.
If the currently selected server stopped working after an update, explicitly select an entry that still exists and has complete settings, then test the connection. A changed selection doesn’t mean the entire app has stopped working. After recovery, check for duplicate groups and automatic updates still pointing to an old URL, so the next update doesn’t overwrite the content you expect. When contacting the original source, share only a redacted error and approximate time. If the full URL needs to be checked, use a private channel agreed upon by both parties, not a public log that exposes access credentials.
05 / Throughput, Latency, and Destination Differences
Connected, but speeds are slow
Make “slow” a measurable, comparable symptom
Slow speeds can mean a long wait before a page first opens, low sustained throughput, repeated video buffering, or occasional delays in interactive requests. These symptoms may have different causes. Note the app, destination domain, network type, and when the delay occurs, then run a small number of tests against the same destination. Connectivity Test values primarily reflect their own test conditions, not real-world throughput. An entry that responds quickly in a test may still be congested on the route to a specific service, so don’t choose one for everyday use based on a single test alone.
Disconnect and check whether the basic network is stable. Look at Wi-Fi signal strength, router load, and whether other devices are transferring large amounts of data. Cellular performance also depends on signal, location, and network handoffs. Keep the device in the same place and on the same network while testing, and pause sync tasks that use substantial bandwidth. If the basic network is unstable, restore a reliable connection before assessing the proxy route. Otherwise, changing wireless conditions may explain the varying results, with no connection to the setting you just changed.
Separate slow name resolution from slow data transfer
If a domain takes a long time to open initially but transfers data steadily once loading starts, check DNS and connection setup first. If text appears quickly on every page but images and video remain slow, investigate the destination route, remote load, and actual routing result. When comparing different kinds of pages, remember that they contain different amounts of data; a lightweight page opening quickly doesn’t mean everything is fixed. Browser caching can also affect perceived speed, so note whether a test used a fresh request or cached content.
In Config, check whether slow requests use the expected policy. Some pages contact several domains. If the main site uses PROXY but its resource domains use DIRECT, the text may appear while images keep loading. Use request records to identify the resource domain that failed before deciding whether to add a rule; don’t broaden DOMAIN-KEYWORD matches just for convenience. Overly broad rules can affect unrelated destinations and send more traffic along an indirect route. See the DOMAIN-SUFFIX and FINAL examples for rules targeting specific websites.
If both Proxy and Config are slow, keep the destination the same and compare with another valid entry you already have on the same network. The result only indicates a difference in the route at that time; it doesn’t establish long-term performance. Server load, destination rate limits, and cross-network routes can all change. Repeated high-volume tests consume data and affect other requests, so collect enough information with a limited number of tests. Before continued testing, check your data allowance so troubleshooting doesn’t become a new source of bandwidth use.
Don’t replace evidence with random setting changes
If connections stall for a long time or large transfers fail while small requests work, further checks of the route and transport may be useful. Don’t blindly adjust MTU, concurrency, or protocol settings. These parameters have network and server constraints, and changing them in either direction can cause side effects. Keep the default or a known-good value and note whether the issue occurs only on a particular network. Make one change at a time only when you have a specific error clue or a recommended value from the operator, and keep the original value so you can restore it. Don’t copy settings from unrelated situations.
Device heat, low battery, background sync, and the destination app’s own decoding can make a page feel slow even when the network isn’t the cause. Try similar content in another app to tell network delays apart from a sluggish interface. If only one destination is consistently slow while others work, consider the destination service as well rather than making endless client-side changes. After a fix, test common pages, sustained transfers, and a network switch. Confirm the improvement isn’t just temporary caching, then restore your everyday configuration and background tasks.
06 / Domain Resolution and Destination Address
DNS resolution failures and websites that won’t open
Why successful resolution doesn’t guarantee access
DNS translates a domain into an address needed to connect, often before the rest of a request. A server test can return a result while a website still won’t open, and DNS may be involved, but that alone doesn’t identify the cause. The test and website may use different destinations or resolution paths; a web request may also fail later during TLS negotiation or while fetching resources. Check the error from one failed request first. A domain that returns no result or times out during resolution is a different case from a connection failure after an address was returned. Changing DNS settings alone won’t fix the latter.
First determine whether the problem affects one domain or many. If just one domain can’t be resolved, consider an issue with its records, a typo, or a temporary outage. If several unrelated domains fail, check the current DNS settings and network. Don’t test by entering a server address directly in the browser instead of the full domain; HTTPS destinations generally rely on the domain for certificate validation and site selection. A failed address or certificate warning doesn’t prove that the original domain resolved correctly, and it isn’t a reason to disable certificate validation.
Check the effective values in General and Host
Check dns-server in the General section of the active Config file, not just in a different backup file. The example below shows basic syntax for using the system’s DNS source; it isn’t a recommendation for every network. system follows the resolution environment provided by the operating system, which can differ on public Wi-Fi, home routers, and cellular networks. If you don’t verify the active file and connection after making a change, you may think the new setting had no effect when requests are actually still using an old configuration or cached result.
[General]
dns-server = system
[Host]
localhost = 127.0.0.1Check the Host section for a static address assigned to the destination domain. A static mapping overrides the address normally returned by DNS, so changing dns-server may do nothing if the mapped address is stale. Save the original before temporarily removing a suspect mapping, and check whether it’s needed for internal access. Don’t copy someone else’s address into Host as a “permanent fix.” Destination addresses can change or depend on the service region. See the Config file sections guide for a full explanation of the structure.
When using encrypted DNS, remember that the resolver itself must also be reachable. If its initial hostname lookup, connection path, or certificate requirements aren’t met, the resolution chain may not start. Don’t add several DNS sources in the hope that more will be more reliable. Start with one trusted source known to be reachable on the current network, and understand whether its requests need to go through a proxy. Mixing sources can also return different addresses for the same destination and make results vary between tests. Establish a simple, predictable baseline first.
Account for caching and address families when retesting
After changing DNS settings, use the app’s available method to refresh the relevant cache, or disconnect and reconnect before making a new request. Browsers and destination apps may also keep existing connections, so refreshing a page alone may not trigger a new lookup. If IPv4 and IPv6 results differ, check which address family the connection actually used and whether the current network can reach it. Don’t permanently disable an address family because one test failed; first determine whether the problem is limited to the current network or a specific destination.
If resolution returns an address but the request still fails, check the connection path, TLS name, and Rule match. If a request works in Proxy but DNS fails in Config, check whether DNS and destination traffic are using separate, unavailable paths. After restoring service, test several different domains, reconnect, and try again so you aren’t relying only on a successful cached result. See the DNS troubleshooting guide for more detail. When sharing feedback, include the error type but remove records containing private browsing history or authentication details.
07 / Active Time and Repeated Connections
Increased battery drain and device heat
Compare battery use under similar conditions
The app’s percentage on the system Battery screen is a statistic for the selected time range, not a fixed measure of power use in every situation. Usage time, screen-on time, network conditions, and other app activity all affect the share. Compare periods with similar usage and the same network, and check for large transfers, repeated connections, or persistent device heat. A higher percentage alone doesn’t prove an issue; reduced use by other apps can increase the share of the total for the same activity.
Note whether the battery change began after a configuration edit, subscription update, network switch, or app update. Separate screen-on use from standby. If network activity continues during standby, check whether photo sync, file transfers, media playback, or other tasks are using the connection. The client processes data for other apps, but those background tasks may be the actual source of traffic. Pause clearly high-volume activities first and see whether the connection stays stable. Don’t infer the cause of all battery use from one system label.
Check On Demand and repeated network switching
Switching back and forth between weak Wi-Fi and cellular may trigger repeated handshakes and reconnections. If On Demand rules specify different actions for the two networks, each switch can also change the connection state. For comparison, stay on one network in a location with a stable signal, note the automatic triggers, and temporarily disable them. Then see whether standby activity changes noticeably. Restore any rules you need after testing. Don’t permanently remove connection conditions you rely on just to reduce battery use; first identify which network or rule combination is triggering repeated connections.
Repeated authentication failures or remote connection resets may cause the device to keep trying to reconnect. Resolve the error using the server timeout section before assessing battery use. Locking the screen won’t fix incorrect authentication details. Check whether the records show the same error repeatedly over a short period and whether it happens after switching networks. A consistent retry pattern is more informative than a single battery change. If needed, stop the current connection to avoid repeated attempts when success isn’t possible, and keep a short redacted record.
Avoid extra activity caused by troubleshooting
Bulk Connectivity Tests, frequent automatic subscription updates, and continuous detailed logging can increase network and processing activity during troubleshooting. Enable only enough diagnostic detail to locate the problem, then restore everyday settings when you have the information you need. Don’t run several test loops at once to monitor battery use, or repeatedly reload large numbers of pages. If the issue goes away after pausing these temporary tasks, adjust their frequency before changing protocol settings that were already working. Evaluate diagnostic activity separately from everyday connection use.
Device heat can also affect performance, making pages seem slow. Compare results after stopping high-volume tasks and letting the device return to its normal temperature. Charging, screen brightness, and ambient temperature also affect what you observe, so keep them as consistent as possible. Don’t infer that a specific component is damaged from how warm the case feels. If the issue continues when disconnected, check other activity on the system Battery screen and follow the device’s guidance. Not every battery problem is caused by a network configuration.
To verify a fix, check one normal-use session and a standby period under similar conditions. Success doesn’t mean the battery percentage must fall to a particular number; it means repeated reconnections have stopped, background tasks behave as expected, and the same usage no longer causes unusual heat. When sharing feedback, include the time range, network type, whether On Demand was enabled, and whether you ran extensive tests. Don’t publish complete traffic logs, which may contain visited domains, server details, or private activity. Keep only the necessary redacted excerpts around the time of the issue.
08 / Configuration Rollback and Isolating Changes
Connection problems after an update
Identify exactly what was updated
“It stopped working after an update” could refer to an app update, system update, subscription sync, or a remotely replaced Config file. Don’t treat these as the same change. List recent actions in chronological order and note what had already changed when the problem first appeared. If the app and subscription were both updated on the same day, that doesn’t establish which caused the issue. Keep the current error, an original configuration backup, and reproducible steps. Test the connection switch, server, and destination separately before restoring everything and losing clues.
Get and update the app only through the App Store. To confirm the product, follow the authenticity verification guide and check the developer name, Shadow Launch Technology Limited, the official icon, and app ID 932747118. Check the App Store listing for compatibility and system requirements. Repurchasing is not a network troubleshooting step; purchase records and local server settings are managed separately. Reinstalling is not a configuration backup. Before doing so, make sure you can recover your existing subscription, server details, and rule files.
Return to a known-good minimal configuration
Restart the app and check the current selection in Home, then verify that Global Routing and Config are still as expected. If the basic connection works but Config doesn’t, compare it with a known-good file you saved. Preserve section headers, field locations, and rule order; don’t copy back a few isolated lines into a new file. The snippet below is for checking rule structure, not restoring a complete configuration. Interpret the example domain in light of your own destination; it doesn’t replace other settings required by your original configuration.
[General]
bypass-system = true
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYIf you recently added URL Rewrite or another optional feature, disable one at a time using a backup, then retest the same destination. Check optional features separately from the basic connection. If a basic request already fails, testing rewrites at the same time only adds variables. Restore features one at a time and check which change affects behavior. See the configuration file structure guide for the roles of General, Rule, Host, and URL Rewrite. Don’t use the syntax for one section in place of another.
If the issue started after a subscription update, compare the old and new entries’ protocol, address, port, and transport fields. Check whether the selected entry was removed. If only the list order changed, select the intended entry again. If the remote content itself changed, contact its original source instead of reverting every new setting to an old value. A remote Config update may also change rules and DNS settings, so track server subscription updates separately from Config file updates. You can choose the right backup only after identifying what changed.
Verify and report issues after a system change
After a system update, check whether the VPN configuration is still present, system authorization needs to be confirmed again, or managed settings have changed. Restarting may clear some temporary states, but it won’t fix an invalid field. If the same configuration fails on multiple networks, reproduce the issue with minimal conditions. If it fails on only one network, check that network’s sign-in, DNS, and transport. Don’t reset all device network settings at once; doing so may remove other saved information without fixing the underlying configuration issue.
When reporting an issue, organize the details as: action that triggered it, expected result, actual result, conditions for reproducing it, and factors already ruled out. You may provide the version shown in the app in a private report, but don’t assume an update must have fixed or caused the problem. Include only necessary redacted log excerpts and remove credentials and full subscription URLs. After recovery, save a new known-good configuration and then restore automatic updates you need. If the issue can’t be reproduced reliably, describe it as intermittent; one successful retry doesn’t prove it’s permanently fixed.
09 / iPad Networking and Multitasking
iPad Connection and Recovery Guide
Keep purchase restoration separate from configuration migration
To restore access on an iPad, first check that the App Store is signed in with the account that has the relevant purchase, then follow the iPad access guide. Check the App Store listing for system requirements and purchase compatibility. Being able to download the app again doesn’t mean your server entries and Config have automatically appeared on the new device. Purchase history and user configuration are separate. After opening the app, check that your existing subscription, server details, and files are all present before connecting. Don’t assume a failed connection means the restoration process went wrong.
To migrate configuration from another device, import a valid backup you saved or re-enter information you already have. Check the selected server, Global Routing, and current Config. Matching group names don’t guarantee matching contents, so check the address, authentication settings, and FINAL at the end of the rules. If you imported only a server list and not the corresponding rules file, behavior in Config may differ from the old device. Establish a basic connection using the quick-start guide before restoring complex rules; it’s easier to find missing items than when migrating every optional setting at once.
Multiple windows don’t mean multiple independent connections
Split View and multiple windows on iPad make it convenient to view the guide and app side by side, but the system network connection still needs to be understood as a whole. Switching, resizing, or minimizing a window doesn’t create a separate VPN session. For troubleshooting, keep one browser window and one test destination fixed. Another window may show a cached page and create a misleading impression. If one window works and another doesn’t, compare the domains, sign-in status, and whether each actually refreshed, then check the request records. Don’t conclude that routing rules failed based only on a difference between windows.
Some iPads have Wi-Fi only, while others also support cellular. On a Wi-Fi-only device, compare using another wireless network you’re authorized to use, keeping in mind that a personal hotspot can also change the upstream network. Keep the server and test destination the same, and note how the iPad connected. Public Wi-Fi may require a sign-in page first. If access fails after unlocking the screen, confirm that Wi-Fi is still connected before checking VPN status; don’t immediately delete the system VPN configuration.
Screen lock, background tasks, and managed devices
A download pausing after the screen locks isn’t necessarily a connection failure; the destination app’s background execution rules may affect whether it continues. Unlock the device and make a new, small request in a browser to check whether the connection works. If the new request succeeds but the old task hasn’t resumed, check that app’s task status. If all new requests fail, check On Demand, network switching, and server reconnection records. Don’t treat one paused file transfer as a system-wide outage or keep the screen lit to hide the cause.
iPads managed by a school, employer, or another organization may have restrictions on VPN settings, certificates, network filtering, or permissions to make changes. Check whether the system indicates that the device is managed and ask the administrator what use is allowed. Don’t remove management settings or certificates you don’t understand; they may be required for work or device access. On a personal device, record the existing system configuration and understand the impact before making changes. If you can’t add a VPN configuration, return to the authorization section; changing server authentication settings won’t fix it.
If an iPad behaves differently from another device on the same Wi-Fi, compare each device’s system time, DNS, current Config, and selected server. The same wireless network doesn’t rule out differences on the device. Browser privacy settings, saved network conditions, and target app permissions can also affect the request path or result. Test the same destination using the same action, and use the app’s request records to identify differences where possible. Comparing home pages in two different apps is unlikely to give you a reliable network diagnosis.