Shadowrocket Troubleshooting
Connections, Routing & DNS

1. Can’t turn the connection on: check system permissions first

First distinguish between a switch you can’t operate, a connection that drops immediately, and a connection that stays on while requests fail. These point to different layers. For the first two, check system permissions, the network extension, and whether the config is valid. If the connection stays on, the connection entry may be established; check the server, routing, and DNS next. Don’t rely on the status icon alone to confirm that a site is reachable, or assume every immediate disconnect means the server is unavailable.

Save the current state and check your internet connection

Note your network type, selected server, Global Routing mode, and whether On Demand is enabled. Save the current Config and list anything changed since the last successful connection. Then quit Shadowrocket and open a site that normally works without it. If that fails too, check for a Wi-Fi sign-in page, mobile data permissions, router issues, or system network restrictions. Troubleshoot the app only after the device itself can access the internet.

Public Wi-Fi may require web-based sign-in. Connecting to a Wi-Fi network does not mean authentication is complete, and the system may have cached an earlier sign-in. Keep Shadowrocket off, open the sign-in page provided by the system, and confirm the network works before trying again. If your device has a management profile from your employer or school, review its network policies. Don’t remove management settings you don’t understand or try to bypass administrator restrictions.

Check VPN settings and competing connections

1. Go to Home and confirm that you selected your own working server, rather than merely importing a list without selecting an entry.
2. Turn the connection on and watch for the system prompt to add a VPN configuration. Approve it as prompted.
3. Check the VPN section in system settings for connection records, and make sure another connection is not repeatedly taking over.
4. Temporarily turn off On Demand and connect manually once, so you can check manual connection and automatic triggers separately.

If you previously denied permission, you may need to confirm its status in system settings before trying again. Only consider removing an old connection record and letting the app recreate it after saving your config and confirming which record belongs to Shadowrocket. Removing a system connection record is not the same as deleting a subscription, but back up first so you can identify the cause if something changes. Don’t start by resetting the device’s network settings.

What to check when the connection drops immediately

First look for a specific permission or config error. Then note whether the connection drops after you tap the switch, change networks, or wake the device. If it fails every time at startup, check that the current config loads and that required server fields are present. If it happens only when switching networks, temporarily disable automatic connection conditions and retry on one fixed network. Test the same action each time; switching between several servers can obscure the trigger.

Incorrect server settings can cause requests to fail after connecting, but not every switch issue is a protocol problem. Record the full error shown in the app and check permissions and config loading first. If diagnostic logs are available, share only the error category and steps to reproduce it. Hide subscription URLs, authentication fields, and server identifiers before contacting support. Check screenshots for QR codes, full URLs, or account details too.

If the issue still reproduces after restarting the app, save your work and restart the device, then test once on the same network with the same config. Restarting can rule out a temporary system state, but it is not a diagnosis. Your reproduction notes should answer three questions: where did it fail, what message appeared, and did the internet work with Shadowrocket off? These details are more useful than simply saying it won’t connect.

2. Connected but no internet: separate server and routing issues

Once the connection stays on, narrow the issue down: do all requests fail, only some domains, or just one app? Test one site that works directly, one destination you access through your existing server, and the affected app. Choose the test targets yourself and keep them the same. Frequently changing sites mixes up service status, caches, and routing differences, making results hard to interpret.

Use Global Routing for a controlled comparison

Global Routing offers Config, Proxy, and Direct modes. Config follows the rules in the current config; Proxy helps test the proxy path; Direct lets you check the direct path. Switching modes is a diagnostic step, not a recommendation to keep one mode selected. Keep the server fixed during testing, close existing browser tabs, and make a fresh request so an established connection does not continue using its previous route.

If Proxy works but Config fails, check the matching rule, selected policy, and DNS result before rebuilding the server entry. If both modes fail, check server authentication, protocol settings, and network conditions. If Direct reaches a site but Proxy does not, that only shows the site is reachable directly on the current network; it does not prove that all proxy requests are failing. Keep every conclusion specific to the network, destination, and mode you tested.

Check rule order and policy targets

Open Config and confirm that the active file is the one you just edited. A file appearing in the list does not mean it is selected, and a remotely updated copy may differ from the one you edited manually. Then check the target domain against the rule order: exact domains, suffixes, keywords, and the final rule may send it to different policies. Usually the first matching rule determines the outcome; a correct rule farther down cannot fix an earlier incorrect match.

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

These examples explain rule syntax; they are not general-purpose config recommendations. The first line sends the specified domain and its subdomains to PROXY, the second rejects an exact domain, the private network example uses DIRECT, and FINAL handles requests that did not match earlier rules. Before copying anything, understand its scope and check it against your network. In particular, don’t paste the example’s reject rule, geographic rules, or final policy into your full config without review.

If a rule points to a custom policy group, confirm that the group contains an available server and that the current selection is what you expect. A correct group name does not guarantee the right entry is selected; automatic and manual selection can also produce different results. For troubleshooting, temporarily select one of your own known-working servers to reduce policy changes as a variable. Restore your original selection method after testing and note the conditions that worked.

If only one app fails

An app may reuse persistent connections, cache addresses, or make requests to several domains. Fully quit and reopen it, then check whether the main screen, sign-in, and media loading fail separately. One working webpage does not prove that every domain the app needs is reachable. If diagnostic logs show request paths, check each failed domain. Don’t broaden a keyword rule across your entire config to fix one resource.

For local network services, also check local network permissions, whether both devices are on the same network, and whether the request uses a domain or a private address. Being able to browse the internet but not reach a printer or home storage is different from failing to reach an external server. Keep only changes verified by an actual request to the target. If you can’t identify which rule made a difference, restore your backup and start over with the smallest possible change instead of accumulating temporary rules that conflict.

3. Connection timeouts and slow speeds: test connection and transfer separately

A timeout means a test or request did not complete within the allotted time; it does not, by itself, prove that the server is down. Slow speeds can occur during DNS lookup, the handshake, the time to first byte, or ongoing data transfer. Describe the specific symptom: did Connectivity Test return no result, did a webpage take a long time to appear, or was a download slow after the page loaded? Each stage calls for different checks, and a latency figure is not the same as download speed.

Check server details and what the test measures

Compare the address, port, protocol, and authentication fields with the details for your own server. Don’t infer its region or protocol from its name; a name is just a label. Check for extra spaces, missing characters, or an incorrect port when copying. If the details came from a subscription, keep the original entry so you don’t confuse manual edits with the next subscription update. If needed, import one comparison entry from the same source rather than overwriting the whole list.

Interpret Connectivity Test results in the context of the selected test method. A test may cover only connection establishment or a particular destination; it does not replace a real request for your service. If a test times out but webpages work, check the test target and method before removing a working server. If the test succeeds but a webpage fails, check the destination path, rules, and DNS. Different results are not contradictory when the test and request use different targets.

Check protocol settings as a group

The Shadowsocks encryption method and password must match the server. VMess and VLESS authentication and transport settings must also match. Don’t guess the Trojan password or TLS settings. If the config uses additional transport paths, a Host, or a Server Name, each field has a distinct purpose; similar labels don’t make them interchangeable. The server address identifies the connection entry point, while the name used for certificate verification may be different. Use the parameters provided with your own service.

For a certificate or handshake error, first check the device time, the name on the certificate, and whether you changed any settings manually. Don’t hide the error by disabling certificate verification: that changes the security conditions and makes later comparisons unreliable. Protocols such as Hysteria2 also depend on specific transport conditions, which must be checked against the current network. The same protocol name does not mean every server uses the same port, authentication format, or transport options.

Compare network and server combinations

1. Keep the same destination and server, then make a fresh request over Wi-Fi and mobile data and note any difference.
2. Keep the network unchanged, switch to another server from your own list, and request the same destination.
3. Check the initial connection, page resource loading, and ongoing transfer separately instead of treating them all as “speed.”
4. Repeat the test at a similar time and pause large background syncs to rule out bandwidth use by the device itself.

If only one network fails, investigate that network’s path to the server, Wi-Fi signal, or access restrictions first. If only one server fails, check that server and its service status. If several servers fail, they may share an entry point or settings; that does not prove the entire client is at fault. Cross-testing helps narrow down the cause, but does not prove either side is necessarily broken.

Avoid changing settings without evidence when speeds drop

First compare the same device’s baseline transfer performance with the client off, then check whether the proxy path is slower. Wireless interference, mobile signal, server load, destination rate limits, and background sync can all affect results. Don’t run several high-bandwidth tasks at once or repeatedly refresh to create a flood of parallel requests. That changes the test conditions and may temporarily trigger server-side limits.

If small pages load but large downloads stall, note whether the issue reproduces with different destinations, then check the network and transport conditions. Settings such as MTU can affect packet delivery, but there is no single value that works for every network. Don’t try a series of values without evidence. If you need help, share the network type, protocol category, failure stage, and comparisons you have run—not passwords or a full subscription URL.

For more on checking servers, see Latency Tests, Regions, and Protocol Types. Describe the result as “slow with this destination, network, and server combination,” rather than reporting only a latency figure. Reproducible conditions help distinguish occasional congestion from persistent configuration issues and prevent you from mistaking a temporary recovery for the effect of an unrelated change.

4. Subscription update failed: check the response before the server list

A subscription update fetches and parses a list; connecting to a server uses one entry from that list. A failed update does not immediately invalidate every saved server, and existing servers still connecting does not mean the subscription URL is still usable. Keep the current list and note the error, time, and network path when the update failed. Don’t clear your config because of one failed update. Restoring a deleted subscription may require checking its source details again.

Check the link and response content

Copy the subscription URL again from the location provided by your own service and check that the beginning, path, and query parameters are intact. A messaging app, line break, or manual edit can remove part of an address; some interfaces display shortened text, which is not the full URL. Subscription URLs often contain authentication details, so treat them like passwords. Don’t post them publicly or paste them into online parsers or third-party test tools.

A single share link is not the same as a subscription URL. ss://, vmess://, vless://, and trojan:// usually represent one server, while a subscription provides an updatable collection. Importing a single-server link through the wrong entry point may produce an unsupported format or only one entry. For more on the difference, read Share Link and Subscription URL Formats, then use the appropriate import option.

Troubleshoot the stage where the update fails

If an HTTP status is shown, record the status code and a brief error category. Authentication failures, rate limits, and server errors need different responses; changing DNS in the client won’t fix every error. A URL opening in a browser does not prove that it returns a valid list: the browser may show a sign-in page, help page, or access notice. Don’t save one of these pages and import it as a server config.

Check dependencies in the update path

A subscription domain may be unreachable on the current direct network while the server selected by the client is no longer working, leaving the update and connection dependent on each other. First check whether your saved list still contains one of your own working servers, then find out which path the update request uses. Don’t assume that changing Global Routing makes every update request use the same path. Verify the result against your settings and any available diagnostics.

If the list contains no working servers, try a network that can already reach the subscription source, without exposing the URL, or check the subscription status with your own service provider. Don’t look for an unknown temporary server just to update the list. Leave time between retries: repeated attempts won’t fix authentication or format errors and may hit rate limits, adding a new problem to the original one.

Check the list after an update

After a successful update, check how the number of entries changed, what is currently selected, and whether the protocol fields look right. Then connect using one of the entries and verify a real request. Your service may change entry names, connection points, or authentication details, so an earlier manual selection may no longer refer to the same entry. Subscription refreshes may also overwrite local edits to an individual server. Keep manual notes, subscription content, and the full Config as separate records.

If your subscription URL was exposed publicly, ask its original source how to replace the authentication details, then update the saved URL in the client. Deleting a chat message does not invalidate the old URL. Keep only the necessary part of the domain, error category, and steps in troubleshooting notes; never include full query parameters in screenshots or shared documents. Resume automatic updates only after the issue is resolved to avoid repeated background requests.

5. DNS issues: check lookup results and the actual request path

DNS translates a domain name into an address needed for a connection. A domain that won’t open, a slow first load, or missing page resources may involve DNS, but could also be caused by TLS, the destination service, or routing rules. Check whether the error occurs before or after an address is returned. If an address was returned but the connection still times out, don’t focus on DNS alone. A successful lookup gives you a candidate address; it doesn’t prove that address is reachable on the current network and route.

Record the domain, address, and rule separately

Record the full hostname that fails, not just the website name. A service may use separate domains for sign-in, images, and APIs; a working home page with missing images can involve entirely different requests. If diagnostics show lookup results, note the address type and time as well. Don’t share authentication parameters from a full URL, or send private internal domains to an untrusted DNS service just to test them.

Open the active Config and check for custom DNS, domain mappings, or other DNS-related settings. Confirm which file is active before checking its rules; editing an unused copy won’t change requests. If you use a remote config, check whether an update replaced local settings. Keep the original file and change just one DNS setting at a time. Otherwise, even if access returns, you won’t know which change helped.

Understand why a rule might trigger a DNS lookup

DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD match domain information; IP-CIDR, IP-CIDR6, and GEOIP involve address ranges or address locations. Under some config conditions, a domain request may need to be resolved before an address-based rule can match it. This can explain why a rule looks correct but the first request is slow: the delay may be in address matching, not the proxy connection.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

In the example, no-resolve means not to trigger a DNS lookup solely for that address rule. It does not disable all DNS or force every domain onto a particular route. It cannot fix an unreachable DNS server or guarantee that local network names will resolve. The example only explains the syntax; real configurations must account for existing rule order, private network ranges, and destination services. Don’t treat the whole snippet as a universal fix.

IPv4, IPv6, and network changes

The same domain may return several addresses, and the current network may have different IPv4 and IPv6 reachability. If the issue occurs on one Wi-Fi network only, note its address environment and compare it with another network. Don’t take access returning after disabling IPv6 once as a reason to disable IPv6 everywhere. It only suggests that address selection or its network path needs further investigation. Save the original setting and know how to restore it before changing system network options.

Wi-Fi and mobile data may use different DNS settings, while caches and existing connections can persist after switching networks. Start a new request for each comparison; if needed, quit and reopen the app you’re testing. Repeatedly tapping refresh may not trigger a new lookup. Don’t substitute entering an IP address in the address bar for a full test: HTTPS certificates, virtual hosting, and service routing often depend on the domain, so either outcome can be misleading.

Internal domains and cache boundaries

Home routers, workplace networks, and local services may use names that resolve only on the local network. Switching to another DNS provider may leave these internal names without a resolver, even while external sites work. First confirm that your device is still on the same local network and whether the domain needs local DNS. Don’t try to fix an internal domain by broadly adding PROXY rules; the proxy path may not be able to reach the private address.

Browsers, apps, the system, and the client may each keep some cached data. After changing a config, distinguish a reused old connection from a new request that now works. Once testing is complete, retry the destination that originally failed and check the route it actually used. If access returns reliably only with a particular DNS condition, record that condition and the networks where it applies; don’t copy an address list to every device. Verify DNS settings with a real request on the current network.

6. Battery drain and unusual data use: find what is staying active

To assess battery drain, you first need a comparable baseline. Device temperature, screen brightness, signal strength, background sync, and actual data transfer all affect battery life; one drop in charge does not show that Shadowrocket is at fault. Check system battery usage for the same time period, and note whether you were downloading files, streaming media, or frequently switching networks. Usage time and data volume also need to be comparable across days.

Separate data attribution from the source of activity

A proxy connection carries data for other apps, and system reporting may attribute some of that network activity to the related process. That does not mean the client generated the same volume of requests itself. First check whether photo backups, file sync, app updates, or media autoplay are running. Then pause those tasks and see whether data use drops. A ranking in one system report does not identify the app that actually made the requests.

If the app provides Data or connection records, use them to see whether activity continues, but keep in mind that measurement methods, reset times, and system statistics may differ. Total data, real-time speed, and an app’s background activity are different metrics. Note the starting values, observe over a fixed interval, and compare the results. Don’t treat a cumulative figure as current traffic or compare numbers from different time periods as proof of a problem.

Check for repeated connections and retries

A weak signal, frequent roaming, or an unstable server may cause apps to keep retrying connections. Even when no page loads, the device may continue handshakes, DNS lookups, and retries in the background. Use a stable network and one of your own working servers, then check whether repeated activity continues while idle. If it happens only when the network changes, record the transition sequence and automatic connection settings before changing protocol settings.

On Demand triggers connections under specified conditions; that doesn’t mean the same trigger should be used in every situation. Temporarily turning it off and connecting manually can help reveal a cycle of repeated connection attempts and dropouts. Note the original conditions and restore them after testing. Repeatedly toggling the switch for an extended period is not a reliable test: the toggles themselves create network activity and may cause background apps to make new requests.

Set up a reproducible idle comparison

1. Finish large file transfers, keep the brightness and network consistent, and note normal usage first.
2. Save your config, use a server you have already verified works, and pause unnecessary manual tests.
3. Lock the screen and check background activity in system statistics. Note any network changes or periods of frequent push notifications.
4. Repeat the same observation with the client off. Check whether the issue still occurs, without assuming the result applies to other networks.

During the comparison, don’t update subscriptions, change rules, or run Connectivity Test repeatedly. Test requests create network activity, and frequent checks mean the device is no longer idle. If automatic updates are enabled, check that the interval is appropriate; you don’t need to refresh constantly to confirm the list is valid. If an update fails, investigate the cause first. Repeated retries can increase background activity without fixing the issue.

Temperature, charging, and connection conditions

Charging, restoring a system backup, indexing, and demanding apps can all heat up a device. If it gets unusually hot, stop high-load tasks and let it return to normal operating conditions before troubleshooting. Don’t compare battery use by repeatedly downloading files while charging. A weak signal may also increase the power needed to maintain a connection. If switching to a stable network helps, don’t attribute that improvement to a rule change.

If the device still overheats or loses charge quickly with the client off, keep checking the system and other apps. If the issue reproduces only with a particular config, server, or automatic connection condition, save that minimal reproduction. Don’t disable certificate verification or delete necessary rules just to reduce a number in system statistics. A reliable fix should allow requests to complete, reduce idle activity, and explain what happens when the original settings are restored.

7. Problems after an update: check what changed before assigning blame

“It happened after the update” establishes timing, not cause. An app update, system upgrade, subscription refresh, remote Config change, and server-side change may all happen around the same time. List these changes and mark what is confirmed versus what is only suspected, then check the action closest to the failure. Don’t guess version numbers or update times, and don’t mistake a temporary network recovery for a diagnosis.

Keep both the previous and current states

Before making changes, export the current config, save the details for your own subscription source, and note the selected server and Global Routing mode. Backups may contain server authentication details, so keep them somewhere you control. If you have a pre-update backup, compare rule order, policy targets, DNS, and protocol settings. Don’t overwrite the current file right away: its current state is important evidence, and overwriting it may make the difference impossible to reproduce.

Test the basic path first: can you access the internet with the client off? Does a manual connection stay on? Can Proxy reach a fixed destination, and does Config behave differently? Use the same minimal tests to classify the post-update issue as a permission, server, rules, or DNS problem. Even without complete pre-update records, this avoids repeatedly guessing that a “new version is broken” without checking where the request actually fails.

Distinguish a config update from an app update

A subscription update may replace server settings, while a remote Config update may change rules or policies; neither requires an app update. Check whether remote content overwrote local edits, whether the active file changed, and whether the selected policy group still contains the same entries. If restoring one server gets things working, compare that server’s details. Don’t replace the entire config with content from an unknown source.

After a system upgrade, recheck VPN permissions, system connection records, and automatic connection conditions. If the system shows a clear authorization prompt, follow it. If only the old connection state looks inconsistent, disconnect and connect manually once. Recreate a system connection record only after backing up and confirming it belongs to Shadowrocket. Removing all network settings is too broad for an initial check.

Confirm you can restore your data before reinstalling

Reinstalling is not a backup. Before deleting the app, make sure you can restore your Config, subscription, and required server details, and know what is stored locally. Check that exported files can be read and note your manual rules and server labels. Don’t assume a purchase record restores your service configuration. If only one destination fails, investigate that destination and its rules first; removing the whole app is usually unnecessary.

If you need an installer, use the platform sections on the download page. Get the iPhone and iPad app from the App Store; check its listing for system requirements. For Mac, Windows, Android, and Linux, use the installer links provided on this site. The iPhone and iPad app costs $2.99 as a one-time purchase; the versions for the other platforms are free. App access and the status of your existing server service are separate.

Allowing installation after a reinstall

Desktop and Android installers are not code-signed, so the system may block the first launch. After confirming the file came from this site, Windows users can choose “More info” and then “Run anyway” in SmartScreen. On macOS, check the blocked item under “Privacy & Security” and choose “Open Anyway.” On Android, follow the system prompt to allow installation from the current source, then revoke that permission afterward if appropriate. Labels may vary slightly by system; verify the file before proceeding.

If macOS says the app is damaged, first confirm that the installation is complete and the file came from the right source. Then follow the installation approval guide to check its quarantine attribute. On Linux, check the installation result for your distribution and package format; an AppImage needs execute permission. Don’t disable system protection globally just to launch one file. A blocked launch and failed requests after connecting occur at different stages and must be checked separately.

Write down a conclusion you can verify

After the issue is resolved, repeat the action that originally failed and confirm the destination request, matching rule, and network changes behave as expected. Record the change that actually helped—such as selecting a working server, restoring an overwritten rule, or granting permission—instead of just writing “reinstall fixed it.” If it still fails, reduce the steps to a short, repeatable sequence and include redacted error details. Read version information from the app itself; don’t fill it in from memory.

8. iPad-specific checks: purchases, migration, and landscape layout

iPad connection troubleshooting follows the same order—permissions, server, rules, and DNS—but purchase restoration, landscape layout, and config migration can introduce confusion. First confirm that Shadowrocket is installed on the device, then check the server selected in Home, the active Config, and Global Routing. Don’t assume that because another device connects, every setting is the same here. Networks, permissions, config copies, and connection records can all differ.

Restoring a purchase is separate from restoring a config

The iPhone and iPad app costs $2.99 as a one-time App Store purchase. The Mac, Windows, Android, and Linux versions are free. If you already purchased the iPhone or iPad app, sign in to the App Store with the original purchasing account and look for it in your purchased apps. Actual availability depends on the store record. A purchase does not automatically transfer subscriptions, servers, or Config; check your local data after installation.

In the store, check for the developer Shadow Launch Technology Limited, the official icon, and app ID 932747118. Check the App Store listing for system requirements. If you can’t find the app, first check the store region for your account and your purchased apps. A missing search result is not a connection issue. For details about purchases on the same account and layout differences, see iPad Shared Purchases and Landscape Layout Differences.

In landscape split view, confirm which item is actually selected

In landscape or split view, a selected list item and its details may appear at the same time. Seeing a server’s details does not necessarily mean it is the server currently used by the connection. Likewise, viewing a Config does not mean that file is active. After making changes, return to the connection screen, check the current selection, and verify it with a real request. Don’t infer the active server or rules file from the item shown in the details pane.

Split view, window size, and system display settings change what is visible. If a button is missing, switch to full-screen app view first, find it, and then return to your usual layout. Don’t rapidly tap several list items before an action is complete, especially when editing, selecting, and connecting happen in different areas. Note which item you tapped, where you saved it, and what the connection screen showed afterward—not just one pane in a screenshot.

Migrate each data type separately, then verify in stages

Before migrating, confirm separately that your servers or subscription, Config, manual rules, and necessary notes have been saved. A full Config and a single share link contain different information; importing one server won’t bring over all your rules. Prefer the app’s built-in import and export features, and transfer data only between devices you control. Files and QR codes may contain authentication details; don’t keep them in public photo libraries, shared documents, or public chats.

On iPad, first import one of your own working servers and use Proxy to test a fixed destination. Then enable the Config you want to migrate. This separates server availability from rule issues. If you import many configs and turn on automatic connections all at once, it will be difficult to identify what caused a failure. Add the remaining entries after a successful test, then check whether a subscription update overwrote your manual changes.

Compare network conditions, even on the same Wi-Fi

Two devices showing the same Wi-Fi name do not necessarily have the same permissions or use the same network path. Guest network isolation, local network access, address types, and caches can all differ. If a home storage device or local service is unreachable, check the device’s network, permissions, and destination address before checking DIRECT rules. If your iPad doesn’t have mobile data, don’t assume you can use it for comparison; try another Wi-Fi network you can access instead.

If the problem occurs after waking the screen, note whether the network changed, On Demand triggered a new connection, or an old app connection was reused. Make a fresh request, then check the system VPN status. Don’t delete all migrated data right away. If it happens in only one app, return to section 2 and check the domains that app uses. If all new requests fail, recheck permissions in section 1 and DNS in section 5.

If you still can’t identify the cause, prepare a redacted report with the device type, network, failing step, error message, behavior with the client off, and the single-variable comparisons you’ve tried. Don’t include a full subscription URL, QR code, or password. Use these facts to revisit the relevant section; this is usually more effective than importing every config again. If you haven’t completed the initial connection steps, return to the setup guide and verify each step.