V2Ray Connection Problems
Complete Troubleshooting Guide

Establish a reproducible troubleshooting sequence

First identify which layer is failing

A V2Ray client connection passes through at least seven stages: the basic network, client interface, proxy core, remote node, system proxy or virtual network adapter, DNS resolution, and the target application. A page failing to open is only the final symptom and does not prove that the node is down. A disconnected network, a core that never started, a system proxy pointing to an old port, mismatched node parameters, or broken DNS resolution can all look the same. Effective troubleshooting is not about toggling every switch repeatedly. First define the failure boundary: can ordinary internet access work with client traffic capture disabled; does the client log show a successful core startup; is the local listening port present; does the node fail while establishing TCP, or during TLS or protocol negotiation; is only the browser affected, or every application?

Start by writing down four facts: the platform and client, changes made before the issue began, the scope of affected applications, and the first error in the log. Recording the “first error” is more useful than copying the last few dozen lines, because later connection closures and retry failures are often only cascading results. If the issue started after a subscription update, keep the old profile group instead of deleting it immediately. If the old profile works but the new one does not, narrow the search to the subscription contents or new parameters. If neither works, check the network, system proxy, and client status first.

Reproduce the issue with the fewest variables

Change only one condition per test round, then reconnect completely. For example, when testing nodes, keep the same network, client, and routing mode while switching only one node. When testing the system proxy, start with a known-working node and compare “system proxy off,” “automatic system proxy,” and “TUN mode” separately. If you change the node, update the subscription, switch cores, and modify DNS at the same time, even a successful recovery will not reveal what fixed it, and the next failure will be just as difficult to diagnose.

Keep the test environment as simple as possible: close duplicate proxy tools, exit debugging software that modifies the network stack, pause browser-specific proxy settings, and temporarily use the client’s default routing. On desktop, use v2rayN as the baseline test; on Android, choose between v2rayNG and v2flyNG according to the core required by the subscription. If the client’s source or architecture is uncertain, verify the platform and installation type on the download page. Do not investigate routing rules while the core cannot start, because every higher-level test becomes meaningless.

Focus on stage keywords when reading logs

Read logs by stage instead of searching only for “error.” A listening address and port mean the core has loaded the configuration and started accepting local connections. A connection refusal usually means no service is running on the target port or an intermediary actively rejected it. A timeout means the connection did not complete within the allowed time. Certificate name mismatches, handshake failures, or server-name warnings point to the system clock, SNI, TLS, or transport settings. DNS query failures should be handled at the resolution layer first. Logs may contain server addresses and subscription details, so remove account identifiers, authentication fields, and complete subscription URLs before sharing them.

No internet access after enabling the client

Separate a basic network failure from a proxy capture failure

First disable v2rayN’s system proxy or disconnect the Android client, but do not delete the configuration yet. Then use a browser to open a site that normally works and test the local network gateway. If access still fails with the proxy disabled, the issue is in the basic network, Wi-Fi connection, gateway, or system DNS; switching nodes will not help. If access returns immediately, the client has captured the traffic but the local proxy is not forwarding it correctly. Common causes include a core that never started, a mismatch between the system proxy port and the actual listening port, an unusable selected profile, or routing that sends every request to the wrong outbound.

On desktop, also check the scope of the failure. If both the browser and system components fail, check the system proxy first. If only one application fails, determine whether it ignores the system proxy or stores its own proxy address. If local network addresses also fail, check whether the routing mode is incorrectly proxying private addresses. If every application loses access in TUN mode, focus on the virtual adapter, routing table, DNS capture, and runtime permissions. Do not treat the “system proxy” and “TUN” as the same feature: the former mainly serves applications that follow system proxy settings, while the latter captures a broader range of traffic through a virtual adapter. Their failure points differ.

Confirm the local core and listening port

A v2rayN interface showing a selected server does not mean the proxy core is running successfully. After switching profiles, review the beginning of the log and confirm that the core configuration loaded successfully and that a local SOCKS or HTTP listener is present. If the log says the address is already in use, another client process, a background process left after an abnormal exit, or another application is probably using the same port. Exit duplicate clients first, then use system tools to inspect the port. On Windows, run the following command in a terminal, replacing the example port with the local port shown in the client settings:

netstat -ano | findstr LISTENING
netstat -ano | findstr :10808
tasklist /fi "PID eq process ID"

On macOS and Linux, use lsof -iTCP -sTCP:LISTEN or ss -lntp to inspect listening sockets. If the port is absent, return to the client log and fix the core startup error. If it is present, test whether the system proxy points to the same port. After changing the port, reapply the system proxy. Changing only the client listener without refreshing system settings leaves applications connecting to the old port and produces connection refusals.

Check the routing mode and stale settings

During diagnosis, start with a basic routing mode provided by the client instead of complex custom rules. If “bypass LAN and mainland China addresses” works but a custom mode cuts off all access, inspect rule order, the default outbound, and domain matching. Routing usually matches rules in order; an overly broad blocking rule placed first can prevent later proxy rules from running. Defining only partial rules without a sensible default outbound can leave unmatched traffic with no clear destination. Once the connection is restored, add rules back one at a time and test domains, plain IP addresses, and LAN addresses.

Windows may retain the system proxy after the client exits unexpectedly. The browser then keeps trying to connect to a stopped local port, making every site appear unavailable after the software closes. Restart v2rayN and disable the system proxy, or turn off the manual proxy in the system network settings. On macOS, check whether the current network service still has web proxy and secure web proxy enabled. Linux desktop environments may separately retain HTTP, HTTPS, and SOCKS settings. When removing stale settings, clear only the proxy entries confirmed to have been set by the client; do not reset the entire network configuration.

Node timeouts, connection refusals, and handshake failures

Handle the three error types separately

“Timeout,” “connection refused,” and “handshake failure” point to different stages. A timeout means the client initiated a connection but received no expected response for an extended period; the address may be unreachable, the port filtered, packets lost, or the server unresponsive. A connection refusal usually means the target host is reachable but no service is listening on the specified port, or an intermediary explicitly rejected the request. A handshake failure means the basic connection may already be established and the issue occurs during TLS, protocol authentication, transport negotiation, or server-name validation. Treating all three as a “dead node” can make you miss a wrong system clock, SNI, transport path, or copied parameter.

Fix one node and run a direct network test first. For a domain-based node, verify separately that the domain resolves, the result is stable, and a TCP connection can be made to the port. On Windows, use PowerShell’s Test-NetConnection; on macOS and Linux, use nc. These tests check only network and port reachability, not VMess, VLESS, Trojan, or TLS parameters. A reachable port does not guarantee that the full proxy works, but an unreachable port means you should address the server address, network, or service status first.

Test-NetConnection example.com -Port 443

nc -vz example.com 443

Replace the example domain with the server address from your configuration. If the domain does not resolve, go to the DNS chapter. If it resolves but the port repeatedly times out, compare results on another network. If the same node behaves differently across networks, the current network path is more likely at fault. If it fails everywhere while other nodes in the same subscription work, suspect the node itself or its parameters.

Verify protocol and transport parameters one by one

For manual configurations, the server address, port, user ID, encryption method, transport type, path, Host, TLS, SNI, fingerprint, and other fields must match the server. Subscription imports fill these automatically, but failed updates, format conversion, or stale profile data can still leave fields incomplete. Do not compare only the address and port. An extra slash in a WebSocket path, a different gRPC service name, a mismatched TLS setting, or an incorrect SNI can make the TCP connection succeed and then close immediately.

For TLS errors, check the system date, time, and time zone first. Certificate validity depends on the local clock, and a large deviation can make a certificate appear not yet valid or expired. Then verify that SNI is a domain covered by the certificate rather than an arbitrary server IP. Do not treat certificate verification bypass as a routine fix; it only hides domain, certificate, or server configuration problems. For detailed certificate error types, continue with the TLS certificate error checklist.

Understand the difference between client tests and real-world access

Connectivity tests, latency tests, and real web requests in a client may use different request methods. If a test fails while the web works, do not delete the node based on that result alone. If a test succeeds but pages do not open, check the system proxy, DNS, and routing capture. Prioritize real application requests and core logs, while recording how each test was performed. Do not compare a single instantaneous result; repeat tests on the same network, routing mode, and roughly the same time.

If every node in a subscription group begins failing its handshake at once, check the system clock, client core, structural changes in the subscription, and whether the current network affects a shared domain or port. If only one node fails, inspect that profile closely. If v2rayN starts reporting errors after switching core types, confirm that the active core supports the protocol features used by the configuration. Xray and V2Fly share common origins, but their support for some protocol extensions is not identical. Do not assume all configurations are compatible simply by changing the core name.

Subscription update failed or the imported list is empty

First confirm that the subscription request was actually sent

A subscription update passes through several stages: parsing the subscription URL, making the network request, receiving the server response, decoding the content, and converting profiles. When the client reports “update failed,” check the log for an HTTP status, timeout, or format error. A request timeout usually means the current network cannot reach the subscription URL or the update request did not use a working proxy as expected. An unauthorized or forbidden response usually relates to an expired link, account status, or access restrictions. A successful response with an empty list requires checking whether the content is in a subscription format supported by the client.

Keep the complete query string when copying a subscription URL. Chat apps, note-taking tools, and browser address bars may truncate trailing characters or convert special characters into visible text. Copy the URL again from its original source and replace the existing value in the client. A subscription URL is part of your account credentials and should not be posted publicly or shown in screenshots. Naming a subscription group only affects local identification; it cannot repair a remote link. Groups with the same name do not necessarily contain the same content.

Distinguish direct updates from proxied updates

In some environments, the subscription URL must be accessed through an already working proxy. If the client has no reachable profile and updates also require a proxy, you get a loop: “you need the subscription to connect, but you need a connection to update.” Keep a known-working old profile, connect first, and then update; or import the initial profile using the method provided by the service. Do not clear the entire server list immediately after an update fails, because the old profile may be the only reliable way to restore subscription access.

v2rayN’s subscription settings may allow updates through the system proxy or current proxy; confirm the actual behavior in the log. If the subscription request times out directly while the browser can open the same domain with the proxy enabled, the client’s update path may be bypassing the proxy. On Android, also confirm that v2rayNG or v2flyNG has network permission for background updates and is not blocked by system data restrictions. Comparing Wi-Fi and mobile data can quickly show whether the current access network is responsible.

Handle “update succeeded but no nodes”

A successful update only means that the request and parsing stages produced no obvious error; it does not guarantee that the content contains valid nodes. Check whether the group is filtered, whether nodes were placed in another group, or whether a search term remains active. If the list is still empty after clearing filters, inspect the response content type. Subscriptions may contain encoded link collections, structured configurations, or client-specific formats. If the server returns a login page, error message, or empty text, the client may report that the format is unsupported.

If all old nodes were replaced after an update, check the update strategy in the subscription settings. Overwrite updates suit groups maintained entirely by a subscription; manually edited nodes should not share an automatically overwritten group. To preserve local parameters, copy them to a separate group before updating. For standard import entry points on desktop and Android, see the subscription URL import steps. For automatic intervals, proxy updates, and failure causes, see how to fix subscription update failures.

Connected but slow or noticeably unstable

Rule out misleading test conditions first

Judge speed under comparable conditions. A single slow-loading page may be caused by the destination, browser extensions, cache, or image assets and does not necessarily mean the proxy path is slow. Use the same network, device, and download target to compare three states: proxy off, proxy on with a fixed node, and a different node. Before each round, stop background sync, large updates, and cloud-drive jobs, and avoid running multiple speed tests at once. Focus on sustained throughput, initial connection time, and long-connection stability rather than one instantaneous peak.

If the connection is slow with the proxy off, address local Wi-Fi signal, router load, and the carrier path first. If direct access is normal but every node is slow, check client routing, TUN, DNS, and device resources. If only one node is slow, its route, congestion, or remote load is more likely. If desktop and Android are both slow with the same configuration on the same network, lower the priority of device-specific causes. If only one device is slow, check battery saving, background restrictions, the virtual adapter, and security software.

Separate latency, bandwidth, and packet loss

Latency affects connection setup and interactive response, bandwidth affects sustained transfer speed, and packet loss causes retransmissions and visible instability. They are different metrics. A node that connects slowly but downloads steadily may have high latency but sufficient bandwidth. A node with a fast initial response but repeated transfer drops may be congested or losing packets. Basic client tests provide limited evidence; validate with the actual use case. Do not automatically switch nodes based on one latency ranking. Frequent switching interrupts existing connections and makes your test samples inconsistent.

Protocol encapsulation, TLS, transport, and routing paths all add overhead, but speed should not be judged by protocol name alone. The same protocol can perform very differently across servers, networks, and times of day. Choose a node with correct parameters and a stable connection first, then compare network paths. If the log repeatedly shows resets, retries, or write timeouts, the slowdown may be a connection-quality issue rather than insufficient device processing power.

Check TUN, MTU, and routing detours

TUN captures more traffic and adds virtual-adapter, DNS, and routing steps. If system proxy mode is normal but TUN is noticeably slower, check for other virtual adapters, duplicate routes, or security-software filtering. On some networks, an unsuitable MTU appears as small pages loading while large files stall or specific sites load incompletely. Do not set MTU to an extreme value. Restore the client default first, then test smaller values gradually for the current network, reconnecting after every change.

Split-routing rules can also create detours. A target domain may first be resolved by remote DNS to an unexpected address and then matched again by IP rules, changing the outbound path. When complex rule sets overlap, inspect the routing matches in the log. During diagnosis, temporarily use a simple mode and add domain rules, IP rules, and remote DNS back one at a time after speed recovers. More rules do not make a diagnosis more reliable; clear priority matters more than rule count.

Check device resources and concurrency

When resource usage is high on desktop, determine whether the load comes from the interface, proxy core, or another application. Many concurrent connections, continuous verbose logging, TUN capture, and real-time security scans can all increase load. Disable unnecessary detailed logs, close duplicate clients, and make sure multiple proxy stacks are not enabled simultaneously. On Android, power saving, high temperature, or background restrictions can throttle or pause connections. Allow the client to run in the background, then test again.

If slowness occurs only in a specific application, check whether it uses QUIC, its own DNS, or a built-in proxy. Temporarily compare a browser with the system download tool to see whether the issue is limited to the application layer. If every application slows down at the same time of day, record the time, network type, and node group instead of continually changing the client. A stable reproduction is needed to separate local configuration from external path changes.

DNS resolution failures, polluted caches, and split-routing mismatches

Recognize typical DNS failure patterns

DNS issues often appear as domains failing while a known IP responds directly, intermittent failures for some domains, lookup or resolve errors in the client log, or a brief recovery after switching networks. A subtler problem is split-routing drift: the domain resolves successfully, but the returned address matches the wrong rule and traffic takes an unexpected path. When troubleshooting DNS, answer three questions: who initiated the query, which DNS server received it, and how does the result participate in routing?

Test the system DNS with the proxy disabled, then enable the client and compare. On Windows, use nslookup or PowerShell’s Resolve-DnsName; on macOS, use dig and scutil --dns to inspect system resolvers; on Linux, use resolvectl query to view systemd-resolved results. Record the domain, returned addresses, and server used instead of writing only “DNS is down.”

nslookup example.com
Resolve-DnsName example.com

dig example.com
scutil --dns

resolvectl query example.com
resolvectl status

Save evidence before clearing caches

The system, browser, client core, and applications may all cache DNS results. Clearing every cache immediately may sometimes restore access temporarily, but it removes useful clues. First compare the system tools with the browser: if system tools resolve normally but the browser fails, check secure DNS, extensions, and the browser’s own cache. If system tools and client logs disagree, inspect the client’s built-in DNS. If every tool fails, check the DNS provided by the current network and basic connectivity.

Once clearing the cache is justified, run ipconfig /flushdns on Windows. On macOS, restart the current network service or refresh the system resolver cache. On Linux, restart the relevant component according to the resolver in use. Run the query again afterward and record the result. If clearing the cache helps only briefly, the root cause is not the cache itself but an upstream DNS server, rule, or network that keeps returning abnormal results.

Check how client DNS interacts with routing

DNS in a V2Ray configuration is more than “enter a server address.” Queries may select a local or remote resolver based on domain rules, and the returned IP may then participate in IP routing matches. If a domain is resolved locally but its traffic is sent through proxy rules, the result may not match what the proxy exit sees. With fake DNS or TUN DNS capture enabled, also confirm that virtual addresses are correctly restored by the core. During diagnosis, disable complex domain splitting and fake DNS, verify one explicit resolution path, and then restore advanced settings.

The example below shows a simplified DNS structure in an Xray-style configuration. Set actual server addresses and query policies for the network environment. The key is to keep local and remote responsibilities explicit and match routing rules to DNS tags:

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

Do not replace an existing complete configuration directly with this example. Core type, rule resources, and network conditions may differ. If the current client is managed by a subscription, adjust DNS and routing through the interface first so the next update does not overwrite manual edits. When using the V2Fly core in v2flyNG, also confirm that the relevant fields are supported by the active core.

Handle differences between browser and system results

Modern browsers may enable their own secure DNS and bypass the system resolution path. If system commands resolve correctly but the browser reaches the wrong address, check the browser’s network settings and temporarily disable extensions for comparison. Some applications cache connections and DNS results; even after the system DNS changes, an old process may continue using the previous result. Fully exit and reopen the application instead of merely refreshing the page.

In TUN mode, if domains fail while plain IP requests work, check whether DNS traffic is captured by the virtual adapter, whether another application occupies port 53, and whether multiple active network interfaces exist. When Wi-Fi, Ethernet, and virtual adapters are active, the system may send DNS queries to a higher-priority interface that is unavailable. Disable unrelated interfaces for verification, then adjust long-term interface priority.

System proxy not working or some applications bypassing it

Make sure system settings match the client listener

A system proxy sends requests from applications that support it to a local HTTP or SOCKS port. When the client says “system proxy enabled,” still verify that the address and port in system settings match the port actually listened to by the core. The local address should normally point to the loopback interface, and the port should match the v2rayN settings and log. After a port change, profile-directory switch, or multiple instances, the system may retain an old value.

On Windows, view the manual proxy on the system network proxy page, or check WinHTTP with the following command:

netsh winhttp show proxy

Note that the user-level Windows system proxy and WinHTTP proxy are not identical. A browser working through the user proxy does not mean system services or command-line tools use the same setting. macOS stores proxy settings per network service, so check Wi-Fi and Ethernet separately. Linux desktop environments, terminal environment variables, and individual applications may also maintain separate proxy settings. First determine which settings the target application reads.

Handle applications that connect directly

Some applications ignore the system proxy or support only HTTP proxies rather than SOCKS settings. The node and core may be fully operational while that application’s traffic connects directly. Verify the local proxy with a browser, then check whether the target application provides its own proxy option. If it does, enter the client’s local listening address and the port for the matching protocol. If it does not and capture is required, consider TUN. Do not change every routing rule for one application until you confirm whether it reaches the local proxy entry point.

Command-line tools commonly read environment variables. For a temporary test, set them only in the current terminal so they disappear when it closes. The following example uses a local HTTP port; replace it with the client’s actual port:

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

The first two lines are for Windows Command Prompt, and the last two are for common macOS and Linux shells. Clear the variables after testing so future commands do not keep pointing to a stopped port. When application proxy settings, environment variables, and the system proxy overlap, the application’s own settings usually take precedence. If system settings are correct but the application still fails, check for a saved old proxy.

Distinguish PAC, global proxy, and TUN

PAC or automatic configuration uses rules to decide which requests use the proxy and suits applications that follow system proxy settings and support automatic configuration. A global system proxy sends more supported requests to the local port, but still cannot cover programs that ignore system proxies entirely. TUN handles a broader range of traffic through a virtual adapter, at the cost of requiring correct routing, DNS, and permissions. Choose the mode based on application coverage; TUN should not be the first fix for every problem.

If some sites bypass the proxy in PAC mode but work in global mode, the cause is likely PAC rules, cache, or limited application support for PAC. Refresh the system proxy settings and restart the target application, then verify rule matches. If the global system proxy also fails but entering the local port directly in the application works, that application is not reading the system settings. If enabling TUN cuts off every application, return to Chapter 2 and inspect the virtual adapter and routing instead of changing nodes again.

Client will not start, crashes, or repeatedly exits the core

First separate the interface process from the core process

v2rayN works through a graphical interface and proxy core. The interface may open normally while the core exits immediately because of a configuration error, port conflict, or permission issue. Conversely, a core left running in the background can make the next interface launch report a port conflict. During diagnosis, inspect Task Manager or the system process list to see which process exits. For an interface crash, check application logs and system events. For a core exit, inspect the first error after the startup command in the client log.

A corrupted configuration file is a common cause. If the issue began after importing a node, editing routing, or updating a subscription, switch back to a previously working profile first. Do not delete the entire configuration directory immediately. Copy a backup, then start the client with a new empty configuration. If the empty configuration starts but the original exits during loading, the problem is in the configuration or database. If the empty configuration also fails, check the runtime environment, permissions, file path, and security-software records.

Check ports, paths, and runtime permissions

At startup, the core must read the configuration, load rule resources, create logs, and listen on a local port. A non-writable installation directory, a path locked by sync software, or a file held by another program can all cause startup failure. On desktop, place the client in a normal directory that the current user can read and write, rather than running it directly from a compressed-file preview window. A wrong download platform or architecture can also prevent execution. Recheck the Windows, macOS, Android, and Linux entries on the download page.

Check port usage using the method in Chapter 2. If an old core process is present, exit the client normally, wait for the process to end, and start again. Stop it with a system tool only if it will not exit. Do not hide duplicate processes by repeatedly choosing random ports, because the system proxy and in-app proxy may continue pointing to the old port. After changing a port, update the system proxy as well and verify that the firewall permits local loopback traffic.

Handle startup problems after an upgrade

Problems after a client upgrade commonly result from old fields that are incompatible with the new interface, changed runtime dependencies, incompletely replaced core files, or an old process still holding files open. Fully exit the client and core, then start again. If it still fails, back up the subscription URL, routing, and essential settings, launch the current package from a new directory, and import items one by one. Do not overwrite the new directory with the entire old directory, or damaged files and incompatible settings may return with it.

The v2rayN desktop edition and classic WPF edition differ in interface technology and platform scope. When display or runtime issues occur, first identify which edition is in use instead of mixing configuration files between their directories. See how to choose between the v2rayN desktop and WPF editions. Back up subscriptions and custom rules before switching, then test in a separate directory to avoid interference from old files.

Determine whether resources or rules trigger the crash

If the client exits only while updating a subscription, running a speed test, or enabling TUN, a specific operation may be triggering the failure. A subscription with many profiles can consume more resources during parsing, deduplication, and testing. Complex routing resources that fail to load can also stop the core immediately after startup. Disable automatic speed tests and updates, verify basic operation with one manually added profile, and restore features one at a time. If only one subscription group triggers the issue, keep the log and inspect that group for abnormal fields.

Rapidly growing logs consume disk space and can affect operation. Temporarily enable verbose logging during diagnosis, restore the normal level immediately after reproducing the issue, and save only the relevant excerpt. Do not retain debug logs with complete connection details indefinitely. If disk space is low, the client may be unable to write configurations or update resources; free space first and confirm that the directory is writable.

Build a recoverable configuration workflow

After the client is stable, keep separate backups of the subscription URL, custom routing, and client settings instead of relying on one program directory for recovery. Before updating, record the client edition, core type, and key ports so you can roll back accurately. Store backups in a controlled location and never share subscription URLs or authentication fields publicly.

If the client runs reliably with an empty configuration, restore items in this order: add one node and verify the connection, add the subscription, restore system proxy settings, and finally add custom DNS, routing, and TUN. Start the client and check the log after every step. If it crashes again, you will know which type of configuration triggered it instead of having to guess from the entire directory.

Android connection drops and background restrictions

Confirm virtual network authorization and client status

On Android, v2rayNG and v2flyNG usually capture traffic through the system’s virtual network interface. The first connection, or a connection after permissions are reset, prompts Android to confirm VPN access. If the client says it is starting but never forms a working connection, check for a hidden permission dialog and verify the virtual network indicator in the status bar. If another network tool is using the same type of interface, disconnect it before starting the current client.

After importing profiles, explicitly select one node. Having a subscription group does not mean a usable profile is selected, and a successful update does not mean the core has started. After connecting, open the log and confirm that the core loaded the configuration, created the local entry point, and attempted to reach the remote server. If the log reports a configuration error during startup, verify with a simple node before enabling per-app proxying, complex DNS, or custom routing.

Handle disconnects after screen lock and background termination

Android power management may restrict background processes when the screen is locked, the device is idle, or memory is low. A typical pattern is normal foreground operation followed by a failed connection after the screen has been locked, with recovery when the client is reopened. In battery and background settings, allow v2rayNG or v2flyNG to keep running and ensure it is not automatically put to sleep. Settings vary by device, but the test is the same: keep the node fixed and compare active foreground use, a short screen lock, and a longer screen lock while watching whether the client process and connection are stopped.

Locking the app in the recent-apps list may not be enough. Also check background network access, data saving, and battery restrictions. Wi-Fi being disabled during sleep can also break the connection; switching to mobile data may require a new connection. A brief reconnect after a network change is normal. If it does not recover, disconnect and reconnect manually, then check whether the log still references the old network interface.

Check per-app proxy and bypass settings

Per-app proxying can capture only selected applications or exclude selected applications. Incorrect selection logic can produce “the browser works but other apps connect directly,” or the reverse. Disable per-app mode first and verify that global capture works. Then enable it again and confirm whether the mode proxies selected apps only or bypasses selected apps. App updates, reinstalls, or work-profile spaces can change application identifiers, so an old list may no longer match.

If only a system component or one application cannot connect, check whether it is excluded, uses its own DNS, or restricts virtual-network access. Do not keep switching nodes to solve an obvious application-scope issue. Reconnect after changing the per-app list so routing rules reload completely. A work profile and the primary user space may have separate network policies; test them separately rather than assuming one setting applies everywhere.

Compare Wi-Fi and mobile data

If the same node works on Wi-Fi but times out on mobile data, or vice versa, the configuration may be valid and the difference may come from the access network, DNS, address family, or MTU. Record DNS results, connection errors, and transport type on both networks. If mobile data prefers IPv6 but the node domain returns an unreachable address, inspect the client’s address and DNS query policies. If Wi-Fi has a captive portal, authenticate first with client capture disabled, then reconnect.

After switching networks, an old connection may remain bound to the previous interface and fail briefly. Wait for automatic reconnection first; if it does not recover, disconnect and reconnect once. If every network switch requires an app restart, check whether the system restricts background network-change notifications and whether the client is frozen. Do not repeatedly clear app data: it removes subscriptions, groups, and routing settings without necessarily fixing network switching.

Choose a v2rayNG or v2flyNG troubleshooting baseline

On Android, choose the client according to the core required by the configuration. v2rayNG uses the Xray core and suits configurations requiring Xray-specific protocol features. v2flyNG uses the V2Fly core and can serve configurations from that ecosystem. If both clients are installed, do not connect them simultaneously and do not assume the same profile has identical support in both cores. For a comparison test, keep the network and node fixed, change only the client, and record the exact error.

If v2rayNG connects but v2flyNG does not, or the reverse, first verify that the corresponding core supports the protocol and transport features in use instead of blaming the phone network. For the functional boundary between Xray and V2Fly, read Xray vs. V2Fly core differences. If reinstalling is necessary, choose the version matching the device architecture from the Android download entry, keeping the original subscription information before migrating.