01 · System permissions and connection lifecycle
The connection switch won’t turn on or turns off right away
First note when the connection fails: does nothing happen when you tap the switch, does the system permission prompt appear but not complete, or does the connection drop immediately after starting? Each points to a different place to check. The switch starts the system network extension; it doesn’t confirm that a server can forward traffic. Keep the connection on before testing a server or checking webpages. Temporarily turn off On Demand so automatic connection attempts don’t interfere with manual checks.
Complete system authorization before checking your configuration
The first time you connect, the system may ask permission to add a VPN configuration. Confirm that the request was triggered by opening Shadowrocket, then follow the system prompts to authorize it and verify your device identity. If you dismissed the prompt, return to the app, try connecting again, and see whether it appears. On a device managed by a school or employer, management policies may restrict these permissions. Changing server settings won’t resolve that restriction; first confirm that the device allows the network configuration to be added and used.
Open system Settings and look for the VPN settings. Check whether a Shadowrocket configuration is listed and whether another network connection is active. Stop any other active connection, then try Shadowrocket again. Avoid changing multiple network components at once. Don’t rely on the status bar alone to confirm that the connection is working: some status indicators may not appear in every situation. Check both the connection status in the app and the system VPN page.
Distinguish a configuration loading issue from a server connection issue
If authorization is complete but the switch immediately turns off, check whether the selected configuration in Config opens correctly. Pay particular attention to fields you just edited, incomplete imports, and policy names that may no longer exist. Restore a saved copy from before the changes rather than layering on more settings. If the connection stays on after restoring, focus on what changed in the configuration. Don’t rush to delete the app or recreate all your server entries.
Also confirm that Home contains an available server and that the intended server is selected for the mode you’re using. An empty server list, a group pointing to a missing item, or a configuration referencing a deleted name can cause unexpected results. For a basic test, select a server whose settings you’ve already verified. “Basic” means reducing configuration dependencies—not disabling certificate validation or permanently sending all traffic through the same policy.
Follow a system recovery sequence you can undo
Turn off the connection normally, leave the current editing screen, then reopen the app and try again. If it still fails, restart the device to reinitialize the system network extension. Save any configuration changes that haven’t been written before restarting. If the problem only occurs after switching networks, test on a stable Wi-Fi connection first, then check mobile network access separately. If the device is low on storage, free up enough space to save configurations and diagnostic logs—but don’t delete configuration files without checking them first.
Only consider removing the corresponding system VPN configuration and letting the app recreate it if you’ve backed up your configuration, can reimport your server details, and have confirmed that the system configuration is damaged. Before doing so, turn off On Demand and disconnect to avoid an automatic connection attempt interrupting the process. Don’t start with Reset Network Settings: it affects other network settings on the device and may not fix incorrect parameters. After authorization succeeds again, first confirm that the switch stays on, then continue to the next section to test connectivity.
02 · Network basics, routing modes, and rules
Connected, but webpages or apps can’t access the internet
Turn off Shadowrocket and open a webpage that normally works directly to confirm the device has internet access. Public Wi-Fi may require you to sign in first, and a router may connect to your local network without providing internet access. Changing proxy settings won’t help until the underlying network is working. Once you’ve signed in or fixed the network, turn Shadowrocket back on and test the same webpage again, keeping the timing and test target as consistent as possible.
Use Global Routing to narrow down the issue
In Global Routing, Config, Proxy, and Direct help separate different paths during troubleshooting. Config follows the rules in the current configuration; Proxy tests the selected proxy path; Direct shows how a direct connection behaves. These are not network quality ratings, and none guarantees that every destination is reachable. Note the original mode before testing, change only this setting, and be clear about which path you’re checking. Remember to restore it afterward.
| Mode | What to check | How to interpret the result |
|---|---|---|
| Config | Rules, policy references, and final match | If only this mode fails, check the rules and configuration first. |
| Proxy | Selected server and proxy path | If it fails, check whether the issue is server communication, DNS resolution, or the destination’s response. |
| Direct | Direct connection path | Success doesn’t confirm that the proxy path or proxy-side DNS is working. |
If Direct can open the test webpage but Proxy fails, check the selected server first; don’t immediately change all your rules. If Proxy works but Config fails, check which policy the destination matched under Config. It may have matched an earlier REJECT rule, or a destination that needs a proxy may have been sent to DIRECT. If all three modes fail, revisit the underlying network, DNS, and system connection. One failed webpage doesn’t prove that the subscription is unusable.
Check rule order and the actual destination
Rules are generally evaluated in order, so a broad rule near the top can take precedence over a more specific one farther down. The snippet below illustrates putting specific conditions first and using FINAL at the end; it isn’t a recommendation to replace your existing configuration. PROXY must refer to a policy that exists in the current configuration. If your setup uses a different policy name, check the actual definition. Edit a copy first, then use the records to confirm which rule matched instead of guessing from the text in the file.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYA webpage usually requests content from multiple domains. The page itself, images, sign-in endpoints, and media may each connect to different destinations, so “the homepage loads but sign-in fails” can still point to inconsistent routing. Check the connection records for the failed request, identify its domain and matched policy, then decide whether a rule needs to change. Don’t send large groups of unrelated domains to the same policy just to save time, and don’t assume every request uses the same address based on the page title.
Rule out app sessions and local network issues
After switching modes, an existing long-lived connection may keep using the previous session. Leave the relevant page in the test app and start a new request. If needed, disconnect normally and reconnect before comparing results. If the issue occurs in just one app, test the same service in a browser to separate app cache or sign-in state from the network path. A service outage, authentication failure, or access restriction can also cause a page to stall. Other webpages working doesn’t prove that the rules are correct.
When accessing a router’s admin page, a local device, or network storage, check that the local subnet isn’t being routed through the proxy by mistake. Don’t copy an example subnet; use the addresses assigned by your current network. If the connection records show the right rule but a domain still won’t resolve, go to the DNS section. If the domain resolves but the server path can’t be established, go to the connection timeout section. Following this decision path helps avoid repeatedly changing rules, subscriptions, and system settings.
03 · Endpoints, authentication, and transport
Server connection timeout or Connectivity Test failure
A timeout means only that a particular test didn’t finish within the allotted time; it doesn’t identify which field is wrong. First identify what the test checks: a port connection, a webpage request through the proxy, a DNS query, or the in-app Connectivity Test. These test different layers. A successful port connection doesn’t confirm that authentication or traffic forwarding works, and a failed webpage test may simply mean the test destination is temporarily unavailable. Note the test target and error message; repeatedly tapping the test button is less useful.
Start by checking the server address and port
Open the relevant server entry and compare Address and Port with the details from your service provider. Address usually takes a hostname or IP address; don’t paste in a full webpage URL, path, or extra spaces. Port must match the server’s listening port—don’t guess based on the protocol. If the address is a hostname, first confirm that it resolves. If it doesn’t, changing Password or transport settings is unlikely to help.
Next, check the protocol and authentication fields. Trojan’s Password, the identity fields for VMess or VLESS, and the encryption method and password for Shadowsocks serve different purposes; don’t interchange them. A successful import means the text was recognized, not that the remote settings were verified. When entering details manually, check for line breaks, leading or trailing spaces, and full-width punctuation. Save your changes, reselect the entry, and confirm that your test is using the one you just edited.
| Parameter | What to check | Common misconception |
|---|---|---|
| Address / Port | Hostname, listening port, and address reachability | Assuming that a successful DNS lookup means the port is available. |
| Authentication | Identity and password fields required by the protocol | Assuming that saving the entry means authentication is correct. |
| TLS | SNI, certificate name, and device time | Treating disabled certificate validation as a routine fix. |
| Transport | Transport type and settings such as Host and Path | Checking only the protocol and missing transport settings. |
Check TLS and transport settings separately
When using TLS, Address and SNI may differ: Address determines which endpoint to connect to, while SNI is used for server name indication and certificate verification. Enter values based on the settings for your server; don’t put an arbitrary domain in SNI. Check that the system date, time, and time zone are correct—a clock that’s off can cause certificate validation to fail. If the error says the certificate name doesn’t match or the certificate has expired, check the remote server configuration. Don’t use certificate verification bypass as a long-term fix.
If the server also requires specific transport settings, check the corresponding Host, Path, and transport type. A leading slash, capitalization, or extra content in Path can affect routing; “close enough” isn’t enough. For UDP-based connections such as Hysteria2, check whether the current network allows that traffic. A working TCP webpage doesn’t prove the UDP path is working. Comparing the connection on another network you’re allowed to use is more informative than changing several protocol fields at once.
Use cross-tests to separate local and remote issues
Test the same server entry on Wi-Fi and mobile networks. Then, on the same network, test another server entry you already have and have confirmed works. The first comparison helps identify network-related differences; the second helps identify a problem with a particular endpoint. Don’t change networks, servers, and configurations all at once, or you won’t know what fixed the issue. If the same endpoint fails on different networks while other existing endpoints work, ask your service provider to check the endpoint and confirm whether its settings have changed.
When contacting your service provider, share only the redacted error type, network environment, and test time. Don’t disclose complete authentication details. If the port connects but webpage requests fail, continue checking authentication, transport, and the destination’s response. If all your existing endpoints fail only on one network, troubleshoot that network and its router first. For a field-by-field explanation of Trojan, see the Trojan settings guide instead of guessing at values.
04 · Fetching, parsing, and local lists
Subscription update failed or no servers appear after import
Subscription updates involve several distinct steps: connecting to the subscription URL, receiving a response, identifying its contents, parsing the entries, and updating the local list. An empty list doesn’t necessarily mean the URL is unreachable. The server may have returned a sign-in page, an error message, or content the current import method doesn’t recognize. Note the error shown during the update, then check the URL and response. Don’t keep deleting the existing list: old entries may still work and help you compare what changed.
Tell a subscription URL from a single-server share link
Check the complete subscription URL with your own service provider. Make sure you haven’t omitted query parameters, the final character, or any required authentication details. A subscription URL and a single-server share link serve different purposes: the former usually retrieves a group of updatable entries, while the latter describes one connection. Pasting a single-server link into the subscription update field, or using a configuration file URL as a server subscription, may fail. Choose the import method based on the content type, not how long the URL looks.
Also check for notes, quotation marks, spaces, or line breaks in the copied text. Some sharing actions copy the title along with the URL; keep only the actual address. Subscription credentials are sensitive: don’t paste them into public URL-checking sites or post them in a discussion asking someone else to test them. If you need to describe the issue, share the error category and remove all identifying information from the URL—not just a few characters.
Determine whether the request failed or returned the wrong content
If the error mentions hostname resolution, a connection timeout, or TLS, first check that the subscription domain resolves and the request can be made. Whether subscription updates go through a proxy may depend on settings and configuration; being able to open a webpage doesn’t prove the update uses the same path. If the current server is unavailable and the subscription request depends on it, the update may fail in a loop. Test the request on a network where it’s permitted and available, and keep your existing configuration. Don’t combine “switch servers” and “fetch subscription again” into one step.
If the error says access is denied or the resource doesn’t exist, first check whether your service provider changed the URL, whether authentication has expired, and whether your account can still access it. If the request is redirected, confirm that the final response is subscription content, not a sign-in page. Even if a browser shows a page successfully, it may only be displaying an error message. Conversely, a browser downloading or showing text doesn’t mean every server entry in it can be recognized by the current import method.
If the list is empty, check filters, parsing, and overwrites
If content was received but no entries appear, first clear any search filters on Home, expand the relevant group, and make sure you’re viewing the subscription you just updated. Compare the number and names of entries before and after the update. Determine whether nothing was parsed or only some protocols or fields went unrecognized. If the subscription includes filters, check whether they exclude every entry. Don’t keep importing the same URL just because one group looks empty; that can create confusing duplicates.
A subscription update may regenerate the server entries it manages, overwriting manual edits the next time you update. If you need to keep personal changes, first check how the entries are managed and save a copy. To separate a content issue from a network issue, test with a complete server entry you already have by adding it manually. If the manual entry works but the subscription consistently fails to parse, focus on the subscription format and response—not system VPN authorization.
To review the available import methods, see subscription and single-server import methods. If you’re not sure what type of content you have, see the share link format guide. After recovery, note one successful update and set a reasonable update frequency. Don’t use frequent retries to hide a persistent request error, and don’t treat the update button as a server connectivity test.
05 · Response time and sustained transfers
Connected, but pages load slowly or transfers are unstable
Break “slow” into three stages: waiting for the first response, loading webpage resources, and sustaining a transfer. A long delay before any response may involve DNS, connection setup, or a handshake. Text appearing before images finish loading may point to different paths for different destinations. If things start normally but slow down during a transfer, consider congestion, packet loss, or server load. Identifying when the slowdown occurs is more useful than looking at one latency number.
Set up a consistent comparison
Choose a destination where the problem is easy to reproduce. Test it two or three times at similar times, on the same network and device, using the same server. Pause large system syncs, heavy transfers on other devices, and unrelated background tasks during testing. Webpage content can change, so use the same page and steps whenever possible. Don’t run several high-traffic tests at once: they compete for the same connection, so you’ll measure the interference rather than typical performance.
Next, compare Wi-Fi with mobile data, or test another server you already have—changing one condition at a time. If every server is slow only on the same Wi-Fi, check the router, wireless signal, and network load. If only one server is slow, focus on that endpoint and its route to the destination. If just one destination is slow, consider the service’s own response and content delivery instead of blaming overall client performance.
Latency, bandwidth, and real-world performance are different measures
Low latency often helps with interactive tasks and short requests, but it doesn’t mean sustained downloads will be faster. Higher latency doesn’t necessarily mean bandwidth is insufficient. In-app tests also depend on the test address, request type, and timeout threshold. Judge performance by the task you’re trying to do: can you sign in, does the video keep buffering, or does a file transfer stop? Don’t switch servers repeatedly based on one test; switching can end sessions and add the cost of a new handshake.
Global Routing also affects test results. Under Config, only some resources may use the proxy; under Proxy, more requests go through the selected path. Results aren’t comparable unless you note the mode used. Check connection records for resources that repeatedly fail, especially sign-in endpoints, media segments, and DNS requests. Repeated retries can make an entire page seem slow when the underlying issue may be just one rule or an unreachable domain.
Troubleshoot the connection path instead of changing settings at random
A weak Wi-Fi signal or frequent switching between access points can reduce throughput and interrupt connections. Test closer to the access point and check that the device isn’t automatically switching between networks. If the network requires sign-in, an expired session can also cause repeated background failures. For UDP-based protocols, check separately for restrictions or packet loss on the current network. Another protocol working only confirms that its transport path is available; it doesn’t prove all traffic conditions are the same.
Don’t change MTU, concurrency, or advanced protocol settings without a reason. An MTU mismatch can affect transfers, but similar symptoms can also come from the destination, wireless link, or remote congestion. Only adjust settings one at a time if the issue is reproducible and you have a clear configuration requirement. Save the original value first, then compare. If there’s no consistent improvement, restore it. Otherwise, you may end up with several settings that mask one another and make future troubleshooting harder.
Finally, check device temperature, battery status, and local storage pressure. Long transfers, screen recording, and other intensive tasks can affect overall device performance. Stop unrelated tasks, let the device return to normal operating conditions, then repeat the same test. If only the first visit is slow and later visits work normally, check DNS caching and connection reuse. If only sustained transfers are unstable, focus on network fluctuations, remote server status, and records of interrupted sessions.
06 · Name resolution and connection paths
DNS resolution fails or only some domains won’t load
DNS converts domain names into addresses needed to connect. It’s related to which server you connect to and which routing policy you use, but it’s a separate step. If a domain doesn’t resolve, the request may not have reached the connection stage. Even after an address is returned, routing, the port, or the destination’s response can still fail. Check whether the error in the records is about resolution, connection setup, or TLS. Don’t label every webpage failure a DNS issue—or rule DNS out just because an address was returned.
Check server hostnames and destination domains separately
Distinguish at least three types of hostname: the proxy server, the subscription URL, and the website you want to visit. If the proxy server’s hostname won’t resolve, the connection itself may not start. A subscription domain issue affects updates but may not affect existing entries. A destination domain issue may affect only some services. These requests may use different settings and paths, so a successful subscription update doesn’t prove that all DNS resolution is working.
System DNS depends on the resolver provided by the current network or specified on the device. Custom DNS uses the resolver endpoint in the configuration. DNS over HTTPS sends queries over HTTPS. Encryption changes the query channel; it doesn’t guarantee the endpoint is reachable or suitable for the current network. If a DNS over HTTPS endpoint uses a hostname, consider how that hostname is resolved in the first place. Don’t send the initial lookup through a dependency that hasn’t been established yet.
Read the existing configuration before changing one setting
Open the active configuration and check for settings such as dns-server. Look for earlier changes in other sections too. The snippet below shows how [General] and rule sections are organized; system means to use the system resolver. It isn’t a universal recommendation for every network. Don’t append it to the end of an existing file and create duplicate sections. Understand the current configuration first, then edit the relevant field in a copy.
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYAfter making a change, send a new test request and consider the effect of cached results. An app may keep an old DNS result or existing connection, so the visible behavior might not change immediately. Close and reopen the relevant page; if needed, reconnect Shadowrocket normally, then compare the records. Don’t keep switching DNS servers and hoping for the best. Keep an explainable baseline and confirm whether each change affected the resolver or the request path.
Check address families, local networks, and routing consistency
A domain may return both IPv4 and IPv6 addresses. If the current network has trouble connecting over one address family, access may be intermittent or succeed only after a delay. Check the actual destination address in the failure records rather than treating multiple returned addresses as an error. Don’t permanently disable an address family to hide an unknown issue. If you need a temporary comparison, note the original setting, restore it afterward, and check whether the server and network support that path.
Local network names may also rely on the router or a specific local discovery mechanism. After switching to a remote resolver, names for home devices might stop resolving even though their correct local IP addresses still work. In that case, check how local DNS works with DIRECT rules rather than sending those devices through the proxy. A mismatch between the resolved address and the final connection path can also affect access, so check both the matched rule and the resolver.
If only one domain fails, compare it across networks and check whether the service changed its domain, certificate, or endpoint. Don’t infer the service’s status from one DNS lookup. If many domains fail while the server endpoint still connects, focus on whether the resolver endpoint is reachable and whether the configuration depends on it. For a more detailed explanation of the fields, see the DNS settings guide. After fixing the issue, retest a regular webpage, the original destination, and any local network resources you need to confirm that all three work.
07 · Background tasks and repeated connections
Increased battery drain, device heat, or excessive background activity
First distinguish between Shadowrocket appearing in battery usage because it handles network traffic and the device actually using more power than usual. The network extension processes traffic that passes through it, and system reports may attribute some related activity to the app. That doesn’t mean every change in battery use is caused by its settings. Compare total battery drain, the tasks you’re doing, screen-on time, and network conditions instead of relying only on one app’s percentage in the list.
Establish a battery baseline using similar tasks
Choose a routine activity you can repeat and note the network, screen state, and main tasks. Continuous video, file sync, and idle time use very different amounts of data, so they aren’t directly comparable. Device temperature, charging state, and wireless signal also affect power use. A weak mobile signal can increase the energy required for communications. Observe usage with a stable signal and normal device temperature first, then check whether the change occurs alongside a Shadowrocket connection.
Don’t start troubleshooting by turning off every feature. First check for sustained high-traffic tasks, including photo sync, file transfers, and background requests from other apps. These can continue through the current connection even when you aren’t actively using the device. Pause tasks unrelated to the test and see whether network activity drops. If it does, focus on traffic sources and task scheduling rather than mistaking normal traffic forwarding for high power use while idle.
Look for repeated failures and automatic connection loops
If the device keeps heating up when you’re barely using it, check the connection records for repeated DNS lookups, handshakes, or a high volume of failures in a short time. An unavailable server, an unreachable subscription URL, or an app repeatedly retrying an endpoint can generate extra activity. Find the most frequent failure and address it first. Don’t hide error records permanently: fewer visible records don’t mean background retries have stopped, and you’ll lose a useful way to observe them.
With On Demand, check whether the trigger conditions conflict with your everyday network changes. Switching between Wi-Fi and mobile data or changes in network sign-in status may trigger repeated connections. Note the current conditions, temporarily turn off automatic connections, and try a manual connection during the same kind of activity. If the loop stops, restore the conditions one at a time. Frequent automatic connections don’t necessarily indicate a malfunction; they may be following conditions that are too broad or that keep alternating between satisfied states.
Reduce unnecessary work without losing useful diagnostic information
Check for overly frequent subscription updates or batch tests. Automatic updates and tests use network resources; there’s no need to fetch existing content every time you switch screens. Set an update schedule that fits your needs, and avoid repeatedly testing the entire list while troubleshooting. To verify one server, test that entry alone. After troubleshooting, return detailed logging to the level you need for everyday use and remove diagnostic files you no longer need. This helps avoid retaining large amounts of sensitive data.
For connection keep-alive, timeout, and protocol settings, follow the requirements of your existing server. Don’t set extreme values just to save battery. Short timeouts can cause repeated reconnects, and overly frequent keep-alives can increase background traffic. Their effects depend on the protocol, remote server, and network, so don’t copy a one-size-fits-all number. Save the original values before changing anything, then assess typical tasks and idle behavior rather than checking the battery percentage after just a few minutes.
If the battery change coincides with a system update, device migration, or a large file sync, wait until background activity has finished before comparing. Restarting can clear some temporary states, but it doesn’t replace observation over time. If the device gets noticeably hot, stop intensive tasks and wait for it to cool before testing; don’t turn a long speed test into another source of heat. If the issue persists with the same tasks, a stable network, and no repeated tests, record the connection frequency and error types, then check the configuration and system status.
08 · Configuration changes and reversible steps
Issues after an app or system update
An update happening before a problem doesn’t prove it caused the problem. The subscription content may also have changed, the network may have switched, the server may have been maintained, or the configuration may have refreshed automatically. Note what changed between the last time things worked and the first time the issue appeared. Separate app updates, system updates, and configuration updates. Comparing the previous and current configurations is more useful than immediately reinstalling—and can prevent you from losing your only working setup during troubleshooting.
First check the source and compatibility
Shadowrocket is a closed-source commercial app available only through the App Store. See the purchase verification section on the download page. Check the developer name, Shadow Launch Technology Limited, the official app icon, and app ID 932747118. Check the App Store listing for system requirements. Don’t rely on system requirements in an old article to determine whether your current device is compatible, and don’t confuse your app purchase history with whether your local configuration has been saved.
If the app opens, first check whether the selected server on Home, the Global Routing mode, and the active configuration in Config still match your previous setup. If a prompt appears after an update, read it before taking action. The issue may simply be that a subscription refresh replaced the entry you had selected. Confirm that the configuration is present, disconnect and reconnect normally, then test the same destination as before. Don’t import multiple backups in a row before checking the current state; that can create further confusion about files and policy names.
Compare the system, app, and configuration separately
First test the underlying network with the connection off. Then check whether the system connection stays on, and finally test actual access through the proxy. This separates system authorization issues from rule issues. If the switch turns off immediately, return to the first section. If the connection stays on but only Config fails, compare the configurations first. If one server fails in all relevant modes, check whether its settings changed or its service stopped around the same time.
When comparing configurations, focus on recently changed DNS settings, rule order, policy names, and remote references. You don’t need to rewrite the whole file. Use an older copy for comparison, but don’t overwrite everything new without checking it. A remote configuration’s content may change even if its filename stays the same, so save a readable local copy. If restoring one field fixes the issue, confirm that the result is repeatable; a network recovering on its own can otherwise look like a successful configuration change.
Check what your backup includes before rebuilding or reinstalling
Restoring an app purchase, restoring server entries, and restoring a configuration are three different things. The App Store can help you recover an app you’ve purchased, but it doesn’t automatically recover every local entry, authentication detail, or manual change. Before reinstalling, confirm that your subscription URL is still accessible, your manually entered server details are safely backed up, your configuration copy opens, and you understand which data depends on sync. Don’t delete anything on the only device that has your complete configuration until you’ve checked your backups.
If you use iCloud or export files for backup, verify the file or the copy on your other device instead of relying on the sync toggle alone. Authentication details and subscription URLs are sensitive; store exported files somewhere secure. For migration steps, see configuration backup and device migration. If you need to rebuild the system VPN configuration, follow the first section. You usually don’t need to erase all app data.
After recovery, verify everything in order: confirm the app opens, system authorization is complete, a configuration is selected, and an existing server works. Then test subscription updates and your everyday destinations. Restore automatic tasks only after each step passes, so multiple background actions don’t start at once. If the issue still occurs, record the system environment, relevant settings visible in the app, minimal reproduction steps, and redacted errors. Don’t publish your full configuration to demonstrate the problem. Describe what you did and what happened, not just “it broke after an update.”
09 · Separate devices, shared configurations, and local networks
Works on iPhone but not on iPad
Troubleshoot the iPad as a separate device; don’t assume that a successful iPhone test applies to it. The devices may be on different Wi-Fi networks, use different DNS resolvers, or have different configurations and servers selected. Even if the subscription names match, the last update time and contents may differ. Put both devices on the same network first, then compare visible settings one at a time to find out whether the difference is in the device environment or the configuration.
Check purchases, permissions, and network conditions
For iPad access, see buying and opening the app for the first time on iPad. Redownloading a purchased app and device compatibility are subject to the App Store listing. Check the App Store listing for system requirements. Installing the app doesn’t mean system VPN authorization is complete; authorization on an iPhone doesn’t grant it on an iPad. Check the iPad’s system VPN page first, then test whether the connection switch stays on.
On a managed iPad, check whether device policies allow the connection. A cellular iPad and a Wi-Fi-only iPad also have different options for network testing. If you don’t have another independent network available, don’t assume a setting is correct just because you couldn’t run a comparison test. Try another Wi-Fi network you’re allowed to use, and check whether public Wi-Fi requires each device to sign in separately. Signing in on your iPhone doesn’t guarantee that the iPad’s network session is ready too.
Compare settings one at a time; don’t replace the entire configuration
Compare Global Routing, the active Config, and the selected server first, then check protocol fields, DNS, and rules. The subscription name may match even if one device hasn’t updated successfully. Entries with the same name may also have different authentication details after manual edits. Don’t send complete credentials through a messaging app; compare each device with the original information from your service provider. Once you find a difference, fix only that item. Don’t copy iPhone rules intended for a local network onto a different network environment without checking them.
Landscape orientation, Split View, and changes to window size can alter how navigation appears, but they don’t change what Config, Home, or Settings mean. If a button isn’t where you expect, exit search, close any editing screen, and check which section is open before importing the same content again. If the list is long, check filters and collapsed groups too. Handle a change in interface layout separately from a server connection failure; an entry being hard to find doesn’t mean the configuration was lost.
Check wake-from-sleep behavior, network changes, and local access
If the issue occurs only after waking the device, note whether the network changed during sleep and whether On Demand reconnected. A new webpage request is more reliable than looking at a page that was already open; the old page may have a broken session. If reconnecting fixes the issue, check network changes and automatic connection conditions. Don’t mask the problem by keeping the screen on longer. Check the battery section for repeated reconnects during sleep instead of looking only at the connection switch in the foreground.
iPad is often used to access network storage, casting devices, and other local services. If these stop working after connecting, check the actual addresses they use, local network permissions, and whether the relevant subnet goes through DIRECT. Device discovery may rely on broadcast or local discovery mechanisms that a single domain rule won’t cover. First test whether you can connect directly to a known local IP address, then distinguish name discovery, app permissions, and traffic routing. Don’t attribute every local network issue to DNS.
Verify configuration sync separately. A file appearing on another device doesn’t mean it’s the active Config, and a server entry appearing in the list doesn’t mean it’s selected. After migration, run a short, complete check on the iPad: select a configuration and an existing server, confirm the mode, connect, and visit the original test destination. Restore automatic updates and On Demand only after everything works. If the issue returns, you’ll know which step introduced the new condition.
Finish by testing the same destination on both devices and noting any remaining differences. If the iPhone works but the iPad fails on the same network with the same settings, check the iPad’s own system authorization, DNS results, and the stage where the error occurs. If both devices fail, focus again on shared network, server, or subscription issues. For help with everyday steps, return to the setup guide. For field definitions, see the glossary. There’s no need to rebuild the entire configuration to fix a local issue.