Shadowrocket Troubleshooting Guide

Connection switch won’t stay on: check system permissions first

This section covers cases where the connection switch on Home won’t stay on, turns off immediately, or gets stuck while requesting system permission on the first connection. First distinguish between a tunnel that won’t start and one that starts but cannot reach the internet. For the former, check system permissions and whether the configuration loads; for the latter, check routing and the server. A VPN icon in the status bar alone does not prove that every request is succeeding.

Check the system prompt and what you tapped

When establishing a connection for the first time, the system may ask to add a VPN configuration and confirm with your device passcode or biometrics. This authorizes the system to save a network configuration; it is not subscription verification. Review the prompt and confirm if you understand it. If you previously canceled, return to Shadowrocket, start the connection again, and watch for the prompt. Avoid repeatedly tapping the switch before responding to the prompt, or it may be hard to tell which attempt took effect.

If no prompt appears and the switch immediately turns off, open system Settings and look for the VPN and device management options. Check whether a Shadowrocket entry exists. Menu names may vary by system language and layout, so use what appears on your device. Note any existing entries before making changes; don’t delete them in bulk. For managed devices, ask the administrator to confirm network restrictions rather than repeatedly recreating configurations to work around them.

Check configuration loading and competing connections

Return to Home and confirm that SERVER contains a selectable server and that the current selection isn’t a subscription item that has been deleted. A successful import only means the information was saved; it doesn’t guarantee that every parameter is complete. After replacing a subscription, deleting a group, or reimporting Config, check that the selected item is still valid. If the issue started after an edit, restore the pre-edit backup and test again.

Next, check whether another VPN configuration is active or a system management policy is reconnecting in the background. Multiple configurations that manage network traffic can replace one another, causing the switch to flicker or the connection status to change repeatedly. For configurations you’re authorized to manage, stop the other connection and test Shadowrocket by itself. Don’t turn off every network-related system setting; that adds more variables.

Check On Demand as well. It can start a connection automatically when network conditions match, making it look as though the connection turns back on after you switch it off. During troubleshooting, note the existing conditions, temporarily disable automatic connections, and test once with the manual switch. If the manual connection is stable but the issue returns when automatic conditions are restored, focus on the condition matching rather than changing server passwords or protocol fields.

Test recovery with minimal changes

Confirm that your current network can access ordinary websites. Then fully disconnect, return to the system Home Screen, reopen the app, and test again. If the problem persists, restart the device to rule out a temporary system network issue. Wait for each status change to finish before testing. Rapidly switching the connection won’t speed up the handshake; it can instead fill the logs with interruptions and obscure the cause.

If you recently edited Config, save a copy and switch to a configuration you previously confirmed worked. A configuration parsing error and a remote connection error occur at different stages: the former may stop setup before the tunnel starts, while the latter usually occurs after it starts. Check the app’s specific error message and address that first. Don’t rewrite both rules and DNS based only on the general message “can’t connect.”

Only after making a backup and confirming that no management policy is involved should you consider removing an old Shadowrocket VPN configuration and letting the app request system permission again. This changes the system configuration record; it won’t fix an expired subscription or incorrect server details. Before proceeding, confirm separately whether your subscription URL, certificates, and manually added entries are backed up. Reauthorizing is not a complete data restore.

You’re done with this section when the switch stays on, the system no longer repeatedly requests permission, and switching it off ends the connection normally. If those conditions are met but websites still won’t load, continue to the next section. If the system still won’t save the configuration, note the full prompt, whether the device is managed, and what happens after a restart. Then review the permission guidance in Frequently Asked Questions.

Connected but no internet: distinguish routing from remote failures

A switch that stays on only shows that the local tunnel is active. Requests still depend on rule matching, name resolution, and the remote connection. First disconnect Shadowrocket and try two websites that normally work on your current network. If they still fail, check Wi-Fi authentication, cellular data permissions, or the underlying network before changing Config. Once the basic network check passes, reconnect and test the same destinations.

Use Global Routing to create a comparison

Note the current Global Routing mode, then briefly compare Config, Proxy, and Direct as needed. These are the interface labels; they determine how requests are routed, not a universal fix for every network issue. Restore the mode you normally use after testing so temporary settings aren’t left in place.

If Proxy works but Config fails, check the rule matched by the failing request, the policy it points to, and whether the configuration is actually enabled. If Direct works but Proxy fails, focus on the selected server and remote route. If access only returns after disconnecting the tunnel, don’t immediately blame the server; also check DNS inside the tunnel, system permissions, and interactions with other network configurations.

Check rule order without replacing the entire configuration

Rules are generally evaluated in the order they appear in the configuration. A broad condition placed too early may match a request that should use a different policy. Find the rule for the specific domain first, then check the fallback rules that follow it. The snippet below illustrates matching order; it isn’t a complete configuration for every environment. Before using it, confirm that the policy names match your existing configuration and environment.

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

In this example, the first rule handles a specified domain and its subdomains, the second checks geographic IP information, and the final rule catches requests not matched earlier. A broad rule near the top can prevent more specific conditions below it from being considered. To make a change, copy your current Config, adjust one relevant rule in the copy, and test the same request. This makes it easier to roll back than replacing the entire configuration at once.

If a website’s home page loads but images or sign-in fail, treat those as separate destinations. A page may request its main domain, static asset domains, and authentication domains. A rule for the home page alone won’t guarantee that related resources use the same route. Check the domains and policies used by the affected requests, then add conditions only where needed. Don’t reroute all traffic just to fix one resource.

Separate rule matching from the service response

If the app provides connection records, reproduce the issue once and check the destination domain, matched rule, selected policy, and error type. First make sure the records correspond to your test, not background refreshes. An HTTP status, authentication error, or website access denial differs from a failure to connect. Receiving a response from the remote service usually means the request reached the application layer, so continue based on the response details.

When a rule uses REJECT, actively blocking the request may be the intended behavior. If a page is missing content, check whether the affected resource matched such a rule before concluding that the server is down. If it needs to be allowed, change only the relevant condition and note why. Name resolution failures can also affect later address-based checks; see the DNS section for those cases.

You’re done with this section when you can explain which destination failed, in which mode, and under which policy. That’s more useful than a generic connection-status screenshot. If every destination times out in Proxy, continue to the server timeout section. If only Config has issues, investigate the rules. If every route reports name resolution errors, check DNS first instead of repeatedly changing server details you’ve already verified.

Server timeouts: check server and protocol details step by step

A timeout in Connectivity Test means the test didn’t get the expected result within its specified conditions. It doesn’t mean every real-world request will fail. Test methods may use different destinations and protocols, so also check actual website access. First note whether one item, several items in the same subscription, or all existing items are timing out. The scope determines what to check next; one number alone doesn’t establish availability.

Use the scope of the network issue to guide your checks

Test a destination you previously confirmed works on the current network, then repeat on another network you’re allowed to use. If the same server works on cellular data but fails on one Wi-Fi network, check that network’s authentication, access restrictions, and exit conditions. If it fails on every network, check whether the server is still running, the port is correct, the account is valid, and the server configuration has changed.

Don’t use repeated bulk tests as a substitute for diagnosis. Test one item, wait for it to finish, then check actual access. Too many concurrent requests can skew results or trigger remote limits. Record the time and network type to distinguish an ongoing failure from an intermittent one. If it only fails at certain times, keep repeat results from that period rather than assuming one successful test proves the configuration is fully restored.

Verify each field against the original server details

The server address and port must match your server details. Leading or trailing spaces, line breaks introduced during copying, or an incorrect port can prevent a connection. Don’t try random ports; use the port the server is actually listening on. If you use a domain, check that it resolves correctly. If you temporarily compare using an IP address, preserve the original TLS hostname semantics.

For items with transport-layer settings, check the transport type, path, and related host fields against the server configuration. The address locates the server; the TLS hostname verifies the remote identity; and a host field for some transports may be used for request routing. They don’t always mean the same thing. Use the same value only when the server explicitly requires it; don’t copy one value into every hostname field by default.

Certificate errors usually provide a more specific message than “timeout.” Check the device date and time, certificate validity, and hostname match. Don’t turn off certificate verification as a routine fix: it changes the security boundary without correcting the server’s certificate configuration. If you manage the server, fix its certificate and service settings. If you’re using existing service details, verify the specified parameters rather than guessing combinations.

Identify transport restrictions and server-side issues

Some protocols or features depend on UDP. A network that can load ordinary websites doesn’t necessarily allow that traffic too. If a transport fails only on certain networks, check the network differences alongside the server requirements. Don’t adjust MTU, keep-alive, or timeout settings blindly. Without evidence of a fragmentation, path, or idle-connection issue, you may compound a single problem with multiple configuration variables.

If you manage the server, check whether the service is running, its listening port, firewall settings, and server logs from the same time. A client message that the connection was closed could mean the remote server ended it or an intermediate network interrupted it; one message can’t establish the cause. Compare client and server timestamps to see whether the request arrived and where it stopped. There’s no need to include full authentication details in troubleshooting notes.

If an update changed or removed an old item, select an item with current, valid details instead of testing a local entry that’s no longer maintained. A display name in a subscription is only a label; the same name doesn’t mean the underlying parameters are unchanged. After recovery, note the failed network, error stage, corrected field, and actual access result. If the subscription still won’t refresh, check the retrieval and parsing steps in the next section.

Subscribe update failed: distinguish retrieval, parsing, and item changes

A subscription update has several separate steps: request the URL, receive a response, parse its contents, and write the items. A failure can occur at any stage. Keep the original working items; don’t delete them before trying an update, or a temporary request failure could erase usable local information. Note the specific message and distinguish a connection timeout, an unexpected status, an unsupported format, and a successful update that changed the item count.

Protect the URL and check that it’s complete

A subscription URL may contain access credentials, so treat it as sensitive information. When copying it, check for missing trailing parameters, spaces, punctuation, or line breaks added by a messaging app. Don’t post the full URL publicly or use an unfamiliar website to convert its contents. If you need to describe its structure, share only the domain type and parameter names, and redact values that could identify your account.

A URL opening in a browser doesn’t prove that it returned importable content. The browser may already be signed in, or it may show a web page, verification prompt, or access error. Use the app’s message and your subscription instructions to identify the response type. If you inspect the raw response, check only whether it has the expected format; don’t post text that may contain credentials.

Separate network errors from content errors

For a timeout or name resolution failure, check the network and DNS. For an explicit authentication error, check whether the URL has expired, the account status, and whether credentials changed. If you see a request-rate limit message, stop refreshing and wait as directed before trying again. Repeatedly deleting and readding the subscription usually won’t restore access; it can create more duplicate requests and make diagnosis harder.

If fetching a subscription requires the current proxy, and that proxy comes from the subscription that’s no longer working, the update can become dependent on itself. First check whether the URL is reachable directly on your current network and how the current configuration handles update requests. If you have another route you’ve confirmed works, use it for one comparison. Otherwise, restore basic connectivity first; one update can’t fix every network-layer issue.

For a format error, check whether the server returned a format currently supported by Shadowrocket. A web page URL, configuration file URL, and server sharing details aren’t interchangeable just because they can all be copied. Use Subscribe or the appropriate import action for the type of information you have. If you’re unsure which option to use the first time, return to Getting Started for the basic steps.

Check the items after an “update successful” message

If the update succeeds but the list is empty, check whether the response actually contained valid items or whether they were filtered. A smaller list may also mean the server removed items as expected; it doesn’t necessarily mean the client lost them. Save the current result, compare it with your subscription instructions, then check for name filters, group differences, or a temporary response issue. Don’t overwrite your only local backup repeatedly before finding the cause.

The next update may overwrite edits to items created by a subscription with the server’s information. For tests, save adjusted parameters as a clearly labeled manual item and keep the original subscription as a reference. Use distinct names so you can tell them apart and know which one you’re testing. Remove temporary copies after troubleshooting so you don’t accidentally select outdated test details later.

Confirm imported items and enabled Config separately. Subscribe updates server details; it doesn’t ensure that the rules, DNS, and policies suit your network. Even when a new item appears on Home, select a valid server, check Global Routing, and test actual access. If the list updates but the connection fails, continue to the server timeout section instead of repeatedly importing the same URL.

Build a recoverable update routine

Before making substantial changes, back up the manual information and Config you need to keep, and confirm what the backup includes. Different export methods may cover different data; having a file doesn’t mean everything has been saved. Store sensitive backups somewhere secure that you control. When describing an issue, share only the error category, time, and necessary structure with credentials removed.

You’re done with this section when updates work repeatedly, the item contents are as expected, and the selected item works in practice. If the URL itself has expired, update it through the management process for your existing service. The app purchase and subscription validity are separate. For purchase or restore questions, see Restore purchases; repeatedly buying the app won’t fix a subscription.

Slow connection: measure response time, throughput, and reliability separately

“Slow” can mean a long wait before a page opens, low throughput after a transfer starts, repeated playback pauses, or a brief interruption after switching networks. Describe the symptom first, then decide what to measure. A Connectivity Test result reflects only its specific test conditions; it doesn’t directly measure large-file transfer speeds or every website. One poor result also can’t rule out later packet loss or remote congestion.

Set up comparable test conditions

Choose a destination you can normally access and compare it on the same device, network, and at a similar time. First test basic access with the connection off, then test the current configuration, and only then try another valid item you already have. Change one condition per test, keeping downloads and syncing in other apps as consistent as possible. If you change networks, servers, and rules all at once, you won’t know what helped or how to reproduce it.

Note when the slowdown occurs. A long delay before anything starts may involve name resolution, connection setup, or the handshake. Slow transfer after data starts points more toward link capacity, packet loss, or server load. If only some page resources are delayed, their domains may use different policies. Identifying the stage narrows the search more effectively than just noting that a page took a long time to open.

Rule out local network and destination differences

Wi-Fi signal bars don’t fully reflect network quality. Distance, interference, access point load, and broadband capacity can all affect transfers. Test closer to the access point and check for heavy background traffic on the same network, then compare with cellular data. If only one Wi-Fi network is slow, focus on that network. If cellular data is also slow, check whether Low Data Mode or app network permissions are limiting the connection.

A proxy item may perform differently across destinations because the route from the remote exit to each website varies. The destination’s load, content delivery network, or account-side limits can also affect results. Check more than one destination to establish the scope, but avoid running lots of concurrent speed tests. A slowdown on one website doesn’t prove the client is generally slow and isn’t a reason to change the entire configuration.

Check rules, retries, and background activity

If Config sends some resources to REJECT or an unavailable policy, the page may wait while requests retry, making it seem like the network is slow. Check whether failed requests share a domain or policy, then review rule order. If the page loads fully under Proxy but is noticeably delayed under Config, compare the relevant rules locally. There’s no need to reroute every request indefinitely to troubleshoot one page.

Check for frequent subscription refreshes, bulk connection tests, or extensive diagnostic logging. These may not be the root cause, but they consume network and processing resources and can interfere with testing. Stop unnecessary repeated actions and observe only what you need. Don’t collect detailed logs indefinitely without a specific goal. Once you can reproduce the issue, save the relevant excerpts and restore your normal settings.

Base transport settings on the requirements of your existing server. Raising concurrency, continually shortening timeouts, or changing MTU won’t guarantee faster performance; these changes can cause more reconnects and retransmissions. Test a parameter only when evidence points to a specific issue, such as large transfers failing on one network while small requests work. Save the original value first and define what counts as improvement and when to revert.

Verify improvements with real-world tasks

If switching to another valid item you already have restores performance, retest the original under the same conditions to rule out a time-of-day change. If all items are slow on one network but work on another, investigate the local route out of that network. If every network is slow only for one destination, check the destination service and route. Repeat each comparison at least once rather than relying on a one-off success.

Consider device temperature and background tasks too. After a system update, photo sync, or extensive indexing, the device may be busy with other work, making page rendering look like a slow transfer. Observe when content finishes downloading separately from when the page finishes rendering. If the device is hot, pause demanding tasks before testing. Don’t compare small differences while running high-load tasks and charging continuously.

Finish by retesting the original task: check whether browsing stays stable, playback still pauses, and the connection recovers after a network switch. Don’t optimize for one lower test number. A few useful, explained observations are enough. If most of the delay occurs during initial domain resolution, continue to the DNS section. If slow performance comes with noticeably higher battery use, check background reconnects and diagnostics in the battery section.

DNS issues: check resolution paths and caches

DNS translates domain names into addresses used for subsequent connections. Successful resolution doesn’t guarantee that the service is reachable, and a resolution failure doesn’t mean server authentication is wrong. Common symptoms include some domains failing to load, a noticeable delay on first access, brief issues after switching networks, and different results across routes. Note the domain and exact error first, then confirm that the failure is actually happening during resolution.

Distinguish system DNS, custom DNS, and encrypted resolution

System DNS is generally provided by the current network; custom DNS changes which service handles resolution requests. DNS over HTTPS sends those requests over HTTPS, but still depends on an accessible underlying network, valid certificate verification, and a reachable service address. It isn’t a fix for every connection issue. Choose an option based on current network conditions, not just its technical label.

If an encrypted DNS service uses a domain as its endpoint, consider how its address is resolved initially and which route carries the request. If your proxy is completely unavailable, a DNS service that depends on that proxy may fail too. Map out the dependencies before choosing a reachable route for comparison. Don’t replace DNS, the server, and every rule at once; that makes the failure chain harder to trace.

Use one domain for a repeatable check

Choose a domain that repeatedly fails and compare it on the same network with the connection off and on. If it fails only when connected, check DNS settings in the current Config and the route used by resolution requests. If it fails both ways, investigate network-level resolution and the destination itself. Use exactly the same domain each time; comparing a home page domain with an image resource domain isn’t a like-for-like test.

Don’t treat successful access to a raw IP address as the only proof of a domain issue. HTTPS services may rely on the TLS hostname and virtual host routing, so entering an IP changes the request semantics and the results may not be comparable. It’s safer to check resolution records, the stage of the error, and the actual connection records together. If you need to test a specific address, preserve the hostname required by the service rather than disabling verification.

Understand how rules and resolution interact

DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD match domain conditions; IP-CIDR, IP-CIDR6, and GEOIP involve address conditions. Whether resolution occurs first, which addresses it returns, and how later rules match all depend on the configuration. Don’t assume every request is matched only once by a domain rule. Check how the failed request was actually handled.

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

The address range above is a documentation example, not a value to use for your network. no-resolve indicates that the address rule shouldn’t trigger domain resolution for matching; it doesn’t turn off DNS globally. Understanding this distinction helps prevent changing the behavior of the entire configuration just to avoid one resolution. After reviewing the example, check the relevant rules in your existing configuration rather than replacing what you currently use.

Check both IPv4 and IPv6. A network may return an IPv6 address without providing a reliable route to it, so some requests may wait before trying another address. Compare results across networks, then check address families and connection records. Don’t disable all IPv6-related settings without evidence. Changing address selection can affect other requests, so keep a way to restore the original settings.

Handle caches and configuration overrides

After changing DNS settings, existing connections and app or system caches may cause short-term results to differ from what you expect. Stop the current connection, reconnect, and test a new request; if needed, close the target app’s old session before trying again. Restart only when necessary. Don’t treat an occasional improvement after a restart as a permanent fix. Track whether the change lasts to determine whether caching or an intermittent issue is involved.

Also check for other DNS configuration profiles on the device and whether the current Config overrides settings from another entry in the app. Seeing a value on a settings page doesn’t prove that the current request uses it. Check the effective configuration and records to identify overrides. On managed devices, don’t remove network settings provided by your organization; first confirm its requirements and your permissions.

You’re done with this section when the domain resolves sensibly, the connection can proceed, and normal behavior persists after a network switch. For more detail on choosing settings, see Shadowrocket DNS Settings Explained. If resolution works but the handshake fails, return to the server parameter checks. If only specific resources are blocked, go back to the rules section instead of changing DNS you’ve already verified.

Battery drain and issues after updates: check background activity and configuration changes

Increased battery use and issues after an update are often reported together, but they need separate evidence. For battery use, look at actual activity during the observation period; for an update issue, identify what changed. A connection staying on doesn’t mean it’s constantly transferring large amounts of data, and an app’s share in battery statistics doesn’t prove it caused all the drain. Start with comparable usage conditions, then look for an ongoing issue.

Make battery observations comparable

Check similar time ranges in the system battery statistics in Settings, and note screen-on time, signal strength, whether the device was charging, and what tasks were running. Weak signal, video playback, hotspot use, and background syncing can all increase total device power use. A mostly idle period isn’t comparable to one with continuous transfers; compare trends under similar tasks.

The network extension handles traffic from other apps routed through the tunnel, so interpret system attribution in context of total traffic. You can compare activity in Data to check for unexpected high-volume transfers, but don’t assume a process is idle just because of the attribution shown. Check whether photo syncing, content downloads, or other background requests were active before changing Shadowrocket settings.

Check repeated reconnects and diagnostic load

Repeated retries after failures may cause more handshakes and network wakeups than a stable connection. Check whether the connection repeatedly restarts on a weak signal, whether tests are running too frequently, or whether On Demand conditions are triggering repeatedly. Save the original settings, temporarily stop unnecessary automatic tests and diagnostics, and observe for the same length of time. Don’t change server-required keep-alive settings just to save power; that may cause idle disconnections.

Detailed logs are useful for reproducing an issue briefly, not for indefinite collection without a goal. Logs may include domains, addresses, and other usage details, so restore normal settings and clear sensitive records when troubleshooting is done. If the device is noticeably hot, stop demanding tasks and resume comparisons once it cools. If it remains unusually hot, investigate other device and system-level causes too.

Identify which layer changed during an update

An app update, system update, subscription refresh, and remote Config update are different changes. Recall what happened after the last time the app worked and record each change separately. Check app updates in the App Store. System requirements are as listed on the App Store page. A subscription or remote configuration can change independently of an app update; timing alone doesn’t prove the app update caused the issue.

Start with a minimal retest: keep current data, use a server and configuration you previously confirmed worked, connect manually, and visit a fixed destination. If the server is unchanged but Config changed, compare rules, DNS, and policy references first. If only subscription items changed, verify their fields again. If nothing changed but system permissions did, return to the connection switch section and check authorization and system records.

When comparing configurations, focus on actual field differences rather than filenames. A remote file with the same name may have changed, while local copies with different names may have identical contents. Restoring an earlier copy can help pinpoint the issue, but doesn’t mean necessary changes should be ignored permanently. Once you identify a difference that caused the failure, understand its purpose and then correct or restore it instead of deleting every new setting.

Reinstalling isn’t the first step

Before reinstalling, check what your backup contains, where subscription URLs and manual items are saved, and which account made the App Store purchase. Being able to redownload the app doesn’t mean local configuration will be fully restored. For purchase restoration, see Restore purchases. That process restores access to the app; it doesn’t restore your service details or change remote server availability.

If you need to rebuild the setup, restore one part at a time: verify authorization and basic connectivity first, restore your own valid server details next, then restore the full rules and additional settings. This shows which step brings the issue back. Importing every backup at once and testing only tells you the problem remains; it won’t show whether the cause is an old configuration, network conditions, or background activity.

You’re done with this section when unusual activity has decreased, common tasks work, and you can repeat the observation under similar conditions. When reporting an issue, share the system type, network type, type of change, and an error excerpt with sensitive information removed; don’t publish your full backup. If the issue only occurs on iPad while the same information works on another device you own, continue to the next section and compare device network and configuration differences.

iPad checks: verify network permissions and configuration consistency

An iPad and iPhone can use the same type of server details, but their network conditions may differ. Common differences include Wi-Fi-only access, cellular data, hotspot connections, and managed network configurations. Don’t assume the app is damaged just because the same subscription works on one device. First align the network in use, selected item, and active Config on each device, then compare results.

Confirm that the underlying network is actually working

After joining public Wi-Fi, you may need to complete its sign-in page. A connected status in the menu bar doesn’t mean you can already reach external destinations. Disconnect first, complete the network’s normal sign-in process, and verify access to an ordinary website. Then connect Shadowrocket. If the sign-in session has expired, fix the network login; repeatedly updating the subscription won’t solve it.

On a device using cellular data, open system Settings and check whether the app is allowed to use cellular data and whether restrictions affecting background activity are enabled. A Wi-Fi-only device won’t have a cellular option to check. System requirements and compatible devices are as listed on the App Store page. For initial download and authorization steps, see Getting Shadowrocket on iPad; don’t infer menu locations from another device.

The same name doesn’t mean the same configuration

When comparing two devices, check the server address, port, protocol, TLS, and transport fields individually rather than comparing display names. A subscription may have updated at different times, and items with the same name may have changed. Then verify the actual Global Routing mode and Config selection. If one device uses Proxy and the other Config, different results may be due to rules rather than device performance.

A larger-screen interface may show lists and details differently. Opening a configuration’s details doesn’t necessarily select it for use; editing one server doesn’t necessarily change a different item that’s currently active. After editing, return to the selection screen and confirm which item is in effect. If the interface labels are unfamiliar, see Home, Config, and Settings: Interface Terms Explained.

After importing a backup, check exactly what it restored. Servers, subscription URLs, rule files, and system VPN authorization are separate types of information; don’t assume that copying one file completes every step. The first connection may still require system confirmation. Verify in order: data is present, the item is selected, the configuration is active, system permission is granted, and access works. Confirm each step before moving on.

Hotspots, network switching, and managed devices

When an iPad uses another device’s hotspot, its network route may differ from the route used by apps on the hotspot device itself. The hotspot device’s connection status doesn’t prove that iPad requests follow the same route. Check the iPad’s current network and connection results independently. An unstable hotspot signal, power saving on the hotspot device, or an upstream network change can also cause intermittent interruptions.

After switching between Wi-Fi and cellular data, existing connections may need to restart, and resolution results may temporarily reflect the previous network. Wait for the switch to finish before starting a new request. If it still fails, disconnect and reconnect, then compare with results while staying on one stable network. Check On Demand conditions too, so a network switch doesn’t trigger repeated connections or reconnect unexpectedly.

School- or organization-managed iPads may be subject to network policies, certificates, configuration profiles, and VPN use rules. Confirm device management requirements first; don’t delete settings you aren’t authorized to manage. If the issue occurs only on the organization’s network, record what happens there and ask the administrator to check it. Server details, system permissions, and organization policies must be handled separately; changing authentication fields doesn’t confirm permission.

Cross-check results and keep a way to restore settings

For a cross-device test, connect two devices you own to the same network you’re allowed to use, use the same valid details saved on each, and access the same destination one device at a time. If results differ, keep checking device settings; if they match but change on another network, the network route is more likely involved. Also account for concurrency limits on your existing service. The test itself could trigger a remote limit and lead to a false conclusion.

Finally, test your normal use: foreground access, recovery after briefly locking the screen, and ordinary network switching. Don’t consider one successful Connectivity Test enough. Keep a secure copy of a working Config and note whether you changed permissions, parameters, rules, or network conditions. If the issue returns, you can start from the point of change instead of repeating every step.