Shadowrocket
Troubleshooting

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

If the connection switch turns off immediately after you turn it on, first check whether iOS allows the VPN configuration and whether another connection profile is competing for control. This does not yet tell you whether the server is available: if the system tunnel was never established, requests may not have reached the server at all. Check whether a system prompt appears, then distinguish between authorization not completed, the configuration failing to start, and the connection stopping shortly after launch. These are not all server timeouts.

Complete authorization, then check the switch

The first time you connect, iOS may ask to add a VPN configuration. Confirm that the prompt is for the Shadowrocket you are using, follow the system steps to authorize it, then return to the app and check the switch. If you previously denied the request, try connecting again and complete authorization. If no prompt appears, search for VPN in Settings and check whether the corresponding configuration is already listed. Menu locations may vary by system version; follow the labels shown on your device.

A VPN configuration in iOS is not subscription content or a server list. Deleting it will not automatically fix server settings and may mean the app needs authorization again. First confirm which app the configuration belongs to, so you do not accidentally remove a work or school profile. Managed devices may restrict adding or editing VPN configurations. If an option is unavailable, check with your device administrator; repeatedly tapping the switch will not override a management policy.

After authorizing, stay in the app, turn the connection on once, and wait for the status to settle. Then check in Settings whether the VPN shows as connected. Note whether the switch turns off before authorization, after authorization, or only after you switch to another app. If it stops only in the background, check On Demand behavior and system status next. If it stops immediately in the foreground, start with the error shown in the app rather than changing web rules or DNS.

Check for automatic connections and configuration conflicts

If the connection turns back on after you switch it off, check whether On Demand is enabled and whether its conditions match the current network. On Demand can make the switch behave differently than expected; that does not necessarily mean it is broken. For a clear comparison, temporarily disable your own On Demand conditions and connect manually once. Note the original settings and restore them after testing. Do not change Wi-Fi, domain, and server settings at the same time, or you will not know which change made a difference.

Check whether another VPN configuration on the system is also connecting automatically. For the test, leave only the connection you need to check active; first disable automatic triggers for other configurations, then try Shadowrocket again. If a managed configuration cannot be changed, leave it as is and ask the administrator. If the switch now stays on, test actual access next. A connected VPN status confirms the tunnel is up; it does not prove that every domain, protocol, or server is working.

If you have multiple configuration files, make sure the expected file is active instead of just checking whether it appears in the list. Keep a copy of the original and test with a server you have already verified and a simpler configuration. If the simplified configuration starts but the original does not, inspect recently changed sections and formatting. A successful subscription update does not prove that the configuration syntax is valid; these are separate processes.

Restore service while preserving your data

After confirming there are no unsaved edits, quit the app normally and reopen it. If needed, restart the device and check whether the system status recovers. After restarting, test the basic network first, then turn on the connection. This helps distinguish an existing network issue from a connection startup issue. If the error persists, note the exact on-screen message, the steps that trigger it, and the network type. “It won’t open” lacks useful diagnostic detail and may lead to repeating checks you have already done.

Rebuilding the system VPN configuration should come after the checks above, and only if the configuration clearly belongs to you. After rebuilding it, request authorization again, then check On Demand and the selected server. Reinstalling may affect local configurations, history, and custom settings, so first confirm you have information you can restore. See Restore a Previous Purchase for purchase and redownload details, and About the VPN Configuration Prompt for how system authorization works.

Connected, but no internet access: check routing and egress separately

If the switch stays on but web pages will not load, establish three points of comparison: whether basic access works with the connection off, whether every destination fails when it is on, and which option is selected in Global Routing. A connected status means the system tunnel is up, but each request still depends on DNS resolution, rule matching, egress selection, and server forwarding. Check these in order; you are more likely to find the cause than by changing the server, rules, and DNS all at once.

First establish the scope of the issue

Turn the connection off and visit a regular web page you can normally access. Check whether the Wi-Fi network requires sign-in. If basic access also fails, address the router, signal, or network sign-in first, then return to the app. Turn the connection on and test the same destination, then try a different one. Testing only one site can make a site outage, account issue, or regional service problem look like a client issue.

Check whether the problem affects the browser and the app where it appeared in the same way. If only one app fails, consider its cache, account requests, independent DNS resolution, or connection reuse. If all apps fail, a shared egress or DNS path is more likely. Test on the same network and around the same time; do not compare results from different Wi-Fi networks or servers with a success from much earlier.

If the network has a sign-in page, turn the connection off and complete sign-in before reconnecting. Before authentication, the system may show that Wi-Fi is connected even though only sign-in pages are accessible. Subscription updates, server tests, and web access may all fail at this point. Do not keep changing rules to work around it. First confirm that the device has normal basic network access.

Use Global Routing for a focused comparison

The Global Routing options Config, Proxy, and Direct correspond to configuration rules, proxy routing, and direct connections. Note the original option, then compare briefly to see whether the issue is related to rules. Direct helps check the direct route; Proxy helps check the proxy egress; Config shows how requests behave when rules are applied. These are diagnostic conditions, not guaranteed fixes.

If a destination works under Proxy but fails under Config, check whether a rule is sending it to a different policy. If Direct works but Proxy fails across the board, check the selected server and its settings first. If all three options fail, do not immediately assume DNS is at fault; rule out basic network access, destination issues, and stale connection state. After each switch, send a new request so the browser does not reuse the previous connection.

Use the app’s connection logs or diagnostics to check the destination domain, matched rule, and final policy. The entry name may vary by app version. If you see REJECT, confirm whether the rejection comes from an expected rule. If you see DIRECT but the destination should use your own server, check the rule order. A rule being present in the file does not mean it will be applied.

Find configuration issues by checking rule order

Rules are generally evaluated from top to bottom. A broad condition near the top can match before a more specific condition below it. The snippets below illustrate rule order only; example.com is a placeholder domain, not a recommended service to visit. Copy your original configuration before testing and change only the smallest section related to the affected destination. Do not replace the configuration file you are using with the examples.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

FINAL applies to requests that have not matched an earlier rule; it cannot change the result of a request already matched above it. When troubleshooting local network access, also check the destination address against the actual subnet on your current network. Do not assume that every home network uses the example subnet. Domain rules and address rules require different checks. For DNS-related symptoms, compare the actual resolution results rather than changing only the final policy.

If the same destination works in a simplified configuration but not in the original, restore rules section by section and retest to isolate the condition. When testing is complete, restore the original routing behavior and keep only necessary changes with a note explaining why. Do not leave Proxy enabled as a temporary setting. For more examples, see Rule Order and FINAL. For interface terminology, see the Glossary.

Server timeout: check server settings one layer at a time

A timeout in Connectivity Test means that the test did not complete within the expected time. By itself, it does not prove that a password is wrong, a server is down, or an entire subscription has failed. Different tests may cover different connection stages, and results depend on the current network and destination. First determine whether one entry fails, every entry in the same subscription fails, or the issue occurs only on one network. Then decide whether to check server settings, service status, or the local network.

Compare the original details with the selected entry

Open the selected entry and compare it field by field with the details from your own service provider. Check the protocol, server address, and port first, then the authentication and transport fields. Watch for leading or trailing spaces, accidental line breaks, and full-width characters; the address field should not contain explanatory text. An imported entry having the expected name does not mean its settings match. Confirm the entry actually selected for the connection, especially if repeated imports left several entries with similar names.

For entries created from a subscription, keep the original subscription and current records before making changes. Manually edited fields may be overwritten by the next update and can make comparison with the original details harder. If your provider confirms that settings have changed, update the existing subscription and check the result before selecting the relevant entry again. If the update failed, go to the subscription section; a timeout on an old entry does not mean the update succeeded.

Distinguish a domain name from a numeric address when checking the server address. A domain depends on DNS resolution, while a numeric address may not match the name in the certificate. Replacing a domain with an address from a DNS lookup can change certificate validation or routing, so it is not a general fix. If you suspect a DNS issue, keep the original address, note the resolution behavior, and follow the DNS checks below rather than conflating the two problems.

Protocol settings must match as a complete set

Authentication fields and transport requirements vary by protocol. For Shadowsocks, check the encryption method and password specified by the server. For VMess and VLESS, check the relevant identity fields and transport settings. When using TLS, also verify the required names and certificate settings. The fact that a field can be saved only means the input was accepted, not that it matches the server. Do not substitute settings from another entry just because they look similar.

For certificate-related errors, first check that the device’s date and time are correct, then verify the required server name and certificate status. Disabling certificate verification does not prove the configuration is fixed and changes the security checks in place, so it should not be a routine troubleshooting step. If a field is unclear, ask your own provider for the complete settings rather than trying different values. The exact error message is usually more useful than the entry’s display name.

Hysteria2, WireGuard, and other protocols have their own transport and key settings; do not reuse settings from a different protocol. If a connection works on one network but fails on another, the network may handle the relevant transport differently, but one timeout alone is not enough to confirm that. Test the same entry and destination on two networks you can use, keeping all other conditions the same.

Use cross-testing to narrow down the cause

If one entry fails while another entry you already have works under the same conditions, focus on the failed entry’s settings and service status. If all entries fail, check basic network access and whether the subscription has expired or is returning old content. Avoid launching many tests in quick succession. Brief network congestion, server-side limits, and device load can magnify the issue and make results harder to interpret.

If Wi-Fi fails but cellular works, confirm that Wi-Fi sign-in is complete, then check the router network and its DNS environment. If the device has no cellular service, compare using another trusted Wi-Fi network when possible. A successful test confirms only that the connection worked under those conditions at that time. After comparing, return to the original network and check whether the issue can be reproduced; do not treat an occasional success as a final diagnosis.

When contacting your own provider, include the protocol, time of the issue, network type, exact error, and whether only one entry is affected. Hide passwords, identity fields, private keys, and the full subscription URL; these details generally do not belong in a public screenshot. This manual explains how to check information you already have; it does not provide connection services. If the server test succeeds but the service you are using still fails, return to “Connected, but no internet access” and check the actual routing.

Subscription update failed: separate retrieval, parsing, and update results

A subscription update is a separate process: the app retrieves the address over the current network, parses the response into entries, then writes them to the local list. A working connection does not guarantee a successful subscription update, and a successful update does not mean every entry will work. Note the exact message and distinguish a failed request, unexpected response, parsing error, or change in entry count. Do not hide the cause by deleting and re-adding the subscription.

Check your subscription URL

Copy the complete URL again from the official information provided by your own service provider. Check for missing trailing parameters, accidental spaces, or explanatory text copied along with it. A web management page, documentation page, and subscription URL may look similar but serve different purposes. Opening a page in a browser does not mean it can be imported as a subscription. Do not guess the format from a word in the URL; follow the provider’s instructions for that address.

A subscription URL may contain access credentials, so protect it like a password. Do not share the full URL when reporting an issue or paste it into an unfamiliar online checker. You can describe the response type, error code, or exact message while hiding account-identifying parameters. If you suspect the URL has been exposed, use your provider’s management tools to address it first, then update the saved URL in the app.

Try one manual update and check the result shown by the app rather than only looking for a changed entry name. Your provider may keep the same names while changing settings; conversely, seeing old entries locally does not prove the request succeeded. Note the existing group and selected entry before updating, then check the actual contents afterward to see where the change occurred.

Tell a failed request from an unexpected response

If the message says the app cannot connect, timed out, or could not resolve a domain, first verify basic access on the current network. Then check whether the subscription domain is available only under certain access conditions. If you already have a working server, you can compare update results before and after connecting, if your provider permits it. Do not keep adding configurations from unknown sources just to update. Check network access and the returned content separately; not every error is a formatting problem.

If the server returns a sign-in page, authentication page, error page, or empty response, the app may not recognize it as a subscription. A status code can help narrow down the issue but cannot replace checking the response body: a successful response may contain a web page instead of the expected data. If access is denied, check that the URL is valid and your service is active. Do not repeat requests while the credentials are unconfirmed.

For a format mismatch, confirm that the subscription type provided by your service provider matches the import method. A server-entry subscription and a complete configuration file are different types of content. They do not belong in the same import flow just because both are retrieved from a URL. If the import produces a configuration file instead of the expected list, check the original instructions rather than trying to fix it by changing the file extension.

Handle issues after an update and automatic updates

After an update, check whether the selected entry still exists, whether its group changed, and whether its settings were replaced. If your provider removed an entry, your previous selection may no longer be available. Choose another entry from your existing list and verify it. A smaller entry count does not necessarily mean parsing failed; the remote content may have changed. Use the update message and your provider’s information to determine what happened.

Automatic updates when opening the app and manual updates happen at different times. If an error occurs every time the app launches, temporarily turn off the relevant automatic update option and run a manual update to observe the process. Note the result, then restore the setting. If startup updates fail but a later manual update succeeds, basic network access may not have been ready at launch. Check the network first rather than deleting the entire subscription.

If you manually edited entries created from a subscription, an update may replace your changes with remote content. If you need to preserve custom settings, first understand how the app handles local edits during subscription updates and save any necessary copies. A temporary edit to a subscription entry is not a reliable backup. To restore it, you need a valid original URL, your own service details, and a clear record of configuration changes.

Re-add a subscription only after confirming its URL and format. Keep the existing record, use a clearly distinguishable name for the test entry, and remove duplicates only after verifying that the new one works. If both entries fail, deleting the old one will not improve the request path. See Manual and Automatic Subscription Updates for more on update triggers, or Getting Started for the initial import steps.

Slow speeds and interruptions: test under consistent conditions

Slow web pages, video buffering, slow file transfers, and frequent disconnects point to different issues. A response time from one connection test does not measure sustained throughput, and the speed of one file does not represent all traffic. First describe the symptom: does the initial page load take a long time, is throughput low after it starts, or does it stop unexpectedly? Knowing when it occurs helps determine whether to check DNS, the connection path, the destination, or device status.

Set up a repeatable test

Choose a destination you are entitled to access and whose content is relatively stable, then test at similar times. Record the network type, selected server, routing option, and whether background transfers are running. Do not update the app, sync photos, or download a large file at the same time and use the result to judge connection speed. Other device tasks compete for network and processing resources. Pause unrelated high-volume activity to reduce interference.

Keep the destination and actions the same when comparing results. The first page load may require DNS resolution, a new connection, and resource downloads; a second visit may use cached content. So a faster second visit does not necessarily mean the setting you just changed helped. Close the existing connection for that destination before retesting, or repeat the same steps several times and look for a pattern rather than drawing a conclusion from the fastest or slowest result.

If the same destination is slow with the connection off, prioritize checking the basic network and the destination service. A strong Wi-Fi signal does not mean the upstream connection is uncongested; router load and network congestion also affect performance. If you compare with another trusted network, keep the server and destination the same. If changing only the network improves the result, focus first on the original network.

Distinguish response time from actual transfer speed

Connectivity Test shows how that particular test completed; do not simply rank entries by the number and conclude that one will suit every use case. A web page may load resources from many domains, and sustained transfers also depend on egress bandwidth, destination load, and connection quality. A low response time with slow downloads and a higher response time with stable transfers can both occur. Test the destinations you actually use.

If only one destination is slow, first check that it matches the expected policy and whether resource domains are using different egress routes. A successful main page does not mean its images, sign-in, and media resources all use the same path. Check relevant connection logs for failed or repeated requests. Do not change every rule to use the same policy just to improve one page; that makes it harder to isolate the cause.

If you already have multiple working entries, test the same destination with each during the same time period. If only one entry is consistently slow, check its service status and contact your own provider. If all entries are slow, consider factors shared by the local network or destination service. Avoid testing several entries in parallel; sequential comparisons make it easier to match each result to a specific egress route.

Handle interruptions, long-lived connections, and network changes

When switching from Wi-Fi to cellular, the network address and route may change, and existing sessions may need to reconnect. Do not change protocol settings because of one brief pause. Wait for the network to stabilize, then repeat the original action. If the issue occurs only during the switch and resolves once the network is stable, record it as a network transition issue rather than a persistent server outage.

If the connection drops after a consistent amount of time, note roughly how long it lasted, whether the screen was locked, whether the network changed, and whether the switch remained on. An interrupted long-lived connection is different from a closed tunnel: the former calls for checking the destination, transport, and session recovery; the latter points back to permissions, On Demand, and system status. If the device is hot or busy with background tasks, let conditions return to normal before retesting.

Do not change low-level settings such as MTU based on guesswork. Make a single-variable comparison in a copy only if you can reproduce a specific symptom and have supporting information from the server or network. Record the original value and the result. Randomly changing several settings and occasionally getting a successful result does not establish the cause. Without a clear reason, check signal quality, concurrent tasks, rule matching, and server status first.

Keep a brief record of the network, destination, entry, action, and whether the issue is repeatable. When contacting your own provider, share these conditions rather than only a screenshot of a momentary speed test. Restore automatic updates and normal routing when testing is finished, and stop unnecessary repeated tests. Continuous speed testing uses data and battery and changes the network load you are trying to measure.

DNS issues: check resolution paths and rule results

DNS resolves domain names to addresses, but a failed domain connection does not always mean DNS is at fault. Connection setup, TLS validation, or a failure to get a response from the destination can also make a page unavailable. First check whether the error explicitly mentions name resolution, then review the app’s DNS settings and request logs. Visiting a site by numeric address is not an equivalent test: certificates, virtual hosts, and resource domains may all depend on the original name.

Start with the relationship between the domain and its address

Note the affected domain and check whether only that domain fails or all destinations needing a new DNS lookup fail. An old page still loading does not necessarily mean DNS is working; it may reuse an existing connection or cached address. Conversely, a single failing domain may have changed its own records. Test additional domains, then see whether failures cluster around a type of destination or one network.

Before reviewing DNS settings in the current configuration, save a copy and confirm which configuration is active and whether there are overrides or conditional resolution paths. Changing an address you see in a file does not prove that every request now uses it. The configuration may not be enabled, and the app may have other related settings. Use diagnostic information to check what is actually happening rather than relying on static text alone.

If the resolver address is itself a domain, consider how it is resolved in the first place. If the resolution method uses a secure connection, also check whether that endpoint is reachable and its name can be verified. Adding more resolvers does not necessarily improve reliability; it may add delays or produce inconsistent results. Use settings you understand and can verify rather than treating an unclear list of addresses as a universal fix.

Check DNS results alongside routing rules

Domain rules match names, while IP-CIDR, IP-CIDR6, and GEOIP rules match addresses or their geographic attribution. They may affect the final policy at different stages. If a domain resolves to different addresses, the result of an address rule may change. So do not ask only whether DNS succeeded; check what address was returned and which egress route the request ultimately used.

If the log shows that a destination matched an unexpected policy, first check the spelling of the domain condition, whether an earlier rule overrides it, and the policy used by FINAL. DOMAIN-SUFFIX matches a different range than the exact DOMAIN rule, and DOMAIN-KEYWORD may match more names. Do not add a broad keyword rule to fix one destination; it could change unrelated requests too.

If the configuration includes local address rules, check the device’s actual subnet and service name. Name resolution for local network devices may depend on mechanisms provided by that network; do not assume a remote resolver can resolve home device names. If only home devices are inaccessible while regular web pages work, compare access by name with access using the device’s actual address, then check the local network path and relevant permissions.

Check IPv6, caches, and network differences

Some domains return addresses from multiple address families, and support for those paths may vary across the current network, server, and destination. If failures are intermittent, check whether they consistently occur with a particular type of address result, but do not assume IPv6 is the problem just because you see an IPv6 address. Keep the original configuration for comparison and confirm what the relevant app options do. Change one thing at a time, then restore it or note why you are keeping it.

After changing DNS settings, cached results and existing sessions may remain in use. Reconnect, then send a new request to the destination. If needed, close and reopen the relevant app normally to reduce the effect of stale state. Do not assume the setting failed because the first request still fails, or that the issue is fixed because one cached request worked. Check whether several new requests succeed consistently under the same conditions before keeping the change.

If the same configuration works on one Wi-Fi network but fails on another, check whether the original network requires sign-in, provides a different DNS environment, or can reach the configured resolver. Keep the server and destination the same when switching networks. If the DNS error goes away but the connection still fails, check the transport stage next. Troubleshooting should allow for more than one issue rather than forcing every symptom to fit one DNS setting.

To restore service, first return to DNS settings you have already confirmed work, then add necessary changes one at a time. Keep the affected domain, exact error, network type, and matched policy; you do not need to share your full browsing history. See the Glossary for related terms. If DNS succeeds but requests still fail, return to the server settings or rules section instead of repeatedly changing a DNS setup that is already working.

Battery drain and post-update issues: keep a baseline for comparison

Higher battery use while connected needs to be assessed alongside data usage, signal quality, retries, and device activity. The app’s share in system battery statistics is not a direct measurement of extra power use, and a single percentage does not prove a configuration is faulty. Post-update issues also need to be separated: an app update, system update, subscription update, and configuration change may happen around the same time, but affect different things. Establish the timeline first.

Check what the device was doing when battery use increased

Check the relevant time period in system battery settings and see whether video playback, file sync, large downloads, or a weak signal were involved. When traffic passes through a tunnel, energy use depends on both network processing and what the device is doing; connection duration alone is not enough to estimate battery drain. For a useful comparison, keep screen brightness, network, activity, and test duration similar. Do not compare idle time with continuous playback.

If the device keeps getting hot with almost no active use, check for repeated updates, frequent connection tests, or requests that keep retrying after failure. Temporarily pause automatic tasks you set up and compare while keeping the normal connection. If things improve, restore tasks one at a time to find the trigger. Do not turn everything off at once and conclude that a particular protocol caused the battery drain; concurrent activity and network retries may be the real difference.

Check signal quality and network switching too. Repeatedly switching between unstable networks or trying to reach an unavailable destination for a long time may increase activity. Switch to a stable network you already use and observe with the same configuration. If the device still gets noticeably hot, stop high-load testing and let it return to normal before continuing. Testing itself should not become a source of persistent heat and battery use.

After an update, identify exactly what changed

Note whether the recent change was to the app, system, subscription, or a configuration you edited manually. A subscription update may replace server settings; a configuration update may change rules; an app update does not mean your service status changed too. First check whether the selected server, active configuration, and Global Routing option still match the previous setup. Many issues described as “broken after an update” actually start after the current selection changes.

Get and update the app through the App Store. To verify the official listing, check the developer name, Shadow Launch Technology Limited, the official icon, and app ID 932747118. See How to Verify the App for details. System requirements are listed on the App Store page. Do not judge the app’s source by interface changes alone or use unverified configuration content as a substitute for checking the app itself.

If the original configuration worked before the change, compare it with a saved copy to see whether the rules changed or the server itself is unavailable. A server in a backup may also have stopped working, so the old configuration failing too does not by itself point to an app update. Consider basic network access, service status, and a simplified configuration together. Find the smallest set of conditions that reproduces the issue instead of inferring cause from timing alone.

Restore and report issues in order of risk

Save any unsaved edits, quit the app normally, and reopen it. Then, once the network is stable, establish a new connection. If the system just updated, you can restart the device and test again, but treat that as a comparison to clear temporary state, not a universal fix. After service recovers, check your original automatic updates, On Demand rules, and routing option so temporary changes do not alter your normal setup.

If the issue occurs only with one configuration, copy that file and remove recently added sections step by step. This is easier to diagnose than clearing all settings. Do not publicly share the original file if it contains server passwords, keys, or identity fields. A minimal rule snippet, exact error, and reproduction steps are usually enough. If removing a section resolves the issue, check its conditions one at a time; you do not need to replace the entire configuration.

Before reinstalling, make sure you have a valid subscription URL, necessary server details, and local custom configurations. Getting the app again from the App Store does not automatically restore all local data; purchase records and configuration backups are separate. See Restore After Changing Devices or Reinstalling for the steps. If you have not confirmed that your data can be restored, keep the current setup and continue with checks that do not involve deleting anything.

When reporting an issue, include the system and app details, sequence of changes, repeatable steps, and results you have already verified instead of simply saying “it broke after an update.” This manual does not list fixed app versions or update dates; refer to the App Store page for current release information. For battery issues, include the usage period and activity under comparable conditions. For connection issues, include the switch status and exact error. Do not merge these into one conclusion.

iPad-specific checks: separate device, network, and configuration differences

If the same subscription works on iPhone but fails on iPad, do not assume the subscription is unsupported on iPad. The devices may be on different networks, use different configuration files, routing options, or server entries, or have content updated at different times. Compare the actual settings rather than assuming they are the same. Check the App Store page for iPad system requirements and compatibility.

Align the app and system status first

On the iPad, open the relevant App Store product page and check the app identity and compatibility. See About Using Shadowrocket on iPad for purchase and access details. A purchase record for the same account and configurations stored on the device are separate things. After installing the app, confirm that your subscription or server details have been imported. A working setup on another device does not prove that this iPad has all the required configuration.

The first connection also requires system VPN authorization. If the layout changes with screen size, look for the relevant features by their original labels—Home, Config, and Settings—instead of relying on where a button appears on a phone. Split View or a different window width may change what is visible, but not the order of checks: confirm the selected entry, check the configuration and routing, then connect and verify access.

Some iPads have Wi-Fi only, so you cannot compare Wi-Fi and cellular on the same device. If possible, test on another trusted Wi-Fi network. On iPads with cellular, record results before and after switching networks. When comparing iPhone and iPad, use the same network around the same time. Do not attribute differences to the device when one is on cellular and the other is on Wi-Fi that still requires sign-in.

Compare configurations field by field, not by name

On both devices, check the selected server address, port, and protocol, then compare the active configuration and Global Routing option. Entries with the same display name may still have different settings, especially after repeated imports, manual edits, or subscription updates. Do not overwrite all the iPad’s settings. Note the differences first and, if needed, change one item in a copy to see whether the issue changes.

Check whether both devices completed the same subscription update and received the same content. If one has old settings and the other has updated ones, the difference may be due to when the content was retrieved. Manually update on the affected device, check the result, then select a currently available entry again. If the update itself fails, use the subscription section rather than comparing two devices with different content.

If only one device fails to reach a particular destination, check for local rules, different DNS settings, or other system configurations on that device. Syncing files does not necessarily include every app setting or make system permissions identical. Keep the original values as you compare; do not delete local network or work settings the device may need just to make everything “match.”

Check local networks, On Demand conditions, and extended use

An iPad is often used on a regular Wi-Fi network. For printing, screen mirroring, or accessing home storage, distinguish local network traffic from remote access. If only these features fail, turn the connection off for comparison, check the device’s actual address and subnet, then review the relevant rules and local network permissions in iOS. Do not route all internet traffic through Direct just to restore access to one local service.

Check On Demand conditions against the iPad’s current network. Even with the same copied conditions, the two devices may use different Wi-Fi networks, network types, or domain triggers. Temporarily disable your own On Demand conditions to establish a baseline with the manual switch, then restore them and test each condition. For more on triggers, see On Demand Settings.

If access fails after the screen has been locked for a long time, check whether the switch is still on, whether the system VPN is connected, and whether reopening the destination restores access. A stale session is not the same as the entire connection stopping. Note any network changes before and after locking the screen rather than assuming background connections are unavailable. Other tasks running in Split View may also use network resources, so keep device load similar when testing speed.

Finish with a comparison record: same network, entry, configuration, and destination, with the result on each device. If the difference is still reproducible under matching conditions, collect the system details and exact error for your report. See Frequently Asked Questions for quick answers. To go through the full setup again, return to Getting Started and follow the steps for importing, routing, authorization, and verification.