Shadowrocket Troubleshooting Guide
First identify where the problem occurs, then adjust the relevant setting. This page provides a systematic troubleshooting process by symptom. If you haven’t completed your first connection, follow the quick-start guide first, then return to the relevant section with specific results. The steps below assume you already have your own subscription or server details. No servers or subscriptions are provided, sold, or recommended here.
For iPhone and iPad. Check the App Store page for system requirements. Interface labels remain in English; locations and available options may vary by device. Test results here are for narrowing down the cause and do not guarantee that a server connection will work.
Connection switch won’t turn on, turns off immediately, or keeps reconnecting
First distinguish system authorization from a server issue
After turning on the connection switch in Home, if the system asks whether to allow a VPN configuration, read the prompt, allow it if you choose, and complete device verification. This creates the configuration required for a connection in the system; it is not a purchase confirmation or subscription import. If you dismissed the prompt earlier, return to the app and try connecting again. Managed devices may restrict adding VPN configurations. Check with the device administrator rather than repeatedly changing the server address.
Watch what the switch actually does: if it never enters a connected state, check authorization and device restrictions first; if it connects briefly and then turns off, the Config, network reachability, or a connection error may be involved; if it stays on but webpages won’t load, continue to the next section. The status bar indicator shows only part of the connection state and cannot confirm that a request reached its destination. Recording these cases separately is more useful than saying only that it “won’t turn on.”
Check system connections and automatic triggers
Open Settings, search for VPN, and check whether a Shadowrocket configuration is listed and whether another VPN connection is active. Disconnect any connections you don’t need, then return to Home and test again. Don’t delete all system network configurations at once; some may be required for work or school. If the VPN entry can’t be edited, is marked as managed, or the system refuses to add a configuration, address the device management restriction before changing Config.
If the switch turns itself back on after you turn it off, check whether On Demand is enabled and whether the current network meets its connection conditions. For a manual test baseline, you can temporarily turn off On Demand and control the connection yourself; restore it to its original state when testing is done. When automatic triggers and the manual switch are both active, repeated connections don’t necessarily indicate an app issue. Also check whether the system has other automatic connection conditions, rather than changing only one setting in the app.
Make one change at a time and run a repeatable test
First confirm the device can access the internet without a connection. On Wi-Fi that requires a sign-in page, complete network authentication first. Then return to Home, explicitly select an existing server with complete connection details, and try connecting. If Config reports an error, check the message and active Config instead of toggling the switch repeatedly. You can temporarily compare against a known-good simplified Config, but keep the original file and note the names and Global Routing modes before and after switching.
If the problem occurs only on Wi-Fi, test the same server over cellular if available and you’re mindful of data usage; do the reverse if needed. Keep the server, Config, and destination the same. If the result changes with the network, investigate the network connection first. If both networks fail at the same stage, check the server details and service status. Don’t update a subscription, switch Config, and change networks all at once; even if the issue goes away, you won’t know which change helped.
When to rebuild the system configuration
If you still can’t connect after these checks, disconnect, close and reopen the app normally, and restart the device if needed before testing again. Consider removing the Shadowrocket configuration and letting the app request a new one only if you’ve confirmed the system VPN configuration is faulty, made a backup, and know how to restore it. Removing the system configuration doesn’t necessarily back up servers, subscriptions, or rules. Reauthorizing the app does not restore its Config. After authorization, check the selected item in Home again.
Shows connected, but all or some requests fail
Confirm the basic network first, then check the request path
Disconnect Shadowrocket and use the same device and network to open a site you can normally access. If that still fails, check Wi-Fi authentication, cellular data permissions, the router, or the network connection first. Turn the connection back on after the basic network is working to avoid mistaking a network access issue for a rules issue. If only one app has a problem, use a browser to test another destination as a comparison. An app may have its own session cache, domain list, or connection method, so don’t assume the entire network is down.
Return to Home and verify which server is selected; don’t just check whether the list contains a usable item. After a list update, the selected item may have changed, and similar names don’t mean the connection details are the same. Then check Global Routing: Config uses the active Config, Proxy routes through a proxy, and Direct connects directly. These modes determine how most requests are handled, but none of them alone proves how all DNS, system behavior, or destination websites are working.
| Mode | Troubleshooting use | What the result does not prove |
|---|---|---|
| Config | Check rules and policies in the active Config. | Verify which Config is active and check the matching request record. |
| Proxy | Compare with Config to check the server path. | Success doesn’t mean every rule in the original Config is correct. |
| Direct | Compare how requests behave without using a proxy server. | This doesn’t mean the VPN is fully disconnected or all DNS settings have been reset. |
Narrow down the issue by comparing modes
Use the same test page and server. Note the result in Config, then temporarily switch to Proxy and try again. If Proxy works but Config doesn’t, check which rule matched the request and the resulting policy instead of immediately changing servers. If both modes fail, check the server connection, DNS, and the destination itself. Restore the original mode when done and reopen the page. An old connection may still be reused, so a single refresh may not take the newly selected path.
If Direct works but Proxy fails, investigate the server path first, while also checking for differences in DNS resolution and incorrect protocol details. If both Direct and Proxy fail for the same destination but other destinations work, the site itself or one of its shared dependencies may be unavailable. Test another independent destination. Don’t treat several pages that depend on the same login service or resource domain as independent test cases.
Check Config against the rule that actually matched
Confirm that the expected file is active in Config, then check the failed request’s domain, matched rule, and handling policy. Rules are generally checked in order, so an earlier match can prevent a later, more specific rule from taking effect. Pay particular attention to broad DOMAIN-KEYWORD rules, wide IP-CIDR ranges, and entries that unexpectedly point to REJECT. The snippets below illustrate rule order only; they contain no usable server details and should not replace your complete Config.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYIn this order, api.example.com is assigned DIRECT by DOMAIN first; other domains matching the example.com suffix then match PROXY. The LAN address and GEOIP entries illustrate different match types, and FINAL handles requests that matched none of the rules above. Actual results also depend on the domain information available to the request, its resolved address, and the rest of the Config. Don’t assume a rule must match based only on the destination name; use the current request record as evidence.
Only some page elements fail to load, or sign-in doesn’t work
A single page usually uses multiple domains. If the page text appears but images, verification, or sign-in fail, inspect the failed resource requests individually instead of adding a rule only for the homepage domain. First check for an explicit REJECT match, then verify whether related domains use different policies. Add only the rules needed for confirmed dependencies, and avoid broad keywords that could affect unrelated requests. If you’re unsure what a rule term means, see the glossary. For first-connection checks, return to the quick-start guide.
Server timeouts, failed tests, and protocol mismatches
Interpret test results separately from real-world access
Connectivity Test results depend on the test method, destination, current network, and server status. A failure alone doesn’t prove that every request will fail, and a successful test doesn’t mean every website or transport method will work. Confirm the selected item, then try accessing a specific destination and note whether the test and actual access agree. If the test destination itself is unreachable, the test may fail even when some services work. Check the test settings before deleting a server based only on the result.
Distinguish a connection timeout from a refused connection, authentication failure, or certificate warning. A timeout usually means the required response didn’t arrive within the waiting period, but “timeout” alone can’t tell you whether the server is offline, the port is unreachable, DNS failed, or packets were dropped in between. A refused connection and an authentication failure point to different causes, so save the exact original message. If the interface provides no detailed error, note whether it fails immediately or only after waiting; that timing can help with comparisons.
Check shared fields first, then protocol-specific fields
Open the item’s edit screen or Add Server and compare its details with the original information from your existing service provider. Start with the type, Address, and Port. Don’t include unwanted paths, leading or trailing spaces, or content from a different protocol link in the address field. The port must match the service. A server’s display name is just a label; changing it won’t fix the address or authentication. For automatically imported items, check the resulting fields too. A successful scan or subscription import doesn’t guarantee that the parameters work together.
| Protocol | Check these fields | Common pitfall |
|---|---|---|
| Shadowsocks | Address, Port, Password, and Method. | The password can be correct while a mismatched Method still causes failure. |
| VMess / VLESS | UUID, transport, TLS, and any additional fields required by the server. | Reusing transport details from a different server won’t produce a valid match. |
| Trojan | Authentication details, TLS, server name, and transport settings. | Confusing the connection address with the certificate verification name. |
| Hysteria2 | Authentication details, TLS, and UDP reachability on the current network. | Ordinary web access doesn’t mean the relevant UDP path is reachable. |
Fields such as UUID, Password, Method, Host, Path, and server name must all come from the same valid Config; don’t combine details from different items. Some transport methods require a specific path or hostname. These values aren’t arbitrary notes: capitalization, slashes, and whether TLS is enabled can all affect the connection. For field differences between VMess and VLESS, see the protocol field comparison. Always follow the requirements of your existing server.
Don’t bypass certificate or time errors
For TLS-related errors, first check that the device’s date and time are correct, then verify that the server name matches the certificate. The connection address, TLS verification name, and transport-layer Host may serve different purposes; don’t change them all to the same value just to make the fields look consistent. If a certificate is expired or the name doesn’t match, ask your existing service provider to check the server. Turning off certificate verification changes the security boundary and isn’t a general fix. It also doesn’t prove that the original Config was correct.
Compare networks and server entries instead of testing repeatedly
Keep the same server entry and test once on each of two available networks. Then, on the same network, compare it with another existing entry whose details have been confirmed. If all entries fail on one network only, investigate that network’s transport restrictions or quality first. If only one entry fails across different networks, check its details and service status. For protocols that use UDP, verify the network conditions separately; ordinary web access doesn’t prove that their transport path works.
When contacting an existing service provider, share the protocol type, failure stage, network type, and a redacted error message. Don’t share a complete subscription, UUID, password, QR code, or authenticated link publicly. If the issue began after a subscription update, compare the changed fields before deciding whether to restore the previous entry or wait for a server-side fix. Stop repeated testing once you have a consistent result, and keep one reproducible case. Retesting won’t fix remote authentication or port settings.
Subscription import fails, updates to an empty list, or creates duplicates
Tell subscription URLs, server links, and Config files apart
Subscriptions usually fetch or update server entries, while Config handles rules and related settings. They aren’t interchangeable just because both contain text. First identify whether your information is a subscription URL, a single server link, a QR code, or a Config file, then use the corresponding option shown in the app. A successful import means only that the content was accepted at that step; it doesn’t confirm network connectivity or server authentication. If you’re unfamiliar with the initial setup, follow the quick-start guide for one import method.
Copy the complete address again from your service provider, checking for line breaks, non-ASCII punctuation, spaces, or explanatory text. Authentication details in the link are sensitive; don’t inspect them in public screenshots or public text-processing tools. Check only that the address is complete, and don’t remove parameters after the question mark; they may be part of your subscription credentials. If the address has expired, check its status in your existing service provider’s account rather than guessing or rewriting its authentication details.
Distinguish a failed request from content that can’t be parsed
If the subscription URL can’t be reached, first check whether the current network can access the service that hosts it. If the request succeeds but parsing fails, focus on the response content. A login page, error message, or account status notice may be returned as a webpage. A successful network request doesn’t mean the response contains subscription data. Even if the response status looks normal, check the error text. Don’t save an HTML page as a Config and try importing it; that turns a retrieval problem into a format error and hides the original cause.
If a subscription can only be fetched through an existing working connection, first identify the path currently in use, then update one subscription at a time. Don’t delete existing entries if any are still usable. Conversely, if the subscription request is routed through a server that is already unavailable, the update may never complete. After checking the rules and network conditions, you can compare with a different working path, but don’t switch blindly back and forth between Direct and Proxy. Record the actual mode and selected item for every test.
Keep the old data if an update returns an empty list
If an update sharply reduces the number of entries or leaves the list empty, check the message, subscription source, and account status before proceeding. The subscription may have returned empty content temporarily, or the provider may have changed its entries. Repeated refreshes erase useful clues. Keep any working entries and a copy of Config, then ask your existing service provider whether this response is expected. If the subscription is valid but entry details have changed, check the actual selection in Home rather than relying on an old name.
A subscription name or server name doesn’t prove that a service is working. Entries with the same name may use different ports, protocols, or authentication details; entries with different names may point to the same service. After an update, open the actual entry and check its fields before connecting, especially the protocol type, TLS, and transport details. If the app says it can’t handle a type or field, check the app’s current support and the format provided by your service provider. Don’t attribute every parsing error to network quality.
Managing duplicate entries and multiple subscriptions
Duplicates can appear when the same subscription is added more than once, manual entries coexist with subscription entries, or multiple subscriptions contain the same server. Identify where each entry came from before removing duplicates. Don’t delete entries in bulk based only on their names, or you might remove the only working Config. Deleting an entry doesn’t necessarily change the remote subscription, so it may reappear at the next update. For long-term organization, decide which subscription source to keep and manage updates and removals by source instead of maintaining the same information in several places.
For multiple subscriptions, use local names that distinguish their source and purpose. Update and verify each one before moving to the next. Updating all subscriptions at once may be convenient, but it makes an unusual response harder to trace. See the guide to managing multiple subscriptions for details. If subscriptions update but none of the entries connect, continue to the section on checking connection details. Subscription updates and server connections are separate issues; success with the former doesn’t verify the latter.
Slow speeds, long initial waits, and intermittent drops
First identify which stage is slow
Break “slow” into specific symptoms: a long wait before a page first opens, slow-loading resources after the main page appears, low sustained transfer speed, pauses after using the connection for a while, or brief outages after switching networks. These can involve DNS resolution, connection setup, destination resources, transport quality, or recovery of an existing connection. Start by recording one symptom you can reproduce. Don’t compare just one test number. Connectivity Test duration can’t be converted directly into sustained transfer speed or used to predict access to every destination.
Check the basic network while disconnected, using the same accessible destination, content, and roughly the same time for comparison. Don’t transfer a large file while running a test, and don’t compare videos at different resolutions or pages of different sizes as if they were equivalent. Watch cellular data use and signal changes during cellular tests. On Wi-Fi, consider distance, interference, and use by other devices. If the basic network itself is unstable, changing rules usually won’t fix the access connection.
Compare servers and networks while keeping other variables fixed
Choose an existing server whose details have been confirmed, then visit two independent destinations on the same network. If only one is slow, consider the destination service or the path to it first. If several are slow, compare with another existing server. Then keep the server unchanged and test again on another network. This helps distinguish server-related, destination-related, and network access issues. Run only the tests you need; frequent speed tests add load and can make brief congestion look like a consistent pattern.
If Config is slow but Proxy works, check the matched rule and selected policy rather than immediately changing the protocol. Different resources may take different paths, making the main page fast while sign-in or images are slow. If Direct is fast but Proxy is slow, that comparison shows only that something on the current proxy path may be contributing; it doesn’t prove the client is malfunctioning. Check the server status, transport method, and network conditions before deciding whether to use another existing entry.
Separate DNS delays, connection setup, and sustained throughput
If the first visit takes a long time but the same page loads much faster afterward, DNS caching, connection reuse, or destination caching may be involved. Verify resolution and routing separately in the next section. Don’t treat one visit after clearing the cache as a stable speed result. If every new connection is slow, check TLS and transport details. If only sustained transfers stall, check for network changes, server disconnects, and whether the issue affects only certain types of traffic. Classify results by symptom instead of calling everything a timeout.
Different transport methods have different network requirements. For protocols that use UDP, reachability and stability on the access network may affect results. But a protocol name alone doesn’t tell you how fast it will be; it must match the existing server. Don’t switch to another type or change bandwidth and connection settings at random to chase a speed result. Incorrect details can make a working entry unusable. Create a separate comparison entry only when your service provider has supplied the complete settings for it.
Network changes, background apps, and long-lived connections
After switching from Wi-Fi to cellular, an existing connection may need to be re-established. Wait for the network to stabilize, then reopen the test page or make a new request in the app. An old page still failing doesn’t mean the new path will fail too. If new requests also don’t recover, note whether the On Demand conditions changed, then disconnect and reconnect once to test. Don’t switch networks and toggle the connection rapidly; overlapping connection attempts, cancellations, and system network changes make the results hard to interpret.
If slow speeds occur only at certain times, note the network, server, and destination, then repeat the same test at another time. There’s no need to run speed tests continuously. If only one app is affected, check whether it’s syncing or reusing an old session; after changing modes, start a new request. One comparison that reproduces the difference is more useful than a large set of unrelated measurements. Once you’ve confirmed an issue with an existing server or destination path, share redacted results with the relevant service provider for investigation.
DNS resolution issues, LAN access problems, and rules that don’t match
First confirm that DNS resolution is actually failing
A “server not found” message, an app failure before the connection starts, or a resolution error in the log may point to DNS. TLS errors, authentication failures, and errors returned by a destination don’t necessarily indicate DNS problems. Compare several independent domains and see whether the issue affects just one domain or a class of internal names. Replacing a domain with its IP address is usually not a valid test: HTTPS certificates, server names, and virtual hosting may still depend on the domain, so a failure after replacement doesn’t prove that the original resolution worked.
Confirm the basic network is working, then check DNS-related settings in the active Config, the [Host] entries, and whether the system uses additional DNS settings. If DNS is configured in several places, record their sources before removing anything. Resolution behavior can differ between the app, the system, and individual apps. A request record that omits a domain doesn’t necessarily mean no resolution occurred. Consider the request type, actual destination, and connection result instead of making major changes based on one missing field.
Check whether the DNS server is reachable
A custom DNS address must be reachable on the current network and in the current connection state. If the DNS server is reachable only through a proxy path, but establishing that path depends on the same server’s unresolved hostname, you may have a dependency problem. Start with the original Config if you’ve verified that it’s reachable, then change one DNS-related option at a time. Don’t pile on DNS addresses from unknown sources; adding more doesn’t give every request a reliable route.
If the problem appears only after switching networks, check whether a DNS service intended for the original network is still in use. For example, an internal name may work only with DNS on a particular Wi-Fi network, while cellular data can’t resolve it the same way. Also check that you haven’t entered a server-required Host or server name as a DNS address. After changing a setting, start a new request. Disconnect and reconnect if needed to rule out an old session, but don’t assume repeated reconnections clear every cache.
Rules are evaluated in order; check domain and address matches separately
DOMAIN matches a full domain, DOMAIN-SUFFIX matches a domain suffix, IP-CIDR and IP-CIDR6 match address ranges, and FINAL handles requests that matched no earlier rule. These rules use different kinds of information. If a domain rule doesn’t match, first check whether the request has a domain available for matching and whether an earlier rule already handled it. Don’t replace every domain rule with an IP range. A domain can resolve to multiple addresses, and an address may be shared by multiple services, so broad ranges can affect other destinations.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.com,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fc00::/7,DIRECT
FINAL,PROXYThis snippet intentionally shows an ordering issue: blocked.example.com matches the earlier DOMAIN-SUFFIX rule and uses PROXY, so the later REJECT rule for the same domain won’t take effect as intended. To handle it separately, put a more specific DOMAIN entry before the suffix rule. Make changes in a copy of your Config and verify the match with a real request. The domain is only a syntax example, not a test service. Apply address-range rules only after checking whether they fit your actual network and existing policies.
Troubleshooting LAN devices and internal domains
If a printer, network storage device, or internal service stops working after connecting, disconnect first to check whether the device is reachable on its own. Then determine whether you’re accessing a direct address or an internal domain. If the address works but the name doesn’t, investigate DNS first. If neither works, check the handling policy for LAN addresses, network isolation, and app permissions. Broadcast or multicast discovery differs from ordinary unicast requests. Adding a DIRECT rule may not restore automatic discovery, so test access to a known address separately from device discovery.
In Settings, check the app’s Local Network permission and confirm that the devices are on the same LAN. Guest Wi-Fi and network isolation can prevent devices from seeing one another. If you use a fixed mapping in [Host], make sure the address still belongs to the intended device, especially after switching networks or a router changes its assignments. Don’t permanently enter an unverified address just to restore access temporarily. After correcting the issue, restore DNS settings one at a time to identify the change that helped and avoid keeping overlapping temporary settings.
Battery drain, heat, and frequent background reconnections
Compare similar usage; don’t rely on percentages alone
The percentage shown on the system battery page is relative to the selected time period, not a fixed amount of energy used by one app. Total device usage, screen brightness, signal strength, background sync, and activity from other apps can all change the percentage. Check activity periods in Settings, then compare them with what you were actually doing when the issue occurred. Shadowrocket appearing in the list alone doesn’t prove anything is wrong. Don’t directly compare time periods with very different workloads.
For a short comparison, keep the network, screen state, foreground app, and activity as similar as possible. Note whether you’re transferring a lot of data, updating a subscription, or running diagnostics. If the device still gets noticeably hot while disconnected, check other ongoing activity and the basic network instead of changing rules first. Battery health, device temperature, and charging status also affect the experience. The goal is to find a repeatable difference, not to calculate a fixed amount of battery use for the client from one observation.
Check for weak signals and reconnection loops first
A weak signal, poor Wi-Fi coverage, or frequent network switching can repeatedly rebuild connections. If the device keeps moving between networks, stay on one stable network and observe the result. If a particular server keeps failing, compare it with another existing entry that has been confirmed to work. Repeated attempts may generate extra network activity when the connection can’t be established, so address the failure first. Don’t shorten retry intervals just to keep the connection indicator on, and don’t leave unused tests running repeatedly in the background.
Check whether On Demand keeps triggering under the current network conditions, including whether the connection turns back on after you manually disable it. You can temporarily turn off On Demand to establish a baseline, then connect manually for testing. Restore the conditions you need afterward. Automatic connection rules should match your actual needs; don’t enable them for every network during troubleshooting and forget to restore them. If the system has other automatic VPN conditions, record those too so you don’t mistake behavior from two sources for repeated reconnects by one app.
Check actual requests; don’t mistake background traffic for a fault
System sync, messaging connections, and other background requests may continue after you close a foreground app. If available connection records show ongoing activity, identify its source and timing, and check whether it coincides with photo, file, or other sync tasks. Ongoing traffic alone doesn’t prove the connection component is faulty. Investigate the relevant domain, rule, and server path only if requests are repeatedly failing and retrying. Don’t bulk REJECT requests just to reduce visible traffic; blocking a dependency may cause even more retries.
Some diagnostic settings add logging overhead. Enable them only as needed, reproduce the issue once, save redacted information, and then restore your usual settings. Don’t leave detailed logging, continuous tests, or frequent manual subscription refreshes running. Log files may contain personal network information such as domains and addresses; review them before sharing. If an issue appears only when a particular diagnostic option is enabled, disable that option alone for comparison while keeping other variables unchanged.
Rules, workload, and how to restore settings
If battery use increases noticeably only with a particular app, first check whether that app is doing intensive work, then see whether related requests are repeatedly failing. An unsuitable REJECT rule or routing choice in Config may make an app reconnect repeatedly, but fewer rules don’t automatically mean lower battery use. Adjust one entry for a confirmed failed request and check whether both the feature and request recover. Don’t remove an entire rule file or disable necessary TLS verification; those changes go far beyond the battery issue you’re investigating.
A useful comparison records the starting state, activity, connection status, current network, and result. You don’t need to share a complete usage history. If the issue persists with a stable network, a confirmed working server, and normal settings, try a simplified copy of Config and note whether it occurs only with a particular activity. If the device continues to heat abnormally, stop high-load tasks and continuous diagnostics, and follow system temperature warnings. Continue troubleshooting after the device returns to a normal temperature; don’t let testing add to the load.
Issues after an update, Config recovery, and iPad-specific checks
First identify whether the change was in the app, system, or Config
A problem occurring after an update doesn’t mean the update caused it. Recall whether you also updated a subscription, changed Config, switched networks, or changed system permissions at the same time. Record app updates, system changes, and Config changes separately, then run the minimum tests described above. Don’t guess at a cause you can’t verify, and don’t repeatedly reinstall before making a backup. If the error is directly associated with a particular Config, compare its contents instead of starting with purchase status.
Get and update the app through the App Store. To verify the product, follow the authenticity check guide and confirm the official icon, developer Shadow Launch Technology Limited, and app ID 932747118. Check the App Store page for system requirements. If the app opens normally but a server fails, you’ll usually also need to check connection details and service status. A valid purchase record doesn’t mean a subscription is still active or a remote server is still available.
Back up first, then use reversible recovery steps
Before changing or restoring anything, confirm that you have usable copies of your server entries, subscription sources, and Config. Exporting Config doesn’t necessarily back up all server authentication details. Check the actual interface and restore results to see whether syncing is enabled and what it includes. Backups may contain sensitive fields, so store them somewhere you control. See the Config backup and migration guide for the procedure, but verify the options on your current device before proceeding.
To recover, first create an existing server entry with clear connection details, complete system authorization, and verify basic connectivity. Then restore Config, followed by other settings one at a time. Importing all old content at once makes it difficult to identify the cause if the problem returns. After restoring each type of content, repeat the same test and record the result. If the issue reappears, investigate the content restored most recently. This is easier to roll back than deleting everything and re-entering details from memory, and helps preserve information that still works.
Don’t assume iPad will behave exactly like iPhone
If the same details work on iPhone but fail on iPad, first confirm that both devices are actually on the same network. The iPhone may be using cellular data while the iPad is still connected to Wi-Fi that requires authentication. On an iPad with cellular connectivity, check its actual connection and permissions too. Once the network conditions match, compare the selected item in Home, Global Routing, and the active Config. Don’t compare names alone; check the address, port, authentication, and transport fields.
On iPad, portrait or landscape orientation, split view, and window layouts may place controls differently from iPhone, but that doesn’t mean a feature is missing. Look for the relevant options using the actual interface labels, such as Home, Config, and Settings, rather than relying on screenshot coordinates. VPN authorization must be completed separately on each device; allowing it on another device doesn’t authorize the current iPad. Check Local Network permission and any device management restrictions in iPad Settings as well.
Handle purchase restoration and Config recovery separately
After changing devices, check the purchased items in the App Store using the original purchase account and follow the page to get the app again. Availability, compatibility, and purchase entitlements are subject to the App Store listing. Getting the app back doesn’t automatically restore server entries, subscriptions, or Config. See the restore purchased app guide for purchase recovery, and check your own saved copies to restore Config. Don’t pay again to fix a connection problem; first determine whether you’re missing the app entitlement or your usage data.
If the iPad only fails when accessing printers or internal devices, return to the DNS and LAN sections to check permissions, network isolation, and internal name resolution. If the issue occurs only when the screen is locked or after switching networks, revisit the battery and On Demand checks. Finally, prepare a redacted report with the device type, network, whether a connection was established, the selected mode, failure stage, and results from changing one variable at a time. Keep the error message, but remove passwords, UUIDs, full subscriptions, and QR codes to document a reproducible issue without exposing credentials.