V2Ray Troubleshooting
Nodes, subscriptions, and system proxy

No internet access: Check your network and proxy path separately

“No internet access” is too vague to pinpoint a problem. First note three things: Can you reach ordinary websites with the proxy off? Does every site fail with the proxy on? Is the problem limited to one app? Temporarily quit other proxy or VPN tools so multiple rule sets do not handle traffic at once. Note the current node and routing mode, and use the same test page throughout. Avoid jumping between nodes, networks, and DNS settings; otherwise, it will be hard to tell which change helped.

Turn off the proxy and test your direct connection

In v2rayN, first select Clear system proxy, then turn off TUN mode. Closing the main window may not quit the client, so check the system tray for a background process. Reopen your browser and visit a site that normally works without a proxy. If that also fails, check your Wi-Fi, cable, gateway, and network sign-in page; public networks may require authentication. Do not adjust node settings until your basic connection is working. If other devices work on the same network but this computer does not, check its firewall, manual proxy, and custom DNS settings.

Once direct access works, launch v2rayN, make sure the node list contains a usable configuration, and select it as the active server. Check the logs for a core process exit, configuration parsing error, or port binding failure. An open client window only confirms that the interface is running; it does not mean the proxy core is listening. Find the actual local port in the settings and compare it with the listening address in the logs. Do not assume every client uses the same port, or enter the server connection port as the local proxy port.

Test the local listener and remote connection separately

Once you have confirmed the local HTTP or mixed-protocol endpoint, bypass the system proxy setting and test by specifying the proxy explicitly. The command below is for Windows PowerShell and assumes the client's HTTP or mixed listener uses port 10808. If your settings differ, replace it with the correct port. The test URL checks the HTTPS request path; it does not guarantee that a particular site is available. If the port only accepts SOCKS, use the SOCKS test in the next section instead of these HTTP options.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

If the command immediately reports that it cannot connect to the local address, check whether the core is running and whether the port matches. If it connects to the local proxy but then reports a remote handshake failure, see the node section. If the command works but the browser does not, check the browser's own proxy settings, extensions, and system proxy rather than switching servers again. A redirect, access-denied page, or other HTTP status means the request received an application-level response; it should not simply be classified as “no network.”

Narrow it down to routing, the app, or the destination site

Temporarily switch to the client's global proxy route and retry with the same node. If global mode works but split routing does not, check whether a direct-connection rule matches the destination domain, whether rule data loaded correctly, and whether DNS results affect IP-based rules. Global mode is only a diagnostic comparison; restore your original mode once you identify the issue. If only one app fails, check whether it follows the system proxy. Some apps need their own proxy settings, while others require correctly configured TUN or VPN traffic capture.

After fixing the issue, test at least two types of access: one site that should connect directly and one that should use the proxy. Then quit and restart the client to confirm the settings persist. If direct access fails again after quitting, a system proxy or network setting may have been left behind; see System proxy not working. If you are new to the setup, revisit the quick start guide for the main workflow. For general questions, see the FAQ.

Node timeouts: Check the address, port, and handshake in order

First distinguish a timeout in the client's test from a timeout during actual use. Different tests may check a TCP connection, request a specific webpage, or use another method; one failed test does not prove the entire node is down. Cross-check with a browser and an explicit proxy command. Then determine whether one node, every node in a subscription, or nodes from all sources are affected. A single failure points more toward node settings or server status; if all fail, rule out local network issues and core startup problems first.

Check the server address and remote port

Open the node editor and check the server address, server port, protocol, and transport. Do not include a protocol prefix, path, or extra spaces in the address field unless it explicitly requires a full URL. The port must match the endpoint provided by the service; do not change the remote port to 10808 just because you see that number elsewhere. After updating a subscription, make sure you selected the updated configuration. Some interfaces retain an old entry or selection, so you may need to select the active server again.

In Windows PowerShell, the command below checks whether a TCP connection can be established to a specified host and port. The example domain is for illustration only; replace it with the node server's domain and actual port when troubleshooting. The result checks only the TCP connection, not protocol authentication, transport routing, or TLS settings. It also cannot be used to test a UDP service as if it were TCP. If the connection fails, repeat the same test on another network, then ask the service provider whether the endpoint has changed.

Test-NetConnection -ComputerName example.com -Port 443

If domain resolution fails, see the DNS section first. If the domain resolves but TCP fails, the cause may be the network path, remote listener, firewall, or unavailable service; repeatedly changing local encryption settings is unlikely to help. If TCP succeeds but the connection still times out, check the handshake and authentication details in the client logs. Keep only the lines around the error. Before sharing logs, remove subscription URLs, user IDs, and authentication fields; never post the full configuration publicly.

Separate TLS, transport, and protocol settings

For a TLS certificate error, first check the system date, time zone, and time synchronization, then verify the SNI or server name. The server address and SNI may differ; making them identical is no substitute for the provider's settings. Transports such as WebSocket also require the correct path, Host, and security layer. Paths are often case-sensitive, and a leading slash may matter. A closed handshake does not necessarily indicate a certificate problem; the request may have reached the wrong service endpoint.

VLESS, VMess, Trojan, and other configurations have different authentication and transport requirements. Changing only the protocol name while reusing other fields will not work. REALITY configurations also require the server's public key, short ID, server name, and other parameters; use the original configuration rather than piecing settings together from the web. Do not treat allowing insecure connections as a general fix. Skipping certificate verification will not correct a wrong path and weakens identity checks. For certificate issues, see TLS handshake and system time troubleshooting.

Use one-variable comparisons to identify the cause

If the client provides a SOCKS endpoint, the command below can send the destination hostname to be handled by the proxy. It assumes the local SOCKS listener uses port 10808; confirm the endpoint type first. Compared with an HTTP proxy test, this can help identify an app proxy configuration issue, but it does not prove that all routing and DNS requests are handled remotely. The result depends on the core's rules.

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

If the same configuration works on another network, investigate the current network. If switching nodes on the same network fixes it, the original node or its route is more likely to be the cause. If every comparison fails, check whether the core supports the fields in the configuration, then consider choosing a client for your platform from the downloads page. Do not switch cores at random or overwrite your original configuration. For a complete troubleshooting sequence, see the node timeout troubleshooting guide. When reporting the issue, include the comparisons you have already made.

Subscription failures: Distinguish download errors from parsing errors

Subscription updates involve two separate steps: retrieving the content and parsing it into configurations the client supports. An “update failed” message can refer to either step. Check whether the error mentions a connection timeout, HTTP status, or certificate, versus an unrecognized format or no valid nodes. The first group points to the connection path; the second points to the response content or subscription format. Do not start by deleting the entire subscription group, or you will lose both the old configuration and useful before-and-after comparisons.

Check the subscription URL and response type

Copy the subscription URL again from your service provider and check for leading or trailing spaces, line breaks, or punctuation added by a messaging app. Some URLs contain query parameters; omitting the end may prevent authentication. Do not remove or change parameters just because they look complex. Account pages, purchase pages, and client subscription URLs serve different purposes. Being able to open a webpage in a browser does not mean it is an importable subscription. Treat the full URL as sensitive information; do not include it in public screenshots, search boxes, or third-party parsing sites.

If the response is unauthorized or forbidden, check whether the subscription has expired, the URL has been reset, or the server restricts access methods. If the resource is not found, check whether its path has changed. A successful request that parses to nothing may have returned a login page, maintenance notice, access verification page, or error message. A success status alone does not mean the client is broken. You can inspect the start of the response locally to see whether it looks like webpage text, but do not copy content containing credentials into logs or public support tickets.

Choose the right update route

If the current network cannot reach the subscription server directly but you already have a working node, select that node first and use the client's update-through-proxy option. Whether normal and proxied updates bypass the system proxy depends on the client implementation; the system proxy toggle alone does not tell you. Conversely, if the client sends update requests through a failed node, switching to a direct update may work. Change only the update method and keep the same subscription URL so you can compare the connection paths.

If you have no working node during initial setup, you cannot rely on a proxy that has not been established to retrieve the subscription. Retry on a network where access is allowed, or ask the service provider for another import method supported by the client. Do not disable certificate verification to work around a failure or use an untrusted subscription conversion service. Update at a reasonable frequency; rapid repeated attempts may trigger server rate limits. If you receive an explicit rate-limit response, wait before trying again instead of creating several identical groups.

Check the format, encoding, and client support

Share links, encoded collections of links, and structured configurations are different formats. Some providers generate different content for different clients, so choose the option for v2rayN, v2rayNG, or v2flyNG. Keep the original text before handling encoded content to avoid double encoding, truncation, or converting line breaks into ordinary characters. Do not simply rename another app's configuration file; the extension does not change its internal format. If the parser reports an unsupported protocol or field, check the client's and core's capabilities instead of deleting the field at random.

If the update reports success but the list has not changed, check the displayed group, search terms, and hidden-item rules. Make sure you are not viewing only favorites or another filtered result. Nodes may also have been removed by the subscription provider; the client may have imported them correctly. If needed, create a temporary group for comparison, but do not overwrite the original group right away. After recovery, select a node manually and test an actual connection; a successful subscription update does not prove that a node works. For import steps, see the subscription import guide. For content checks, see the subscription parsing troubleshooting checklist.

Slow speeds: Test connection setup, throughput, and app performance separately

First describe where the slowdown occurs: a long wait before a page opens, slow images after the main content appears, or a low rate during sustained downloads. Delays during connection setup may involve DNS, the handshake, or the destination site's response. Sustained transfers are also affected by bandwidth, packet loss, congestion, and server load. A latency result in the client reflects one particular test; it does not measure usable download bandwidth, and one result cannot predict a node's long-term performance. Keep your current mode and node, and establish a repeatable test.

Rule out local bandwidth and device load

Pause system updates, large downloads, cloud sync, and other network-heavy tasks. Check whether other devices on the same network are also transferring data. A strong Wi-Fi signal can still be affected by interference; move closer to the access point or compare with a wired connection. If direct access is also slow, fix the underlying network before changing proxy settings. A mobile hotspot can provide a useful comparison with a fixed network, but keep data charges and limits in mind and avoid repeated large downloads.

Check CPU, memory, and disk activity in Task Manager or your system monitor. High device load, low storage, or overheating can slow the browser and client; apparent network lag may actually be a local bottleneck. TUN handling traffic for many apps, complex rules, and verbose logging can also add overhead. Pause unnecessary tasks and compare the standard system proxy with TUN mode. Do not weaken verification or disable system protections for a superficial speed boost.

Compare nodes and routes fairly

When testing nodes, keep the destination site, network, client mode, and test time as consistent as possible, and switch only one node at a time. Do not run large downloads through multiple nodes at once; they will compete for local bandwidth. A shorter geographic distance does not guarantee a faster connection: peering, remote egress, and congestion also matter. If one site is slow while others work normally, the site itself, its content delivery path, or restrictions on the remote egress may be responsible. Do not immediately blame every proxy connection.

If global routing is fast but split routing is slow, first confirm whether the slow request goes through the proxy or connects directly. A webpage usually loads resources from multiple domains. If the main page loads but images do not, resource domains may be using different routes. Temporarily enable a reasonable level of access logging to identify slow or failed resource domains, then adjust the relevant rules. Do not add a rule based only on the domain in the address bar, and do not leave highly detailed logging on during everyday downloads; it can consume disk space and expose browsing records.

Understand connection multiplexing, UDP, and MTU limits

Multiplexing is not a speed boost that should always be enabled. It may reduce repeated handshakes, but on some routes it can worsen congestion or cause compatibility issues. Follow the node requirements and compare under the same conditions. Web technologies such as HTTP/3 use UDP, which is not necessarily handled by the system HTTP proxy. An app may fall back to another connection method, causing a delay on first load. Check which transport the app actually uses and what traffic is captured before attributing every delay to low node bandwidth.

Investigate MTU only if specific large pages, uploads, or long-lived connections stall in TUN mode while the standard system proxy works. Record the default value, consult the client guidance for your network, and adjust gradually, testing after each change. A value that is too low adds fragmentation and processing overhead, while copying a fixed value from an online post may mask the real issue. MTU will not fix authentication failures, certificate errors, or a server outage; check it only after confirming basic connectivity.

Judge recovery by the tasks you actually need to do: Can pages open reliably? Do calls or long-lived connections drop? Can transfers maintain a steady rate? If performance is poor only at certain times, record comparisons across several time periods and report them to the service provider instead of repeatedly changing every local setting. If delays occur mainly on first access or behavior differs between IP and domain access, see the next section on DNS. If only one app is slow, check its own proxy settings and routing rules rather than switching nodes globally.

DNS issues: Find where names resolve and how queries are routed

DNS translates domain names into addresses, but a single visit may involve the system resolver, browser secure DNS, the client's built-in DNS, and resolution on the proxy server. If a domain fails while other connections work, first identify which layer is failing. A log showing that the server's domain could not be resolved is different from an error resolving the destination website: the first may prevent the proxy connection from starting, while the second occurs after an exit has been selected. Changing one public DNS address does not necessarily change the entire resolution path.

Check system resolution and cache first

The Windows commands below show the system's DNS results and clear the local DNS cache. The example domain is for comparison; also query the actual destination and node server domains when troubleshooting. Getting an address does not guarantee it is the one the destination service expects. Different resolvers, networks, and geographic exits may return different results. Record the original result before clearing the cache, then reopen the app and query again. Do not infer the cause from a page that happens to load once.

nslookup example.com
ipconfig /flushdns

If a query times out, check whether the DNS server configured on the system is reachable and whether it points to a local network device that is offline. Corporate and campus networks may rely on internal DNS for private domains; blindly switching to a public address can break internal services. Restoring automatic DNS can be a useful comparison, but record the original setting first. Clearing the cache removes old results; it cannot fix an unreachable upstream resolver, incorrect routing rules, or missing records on the server.

Tell browser, system, and proxy DNS apart

A browser may use its own secure DNS, so it is possible for command-line lookups to work while the browser fails. Check for a custom resolver, proxy extension, or separate browser network configuration, then compare with another app that follows system settings. Do not change browser secure DNS, system DNS, and client DNS at the same time, or you will not know which layer helped. With encrypted DNS, also confirm that the resolver itself is reachable over the current network or proxy; otherwise, solving one domain issue may introduce a new connection dependency.

In a SOCKS test, socks5h can send the destination hostname to be resolved by the proxy, unlike a typical local resolution path. If the results differ, investigate local versus proxy-side resolution, but this does not prove that the client handles every domain the same way. Routing policies, core DNS settings, and app-specific resolution logic all affect the result. Do not replace an HTTPS URL with an IP address as a simple test; certificates, SNI, and virtual hosting also depend on the original domain.

Check routing dependencies and resolution loops

With domain-based rules, a request may be routed by its domain. With IP-based rules, the core may need to resolve the domain before it can match an address. Some policies, such as IPIfNonMatch, resolve only when no domain rule matches; they are not a “always resolve remotely” switch. Before changing the policy, understand the rule order and check whether an earlier rule has already selected a route for the problem domain. If the proxy server's own domain must be resolved through a proxy that has not connected yet, startup can become circularly dependent.

TUN may also use virtual DNS addresses and address mapping. Do not enter a virtual address as a real server address in a node configuration. After an app or core restarts, mappings used by old connections may no longer be valid. After changing these settings, reconnect the affected app and restart the client if needed rather than relying on a long-lived connection in an existing tab. If the problem occurs only in TUN mode, switch back to the standard system proxy to narrow it down to the virtual adapter, DNS capture, or routing conflicts before changing advanced settings.

Final testing should cover both proxied destinations and local network resources. If websites work again but printers, internal domains, or local services do not, routing or internal DNS still needs adjustment. Do not force every unknown domain through one exit as a permanent fix. For domain rules, IP rules, and core names, see the glossary. If the logs show successful resolution but the remote handshake still fails, return to the node section instead of repeatedly changing DNS settings.

System proxy not working: Check the mode, listener, and app behavior

A system proxy tells apps that honor the setting where to connect; it does not automatically capture every network request. In v2rayN, Set system proxy automatically, Clear system proxy, and Do not change system proxy respectively apply, remove, or preserve the current system proxy state. These are separate from global, bypass mainland China, and direct routing modes. The former determines how an app sends traffic to the client; the latter determines where a request goes after it enters the client. Confusing these layers is a common reason global mode appears to have no effect.

Confirm the core listener and endpoint type

First check the actual local listening address, port, and protocol in the settings, then verify that the system proxy points to the same endpoint. Do not identify HTTP, SOCKS, and mixed endpoints by port number alone; check the client documentation for the protocols a mixed endpoint accepts. Older configurations may use different ports, so do not force a tutorial's default value. A listener bound to the local loopback address is suitable for use on that device; there is no need to expose it on every network interface for troubleshooting. Widening the listening address also creates additional access risks.

On Windows, the commands below can check whether port 10808 is listening and identify the associated process. The first uses PowerShell; the second is a system utility that can be run from Command Prompt or PowerShell. If there is no result, check the core logs. If another process is using the port, note its process ID and identify the program in Task Manager. Do not terminate an unfamiliar system process, and do not assume that a listening port belongs to this client.

Get-NetTCPConnection -LocalPort 10808 -State Listen
netstat -ano | findstr ":10808"

Once you confirm a conflict, quit the other proxy tool normally or choose an unused port in the v2rayN settings. Restart the relevant core after changing the port, then apply the system proxy again. Update any browser-specific proxy settings, terminal environment variables, and other manual settings too. Changing only the listening port while leaving the app pointed at the old one can make the client appear to run normally while requests still go to the wrong port. For details, see How to fix a local port conflict.

Check system proxy settings on each platform

If an explicit proxy command works but a regular app does not, check the app's settings first. Browser extensions may override the system proxy, terminals may inherit outdated proxy environment variables, and services may use separate configuration. On Windows, netsh winhttp show proxy shows the WinHTTP proxy; it does not represent the proxy state used by every browser and desktop app. Do not keep writing another system setting just because this command reports a direct connection.

Check for leftover settings and TUN traffic capture

If the client exits unexpectedly while the system still points to a local proxy port, apps that follow that setting will fail once the core has stopped. Restart the client, select Clear system proxy, then check the system proxy page for a manual endpoint or automatic configuration script that remains. If the settings are managed by an organization, do not overwrite them. After a normal exit, verify that direct access works instead of merely closing the window. When multiple proxy tools are running, the one that writes its settings last may override the others; quit the rest before testing.

TUN captures traffic through a virtual network interface and requires appropriate permissions, routing, and firewall support. It is not another name for the system proxy toggle. First confirm that the standard proxy works, then enable TUN separately and watch the logs. If the connection drops as soon as TUN starts, turn it off to return to a known working state, then check for conflicts with the virtual adapter, other VPNs, or security software. After fixing the issue, test apps one at a time to confirm what is captured. Preserve local network access and necessary direct connections; sending all requests into the client does not mean every request must go through the remote proxy.

Client crashes: Separate UI exits from core startup failures

First identify where the failure occurs: no window appears after launch, the window opens and immediately closes, the main interface works but a connection will not start, or the process disappears after running for a while. The graphical interface and proxy core may run as separate processes, so the core can exit while the main window stays open. Note the action that triggered the problem, the exact error, and the system architecture before considering a reinstall. Do not repeatedly delete settings, rebuild subscriptions, and switch cores; you may lose configuration and make the original problem impossible to reproduce.

For startup failures, check the package, directory, and runtime

Choose an option that matches your system and processor on the client downloads page. v2rayN is the recommended desktop client. The Windows desktop and classic WPF versions use different interface technologies and have different runtime requirements; check the requirements for the package you selected. Do not copy missing component files from one package into another. On macOS, choose between Apple Silicon and Intel builds. On Linux, select a package type that suits your distribution as well as your architecture. The wrong architecture or a missing runtime usually cannot be fixed by changing proxy rules.

If the package needs to be extracted, extract it fully to a directory where the current user has write access. Do not run it from a compressed-file preview window. Long paths, protected directories, or files quarantined by security software can prevent startup components from loading. Check system alerts and security software records to identify the affected file; do not simply disable all protection. Installers should be used through the normal installation process, not mixed with loose files in a portable directory. For common Windows choices, see Installation setup and package types.

If the core exits, check the configuration and port first

If the main interface works but the core will not start, look for the first clear error in the logs. For a port binding failure, see the port section. If a field is unrecognized or the configuration fails to parse, consider whether you recently imported a custom configuration, changed advanced settings, or switched cores. The new configuration may contain fields unsupported by the current core or invalid JSON syntax. Do not focus only on the final “process exited” message; the cause is usually in the earlier parsing or startup output.

The following is a minimal, valid JSON logging snippet. It illustrates object, field, and string syntax; it is not a complete proxy configuration that can be launched as-is. In practice, change the log level through a client-supported settings option or edit the correct section of a complete configuration. Do not replace the whole configuration file with this snippet. Restore the usual log level after troubleshooting to avoid accumulating extensive access records.

{
  "log": {
    "loglevel": "warning"
  }
}

A trailing comma, an unclosed quote, or a number where a Boolean is required can cause parsing to fail. A JSON syntax checker can confirm that the structure is valid, but it cannot verify whether a field is supported by the current core. Unless you have a clear reason to keep an advanced option, revert the one you just changed and let the graphical client generate the configuration. When troubleshooting a core switch, first restore a combination of nodes and settings supported by that core. Xray and V2Fly are not interchangeable programs that support every field in common.

Compare with a backup and a clean environment

Quit the client completely, then back up its configuration directory or export its settings according to the client's storage method. Backups may contain subscription and authentication details; keep them in a secure local location. Leave the original directory untouched and start a clean instance from a separate directory or fresh app configuration. Do not run two instances at once during testing, as they may compete for the same port. If the clean environment works, restore subscriptions and essential settings gradually rather than overwriting everything at once. If it fails too, check the runtime, file permissions, and system-level error logs.

After an upgrade, save the current state first. Make sure old and new packages have not been mixed, the old process has exited, and configuration migration is complete. Do not replace files that the client is currently using. If macOS shows a security alert, check its type and use the system-provided option. On Linux, review startup output and desktop session dependencies rather than always running with elevated privileges. After recovery, verify subscriptions, system proxy settings, and cleanup on exit, then remove temporary test directories. When reporting the issue, include only the necessary error, system architecture, and reproduction steps; do not attach a full private configuration.

Mobile troubleshooting: Check VPN permissions, per-app routing, and background limits

For Android, v2rayNG is the recommended client and uses the Xray core; v2flyNG is an alternative with the V2Fly core. Their configuration support and settings are not identical, so do not copy every setting just because the interfaces look similar. Before troubleshooting, note the app, selected node, operating mode, and network. Then determine whether the connection fails from the start, drops after the screen locks, stops working after a network change, or affects only some apps. Get one client working reliably on a single network before comparing; do not start two VPN connections at once.

For a first connection, check permission and VPN conflicts

VPN mode usually prompts the system to confirm a local VPN connection. If you previously denied permission, start the connection again and look for the authorization prompt. A button showing that the client has started does not prove that traffic from every app is going through the VPN. Check whether another VPN, a work-profile network tool, or an always-on VPN setting is in use. Some systems manage network access separately for each profile, so personal and work apps may be subject to different policies. A VPN icon in the notification bar alone does not confirm that every app is covered.

Proxy-only mode usually provides a local proxy endpoint; it does not automatically route every other app through the client. If the system or an app is not configured to use that endpoint, it is possible for a node test to work while a browser request bypasses the proxy. First decide whether you need VPN traffic capture or a local proxy, then configure the target app accordingly. If the system VPN page has Block connections without VPN enabled, basic internet access may also fail when the client has not established a tunnel. Understand the setting before testing, and do not repeatedly reinstall the client.

If only some apps fail, check per-app routing

Check whether per-app proxying is enabled and whether the current mode is an allowlist or a bypass list. The same app list has opposite meanings in the two modes: one sends only listed apps through the proxy, while the other excludes listed apps. Newly installed, cloned, or work-profile apps may have separate identities, so check the list again. If a browser works but one app does not, first see whether that app is excluded or uses its own network method, then check whether routing rules send its destination domain directly.

Do not route every domain through the same DNS or exit just to restore one app. Temporarily disable per-app filtering and test the target app on the same node and network. If it works, rebuild the app list gradually. Apps may cache connections, so force-close and reopen the app after changing settings. System browsers, embedded webpages, and standalone apps may behave differently; a successful sign-in through one browser does not replace testing the actual app. If troubleshooting involves an account session, never include login details in public logs.

Troubleshoot screen-lock disconnects separately from network-switch failures

If the connection drops only when the screen locks or the app moves to the background, check battery optimization, background activity limits, and the device manufacturer's process-killing policies. Allow the client the background activity it needs, keeping battery use in mind, and check whether its notification remains visible. Do not disable battery management for every app; test only the client involved. If the process is still running but the connection has failed, check whether the network changes during sleep, whether the remote connection needs to be re-established, and whether system logs show that the VPN was revoked.

After switching between Wi-Fi and mobile data, an existing connection may depend on an address or network path that has changed. Stop and restart the client connection, then test the target app. Distinguish “reconnecting fixes it” from “one network always fails.” If only public Wi-Fi fails, complete the network sign-in first. If only mobile data fails, check basic connectivity, DNS, and the network path. Do not use repeated airplane mode toggles instead of recording the cause, and do not change APN or low-level network settings without evidence.

Check installation compatibility and verify recovery

If installation fails, check the processor architecture, system requirements, available storage, and whether another app with the same name has a conflicting signature. Most recent mainstream devices use arm64; if you are unsure, follow the downloads page instructions for a universal package. Do not extract files manually from another app's directory. If an in-place update is blocked, back up your settings and understand the system prompt before deciding whether to uninstall; uninstalling may delete subscriptions and settings. Choose a package from the Android downloads page, and do not mix the configuration directories of two clients.

If v2rayNG works but v2flyNG fails with the same node, first check whether the protocol and settings are supported by that core instead of immediately blaming the device. When reporting the issue, include the client name, network type, operating mode, per-app policy, and steps to reproduce it, along with an error excerpt stripped of sensitive fields. To follow the setup workflow again, return to the quick start guide. To understand a specific setting, see the FAQ; do not use reinstalling as a substitute for troubleshooting.