V2Ray Troubleshooting Guide

No internet access: check each layer from app to server

A client showing that it’s running only means the interface or core has entered some kind of working state. It doesn’t confirm that you can reach a website. First, narrow down what’s affected: all apps, just the browser, or only certain sites? Note when the problem started, what settings changed recently, and whether it persists on a different network. These details are more useful than repeatedly clicking Connect and help distinguish a site outage from a client configuration problem.

Establish a baseline connection

Stop the client from routing traffic and make sure the system proxy has been cleared. Then visit a site that normally works without a proxy. If it still fails, check your Wi-Fi or Ethernet connection, gateway, and any captive portal. Complete the sign-in process first on networks that require web authentication. Once the basic connection works, start the client and select a known-good configuration. Keep other tools that change your network route turned off during testing.

Next, check that the local proxy endpoint is available. In v2rayN, find the actual HTTP or SOCKS listening address and port; don’t copy numbers from another guide. If your browser uses a manual proxy, its protocol must match the listener, and the address usually points to your own computer. Putting a SOCKS endpoint in the HTTP field, or entering the remote server port as the local proxy port, can make every page fail even when the node configuration is fine.

Use logs to distinguish “traffic never reached the client” from “traffic failed after reaching it”

Open the client log and revisit a specific target. If there’s no corresponding connection record, check whether the browser bypasses the system proxy, an extension overrides its settings, or the app ignores the system proxy entirely. If the target domain appears in the log, check whether the failure occurs during DNS resolution, connection, or handshake. Logs may combine repeated messages, so a missing new line alone doesn’t prove that traffic never arrived. If needed, temporarily increase log verbosity and test again.

If one site fails while others work, check whether routing sends its domain through an unsuitable outbound. Temporarily switching to the client’s global proxy mode can help narrow down the cause, but restore your usual routing when the test is done. If global routing works but your normal rules don’t, check rule order, domain matching, and direct DNS. If both fail, investigate the node connection and the target service.

Check for authentication, certificate, and stale-connection issues

If you see a certificate error, check the system date, time zone, and time synchronization first, then verify the node’s server name setting. Don’t hide the problem by disabling certificate verification. If a browser works but a particular app can’t connect, check whether it uses its own proxy, a persistent connection pool, or a background service. Existing connections may not be recreated immediately after changing the system proxy. Fully quit and reopen the app; this is often a better test than simply refreshing the page.

If enabling TUN cuts off all traffic but turning it off restores the browser, check permissions, the virtual network adapter, routes, and DNS handling. Don’t immediately reinstall the whole client. Save your current settings, return to a minimal working setup with one client, one node, and the system proxy, then add rules back one at a time. Test the same page each time and record the exact error. “Doesn’t load” needs to be narrowed down to a timeout, connection refusal, DNS failure, or certificate verification error.

After restoring access, verify at least three things: a regular webpage loads, apps that need the proxy can establish new connections, and basic internet access still works when the client is closed. If only some resources fail to load, check the failed domains in your browser’s developer tools instead of switching the entire configuration again. For a more detailed sequence, see the checklist for when you’re connected but can’t access the internet. If you haven’t finished the initial setup, return to the main setup guide.

Connection timeouts: identify failures in the port, transport, or handshake

A timeout can have several causes: one step in the connection chain didn’t finish in time. The client’s test tool may check TCP connectivity, make an HTTP request through the proxy, or run another kind of probe. These tests aren’t interchangeable. Check which one you’re using, then try an actual connection. One failed node test doesn’t mean the entire subscription is broken, and an open port doesn’t guarantee that authentication and transport settings are correct.

First check whether one node or the whole setup is affected

On the same network and with the same client settings, test two working nodes from different sources or routes. If only one fails, focus on that node and the server status. If all fail at once, check your system clock, network route, firewall, and whether the core started. Then briefly test on a different network. Switching networks changes DNS and the route at the same time, so it can show that the problem is environment-related, but it can’t identify a specific setting as the cause.

Use the complete server address and port provided by your subscription or service provider. Don’t add a protocol prefix after the domain, and don’t include a path in the port field. For manual configurations, check for leading or trailing spaces, full-width punctuation, and missing characters. If the server address is a domain, confirm that your device can resolve it. If the service has updated its address, fetch the latest configuration instead of relying on an old lookup result.

Narrow down the problem by where the error occurs

These terms are clues for troubleshooting, not definitive diagnoses. For example, a connection refusal means that something explicitly rejected the connection, but that could be the remote service or a device along the route. A timeout alone can’t tell you whether packets were dropped or the service failed to respond. Save the log lines immediately before and after the error, especially the connection target and outbound used. A website refusing a connection and a proxy server refusing one are different failures at different layers.

Keep transport settings consistent as a set

For nodes using TLS, check the server name, transport protocol, and server requirements. WebSocket paths and Host values, gRPC service names, and similar parameters must match the server configuration; changing the protocol name alone isn’t enough. For VLESS with REALITY, also verify the public key, short ID, server name, and flow-control settings where applicable. Required fields depend on the specific combination. The safest approach is to import the complete link again rather than piecing together settings from different guides.

An incorrect system clock can affect certificate validity checks and, in some cases, protocol authentication. Sync the time in system settings, then restart the core to establish a new connection. If you encounter a certificate chain error, check that the system trust store is working and that the network doesn’t require a sign-in. Don’t leave verification disabled as a permanent workaround. For more on server names and time settings, see the guide to TLS handshake and certificate errors.

Finally, consider updating the client or core. An update is directly relevant only when logs explicitly report an unsupported field, an unrecognized protocol, or a configuration parsing error. Save your configuration first, then choose the right platform on the client downloads page. Retest with the same node after updating so you don’t change routes at the same time. If the node itself is no longer working, ask the service provider to confirm its settings and status instead of repeatedly testing at shorter intervals.

To confirm recovery, don’t stop at one successful test. Load an actual webpage and check that it stays accessible. Save the working node settings and test conditions, and remove temporary firewall exceptions and debugging changes. If timeouts return, this baseline will help you tell whether the node, network, or local settings have changed.

Subscription failures: check the URL, retrieval method, and content format

A subscription update has three stages: fetching the content, parsing it, and updating the group. When an update fails, first identify the stage. A connection timeout usually occurs while fetching; unrecognized content points to a parsing issue; an update that completes but shows no nodes calls for checking group filters and content changes. Don’t delete the original subscription right away. Working nodes can keep you connected and help you compare results.

Verify the complete URL and protect subscription credentials

Copy the subscription URL again from the service provider’s page and check that the beginning, end, and query parameters are all intact. Line breaks in chat apps, copying displayed text instead of the actual link, or deleting parameters after the question mark can all break the URL. Subscription URLs often contain credentials, so don’t post the full URL in public forums or upload it to an unknown conversion service. When asking for help, describe the error and redact the URL, account details, and node authentication fields in screenshots.

Check the account page for notices that your subscription has expired, been disabled, run out of data, or had its URL reset. Being able to sign in to the service doesn’t mean your old subscription URL still works, and a working website doesn’t prove that the subscription API is available. If the provider has issued a new URL, edit the existing group and update it instead of creating several groups with similar names. Keep the group notes so you can tell which nodes came from the same source.

Separate subscription retrieval from node connections

A working node doesn’t guarantee that the subscription endpoint is reachable through the same route. If all nodes are down, trying to fetch the subscription through an existing proxy can create a deadlock. Check whether the client offers options such as updating through the proxy or connecting directly. Choose based on your current network, then test each method separately. Options vary between clients and versions; don’t assume that subscription updates always use the system proxy.

If a direct update times out but a working node can reach the subscription service, try updating through the proxy. If the proxy is down but the subscription endpoint is directly accessible, switch to direct retrieval. Change only the retrieval method each time; don’t also change DNS or the group URL. If repeated attempts fail, wait a while to avoid triggering rate limits. On networks that require a sign-in, complete authentication first; otherwise, the response may be a login page.

Check format compatibility and missing nodes

Subscription content may be a collection of encoded share links or a format designed for a specific client. A filename or URL extension doesn’t guarantee that the contents are compatible with your client. Use an endpoint the provider explicitly says is compatible with v2rayN, v2rayNG, or v2flyNG. If the log reports an unsupported protocol field, check the client and core capabilities before updating. Deleting fields at random may let you save a node that then fails to connect.

If the update completes without an error but only some nodes remain, check for keyword filters, protocol filters, or group filters. Also see whether the provider changed its list of routes or the client merged duplicate entries. Switch to the full group list and look for a node alias you recognize. A different node count from yesterday doesn’t by itself mean parsing failed; the server may have changed its content.

Changed connection settings after an update are a separate issue. A node may have been replaced, or the selected entry may have been removed. Select an updated node and start the core again. If the new subscription imports successfully but none of its nodes connect, troubleshoot the connection timeout section instead of continuing to investigate retrieval. Once everything works, keep a backup of the group settings you need in a secure location; don’t share it publicly along with logs.

Verify the whole process: the update finishes successfully, the target group contains new content, and a valid node can establish an actual connection. For adding your first group, see the subscription import guide. For URL management and common questions, see the FAQ. If the same URL fails on multiple devices while the account is active, wait or ask the provider about the endpoint before reinstalling anything.

Slow speeds: test latency, throughput, and app performance separately

Slow page loads, video buffering, and slow file downloads don’t necessarily have the same cause. Latency measures round-trip time; throughput measures sustained transfer capacity; packet loss and jitter affect connection stability. A good result in one node test doesn’t guarantee that every app will be fast. First identify what’s actually wrong: slow initial loading, low sustained speeds, or intermittent disconnections. Then choose the right comparison test.

Use consistent test conditions

Choose a target that normally works well, then test it at similar times using the same network, client, and steps. Pause system updates, cloud sync, and other high-bandwidth tasks, and check that no other device on the network is saturating the upload. Upload congestion can slow page responses too, so don’t look only at download usage. If your Wi-Fi signal is weak, move closer to the access point or use Ethernet before blaming the remote route for local wireless retransmissions.

Next, change only the node and compare the same target. If several nodes are slow for one site but other sites work, consider rate limits on the target, its content delivery path, or account restrictions. If the same node works on mobile data but not on a fixed connection, the access route may be the difference. Don’t run several speed tests at once: they compete for bandwidth, distort everyday performance, and make comparisons unreliable.

Use logs and system resource usage to locate the bottleneck

If you see frequent reconnects, timeouts, or connection resets during transfers, fix the stability problem first; adding more concurrent connections may only make it worse. Use Task Manager or the system monitor to see whether the client, core, or target app is using a lot of CPU. Power-saving mode, overheating, or frequent background scans can affect encryption and network processing. Restore normal power and cooling conditions before deciding whether to change software settings.

If browser downloads work but one app is slow, check whether it uses a different route, its own proxy, or a different service region. Routing rules may send web pages through the proxy while downloading domains connect directly, or the other way around. Use connection logs to check the actual outbound for the target domain. Don’t infer the route from the app name alone: an app may use separate domains for sign-in, media, and updates.

Change transport and TUN settings with care

Multiplexing isn’t faster on every protocol or network. If the problem started only after enabling an advanced transport option, restore its default and compare. Don’t combine supposed universal speed-up settings from different sources. Protocol and core combinations have limits; enabling a feature on the client can’t add performance if the server doesn’t support it. Keeping the provider’s original settings intact is more important than changing the transport type at random.

If small pages load but large files stall in TUN mode, MTU, path MTU discovery, and UDP handling are worth checking, but they aren’t the only possible causes. Turn off TUN and retry the same download through the system proxy. If only TUN fails, check the virtual network adapter and core logs. If you need to change the MTU, record the original value and test small adjustments. Restore it if nothing changes, and don’t keep network settings you can’t explain.

DNS can also make things feel slow. If DNS retries delay the first page load but file transfers are normal once they start, see the DNS section instead of switching to a higher-bandwidth node. Browser caching is another common source of confusion: the second visit may be faster simply because resources are already stored locally. To compare first loads, use a fresh session or keep cache conditions consistent.

Look for improvements you can reproduce, not a one-off speed peak. Test with your actual apps over time and make sure you haven’t traded frequent disconnections for a brief speed boost. A provider’s traffic multiplier is a billing rule, not a speed guarantee; consider these separately when choosing a service. For help comparing locations, protocols, and multipliers, see the node selection guide. Client settings can’t make up for congestion on your underlying connection, so address local and upstream network issues first.

DNS issues: find out what resolves the domain and where the result is used

DNS translates domain names into IP addresses, but with a proxy, resolution may happen in the operating system, browser, client core, or at the remote end. A successful lookup in one place doesn’t mean the connection uses the same result. Rather than changing DNS servers straight away, find out which component made the failed request, which route the lookup took, and whether the resulting address affected routing. Check name resolution and the connection’s outbound together.

First distinguish a DNS failure from a connection failure

If the log explicitly reports a DNS resolution failure, note the domain and compare its result with other domains at the same time. If all domains fail, check the DNS service and its route. If only one domain fails, consider its authoritative records, cached results, or service status. Visiting a site by IP address isn’t a reliable substitute test: many sites rely on the server name, certificate, and virtual host. Reaching the IP doesn’t prove the domain-based connection is working.

Use built-in system tools to check resolution from the operating system. On Windows, run nslookup example.com. This confirms whether a system lookup gets a response; it doesn’t guarantee that browser encrypted DNS or the client’s built-in resolver behaves the same way. Record the query time and network when comparing results rather than saving just one IP address. If the system resolves the domain but the client reports an error, check the core’s DNS settings instead of repeatedly flushing a cache that isn’t involved.

Understand domain rules and their order

Routing rules can match domains or IP addresses. When no domain rule matches, some strategies resolve the domain so they can continue checking IP-based rules. The example below shows part of a V2Ray/Xray routing object to illustrate where fields go; it isn’t a complete, runnable configuration. It also isn’t a DNS server setting, so changing this line alone won’t fix every DNS problem.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

IPIfNonMatch means the domain is resolved if it doesn’t match an existing rule, so related IP-based rules can then be checked. The outcome also depends on rule order, the resolved address, and the default outbound. Switching to another strategy changes when matching happens; it doesn’t guarantee better routing. First determine which outbound should handle the domain, then find out why the relevant rule wasn’t matched. For more background, see the routing and traffic-splitting glossary.

Avoid a DNS and proxy dependency loop

If the proxy server address is a domain, but resolving it requires a DNS request that can only go through the proxy, you can end up with a startup loop. The address of an encrypted DNS service may itself need to be resolved first. Within the options supported by your client, keep a working bootstrap resolution path for the server domain and confirm it works before the proxy starts. Don’t add a complex chain of remote lookups without verifying that it’s needed.

With TUN enabled, check that system DNS requests are captured, forwarded, and routed correctly. If browser encrypted DNS, system encrypted DNS, and core DNS are all enabled, different apps may get different results. Start with one clearly defined test path, temporarily disable custom settings at other layers, then restore them one at a time. If you use a mapping method such as FakeDNS, apps may need to reconnect after you disable traffic capture; they could otherwise keep using mapped addresses that only make sense with that method.

Check dual-stack networking too. A domain may return both types of addresses even when one network path isn’t working, causing intermittent waits or failures in some apps. First check which address type the connection actually uses, then briefly compare the client’s address-selection options. Disabling one address type system-wide shouldn’t be your first step: it may hide problems with routing, the gateway, or the upstream network and affect other apps.

To verify recovery, check system lookups, client logs, and actual webpage access separately, and confirm that their results agree. Then switch networks once to see whether DNS settings or bootstrap conditions change. If changing the DNS server fixes things briefly but the problem returns, check what happens when the cached result expires. Note whether DNS succeeds but the connection fails; that points to the outbound or target service, not a need to keep trying different DNS servers.

System proxy not working: check the endpoint, permissions, and TUN

The system proxy is a set of settings that apps can choose to follow, not a switch that forces every program through a proxy. Some apps use it, some have their own proxy settings, and others connect directly. So if the browser works but another app doesn’t, that doesn’t necessarily mean v2rayN failed to start. First find out which connection method the app supports, then choose the system proxy, its in-app proxy, or TUN.

Confirm that the system proxy settings were applied

After selecting automatic system proxy configuration in v2rayN, open your operating system’s network proxy settings and check that the address and port point to the current listener. If they still show an old port or another program’s address, check whether a different client, management tool, or script is overriding them. Turn off other traffic-routing tools and apply the settings again. Organization-managed devices may restrict network settings; confirm which configurations are allowed instead of bypassing those policies.

For a manual proxy in an app, check the protocol, host, and port, then make sure you haven’t filled in an authentication prompt by mistake. A local listener usually doesn’t require authentication, so don’t put the node’s user ID or password into the browser’s proxy authentication dialog. Don’t change the listening address to all network interfaces just for troubleshooting. If it’s only for local use, keeping it bound to the local machine makes access easier to control. Plan access permissions separately if you need to share it on a LAN.

Check auto-config, app-specific proxies, and environment variables

A system may have a manual proxy, an auto-configuration script, and an in-app proxy at the same time. Which one takes precedence depends on the app. Browser extensions can also change the browser’s outbound route. Disable relevant extensions, check the browser’s proxy settings, and start a new session. Command-line tools and background services may use environment variables or their own settings. Don’t assume they follow the browser’s route just because it works; this guide focuses on verifying the active endpoint through graphical settings.

Split TUN problems into startup and traffic forwarding

TUN uses a virtual network adapter to handle traffic routed to it, but the actual coverage depends on system routes and client settings. If startup fails, check permissions, virtual adapter creation, and driver-related logs first. If startup succeeds but you can’t get online, check routing, DNS, outbound selection, and whether the server address is correctly excluded from interception. An enabled toggle doesn’t prove that all traffic is being captured, and different clients don’t necessarily offer the same settings.

Use the operating system’s approved authorization flow for desktop operations that need elevated permissions. If it still fails, check for leftover virtual adapters, other network tools using the routes, and clear blocking events from security software. Don’t disable all protection. Allow only the components needed based on actual logs, then test again. If there’s no clear evidence of a block, leave your existing protections enabled to avoid introducing new risks.

If you encounter a routing loop or lose access as soon as TUN is enabled, turn TUN off and confirm that the system proxy baseline still works. Then enable traffic capture and DNS settings one at a time to identify what triggers the problem. Routing rules determine where captured traffic goes; TUN doesn’t automatically send every destination through the same node. For setup steps and use cases, see the TUN setup guide and the virtual network adapter explainer.

If your network stops working after you exit the client, first check whether the system still points to a local proxy that has been shut down. Then check whether the virtual adapter and routes were released properly. Reopen the client and use its normal options to stop traffic capture and clear the system proxy instead of killing every process. Once access is restored, note the working routing setup. Use only the layers you need day to day to avoid proxy loops and settings that override each other.

Client crashes: check the interface, core, and configuration separately

A window that suddenly closes, a Start button that does nothing, and an open interface with an exited core are three different problems. Check whether the tray icon is still present, whether logs are updating, and whether related processes are still running in your system’s process manager. Note what triggers the issue: does it exit on startup, after importing a particular node, or only when TUN is enabled? A reproducible trigger is usually more useful than an isolated crash message.

Protect your settings before changing the runtime environment

Before deleting folders, resetting settings, or reinstalling, use the client’s export feature to save the configuration you need. Subscription URLs and node authentication details are sensitive; keep backups somewhere you control. If the interface won’t open, you can copy the existing data directory for recovery, but don’t share the entire folder publicly. Then confirm that the configuration belongs to the current installation so you don’t mistake data from a different portable copy for the active one.

Check the platform and processor architecture on the client downloads page. A desktop operating system’s ability to run one kind of app doesn’t mean a package built for a different architecture will work. When moving between devices with different processors, choose the package for the target device. The desktop and classic WPF editions of Windows use different interface technologies. Follow the runtime requirements for the version you installed; don’t apply dependency instructions for one interface to the other.

Troubleshoot the interface and core startup separately

If the interface closes on startup, check system event logs, app logs, and available disk space. An unwritable install directory, incorrect permissions on the user data folder, or sync software locking files can all interfere with startup. Put the program in a location the current user can access, and confirm that the account has the necessary permissions. Don’t run with elevated privileges all the time to mask a regular file access problem. Evaluate any TUN permission requirement separately from normal interface startup.

If the interface stays open but the core exits immediately, focus on configuration generation and listener port errors. A log saying that an address is already in use may mean another instance is running or a different program has taken the same port. Close duplicate instances and check what uses the port before changing the local listener settings. If you change the client port, update the system and app proxy settings too; otherwise, the browser may still point to the old port and show a new “client running, but no access” problem.

If the client reports a configuration parsing error, unsupported field, or failed rule file, find the most recent change. For manually edited JSON, check quotes, commas, and field types—but don’t edit a file that the client regenerates at every startup. Prefer reverting the setting in the interface or restoring a saved configuration. If imported settings aren’t compatible with the current core, check protocol support instead of deleting lines at random.

After an update, compare what changed

If the problem started right after an update, note the package type, system environment, and trigger before and after updating. Don’t guess or rely on memory for version details. Check that the old process exited and that the new program is using the original data location. Multiple instances sharing a data directory can cause inconsistent state. Before reinstalling, confirm which executable is running; a desktop shortcut may still point to an old directory.

If security software quarantines or blocks a component, check the specific event and file source before restoring it or adding an exception. Don’t turn off all protection at once. Low disk space, an unexpected shutdown, or an interrupted write can also leave an incomplete configuration. If the interface still opens, export whatever data is readable, then create a new working data set. Restore groups and rules one at a time to identify what triggers the issue.

When asking for help, include the operating system, architecture, client interface type, reproduction steps, and a redacted excerpt of the relevant error. Hide subscription credentials, server authentication fields, and unnecessary personal paths. Once the client works again, verify a basic connection before restoring complex routing and TUN. Test it during normal use to make sure only the window—not the connection—has recovered. For more on how cores and graphical clients relate, see the Project V ecosystem guide to distinguish interface problems from core issues.

Mobile issues: VPN permissions, background activity, and per-app rules

These Android steps focus on v2rayNG, with v2flyNG as an alternative that uses the V2Fly core. Their configuration options and interfaces may differ, so don’t assume that an advanced setting available in one client also exists in the other. First confirm which client is running, then check in this order: basic network, VPN permission, node connection, and app rules. Desktop system proxy instructions don’t apply directly to Android VPN routing.

No internet after starting: check permissions and VPN conflicts

The first time you connect, Android asks for permission to establish a VPN connection. Without that permission, importing a node won’t route app traffic. Check Android’s VPN settings and the client notification to confirm that the active connection belongs to the expected client. Android typically allows only one active VPN service per user profile, so other network tools that use VPN APIs may conflict. Stop them before testing the client on its own.

If Always-on VPN or blocking connections without a VPN is enabled, basic internet access may stop when the client disconnects. This is a system policy, not necessarily a network failure. Before troubleshooting, understand what these settings do. If necessary, adjust the test conditions within your device management rules and restore them afterward. On work-managed devices or profiles, follow the network setup provided by your administrator.

Test screen-off disconnections separately from background restrictions

If the connection works in the foreground but drops after the screen locks, check battery optimization, background activity limits, and Data Saver. Settings vary by device manufacturer; look under the app’s information page for battery, background data, and auto-start options. Grant only the permissions the client needs. You don’t need to change power settings for every app. Also check notification permissions and background service restrictions, but the presence of a notification alone doesn’t prove that the node is still connected.

Use one node for testing. First confirm that a page loads in the foreground, then lock the screen, wait, and check the logs for reconnections and network changes as soon as you unlock. If the connection drops only when switching from Wi-Fi to mobile data, the old connection may have failed without reconnecting. Stop and reconnect, then check whether the new network works. Don’t keep changing protocol settings before the connection is re-established, or you’ll mix up a network handoff issue with a configuration problem.

If some apps fail, check per-app routing and DNS

Per-app proxy settings usually offer a choice between proxying selected apps and bypassing selected apps. Choosing the wrong mode can make checked apps skip the proxy. Confirm the mode first, then check that the target app and its required services are in the right list. Reconnect the VPN and fully quit and reopen the target app after making changes. A browser and another app may behave differently because they use different DNS or connection protocols; one successful webpage test doesn’t show which apps are being routed.

Android Private DNS, client DNS, and an app’s own encrypted DNS can all be active at once. If the log reports a name resolution failure, follow the DNS troubleshooting steps to find out which resolver is involved. Don’t change every DNS setting to a different service at the same time. If results differ between mobile data and Wi-Fi, check whether the new network requires authentication, restricts a type of connection, or prevents the client from restoring its previous outbound. If needed, compare using a different working node while changing one variable at a time.

Installation, migration, and final checks

A package built for the wrong architecture may fail to install or run. Choose one based on your device’s processor and system capabilities. Most current devices use arm64; if you’re unsure, check the device information and the general package notes on the downloads page. If you can’t install over an existing app, read the system’s error and check for a different signing key or an installation under another user profile. Don’t clear app data just to force an install; back it up first.

When migrating settings, add your subscription again and update it instead of blindly copying every system-related option. Per-app lists, background permissions, and VPN authorization are tied to the device, so check them again on the new one. If one manually configured node fails, verify its complete share link and core compatibility. If every node fails on both Wi-Fi and mobile data, check your account and the service status rather than repeatedly searching through phone settings.

Verify normal use: foreground access, recovery after locking the screen, network switching, connections from target apps, and basic internet access after disconnecting should all work as expected. Save working settings and undo temporary debugging changes and unnecessary permission adjustments. To choose a different package, visit Android client downloads. For common usage questions, see the FAQ. Once you’ve completed these checks, restore your usual advanced rules so you have a clear baseline for the next issue.