V2Ray troubleshooting: Find connection problems by symptom

First distinguish “no local network” from “the proxy path is down”

A client’s tray icon only shows that the interface and core process have started; it does not prove that traffic has reached the remote server. During troubleshooting, temporarily disable the system proxy or Android VPN connection, then visit a site that normally works on the local network. If access still fails with the client closed, the problem is with the current Wi-Fi, Ethernet, mobile network, gateway, or system network stack. Do not keep changing node parameters. Reconnect the network, disable and re-enable the adapter, or test on another network—this is usually faster than repeatedly importing the subscription.

If direct access works but every site fails when the proxy is enabled, check the client logs next. In v2rayN, review Xray startup and connection records in the log area; in v2rayNG and v2flyNG, open the log page and access the target address once more. The first error matters more than the number of log lines. connection refused usually means the destination port explicitly rejected the connection; timeout means the handshake did not complete within the allotted time; no such host points to DNS resolution; certificate or handshake errors call for checks of the system clock, SNI, and transport security parameters.

Use a minimal configuration to rule out routing interference

Complex routing can send browser traffic to an unavailable outbound, or mistakenly send domains that should use the proxy through a direct connection. Keep one confirmed working node, temporarily switch routing to global proxy mode, disable extra custom rules, proxy chaining, Mux, and experimental DNS features, then test a regular HTTPS page. If global mode works but rule mode does not, the fault lies in route matching, not in the node itself. Restore rules one group at a time and establish a new connection after each change, so the browser does not keep reusing an old TCP or HTTP/3 session.

Routing rules configured in the graphical interface are ultimately converted into an Xray configuration. Rules are matched in the order generated by the client, and the domain, IP, port, and network type may jointly determine the outbound. The minimal structure below keeps only proxy and direct outbounds to clarify the troubleshooting boundary; a real client will add inbound listeners and node credentials.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {}
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Check port conflicts, the system clock, and leftover processes

Desktop clients listen locally on SOCKS, HTTP, or mixed proxy ports. If a port is already occupied by another proxy program, an old core process, or a debugging tool, the new core may fail to start while the interface still shows its previous state. On Windows, run netstat -ano in a terminal to view listening ports and process IDs; on macOS and Linux, use lsof -iTCP -sTCP:LISTEN. After finding a conflict, exit the related program and fully restart the core from the client—do not merely switch nodes.

netstat -ano | findstr LISTENING
lsof -iTCP -sTCP:LISTEN
date

The system clock must also be accurate. TLS, REALITY, and HTTPS connections to subscription servers all rely on time checks. A significantly incorrect clock often causes every node to fail at once, prevents subscription updates, or produces repeated messages that a certificate is not yet valid or has expired. Enable automatic time synchronization, then fully exit and restart the client so new connections use the corrected time. If these checks are normal, visit the download page to confirm that you are using the client for the correct platform, then rebuild a minimal configuration instead of overwriting a large set of old settings.

A latency test does not equal real-world webpage speed

v2rayN latency tests may use TCP connection setup, a real latency check, or another availability test; each answers a different question. A successful TCP connection only shows that the remote address and port completed a basic handshake. It does not prove that protocol authentication, TLS, REALITY, or access to the target website will succeed. A real latency test involves more processing, but can still be affected by the test address, DNS, and current route. Do not delete a node solely because of one timeout label. Check the test type first, then visit a webpage and use the logs to identify whether the timeout occurred during resolution, the remote connection, the TLS handshake, or outbound access.

If one node times out while other nodes in the same subscription work, the issue is usually that node’s address, port, transport parameters, or service status. If all nodes time out at once, suspect the local network, system clock, DNS, core startup, or a change in the network environment. If everything fails only on one network and recovers on another, check the current router, firewall, enterprise network policy, or UDP availability first. Do not change every node at the same time.

Verify the address, port, and transport parameters one by one

When configuring a node manually, the server address must not include a protocol prefix, path, or extra spaces; the port must be an integer; and authentication fields such as the UUID, user ID, and password must be copied in full. VLESS and VMess are not interchangeable protocols, and TCP, WebSocket, and gRPC transport cannot be inferred from the port alone. For TLS, verify the server name and host fields. For REALITY, also match the public key, short ID, fingerprint, and server name. Any mismatch can appear as a handshake timeout or a connection that closes immediately after being established.

For WebSocket nodes, also verify the path and Host. The path usually starts with a slash, and both its case and any query string may affect server-side matching. For gRPC, check the service name; do not put it in the WebSocket path. If the node came from a subscription, update the subscription again rather than manually “fixing” fields, because the provider may have changed the parameters. Before reimporting, you can copy the current subscription group for reference, but do not let two same-named nodes participate in automatic selection at once, or the test target may become unclear.

Do not use a longer timeout instead of finding the cause

Increasing a connection timeout from a few seconds to a very long interval only makes an unusable node fail later; it usually will not fix a protocol or port error. For a useful retest, select one node, disable automatic switching, establish a completely new connection, and observe what happens between clicking Connect and the first error in the logs. If TCP connects but the TLS handshake fails, focus on SNI and the system clock. If TLS completes but authentication fails, check the user ID and protocol. If the proxy is established but a specific website times out, investigate routing, DNS, MTU, or the destination’s connection behavior.

UDP scenarios require a separate check. Some networks handle UDP poorly; browsers may prefer HTTP/3, and DNS may also use UDP, producing symptoms such as some pages spinning while ordinary TCP tests pass. Temporarily disable HTTP/3 in the browser, or switch DNS to TCP or HTTPS, and see whether the problem disappears. If only UDP fails, do not label the entire node unusable; adjust the transport and routing to match the applications you actually need.

Automatic selection and load-balancing strategies add more variables. During testing, pin one outbound and prevent the client from switching between nodes. Restore automatic selection only after one node is stable. If a node fails on both desktop and Android while the devices use different networks, its parameters or remote status are more likely to be at fault. If the same node fails on only one device, compare the core type, routing rules, DNS settings, and system clock instead of buying a new subscription or repeatedly importing the same one.

First distinguish a subscription URL from a single-node share link

A subscription URL usually returns a set of node data that the client can update later; share links beginning with vmess://, vless://, and similar schemes usually describe a single node. Putting a single-node link into a subscription manager may produce a format error or an empty list after updating; trying to scan a subscription URL as a single node may also fail. See Share Links and Subscription URLs Explained for the distinction. During troubleshooting, confirm that you copied the complete URL without line breaks or truncation from a chat app and without dropping trailing parameters.

A subscription update involves two connections: the client first retrieves the content from the subscription server, then parses it into nodes. A download failure commonly produces DNS, TLS, HTTP status, or connection-timeout errors; a successful download followed by a parse failure usually reports an unsupported format, empty data, or an invalid individual entry. Identify which stage failed before changing anything, so a network problem is not mistaken for a node-format problem.

Check the system proxy and the subscription update route

A subscription update may use a direct connection or the current proxy. If the subscription URL is reachable only through a working proxy while the current node is already down, you get a “you need a node to update your nodes” loop. Switch to an older node that still works and update again, or inspect the client’s subscription proxy option to see whether it uses the system proxy, the current proxy, or a direct connection. Do not enable multiple proxy layers without understanding them, as requests can be sent back to the local proxy port and create a loop.

Conversely, if the subscription server is reachable directly but fails through the proxy, temporarily use a direct connection for the update. Keep the old group until the new list contains the expected nodes, then remove duplicates. With multiple subscriptions, update them individually instead of using “update all” to identify the failing URL. The subscription name is only a local label and does not affect connections; check the URL, update method, required user agent, and returned content.

Use HTTP status codes and response content to locate the failure

Status codes quickly clarify responsibility. A 401 or 403 often means the token, path, or access conditions in the URL are no longer valid; 404 commonly indicates a replaced or mistyped link; 429 means too many requests in a short period, so stop refreshing and try again later; 5xx indicates a temporary subscription-server problem, which reinstalling the client repeatedly will not fix. If the status is 200 but the list is empty, check whether the response is node text, a webpage message, or a login page. A graphical client may show only “parse failed,” while detailed logs often reveal the response type or decoding error.

On desktop, use built-in system tools to inspect response headers only. Avoid printing the full subscription content to a shared screen or public log. The URL in the command below is a local example and contains no real subscription information:

curl -I "https://example.invalid/subscription"
nslookup example.invalid

If the domain cannot be resolved, move to the DNS section of this guide. If TLS reports an error, correct the system clock and check the certificate name. If the response is normal but the client cannot parse it, create a blank subscription group and import only that URL to rule out stale cache and duplicate-name effects. v2rayN, v2rayNG, and v2flyNG may handle common share formats differently, so when the same subscription behaves differently across clients, check whether it contains extension fields that one client cannot recognize instead of assuming the device network is at fault.

When nodes do not change after an update

A successful update with an apparently unchanged list may mean the subscription returned identical content, or that the client preserves custom nodes, merges by remark, or displays cached data. Compare the node count, remarks, and server addresses, then fully leave and reopen the list page. If the client offers an option to clear subscription cache or remove old nodes, use it only after making a backup. Do not judge an update by node names alone: a provider may keep the name while replacing the address, or change the name while keeping the same connection parameters.

An incorrect system clock can also make HTTPS subscription updates and node connections fail together, making it an easy shared cause to miss. If every subscription suddenly reports certificate errors while every TLS node is unavailable, synchronize the clock and restart the client first. If only one subscription fails, focus on that URL. After updating, manually select a new node and test actual access instead of letting automatic selection continue using a cached reference to a deleted node.

Break speed problems into latency, throughput, and stability

“Slow speed” covers at least three different symptoms. A webpage that takes a long time to start usually points to DNS, connection setup, or latency. A low sustained rate when downloading a large file is more related to link throughput, congestion, and device performance. Rates that swing up and down or periodic video buffering call for checks of packet loss, wireless interference, node load, protocol retransmissions, and background traffic. One latency number cannot explain all of these. Compare two nodes on the same device and local network, around the same time, while keeping routing, DNS, and the test target consistent.

Before testing, pause cloud sync, system updates, game downloads, and other high-bandwidth tasks on every device. Test once near the Wi-Fi router, then retest over Ethernet or another network. If direct downloads are already slow, a proxy cannot remove the local access bottleneck. If direct access is stable but every node fluctuates, check the local proxy path, MTU, core load, and how the network handles UDP. If only one node is slow, the node’s route or remote load is more likely.

Check whether routing is taking a detour

Rule mode selects an outbound based on the domain, IP, port, and protocol. After a domain is resolved locally to an IP, an unsuitable combination of domainStrategy and rule sets can send a site’s main page, images, and video through different outbounds, so the page opens while media loads slowly. Temporarily use global proxy mode and compare the same resource. If global mode is clearly better, inspect rule-match order, conflicts between domain and IP rules, and whether DNS results match expectations.

More routing rules are not necessarily better. Overlapping rules are harder to maintain, and an old rule set may send a newly added domain to the wrong outbound. Start with the client’s simple built-in rule set and confirm a stable baseline before adding custom entries. Add one group at a time and verify in the logs which outbound label each domain ultimately uses. If an application connects directly by IP, domain rules may not match; design rules around the application, destination IP, or port, while avoiding overly broad networks that send unrelated traffic through the proxy.

Balancing Mux, concurrency, and transport choices

Mux lets multiple logical connections share an underlying connection, which can reduce repeated handshakes in some high-latency situations, but it does not guarantee higher throughput. During long, high-volume transfers, packet loss on a multiplexed connection can affect multiple requests; some server configurations also do not suit client-side Mux. When troubleshooting speed, disable Mux and establish a baseline before enabling it alone for comparison. If disabling it improves stability, leave it off. If many short connections improve noticeably, consider enabling it. Do not change Mux, concurrency, fragmentation, DNS, and routing at the same time, or you will not know which change mattered.

WebSocket, gRPC, TCP, and other transports are determined by the server configuration; switching them at random cannot “speed things up.” A mismatch normally causes an immediate failure rather than a faster path. REALITY and TLS address handshake and secure-transport requirements, not speed. Throughput is mainly affected by local access quality, device CPU, remote capacity, link congestion, packet loss, round-trip time, and the application’s own concurrency strategy.

Watch device resources and MTU symptoms

Low-performance devices may show high CPU usage under high-throughput encryption, complex rules, or heavy concurrency. On desktop, watch Task Manager or the system monitor; on Android, pay attention to heat and background restrictions. If CPU usage approaches saturation as speed rises, simplify routing, disable unnecessary logs and concurrency features, and compare different core clients. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; they provide useful Android comparisons, but the node protocol must be supported by the corresponding core.

MTU problems often appear as small webpages loading normally while large images, uploads, or specific HTTPS pages stall. VPNs, tunnels, and some broadband connections can reduce the effective packet size. Switch networks first: if the same device works normally elsewhere, inspect the original network’s MTU or routing equipment. On Linux, you can use ping with fragmentation disabled and gradually reduce the packet size, but syntax varies by system and results depend on whether the destination responds, so treat this only as a clue. A graphical client does not need a lower-level MTU change for ordinary speed fluctuations; first establish that the symptom is network-related, then adjust carefully at the system or router level.

For a meaningful comparison, use the same file, time window, and at least several minutes of sustained transfer, recording the average rate and interruptions. A single peak is not representative. Once the node is stable, restore rule mode, automatic selection, and your usual DNS settings one at a time, retesting after each change so you can tell whether performance loss comes from the node or local configuration.

Recognize the typical boundaries of a DNS failure

DNS converts domain names into IP addresses. When resolution fails, a known IP may still respond while the domain reports that the server cannot be found. When resolution returns an unsuitable address, the page may time out, show a certificate-name mismatch, or behave differently across networks. If every site fails, do not immediately blame DNS: the local proxy port, node, and system proxy can also cause a total outage. A more reliable diagnosis is to query the domain separately, inspect client DNS logs, and compare behavior with the proxy disabled.

On desktop systems, use nslookup or dig to check basic resolution. The DNS server, returned addresses, and error type in the output are more useful than simply asking whether a webpage opens. If system queries succeed but access through the proxy fails, the cause may be Xray’s built-in DNS, routing rules, or the browser’s secure DNS using a different resolution path. Troubleshooting becomes difficult when the browser, system, and client all enable separate secure DNS paths, so temporarily keep one clearly defined path.

nslookup example.com
dig example.com A
dig example.com AAAA

Understand local resolution, remote resolution, and routing

A domain can be resolved by the system before entering the proxy, or handled by the proxy core’s DNS module. The former benefits from the system cache but is affected by local DNS; the latter keeps domain handling more consistent with routing rules, but requires correctly configured DNS outbounds and query paths. Xray’s domainStrategy also determines whether domains are resolved during route matching. AsIs keeps the original domain whenever possible, while IPIfNonMatch resolves an IP and tries again when no domain rule matches. Choose the strategy to fit the rule structure; more complexity is not inherently better.

The simplified DNS structure below shows how the fields relate using ordinary addresses. In real use, configure it for your network and client interface; do not overwrite the complete file automatically generated by the client.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

The public resolver addresses in the example are not suitable for every network. The key questions are where the query originates, which outbound carries it, whether it returns A or AAAA records, and how the result participates in routing. If the query goes direct but the current network cannot reliably reach the resolver, intermittent timeouts may occur. If it goes through the proxy before the proxy is established, startup becomes dependent on DNS. The client’s default configuration is usually easier to maintain than a complex setup assembled from several tutorials.

Clear caches and handle IPv6 differences

After changing DNS, the system, browser, and client may continue using old results. On Windows, run ipconfig /flushdns to clear the system cache; on Linux, the command depends on the resolver service in use; on macOS, reconnect to the network or restart the relevant resolver service. Browsers may also maintain independent connection pools, so fully close the affected pages and reopen them. Clearing the cache only removes stale records; it does not fix incorrect DNS routing or an unreachable resolver.

ipconfig /flushdns
resolvectl flush-caches

IPv6 is another common branch. When a domain returns both A and AAAA records, the system or application may try IPv6 first. A network may appear to have an IPv6 address while its actual IPv6 path is unstable, causing a delayed first connection, failures on some domains, or success only after fallback. Temporarily configure DNS to return IPv4 results only and compare. If the issue disappears, check local IPv6 connectivity and the client’s query strategy rather than relying permanently on repeated refreshes. Conversely, disabling IPv6 outright on a healthy IPv6 network may discard a better path.

When FakeDNS helps—and when to turn it off

FakeDNS assigns reserved addresses to domains and restores the domain during connection handling, which is useful for transparent proxying and domain-based routing. It is not a drop-in replacement for ordinary DNS. Some applications inspect returned IPs, bypass the proxy after caching an address, or use their own resolver; this can cause login failures, unreachable LAN devices, broken push notifications, or unstable UDP applications. At these boundaries, disable FakeDNS first and establish a baseline with regular DNS. For a deeper explanation, see How FakeDNS Works and When to Use It.

If only LAN hostnames, printers, or router administration addresses fail, make sure private addresses and local domains use direct local resolution rather than remote DNS or FakeDNS. If only the browser fails while other applications work, check the browser’s own secure DNS. If every application fails, check system DNS and the client’s DNS inbound. Verifying the three layers—system query, client query, then browser query—is more likely to reveal the real conflict than repeatedly switching public resolvers.

Make sure the system proxy matches the local inbound port

A system proxy sends applications that support proxy settings to a local HTTP or SOCKS listener. When the client says “system proxy enabled,” verify that the system address and port match the values the current core is actually listening on. The address is commonly the loopback address, while the port is set by the client. If you changed the local port but the system still uses the old value, applications will connect to a nonexistent listener. If an old client process still owns the port, traffic may enter the wrong instance.

First confirm in the client logs that the inbound has started, then use a port-inspection command to verify the listening process. Do not confuse the remote node port with the local proxy port: the remote port is used by the core to connect to the server, while the local port is used by the browser to connect to the client. The system proxy needs only the local listening address, not the node address. After changing it, fully close and reopen the browser because existing connections may continue using the old path.

Understand how applications differ in system proxy support

Browsers and most desktop network programs read the system proxy, but not every application does. Some programs have their own proxy settings, some command-line tools read only environment variables, and some applications connect directly. Therefore, “the browser works but one application connects directly” does not prove that the system proxy is broken. Establish a baseline in a browser known to support the system proxy, then check whether the target application offers HTTP, HTTPS, or SOCKS settings.

Command-line tools usually require explicit environment variables. The example below sends HTTP and HTTPS requests to a local HTTP proxy port; replace the port with the actual value shown by the client. These variables apply only to the current terminal session and its child processes, and normally disappear when the terminal closes.

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

SOCKS proxying also affects where DNS is resolved. In some tools, socks5 resolves domains locally, while socks5h sends the domain to the proxy for resolution. If a command fails only with a domain while an IP works, check this distinction. Do not configure a proxy in the application, in the system, and in a transparent proxy at the same time, or the same traffic may enter the client repeatedly.

Check PAC files, bypass lists, and rule mode

The system proxy may use global mode, PAC, or no change. PAC uses a script to decide which addresses use the proxy; if the script is stale, cached, or does not cover the target domain, the browser connects directly. Global system proxy mode sends supported requests into the client, but Xray routing rules still apply afterward, so “global system proxy” does not mean every flow uses a proxy outbound. Inspect the operating-system layer and the core-routing layer separately.

System bypass lists commonly include LAN addresses and local hostnames. If the list is too broad, ordinary domains may bypass the proxy; if it is too narrow, router administration pages and LAN services may be sent through the proxy. Keep the loopback address and clearly defined private networks, and avoid vague wildcards covering large groups of domains. If an organization centrally deploys proxy settings by policy, the client may not be able to override them persistently; compare the system proxy value before and after changes to see whether it is being restored automatically.

Handle leftover proxies after exit and wake from sleep

After an abnormal exit, forced process termination, or wake from sleep, the system proxy may still point to a local port whose core has stopped. Every application that follows the system proxy then fails, while disabling the proxy restores access immediately. First turn off the proxy in the system network settings, then restart the client and let it enable the proxy again. A normal client exit usually performs this cleanup, but an abnormal process cannot be expected to do so.

On Windows, distinguish the current user’s proxy settings from the different interfaces read by some older programs. On macOS, verify that you changed the network service currently in use. Linux desktop environments may have three sources: system proxy settings, desktop proxy settings, and application environment variables. Do not fill in all of them at once; choose one clear method and test it. For v2rayN Linux desktop installation and autostart, see the Linux Desktop Installation Guide to check whether the user service and desktop session run in the same environment.

For the final check, see whether the client access log contains the target domain. If there is no record at all, traffic has not entered the client; continue checking the application and system proxy. If the domain appears but uses direct, the issue is in the routing rules. If it uses the proxy and then times out, return to the node and DNS sections. Layering the diagnosis through logs prevents repeatedly changing nodes when the system proxy is the actual problem.

Distinguish a graphical-interface crash from a core startup failure

v2rayN consists of a graphical interface, configuration data, and a proxy core. A window that never opens, one that disappears immediately, and an interface that works but has an unresponsive Connect button can belong to different layers. If the interface remains usable but the logs show that the core exited, inspect the generated configuration and ports. If the program has no window at all, check system events, terminal output at launch, file permissions, and runtime dependencies. Do not attribute every startup issue to a node: a broken node usually causes connection failure, not a completely invisible interface.

Before troubleshooting, fully terminate the relevant processes and start the client once more. Repeated double-clicks can launch multiple instances, locking configuration files or creating local port conflicts. On desktop, use Task Manager or the system monitor to confirm whether the graphical process or Xray process remains. If a reboot fixes the issue, still inspect the previous log for port conflicts and abnormal-exit causes so the problem does not return after the next sleep cycle.

Trace upward from the first configuration error

When loading a configuration, the core validates JSON structure, field types, protocol parameters, and referenced tags. The many exit messages that follow are usually caused by the first configuration error; the useful clue is the earliest failed to load config, unknown field, missing outbound tag, or JSON parse position. When editing JSON manually, commas, quotation marks, and brackets are the most common mistakes. If a graphical client fails to generate a configuration, an invalid custom route, DNS entry, or extra node parameter may be responsible.

JSON does not allow comments or a trailing comma after the final member. Backslashes and double quotes inside strings must be escaped. The structure below is syntactically complete and can be used to compare the basic hierarchy, but it does not contain a connectable node:

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ]
}

If the error appears only after enabling custom configuration, disable the custom items first and let the client regenerate its defaults. Once the default configuration starts successfully, add DNS, routing, and outbounds section by section. For the structure and role of each block, see Anatomy of a V2Ray JSON Configuration. Do not overwrite the current client’s complete configuration with one from another client, because the interface may depend on its own generated inbound tags, ports, and management interfaces.

Check directory permissions, paths, and security-software blocks

The client must read configuration, write logs, and launch a core subprocess. A non-writable installation directory, abnormal user-directory permissions, or a read-only disk can all prevent startup. On Linux, avoid launching once as an administrator and then running the same configuration directory as a regular user, because files created during the first run may belong to the administrator. Correct ownership and permissions, then restart as the regular desktop user. On macOS and Windows, verify that system protection has not blocked writes to the program directory, and check whether security software quarantined the core file or blocked its subprocess.

Modern clients usually handle special characters in paths, but external scripts, old configurations, or custom commands may split them incorrectly. Temporarily move the configuration directory to a short path in the user directory for comparison. Do not test from a live-sync folder, because synchronization may create conflict copies or briefly lock files while the client writes them. Once you confirm that the path is involved, restore the original location one change at a time.

Keep diagnostic data and rebuild the configuration safely

When a reset is necessary, exit the client and copy the configuration directory as a local backup. Then rename only the current configuration directory and let the client create a clean set of settings. If the new setup starts, the program files and system environment are broadly healthy, and the issue is in the old configuration. Re-add the subscription and only the necessary rules; do not immediately copy the entire old directory back. Restore subscriptions, routing, DNS, and interface settings by category, starting the client after each step.

If a clean setup still will not start, consider reinstalling. Use the client downloads page to choose a v2rayN package matching your platform and processor; on Android, use v2rayNG, or choose v2flyNG when you need the v2fly core. Before reinstalling, record the log error, operating system, processor architecture, and reproduction steps. These details are more useful for diagnosis than a screenshot saying only “cannot start.” Do not invent or guess compatibility relationships; follow the package types and system requirements currently listed on the downloads page.

If the crash begins after importing a particular node, first import other nodes into the clean configuration, then import the suspicious link separately. If it begins after enabling a particular DNS or routing feature, keep the defaults and reproduce the issue one option at a time. Identifying “which addition caused the failure” narrows the problem to a specific setting without changing the system, client, and subscription all at once.

Check VPN permission and the single active connection instance

On Android, v2rayNG and v2flyNG typically take over traffic through the system VPN interface. On the first connection, confirm the system permission; if the authorization prompt was dismissed, the client can save nodes but cannot establish a VPN. A VPN icon in the status bar only means the interface was created; check the logs to confirm that the core and node connection succeeded. Android generally permits only one VPN service at a time. Other VPN apps, work-profile management tools, or system network features may take over the interface, causing an immediate disconnect.

During troubleshooting, disable other VPN-related features, fully stop v2rayNG or v2flyNG, then reopen it and grant permission. Do not leave both clients set to connect automatically. If the old VPN icon remains after switching clients, disconnect the current VPN in system network settings before starting the target client. If a node works on desktop but fails immediately on Android, compare the imported protocol, transport, security method, server name, and path first, and make sure the QR code or clipboard content was not truncated.

Handle battery-saving policies and background limits

If the connection drops a few minutes after the screen turns off and returns when the screen wakes, background restrictions are the usual cause. Android manufacturers may suspend the client, restrict background networking, or kill a long-running VPN service. In the system app settings, allow the client to run in the background, exclude it from battery optimization, and allow any necessary autostart or background activity. Menu names vary by device, but the standard is the same: the client must continue running while the screen is locked and must not be listed as a restricted app.

Leaving the client in the recent-apps list may not be enough; a system “lock task” option is not necessarily permission for background networking. After changing the settings, lock the screen for a while, then verify continuity through message synchronization, a webpage request, or the client logs. If the connection drops only when switching from mobile data to Wi-Fi, the old connection may not be rebuilt promptly after the network changes. Stop and start the client manually to test for a reconnection issue. When switching networks frequently, avoid enabling always-on VPN, other automated network tools, and the client’s own auto-connect at the same time, as multiple mechanisms may compete.

A sensible order for checking app routing and bypass settings

Android clients can decide which apps send traffic through the VPN. The setting is easy to misread: some interfaces mean “proxy only selected apps,” while others mean “bypass selected apps.” Reversing the meaning can make the browser work while the target app connects directly, or leave only a few apps online. First disable app routing so every app uses the same VPN path and confirm that the node and DNS work. Then enable app routing and select only one test app.

System apps, work-profile apps, and ordinary user apps may belong to different configuration scopes. If the target app uses a system component to open a webpage, the main app and system component may use different paths, so the login page and body can behave differently. Check whether the target domain appears in the client logs and whether related system components are excluded by routing. Do not start by adding a long app list; the longer the list, the harder it is to determine what is actually selected.

Fix LAN access, hotspot sharing, and DNS differences

If the router, LAN storage, or printer becomes unreachable after enabling the VPN, check the “bypass LAN” setting or direct rules for private addresses. LAN addresses generally should not be sent to the remote node. If access works by IP but not by a local hostname, suspect local DNS or multicast resolution rather than the node. Disable FakeDNS, resolve LAN domains locally, and send private networks direct to establish a clearer baseline.

Hotspot sharing adds another layer of network forwarding, and devices connected to the phone’s hotspot do not necessarily use the phone’s VPN. Even if the phone’s browser uses the client, downstream hotspot devices may have an independent exit path. Verify the route separately on the downstream device instead of relying on the phone’s status bar. If you only need proxying for apps on the phone, disabling hotspot sharing removes a variable. If shared traffic must be handled, confirm that the client and system support it; do not assume ordinary VPN mode automatically covers hotspot traffic.

Android Private DNS and the client’s DNS can coexist. When Private DNS is unreachable, some apps may wait indefinitely. Meanwhile, FakeDNS or remote DNS in the client can produce results that differ from system policy. For troubleshooting, set Private DNS back to Automatic and disable the client’s advanced DNS options, leaving only the defaults. Once the baseline works, enable options one by one. If only one app fails, also consider its built-in DNS, QUIC, or certificate pinning; not every difference is a client error.

Collect logs and compare the two Android clients

Before reproducing the issue, clear the current logs or note where they begin. Then perform one explicit action, such as reconnecting, opening a failing domain, or locking the screen and waiting. Record the first error, network type, whether app routing is enabled, DNS mode, and node protocol. If the target request never appears, check app routing. If it appears but resolution fails, check DNS. If the node connection times out, return to the address, port, and network. If core logs stop after the screen locks, focus on background restrictions.

v2rayNG uses the Xray core and is the preferred Android client; v2flyNG uses the v2fly core and can provide a protocol-compatibility and runtime comparison. For a fair test, import the same supported node and keep DNS, routing, and app routing as simple as possible. If both clients fail on the same network while desktop works on another, switch Android networks and retest. If only one client fails, compare core support and the generated configuration. Do not change the client, node, and network at the same time, or the result will not identify the cause.

After troubleshooting, restore the necessary background permissions, app routing, and DNS settings, verifying each one in turn. A stable long-term configuration is usually easier to maintain than one packed with experimental options. For the initial setup, return to the setup guide; for certificate-handshake errors, continue with the TLS and Certificate Error Checklist.