Switch won’t turn on: Check permissions and system restrictions first
A switch that immediately turns off, stays on Connecting, or causes the app to quit are three different symptoms. Note exactly when the problem occurs: before a system permission prompt appears, just after you allow a VPN configuration, or only after selecting a server. Don’t delete all subscriptions or keep tapping Connect. Turn the connection off, wait for the system status to settle, then check that a regular browser can open a page normally accessible on your current network. Until the underlying network is working, server tests and rule changes won’t give you a reliable comparison.
Confirm VPN permission was granted
On the first connection, the system may ask to add a VPN configuration and confirm with your device passcode or system authentication. Dismissing the prompt does not grant permission, and a momentary change to the in-app switch is not a substitute for system confirmation. Return to Home and try connecting once more, reading the prompt carefully. Then look for the VPN entry in system Settings and confirm that the configuration is present. Menu names and locations vary by system version; use Settings search if needed. If the configuration exists but won’t enable, disconnect first. Then consider removing only the corresponding VPN configuration and granting permission again, leaving your servers and Config intact.
On a device managed by an employer or school, management policies may restrict new VPN configurations, network extensions or background connections. The administrator must confirm these restrictions; importing a subscription again won’t change system policy. Don’t remove management profiles unless you know what they’re for. If another VPN connection or network filter that relies on a local VPN is active, pause one of them and start Shadowrocket on its own. Changing several network tools at once makes it harder to identify the cause.
Check automatic reconnection and configuration errors
On Demand may reconnect after you switch the connection off manually, or retry when the network changes. To observe one complete manual connection attempt, temporarily turn off On Demand and note its original conditions so you can restore them afterward. If the switch drops only when you select a particular server, check Add Server for required fields such as the address, port and protocol parameters. A subscription name appearing normally doesn’t mean every entry is complete. Compare any fields that weren’t recognized during import with the original details you already have.
If the app opens normally but the system never finishes granting permission, turn off the connection, quit the app and reopen it. If nothing changes, restart the device. A restart clears temporary extension state; it doesn’t prove the configuration is correct. After restarting, test only the same server entry—don’t update the subscription or change rules at the same time. If it works, check whether the issue returns after locking the screen or switching networks. If it still fails, check storage, system restrictions and the current configuration instead of reinstalling repeatedly.
Separate installation blocks from connection issues
If the app won’t open at all, troubleshoot installation before investigating network issues. Shadowrocket is available for iPhone, iPad, Mac, Windows, Android and Linux. The iPhone / iPad version costs $2.99 once on the App Store. Mac (Apple Silicon and Intel), Windows, Android and Linux versions are free. For iPhone / iPad system requirements, refer to the App Store listing. For other platforms, get the installation files from this site’s download page; the files are served from this site’s /dl/ path.
Desktop and Android installers are not code-signed, so the system may block them the first time you open them. After confirming the file came from this site, on Windows select “More info” and then “Run anyway” in SmartScreen; on Mac, allow the app to open in “Privacy & Security”; on Android, follow the system prompt to allow your browser or file manager to install unknown apps. On Linux, check file permissions and package format as well. See installation permission instructions for detailed steps. Don’t try to fix installation problems by repeatedly changing rules.
No internet after connecting: Separate the tunnel, server and routing
If the connection indicator looks normal but pages won’t load, first determine whether all requests fail or only some domains. Turn off Shadowrocket and try a page that normally opens directly. If it still fails, check your router, mobile data, Wi-Fi sign-in or system proxy settings first. Hotel and guest networks often require you to sign in through a browser; establishing the tunnel beforehand may prevent the sign-in page from appearing. Complete network sign-in before reconnecting, so a blocked network entrance isn’t mistaken for a server problem.
Use Global Routing for a brief comparison
Once the underlying network is working, select a server entry you already have with complete details and compare using the same target and network. In Global Routing, Config, Proxy and Direct correspond to configuration-based routing, proxy routing and direct connections. Switching modes is for narrowing down the cause, not a permanent fix. Send a fresh request after each change. Existing pages may reuse connections or cached content, so seeing old content on screen is not a reliable test.
| Mode | What to check | How to interpret the result |
|---|---|---|
| Config | Apply the rules and policies in the current Config | If only this mode fails, check rule matching and policy references first |
| Proxy | Route the test request through the proxy | Check whether the selected server can handle an actual request |
| Direct | Compare with the direct connection path | Establish a baseline for the underlying network; this does not mean every target should be reachable |
If ordinary pages work under Direct but the same page fails under Proxy, focus on server parameters and the route from the server to the target. If Proxy works but Config fails, check the active Config, rule order and policy names. If all three modes fail, don’t assume the rules are at fault; return to the underlying network, DNS and system connection status. Some websites have different access conditions on different network paths, so test at least two targets with different purposes instead of drawing conclusions from one website.
Make sure the selected server matches the one actually used
The server selected in Home isn’t necessarily the server ultimately used by every policy in Config. A configuration may reference a policy group, or route some requests through DIRECT or REJECT. Open the request log, find the domain you just tested, and check the matching rule and final policy. If there’s no new entry, confirm that you sent a fresh request, the system is still connected to the current tunnel, and the test app actually accessed the network. If an entry shows the wrong policy, fix the rule instead of switching servers again.
When checking Config, first confirm which file is active, then edit a copy. Rules are generally evaluated from top to bottom, so specific domain rules should come before broader rules; FINAL is the fallback. This snippet demonstrates rule order only. example.com is a sample domain, and PROXY must resolve to a valid policy in your actual configuration. Don’t replace your existing configuration with this snippet, or add broad allow rules you don’t understand just for testing.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYChoose the next step based on where the failure occurs
If the page reports a domain resolution error, go to the DNS section. If it times out after waiting, go to the connection timeout section. If the connection is established but a certificate warning appears, check the system date and time, target domain and server-provided TLS parameters. Don’t disable certificate verification to hide the error. If only one app fails, check its network permissions, sign-in status and service availability first, then compare with a browser accessing a similar target.
Once service is restored, return Global Routing to its intended mode and test one request that should go direct and one that should use the proxy. Note the network, server and configuration associated with the successful results. If only Proxy works temporarily, keep the finding—“Proxy works, Config fails”—and continue investigating routing. Changing the route globally may bypass the problem without fixing it. For more on rule matching, see Custom Rules and FINAL.
Connection timeouts: Check the address, port and handshake stage
A timeout means a step didn’t finish before the time limit; it doesn’t necessarily mean the server is offline. Connectivity Test results depend on the test method, target and network at the time. A successful probe only confirms that particular probe path worked. A real web request also depends on DNS, protocol authentication, TLS and the target site’s response. Record separately whether the server can’t be reached at all or connects but pages fail. Don’t treat a single reading as proof that every app is usable.
First confirm the address and port are exactly as provided
In Add Server, check the server address, port and protocol. The address field should normally contain only the server hostname or address, not a web page path or explanatory text. Use the port in your existing details; don’t guess based on the protocol name. Watch for spaces, line breaks or full-width punctuation introduced when copying. If the address is a hostname, check whether it resolves. If it’s an IPv6 address, the current network must support reaching it; other websites working doesn’t prove this address is reachable.
If the same entry fails on Wi-Fi but works on mobile data, the issue is related to the network or route. Check Wi-Fi sign-in, router rules and upstream connectivity. If it fails on both networks but another server entry you already have works, check the original server and its parameters first. If all entries suddenly fail, check the underlying network and shared DNS dependencies before changing passwords. For each test, change only the network or the server so the result has a clear meaning.
Protocol parameters must come from the same set of details
Fields aren’t interchangeable between protocols. For Shadowsocks, check the encryption method and password; for VMess and VLESS, check the user ID and transport options; for Trojan, check the password and TLS settings. Even a one-character error in a user ID or password can cause authentication to fail. After importing a link, verify that key fields were recognized correctly, especially if the link contains escaped characters or additional transport parameters. Don’t combine parameters from different entries to make a seemingly complete new one.
| Stage | Key fields | What to do |
|---|---|---|
| Reaching the server | Address, port, address family | Compare with the original details and test on different networks |
| Protocol authentication | Password, user ID, encryption method | Check each field; don’t reuse fields from another entry |
| TLS and transport | Server Name, Host, Path, transport type | Match the service configuration and keep certificate verification enabled |
The TLS Server Name may differ from the connection address. Host and Path can also serve different purposes, so don’t set them all to the same domain just because the names look similar. Check that the system date and time are correct; a clock that’s off can make a valid certificate appear not yet valid or expired. If you get a certificate error, note its category and check your details. Don’t accept a mismatched certificate without reason. Correct protocol settings and a trusted certificate are separate requirements; bypassing one doesn’t prove the other is satisfied.
Check for UDP and network path differences
Some protocols and features rely on UDP. Hysteria2 performance can depend on UDP conditions on the current network; WireGuard also needs the right keys, addresses, endpoint and routing scope. A webpage working through another entry doesn’t prove the UDP path is working. If only one protocol fails, check its required parameters and network conditions instead of changing every server. Avoid adjusting low-level settings such as MTU unless the issue is reliably reproducible and other causes have been ruled out.
If timeouts continue after confirming the original parameters, contact the administrator of the service you already use. Share the test time, network, failure stage and a redacted error message. Don’t send a complete subscription link, password or key. If the connection used to work but stopped, also ask whether the server address, port or authentication details changed. Update the entry only after they confirm. Then verify recovery with a real request and keep a reproducible test step to help distinguish intermittent congestion from a persistent issue next time.
Subscription fails or the list is empty: Check retrieval and parsing separately
A subscription update has two stages: first, retrieving the content returned by the server; then, parsing it into server entries. An update error can occur at either stage, and a successful update with an empty list doesn’t necessarily mean the network is unavailable. Keep the existing entries and note the subscription group name, changes in the entry count and any error message. A one-time client purchase is not a service plan. Installing or purchasing the app does not generate server details. This site does not provide, sell or recommend servers or subscriptions; this article only explains how to check details you already have.
Check that the copied content is a subscription URL
Get the subscription link again from the service provider you already use and confirm you copied the complete URL, not a sign-in page, management page or truncated display. Subscription URLs may include query parameters; removing the end or converting special characters to full-width characters can change their meaning. After pasting, check for leading or trailing spaces and line breaks, but don’t rewrite parameter order or decode the content. If the provider gave you a single share link, import it as an individual server rather than treating it as a subscription that needs periodic updates.
Don’t paste a real subscription URL into a search box, public forum or online parsing tool. It may contain credentials that grant direct access. When documenting an error, keep only the protocol, a redacted version of the domain and the error category. Before sharing a screenshot, obscure the QR code, complete URL, username and identifiable server notes. A QR code and text link may carry the same access; hiding only one doesn’t protect the other.
Check whether the network request actually retrieved content
If the update times out, first check whether the subscription domain resolves on the current network, then check the route used to retrieve it. In some cases, the existing server is unavailable and updating the subscription depends on that same proxy path, creating a deadlock. If the underlying network works and the service address permits it, compare the update result while disconnected. You can also compare with another working entry you already have. Don’t assume a subscription must use a proxy or a direct connection; choose based on whether the address is reachable.
If the error includes a status code, distinguish what it means. Authentication or access-denied responses usually call for checking link permissions. If requests are being rate-limited, stop refreshing repeatedly. Server errors need to be handled by the service administrator. Even a successful response may return a sign-in page, verification page or general information page instead of subscription data. So seeing a page in a browser doesn’t prove the subscription content is correct—and you shouldn’t paste the page’s text into a server address field.
If the list is empty, check parsing and display settings
If content was retrieved but no entries appear, clear any search filter in Home and expand the relevant group to rule out filtering or a collapsed list. Then check whether the error mentions an unsupported format, missing fields or unrecognized content. Subscription formats can contain different fields; changing the URL suffix won’t convert one format into another. If you need a different format, follow compatibility instructions from the service you already use instead of handing a private link to an unknown tool.
If only some entries disappeared after an update, compare the missing entries’ protocols and parameters. Check whether the service removed them, renamed them or whether parsing failed for an individual entry. Don’t identify a server by its display name alone; names can change or be reused. If an update overwrites fields you edited manually, stop repeatedly editing the subscription entry. Keep a manageable local copy for troubleshooting, understanding that it won’t inherit future changes automatically. Use the save options available in the current interface.
After recovery, confirm the original issue is resolved
If the subscription reappears, that only confirms retrieval and parsing succeeded; you still need to select an entry and test a real connection. First confirm the group contains entries, then check key parameters and finally visit a test target. Don’t update Config and all subscriptions at once, or you won’t know which step fixed the issue. If a new link updates but the old one doesn’t, disable the old link after confirming recovery and ask the original service administrator whether its credentials have been revoked. For more failure scenarios, see Troubleshoot failed subscription updates and empty lists. For link types, see Share links vs. subscription links.
Slow speeds and intermittent drops: Set up a comparable test
Low latency doesn’t mean high throughput, and good throughput doesn’t guarantee fast responses to interactive requests. Loading a webpage involves DNS resolution, connection setup and waiting for the first byte; large downloads depend more on sustained bandwidth, packet loss and server load. First describe what feels slow: a long wait before anything starts, consistently slow transfers, playback that stalls, or disconnections only after locking the screen. Identify the symptom before testing. Don’t lump different issues together as “slow speeds” and then change the protocol, DNS and rules all at once.
Keep the target, network and test window consistent
Choose a moderately sized, legitimate test resource and compare on the same network and device at roughly the same time. Pause system updates, cloud sync and other high-bandwidth tasks, and make sure the device isn’t getting noticeably hot. Change only one server entry you already have or switch Global Routing once; keep everything else the same. Speed tests use data, so limit them on mobile networks. Repeated high-volume testing can itself cause congestion and heat, making later results worse.
If ordinary pages are also slow when using a direct connection, check the Wi-Fi signal, router load and upstream network first. If performance improves closer to the router, prioritize local wireless conditions. If it improves on another network, focus on the original network path. If the same server is slow on different networks but another entry you already have works, the server or its outbound path may be limited. Changing local rules can select a different route, but it can’t increase the available bandwidth at the remote end.
Distinguish a slow first request from slow ongoing transfers
If the first visit is slow but repeat visits are much faster, DNS caching, connection reuse or cached content may be involved. That alone doesn’t prove the server is unstable. Check the domain, matching policy and error stage in the request log. If the request took an unnecessarily indirect route, fix the rule and test again. If it matched the expected policy, compare DNS resolution time, connection setup and the target’s response. If the log doesn’t provide enough information, say so rather than guessing at timings.
Regular pauses during a download may be caused by packet loss, network switching, wireless interference, server-side rate limits or the app’s buffering behavior. First reproduce the issue while the device stays still and on one network, then compare with another entry you already have. If only one target is slow, the target site or its content delivery path may be the problem. Don’t use a single video or download site to represent all traffic, and don’t keep changing your long-term configuration to chase a one-off test result.
When a connection drops, record its status and timing
When a connection drops, check whether the system VPN status changed, then check whether Shadowrocket still shows an active connection. New requests failing while the status remains connected calls for a different troubleshooting path than a system tunnel that has disconnected. In the first case, check the server, DNS and existing connections. In the second, check network changes, On Demand, system restrictions and app issues. Note whether the drop followed screen lock, a Wi-Fi-to-mobile switch, hotspot use or Low Power Mode. The timing can be more useful than a single speed test.
Some connections don’t recover automatically after a network switch and need to be re-established by the app. First send a small new request and check whether a new connection succeeds; then decide whether to disconnect and reconnect. If only an old download has stalled while a new page loads, the old session may have expired without the whole tunnel becoming unavailable. A forced reconnect interrupts other active sessions, so check the scope of the problem first.
Use Data to add context, not as a diagnosis
Traffic readings in Data can help identify heavy background activity, but their meaning depends on the measurement scope, time range and when the counters were cleared. High cumulative traffic for a server doesn’t mean it’s fast now; low traffic for an app doesn’t mean it has no connection issues. Confirm what the counters measure, then compare them with the actual test period. For notes on viewing traffic by server and app, see Traffic statistics in the Data tab. If you need to reset the counters, save the current readings first so you don’t lose evidence for comparison.
DNS and rule-matching issues: Separate domains, addresses and policies
DNS resolves domain names to addresses; rules decide which route a request uses. They’re related, but one can’t replace the other. A domain may fail because resolution failed, or because resolution worked but the connection to the target didn’t. Reaching an address doesn’t prove the domain path is working properly either, since HTTPS often depends on the correct domain and certificate. Don’t replace a webpage’s domain with its IP address to diagnose every issue, and don’t add several unfamiliar DNS servers just because you saw a resolution error.
First identify which layer is failing
Visit the target again and check the request log: does the domain appear, was an address returned, which policy was ultimately used, and did the error occur before or after resolution? If several unrelated domains fail to resolve, check the current DNS settings and whether their route is reachable. If only one domain fails, consider the domain itself, caching or its matching rule. Include an ordinary domain that usually works as a reference, rather than testing only targets that already have different access conditions.
Encrypted DNS also needs a working connection to its resolver, and in some cases that resolver’s domain must be resolved first. If DNS requests depend on an unavailable proxy route, every domain may appear to fail at once. Record separately which resolver is being used and how traffic reaches it. Don’t assume a feature works just because of its protocol name, and don’t permanently disable protections required by the system or configuration just to troubleshoot temporarily.
Check rule order and policy references
Rules are evaluated from top to bottom; the first matching rule usually takes effect. DOMAIN matches a complete domain, DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an address range, and FINAL catches requests that weren’t matched earlier. Domain and address rules use different criteria. For address-based matching, also consider whether an address has been resolved and how the configuration handles resolution. When troubleshooting, start with a specific domain and a narrow test; don’t add broad keyword rules right away.
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYThis snippet shows a specific rule before a broader one: intranet.example.com matches the first rule, not the later suffix rule. GEOIP uses address-location data; it doesn’t identify a website’s language, business location or content type, and the data may not reflect the actual egress location. PROXY, DIRECT and REJECT describe policies. In an actual configuration, a proxy policy must also reference a working server correctly. Even a correctly written rule won’t work if its policy points to a failed entry.
| Keyword | What it matches | Common misinterpretation |
|---|---|---|
| DOMAIN | A specific complete domain | Assuming it also matches every subdomain |
| DOMAIN-SUFFIX | A domain suffix | Overlooking an earlier rule that already matched |
| IP-CIDR / IP-CIDR6 | An IPv4 / IPv6 address range | Confusing address reachability with domain resolution |
| FINAL | Requests not matched by other rules | Assuming it can fix a request matched incorrectly by an earlier rule |
Check IPv4, IPv6 and local network domains separately
Some domains return both IPv4 and IPv6 addresses, while the current network or server may only work properly with one address family. If the behavior changes with the network, check for address-family differences instead of immediately concluding that DNS returned the wrong result. Local devices may also rely on the router’s local resolver or a specific search domain. Switching to an external resolver may let regular websites work while printers, file services or internal domains fail. That’s a change in resolution scope, not something to fix by routing all requests through a proxy.
After changing DNS or rules, make a new connection and send a fresh request. Existing connections and caches may still affect the result. Wait for the relevant state to update, then test the same target and restart the test app if needed. Clearing a cache is a way to rule out stale state, not a permanent fix. Once service is restored, save the changes you made, remove temporary test rules and check that local network access still works. If the cause remains unclear, share redacted details about the matching rule, address family and error stage; that’s more useful than simply saying “the domain won’t open.”
Battery drain and post-update issues: Restore a stable baseline first
A sudden increase in battery use needs to be assessed alongside network activity and the observation period. The system may attribute network activity carried by the tunnel to the related app, so a high battery ranking alone doesn’t prove there’s a problem. Compare battery use under similar workloads, screen-on time, mobile signal, device temperature and data usage, then check for repeated reconnections. If an issue appeared after an update, first check whether the configuration changed; timing alone doesn’t prove the update caused it. Keeping the original configuration helps distinguish a network change from a local state change.
Look for sustained activity, not just battery rankings
Pause downloads, cloud backups, media uploads and repeated speed tests. Let the device cool, then observe it during ordinary use. Weak mobile signal, hotspot sharing and frequent network switches all increase system workload, so consider them separately from app behavior. If things improve after other high-bandwidth activities stop, check which apps were using data. If the device still heats up noticeably while idle, look for repeated connection failures, subscription updates or requests. Don’t delete every server entry to “clean things up” without clear evidence.
If On Demand conditions trigger frequently as the network changes, they may cause repeated connection attempts. Note the original conditions, turn off automatic connection briefly and observe with manual connections. If this helps, restore the conditions one by one to find the setting associated with the issue. Don’t treat permanently disabling the connection as a fix, or turn off every system networking feature at once. If you need an all-day connection, retest screen locking, waking and network switching under stable conditions rather than stopping after a short foreground test.
Reduce the extra load caused by troubleshooting
Keeping detailed logs for a long time, repeatedly probing many servers and constantly refreshing subscriptions can all create extra activity. Keep only the diagnostics you need during the period when you reproduce the issue, then restore normal settings once you’ve identified it. Logs may contain domains you visited and connection details; review and redact them before exporting. Keep the record to a short window covering the start of testing, the event and the end. Long logs add overhead and can bury the useful error information.
Low storage can also affect system and app updates, cache writes and saving configurations. Use the system’s storage manager to free space by removing content you’ve confirmed is safe to delete, then reopen the app. Don’t manually delete internal files you don’t recognize. For battery tests, avoid comparing temperatures while charging; charging itself changes the device’s thermal state. Keep screen brightness, network and app usage similar in each round to tell whether a change has a lasting effect rather than a one-off fluctuation.
Compare the app and configuration separately before and after an update
An app update, subscription update and Config update are separate actions. Recall exactly what happened before the issue: did only the app change, or did server parameters and rules change too? Confirm the selected server and active Config, and check whether Global Routing is set as intended. If Proxy works but Config doesn’t, compare configuration changes first. If all modes fail, return to the underlying network and server parameters. Don’t keep uninstalling to test an update issue; uninstalling may also remove data you haven’t backed up.
App updates for iPhone / iPad are managed in the App Store. For Mac, Windows, Android and Linux, get updated installers from the app downloads page. If reinstalling triggers a system warning, confirm the files came from this site, then follow the download page’s installation permission instructions. Before installing, save your Config, manually added servers and any notes you need. Backups contain sensitive information; store them somewhere you control and don’t upload them to a public location.
Recovery order and reproduction notes
If you need to rebuild a test environment, first grant system permissions. Import one server entry you already have with clearly specified parameters and verify that it works. Then add the original Config, followed by your subscriptions and On Demand. At each step, test the same target and note when the issue starts. This separates basic app connectivity, server details and complex configuration. If the issue returns immediately after importing a full backup but a single entry works, check the backup’s settings instead of reinstalling again.
When reporting a post-update issue, include the device model, system environment, network type, steps that fail and a redacted error message. Read app details from the current interface rather than relying on memory. It’s especially useful to say whether the issue reproduces reliably and whether it occurs with a minimal configuration. After recovery, keep a verified copy of the configuration and make another copy before the next change. There’s no need to reset things constantly; make each change traceable and reversible, and confirm that your usual setup still works.
iPad-specific checks: A synced configuration doesn’t mean the environment is the same
If the same details work on iPhone but fail on iPad, compare the two devices’ networks and system permissions first. Don’t assume the tablet needs a different protocol. Even on the same named Wi-Fi network, the devices may be on different guest networks, address families or management policies. Put both devices on as similar a network as possible, disconnect and verify that each has basic internet access, then briefly test the same server entry you already have. Keep Global Routing consistent to avoid mistaking a configuration difference for a device difference.
Grant first-time permission on the iPad itself
VPN permission granted on another device doesn’t replace the system confirmation required on this iPad. The first time you connect, allow the VPN configuration on the iPad and complete system authentication. If no prompt appears, check whether the corresponding configuration already exists in system Settings or whether device management is restricting it. School- or work-managed devices may have specific network policies; importing the subscription repeatedly won’t bypass them. If you’re unsure about the restrictions, ask the administrator what’s allowed.
A larger screen and side-by-side windows don’t change the system-level nature of the connection. Moving the app to the background or out of the current window doesn’t disconnect the VPN. Conversely, seeing Home in the foreground doesn’t prove the system tunnel is still active. Check both the system VPN status and the in-app connection status, then send a fresh request. If an old page stops responding only after you switch windows, try a new request first to distinguish an expired session from a full connection failure.
Compare servers and Config one item at a time
After importing the same subscription, the two devices may have different entries selected, or one device may not have updated yet. Compare the protocol, address, port and key transport parameters—not just the server name. Check credentials locally only. Then compare the active Config, Global Routing and selected policy groups. Files with the same name aren’t necessarily identical; manual edits and later updates may have changed their contents. Matching list views don’t prove requests use the same route.
If you imported using Scan QR Code, confirm whether you scanned a server entry or a subscription link; they behave differently when updated. If you share details between devices, make sure everything was transferred. After importing, check required fields in Add Server and test actual access. The appearance of a new entry doesn’t prove the entire configuration is correct. Be aware of your surroundings when sharing a QR code: it may contain the same sensitive information as text credentials.
Check local network access and network-switching scenarios
An iPad is often used with printers, file services and other local network devices. If regular websites work but local resources don’t, check whether the target address range uses DIRECT and whether local domains still resolve as expected. Local network ranges aren’t always 192.168.0.0/16; use your actual network instead of copying a sample rule. If the app requests local network access, decide whether to allow it based on how you use the app. A working VPN status doesn’t replace the system permission an app needs.
An iPad with mobile data may need to re-establish its connection after switching from Wi-Fi to mobile data. A Wi-Fi-only iPad may need to reconnect after waking from sleep. Check whether the issue consistently follows a network switch or wake-up, then send a fresh request once the network is stable. If reconnecting restores service, check On Demand conditions and how the server handles the changed route. Don’t update the subscription during a network switch; overlapping events make it hard to identify the cause.
Restore purchases and a checklist for reporting the issue
When changing devices or reinstalling, first confirm that the App Store is signed in to the account used for the original purchase, then look for the app in your purchased items. Restoring an App Store purchase and restoring server details are separate tasks: the former provides the app, while the latter requires a configuration or subscription you saved yourself. The iPhone / iPad version costs $2.99 once on the App Store and works on both device types; Mac, Windows, Android and Linux versions are free. Refer to the App Store listing for its current information and system requirements. See restore purchases for instructions.
When reporting an iPad-specific issue, list in order whether the underlying network works, VPN permission is granted, the same entry works on another device, and what you observed in the three mode comparisons. Also say whether the issue occurs only after screen lock or a network switch. Include redacted matching rules and error categories, but not a complete subscription or QR code. This gives the next troubleshooting step a clear starting point instead of requiring someone to guess from scratch. If you haven’t completed the initial import, return to the Quick Start guide. If you can connect but some requests fail, continue with connection and routing checks on this page.