The connection switch won’t stay on: check the system connection first
If the switch in Home turns off immediately after you enable it, the connection setup hasn’t completed. This is different from a switch that stays on while websites fail to load. Check whether iOS prompts you to add a VPN configuration, whether an error appears, and when the switch turns off. Don’t rely on the status bar icon alone; its placement can vary with the system layout. Check the status in Home and keep the exact error message instead of repeatedly tapping the switch.
Tell authorization issues, configuration conflicts, and connection failures apart
The first time you connect, iOS asks for permission to add a VPN configuration. If you dismissed the prompt, return to Shadowrocket and try again, then approve it when prompted. Enter your device passcode in the system dialog. Next, open Settings and check whether the VPN configuration exists and which one is active. Having multiple VPN configurations isn’t necessarily a problem, but starting another VPN may interrupt the current connection. Stop any other active VPN and test Shadowrocket by itself. Don’t delete all network settings.
If the device is managed by a school or employer and the authorization switch is unavailable, a configuration can’t be added, or iOS reports a management restriction, ask the administrator about the policy. Deleting the app usually won’t remove the restriction and may erase local configurations. On a personal device, check for automatic connection rules: if the connection turns back on right after you stop it manually, the switch may be working as intended and On Demand may be triggering. Note the conditions, then temporarily disable the relevant automatic connection behavior. See Battery drain and On Demand.
Use a minimal configuration to narrow down the issue
In Home, make sure you have a server with all required settings and explicitly select it as the default. Importing a list without selecting a default server isn’t enough for a valid test. Temporarily set Global Routing to Proxy to rule out interference from rule files. If the switch still turns off immediately, check authorization, the system network extension, and server fields first. If it stays on, inspect the original Config and its policy references. Restore your previous routing setting after testing.
After saving your current .conf file and any necessary server details, disconnect normally and reopen the app to test again. If the issue started after switching networks, make sure the current Wi-Fi connection has completed its sign-in process or that cellular data can load a regular webpage. A proxy connection may fail if it starts before network sign-in is complete. Disconnect, finish signing in, and then start Shadowrocket. A sign-in page that won’t load doesn’t necessarily mean the server is down. Don’t enter subscription credentials into an unfamiliar prompt.
When to rebuild the system configuration
Consider rebuilding the system VPN configuration for Shadowrocket only if the network works, the default server is clear, and authorization continues to fail. First back up the in-app configuration, disconnect, and turn off On Demand. Identify the correct entry in system Settings. Remove that entry, then return to the app and reconnect so the system can request authorization again. This addresses problems in the system connection configuration; it won’t fix an incorrect address, port, or password. Don’t make it your first step for every issue.
If the switch started turning off after a system update, restart the device and retest with a minimal configuration instead of reinstalling repeatedly. Note whether the authorization prompt appears, whether a configuration is created, and whether the connection stays on. Restore your original rules, automatic connection behavior, and other settings one at a time, testing after each change. If enabling a setting causes the switch to turn off again, keep that result and check the setting’s dependencies and configuration. See the FAQ for common authorization questions.
Connected but no internet: check four layers in order
A switch that stays on only confirms that the system connection is active; it doesn’t prove the selected server can forward traffic. Disconnect Shadowrocket and use the same network to visit a website that normally works. This checks the basic network, Wi-Fi sign-in, and cellular data access. Reconnect, then check the default server, Global Routing, DNS, and rule matches in order. Test the same destination at each step and note whether it times out, fails to resolve a name, shows a certificate warning, or returns a server error. Each points to a different cause.
Check the server, then compare the three routing modes
In Home, check that the default server is still the one you expect, especially after updating a subscription, deleting an old entry, or switching groups. Use Connectivity Test to check the connection, but don’t treat one test result as proof that every service will work. If the test succeeds but a destination won’t load, the issue may be with the destination, DNS, or protocol transport. If you have another working server, select it as the default for comparison. Reconnect after switching so you don’t mistake the old connection’s behavior for the new server’s result.
| Option | What it tells you | How to interpret the result |
|---|---|---|
| Config | Processes requests according to the rules and policies in the current configuration. | If only this mode fails, check the rules and policy references. |
| Proxy | Routes most traffic through the proxy path, subject to system and app settings. | Use it to narrow down rule-related issues, not as a permanent fix. |
| Direct | Routes most traffic directly. | Compare with the result when disconnected to check the underlying network. |
These tests aren’t a recommendation to use one mode permanently; they create comparable conditions. If Direct works but Proxy doesn’t, check the server settings and network reachability. If Proxy works but Config doesn’t, check rule order, policy names, and the active configuration file. If all three fail, check the underlying network and DNS before adding more rules. Once you’ve isolated the issue, restore the Config setting that suits your needs and make sure it references an existing policy.
Check rules in match order, not just by keyword
Rules in [Rule] are generally evaluated in order, so a broad rule near the top may match before a more specific rule below it. This snippet illustrates rule order only; example.com is a demonstration domain and isn’t a replacement for your full configuration. DOMAIN-SUFFIX matches the domain and its subdomains. GEOIP checks information associated with the destination IP. FINAL is a fallback when no earlier rule matches. Consider the DNS result, rule scope, and selected policy together. Seeing PROXY in the file doesn’t prove that a request will use the proxy.
[General]
bypass-system = true
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYIf your configuration uses custom policy groups, check that each group name is spelled correctly, still contains available entries, and hasn’t changed selection after a subscription update. Save a copy before editing so you have a known-good version to restore. If only one website fails, test with a temporary rule for that domain. Decide whether to keep it only after testing. Don’t mask the issue with a broad DOMAIN-KEYWORD rule or move FINAL above the rules that follow it.
Check browser behavior separately from system status
A browser may retain an old page, existing connection, or previous DNS result. After changing modes, make a new request rather than watching the old loading indicator. Close the failed page and reopen it; if needed, test a destination you haven’t visited before and compare the result in another app. If only one site fails, check its status and certificate before resetting connections. If several domains fail while the connection remains active, check DNS next. See the DNS troubleshooting section.
Server timeout: check settings and the connection path
A timeout means no expected response arrived before the waiting period ended. It doesn’t necessarily mean the password is wrong or the server is down. The connection may have stalled at DNS resolution, address reachability, port connection, TLS handshake, or protocol authentication. Note the test type and exact error, and check whether the timeout came from Connectivity Test or an actual webpage request. Some servers don’t respond to certain probes, so confirm with a real request before treating a failed probe as a reason to delete a configuration.
Check each field against your existing server details
Open the relevant entry under Add Server and compare each field with the details from your service provider. Don’t add a path, spaces, or a protocol prefix to the server address; use the port specified for that server. Preserve the exact case and characters in passwords, UUIDs, and other credentials, and watch for trailing line breaks when pasting. Don’t substitute fields just because they look similar, and don’t paste a subscription URL into the server address field. After importing a QR code, check the protocol and key settings. Successful import only means the data was recognized, not that the settings work on your current network.
| Protocol | Check these fields | Common misdiagnosis |
|---|---|---|
| Shadowsocks | Address, port, encryption method, and password. | Changing the password without checking the encryption method. |
| VMess / VLESS | UUID, transport type, and matching TLS settings. | Assuming a correct UUID means the transport settings can be ignored. |
| Trojan | Password, port, TLS, and server name. | Treating the connection address and certificate verification name as the same field. |
| Hysteria2 | Authentication, TLS, and UDP availability on the current network. | Assuming that working webpages mean the UDP path also works. |
| WireGuard | Key, peer address, and allowed address ranges. | Overlooking changes to the route range or peer settings. |
This table is a checklist, not a universal set of values. Enter fields according to the actual configuration for your server. See Protocols and settings overview for more details. If your server details came from a subscription, try updating it and comparing the fields before editing them manually. Changes to subscription-generated entries may be overwritten on the next update, undoing a temporary fix.
Check TLS, transport, and UDP separately
For TLS handshake or certificate errors, check that the device’s date and time are correct and that the server name matches the details provided for the server. The connection address and certificate verification name may differ; enter only the values specified in your configuration. Don’t leave certificate verification disabled to bypass an error. That can hide a name mismatch, expired certificate, or connection to the wrong host. For transports that require settings such as Host or a path, make sure those match the server configuration too. Checking only the address and credentials isn’t enough.
A working webpage only confirms that its particular path works; it doesn’t test every UDP use case. If browsing works but real-time communication or another UDP-dependent feature fails, check protocol support, server requirements, and whether the current network permits that transport. When comparing another working configuration, change only one variable at a time: for example, the server on the same network, or the network with the same server. Changing the protocol, network, and DNS together won’t reveal what fixed the issue.
Compare networks to narrow down the cause
A timeout on Wi-Fi but not on cellular may point to DNS, port, or transport restrictions on that Wi-Fi network. The two networks may also resolve the server to different addresses, so compare the resolution result and connection target before drawing conclusions. If the same server fails on multiple networks while other servers work, ask your service provider whether that server endpoint has changed. Share the protocol, exact error, and conditions needed to reproduce the issue. Don’t send passwords, keys, subscription tokens, or a QR code containing all your settings.
After confirming the server settings, return to a local test: select the default server, temporarily use Proxy, disconnect and reconnect, then open the same destination. If it works, restore Config and automatic connection settings one at a time. If it still fails, keep a clear result such as “basic network works, other servers work, this server times out on two networks.” That’s more useful than continually increasing the timeout. A longer wait only delays the error; it doesn’t fix an unreachable address, wrong port, or mismatched transport settings.
Subscription update failed: separate download from parsing
A subscription update involves at least two steps: fetching remote content and parsing it into server entries. An unreachable URL, expired authentication, and an unsupported content format require different fixes. Before troubleshooting, keep your working entries and configuration. Note the exact error, whether existing entries remain, and whether the failure occurred during a manual or automatic update. Don’t delete the whole subscription just to retry. If the remote address is temporarily unreachable, deleting local entries may leave you without a usable connection.
Check the URL and access requirements
Get the subscription URL from your own service provider and confirm it’s intended for importing into a client, not a login page, help page, or account portal. Check the beginning, path, and query parameters when copying; don’t copy only the visible portion. A subscription token grants access, so don’t paste it into search boxes, public notes, or public screenshots. Line wrapping in a displayed URL isn’t necessarily a problem, but inserted spaces, missing parameters, or copied punctuation can cause an update to fail.
If the response is a login page, access confirmation page, or ordinary webpage, the request reached content other than the expected subscription data. Check the provider’s import instructions and your account status instead of repeatedly changing protocols in Shadowrocket. For an authentication error, check whether the URL was reset or expired. The app can’t restore a token revoked by the remote service. When contacting the provider, share the error status and approximate time, not the full access URL.
Check whether the update depends on the current connection
Some subscription URLs can’t be reached directly on the current network but may work through a valid connection you already have. Compare update results while disconnected and connected, and note the default server used. If updating works only while connected, the issue is with the subscription’s download path. If it works only while disconnected, the proxy route or its DNS settings may be affecting the download. Don’t assume every subscription needs the same connection method; check how this URL behaves on your network.
Be especially careful with circular dependencies: if the remote subscription is temporarily unavailable and every local entry is invalid, repeated updates won’t create a working server. Restore a known-valid entry from your own server details or ask the original provider about access requirements. Shadowrocket uses server details you already have; it doesn’t provide connections. Make sure manual updates work before configuring automatic updates, and don’t assume an automatic update failure means the subscription itself is corrupted.
Check the format if the download succeeds but the list looks wrong
If content downloads but can’t be parsed, produces an empty list, or is missing protocol fields, check that its format matches the import method. A server subscription and a .conf configuration file serve different purposes: the former mainly provides server details, while the latter may also include routing, DNS, and other settings. Don’t treat them as interchangeable or choose an import option based only on the file extension. Content may include credentials; if you inspect it manually, check its structure without copying the full contents into an external tool.
A change in the number or names of entries after an update doesn’t necessarily mean something went wrong; the remote content may have changed. Check that the new list contains the entry you need, then verify the default server and custom policy groups. If a rule references an entry that disappeared, the update may succeed while internet access fails. In that case, switch to routing troubleshooting instead of repeating the download. Note the differences before and after the update, then restore valid references so you don’t mistake two consecutive issues for one.
After fixing the issue, keep a recoverable copy of your configuration and securely save a note about the source of your subscription. Store backups somewhere protected, not alongside public documents. If you exposed the full subscription URL, contact the original provider to rotate the token, then update the URL in the app. Deleting a public screenshot alone may not invalidate the old credentials. For the full import workflow, see the setup guide. This section covers issues with downloading, parsing, and referencing subscription content.
Slow speeds and intermittent drops: compare like with like
Slow speeds can mean a long wait before a page opens, low download throughput, repeated video buffering, or brief interruptions during a network switch. These symptoms have different causes, so identify which one you’re seeing before testing. Connectivity Test latency doesn’t measure large-file throughput, and a webpage that loads quickly doesn’t prove a long-lived connection is stable. Use the same accessible test destination under similar conditions. Don’t compare results from different times, websites, and networks to decide which server is better.
Separate local network, server, and destination issues
Disconnect first and check whether the current Wi-Fi or cellular network is also slow. Wi-Fi signal bars show only part of the wireless picture; they don’t confirm that upload speed, congestion, and packet loss are all fine. Move closer to the access point, pause bandwidth-heavy activity on other devices, and test the same destination again. If the direct connection is already slow, address the local network first. Changing proxy protocols or rules won’t usually fix wireless interference, insufficient bandwidth, or an incomplete network sign-in.
Once the underlying network works, keep the network and destination unchanged and switch only to another working server you already have. If only one server is slow, check its route, load, or server-side limits. If every server is slow for the same destination, the issue may be with the destination or a shared network path. When contacting your own provider, include the network type, destination category, and whether only one server is affected. Don’t send credentials. Avoid running many simultaneous tests; the tests themselves use bandwidth and can skew the results.
Distinguish DNS delays, handshake delays, and slow transfers
If a page is slow to open the first time but much faster on the second attempt, DNS caching, connection reuse, or destination caching may be involved. That doesn’t immediately point to a bandwidth issue. Note whether the delay happens before the page starts loading or after. If several new domains stall at the start, check DNS. If name resolution finishes but the connection still takes a long time, check server connectivity and TLS. If loading starts quickly but the transfer remains slow, investigate congestion, server throughput, and destination limits.
Comparing Config with Proxy can also help narrow things down. If Proxy works but a particular destination is slow in Config, a rule may be sending the request along a different route, or a custom policy group may have selected another server. Check the active file and policy references, not just whether the default server name matches. If a DIRECT rule matches the destination, the selected proxy server may not be used for that request. Start a fresh request for each comparison so an existing long-lived connection doesn’t carry over the old route.
Handle network switches and interrupted long-lived connections
When switching from Wi-Fi to cellular, the device’s address and network route may change, and existing long-lived connections may not survive. Distinguish a brief recovery delay from a connection that never returns. If new webpages load after the switch but an old session is stuck, restart that session. If all requests stop, disconnect and reconnect Shadowrocket. Note whether the issue happens with every network switch, and check whether On Demand conditions keep triggering as the network changes.
If interruptions occur only in real-time communication, games, or another specific service, check whether it relies on UDP and whether the server, protocol, and network support it. Browsing normally doesn’t rule out a transport issue. Don’t change MTU or other low-level settings without evidence. If an adjustment is warranted, record the original value, change one setting at a time, and retest the same service. Revert it if you can’t confirm an improvement, to avoid ongoing side effects in other situations.
End testing with a clear finding, such as “On the same Wi-Fi and destination, only server A has poor sustained throughput” or “First visits to new domains are slow, but speeds are normal once connected.” A specific result points to the next step. A single fastest reading isn’t very useful; also note whether repeated tests are consistent, whether reconnections occur, and whether background tasks affect the result. When finished, stop temporary probes and restore your original Config so diagnostic traffic doesn’t affect everyday use.
DNS issues: separate resolution from connection failures
DNS converts domain names into addresses needed to connect. The server itself may have a domain name, and so may the destination website. A DNS failure can therefore prevent the proxy server from connecting or affect only certain websites. Common signs include new domains failing to open, existing connections still working, or different results on different networks with the same server. Browser errors can offer clues, but a page that won’t load doesn’t prove DNS is at fault. First rule out basic network problems and an unreachable server port.
Start with a known-good DNS baseline
Save your current configuration before making changes, and note the original DNS-related settings in [General]. The example below uses system DNS as a starting point for diagnosis; it won’t suit every network or every domain. First check that system DNS works on the current network, then decide whether to keep using it. Don’t add several unverified resolvers at once. The more complex the configuration, the harder it is to tell which path a request took and whether the failure came from the resolver or the connection to it.
[General]
bypass-system = true
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXYIf the original configuration includes remote DNS, encrypted DNS, or special domain handling, account for dependencies between those settings when restoring it. Changing one line may not restore the baseline if other sections still affect the result. If you’re unsure about an option, copy the file and create a separate test configuration before removing or restoring settings one at a time. See How .conf files are organized. Don’t combine snippets from multiple sources without understanding their scope.
Don’t rely on opening an IP address in a browser as your only test
HTTPS websites typically require the correct domain name, certificate name, and request details. Entering an IP address directly in a browser and getting an error doesn’t prove that DNS works or is broken. Likewise, reaching one IP doesn’t prove that the original domain resolves correctly. Instead, use request or diagnostic details visible in the app to distinguish a name resolution error from a connection failure, and compare multiple destinations. Logs may include domain names; redact them as needed before sharing.
A domain can resolve to several IPv4 or IPv6 addresses, and different networks may return different results. If the issue persists on only one network, note the address type used and the connection result, then check that path. Don’t assume IPv6 is the cause just because it appears, or make global address-family changes as a routine fix. Diagnostic changes need a comparison and a record of how to revert them. If only one address for one destination is unreachable, investigate that route instead of changing behavior for all requests.
Check Host overrides, rules, and caching
A static mapping in [Host] can keep a domain pointed to an old address even after external DNS changes. If only a few fixed domains fail, check for relevant mappings and verify their source and purpose. Don’t add a permanent IP mapping to work around a temporary issue; destination addresses can change, and certificates or service routing may be affected. Back up the configuration before removing a mapping. Retest before deciding whether to make the change permanent.
Rules can also change the route used after a domain resolves. DOMAIN rules match domain names, while GEOIP and IP-CIDR rules use address-related information, so their match conditions differ. If a domain resolves to an unexpected address range, the resulting policy may change too. Check both what address was resolved and which policy was ultimately used. The presence of a GEOIP rule doesn’t mean every destination will be routed the same way. Don’t use a broad rule to mask an unresolved DNS issue.
After changing settings, make a new request to verify the result; existing connections or cached data may retain the old behavior for a while. Reconnect, reopen the test page, and compare with a domain you haven’t visited before. You don’t need to reset all network settings every time. Once new requests work reliably, restore any custom DNS options you still need. Keep the final configuration minimal, with a clear purpose for each setting, so obsolete workarounds don’t carry over when you migrate it.
Battery drain and On Demand: find what’s keeping the connection active
Shadowrocket showing activity in the system battery report doesn’t necessarily mean the app is running unnecessary tasks. While a proxy connection is active, traffic from other apps also needs to be handled. Consider usage time, traffic volume, signal strength, and whether the connection keeps rebuilding. Note whether battery use occurs while idle, streaming video, transferring files, or switching networks, then compare under similar conditions. Usage varies from day to day, so battery percentage alone can’t tell you how much extra power the app used.
Check reconnects, probes, and bandwidth-heavy tasks first
On a weak network, frequent reconnects may repeatedly trigger connection setup, DNS resolution, and session recovery. Check connection stability before optimizing rules. For comparison, use a stable network and the same server you already have, pause unnecessary downloads and cloud sync, and stop continuous probes started for troubleshooting. Don’t run multiple speed tests just to observe battery use. Speed tests generate real traffic and change the conditions being measured, so they don’t represent everyday idle use.
Continuous logging, frequent connection tests, and repeated failed retries are also worth checking. If you increased logging for troubleshooting, return it to normal afterward and handle records containing sensitive information carefully. Check whether a background app repeatedly requests domains that can’t be reached, or whether a sync keeps retrying uploads on an unstable connection. Fix the underlying network issue rather than blaming the proxy switch. Matching the source of requests to periods of activity helps identify which layer to adjust.
How On Demand interacts with the manual switch
On Demand triggers connections when its conditions are met. If the connection turns back on shortly after you switch it off manually, check whether a trigger condition still applies instead of assuming the switch is broken. Note the network conditions in the rules and whether the device is switching networks frequently. For comparison, temporarily turn off On Demand while keeping other settings unchanged, then check whether manual connections stay stable. Restore it afterward if needed so you don’t accidentally leave automatic connections disabled.
If you need to change the conditions, start with simple, easy-to-understand rules. Confirm that a rule triggers on the intended network and doesn’t trigger under other conditions before adding more. Overlapping rules may behave differently from what you expect. Don’t change the network name, trigger behavior, and server selection at the same time; you won’t know which change helped. On school- or employer-managed devices, check the management policy too so you don’t confuse a system-enforced behavior with your On Demand settings.
Run a repeatable battery comparison
Choose similar observation periods and keep screen use, network type, server, and background tasks as consistent as possible. Record connection stability, device heat, and system-reported activity. Look for a repeatable pattern rather than a percentage that applies to every device. If only one server causes frequent reconnects, follow the Server timeout guidance. If the issue occurs only when switching Wi-Fi networks, check network switching and automatic connections instead of replacing the entire configuration.
Overly broad rules can send requests through a remote route even when they could be handled directly, but understand the original intent before changing them. Check how frequently used services are matched and correct obvious routing mistakes. Don’t switch every request to DIRECT just to reduce traffic. Keep policies that meet your privacy and routing needs. The goal is to reduce unnecessary retries and incorrect routes, not to trade accuracy for a temporarily better-looking battery report.
If the device continues to get unusually hot or drain battery after disconnecting, investigate system update tasks, other app activity, and battery health at the system level. The fact that Shadowrocket was on at the same time doesn’t prove it caused the drain. If the issue is repeatable on a stable network with low traffic and diagnostic probes off, record the conditions and keep a redacted log, then follow the configuration recovery steps in the final section. A repeatable comparison is more useful than reinstalling without keeping notes.
Post-update issues and iPad: keep a baseline before restoring
“The problem started after an update” describes timing, not necessarily cause. A subscription refresh, system update, default server change, or network switch may have happened around the same time. List what actually changed, keep your current configuration and exact error, then retest with a minimal setup. Don’t delete the app without a backup: local servers, configurations, and preferences may be lost and might not return after reinstalling. Start with reversible recovery steps and consider reinstalling only as a last resort.
Check app, system, and configuration changes separately
First confirm the underlying network works, select a known-good server, temporarily use Proxy, and make a real request. If the minimal setup works, restore Config, custom policies, DNS, and On Demand one at a time. If the issue returns after a change, investigate that setting first. If the minimal setup also fails, continue with the authorization, timeout, and DNS checks earlier on this page. Don’t immediately restore the entire old configuration; that may bring the unresolved issue back.
iPhone / iPad app updates are handled through the App Store. Check the App Store listing for current system requirements. If you need to download the app again, verify the developer name, Shadow Launch Technology Limited, the official icon, and app ID 932747118. The iPhone / iPad app costs $2.99 on the App Store as a one-time purchase; the Mac, Windows, Android, and Linux versions are free. See How to restore a previous purchase for purchase recovery and platform download instructions. Check purchase status and local configuration backups separately.
System security prompts when reinstalling on desktop and Android
To reinstall on Mac, Windows, Android, or Linux, go to the download page for all platforms and choose your device. Installers are provided from this site under /dl/shadowrocket/. On a Mac, check About This Mac to see whether it has Apple silicon or an Intel processor; don’t guess based on its appearance. Keep your existing configuration before reinstalling, and confirm the download source and file before opening it. Replacing the app won’t fix a server issue you haven’t diagnosed.
These platform installers aren’t code-signed, so the system may block them the first time you open them. If SmartScreen appears on Windows, confirm the file came from this site, then select “More info → Run anyway.” On Mac, choose “Open Anyway” for the app under Privacy & Security. On Android, allow “Install unknown apps” only for the app you’re using to install, then revoke that permission when you’re done. Linux AppImage files need execute permission. See the installation prompt guide for more details and commands. Don’t disable system protection globally to get around a prompt for one file.
iPad landscape layout, purchase status, and configuration transfer
In landscape, iPad may show the list and details side by side. Check that the item you’re editing is also the current default server; opening an entry’s details doesn’t select it automatically. After rotating the screen, use the selection and connection status in Home to confirm which server is active. Don’t infer the connection target from the entry that remains open in the details pane. If a layout change makes a control hard to find, return to the list and follow the getting started steps to check each setting.
If you purchased the app on iPhone, use the Apple ID from that purchase to check App Store purchases on iPad. Restoring the app purchase doesn’t automatically transfer server entries or .conf files. Check existing subscriptions, the default server, routing mode, and system authorization on each device separately. A working connection on one device doesn’t rule out authorization or network issues on the other. Import the required details first, test the connection, and then restore additional settings so you don’t bring over too many unknown differences at once.
If iPad and iPhone behave differently on the same Wi-Fi, compare their active configurations and DNS settings first. Then check cellular data, automatic connection conditions, and device management policies. Once the configurations match, retest using the same destination and server. Configuration files and QR codes may contain credentials; transfer them through a secure personal method and delete temporary copies afterward. See iPad usage and configuration transfer for layout and purchase details.