V2Ray Troubleshooting Guide

“No internet access after connecting” does not necessarily mean the node is down. A client showing that it has started only confirms that the local process finished initializing; it does not prove that the remote handshake, DNS queries, and application traffic all succeeded. First define the scope: are all websites unreachable, or only domains; does disabling the system proxy restore direct access; does the same node work on another network; is only the browser affected, or are command-line tools and other apps affected too? These four questions quickly narrow the problem to the network, DNS, proxy access, or node configuration.

Restore a baseline, then enable features layer by layer

In v2rayN, first disable the system proxy and TUN mode while leaving the client process running, then confirm that ordinary direct internet access works. If direct access also fails, troubleshoot the router, network authentication, network adapter, or local DNS before changing the V2Ray configuration. Once direct access is restored, select a known-good node, enable only the system proxy, and switch routing to global proxy mode for a short test. If global mode works but rule mode does not, the problem is usually in routing rules, GeoSite data, or DNS split routing. If global mode also fails, continue by checking the node and local proxy ports.

1. Exit other proxy, accelerator, or traffic-capture tools so that multiple programs do not modify the system proxy and routing table at once.
2. Check the system time and time zone. Clock drift can cause TLS certificate validation errors and may also break authentication that includes time-based fields.
3. In the client, select the node again and start the core. Confirm in the logs that a local inbound listener appears instead of the core exiting immediately after startup.
4. Enable only one access method. For ordinary browser testing, prefer the system proxy and do not enable the system proxy and TUN at the same time.
5. Visit one target by IP address and another by domain name to determine whether the problem is limited to DNS.

On Windows, use the commands below to check whether the local ports are listening. Use the port numbers from the current v2rayN settings; common configurations have both SOCKS and HTTP entry points. If the commands produce no output, the core is not listening on that port, possibly because of a port conflict, failed configuration generation, or an exited core process.

netstat -ano | findstr LISTENING
curl.exe -x http://127.0.0.1:10809 https://example.com/

The second command bypasses the system proxy settings and sends a request directly through the local HTTP proxy. If it returns a page response, the basic “application to local proxy to node” path is working, so the problem is more likely the system proxy switch or the browser’s own settings. If the local port cannot be reached, check the inbound port. If the local port connects but the remote request fails, inspect the core logs for handshake, certificate, address, and routing details.

Distinguish configuration errors from network blocking

Check the node configuration field by field: server address, port, user identifier, transport, TLS setting, server name, and path. VMess, VLESS, and Trojan use different fields, so replacing only the address and port while keeping old transport parameters is not sufficient. If the subscription generates nodes automatically, update the subscription and select the node again first. For manual entries, compare every field with the provider’s complete parameters, paying particular attention to the leading slash in WebSocket paths, the gRPC service name, and the TLS server name.

If the same configuration works on a mobile network but not on a home network, check for DNS hijacking, router filtering, a double proxy, or an unreliable IPv6 route at home. If it works at home but fails on mobile, check background restrictions, Private DNS, and the current carrier connection. Do not blame the network based on one request; cross-test on at least two networks and with two different nodes. The results can distinguish a node-specific problem, a network-specific problem, and a client-wide configuration problem.

After the connection is restored, switch routing from global mode back to the rule mode used in practice. Then verify that mainland-China destinations, proxied destinations, and local-network addresses use the expected exits. For mode differences, see System Proxy, Global Mode, and Bypass Mainland China Mode Explained. If switching modes breaks the connection again, the basic connection is sound; focus on routing rules and DNS instead of reinstalling the client.

A timeout means that one layer did not receive a valid response within the expected time, but a log entry containing “timeout” may refer to TCP connection setup, the TLS handshake, protocol authentication, a DNS query, or the target website’s response. Before troubleshooting, record where the timeout occurs and how long it lasts. If multiple nodes time out at once, check the local network, system time, DNS, and client core first. If only one node times out, start with its address, port, transport parameters, and remote status.

Use cross-testing to establish the fault boundary

Set up a two-by-two test: test the same node on the current network and another network, then test a second node on the current network. If a node still fails after changing networks while other nodes work, the issue is centered on that node. If every node fails on the current network but works after switching networks, the local network path is the likely cause. If every combination fails, check the client’s shared settings or subscription parameters. Keep the client version, routing mode, and DNS configuration unchanged during cross-testing; otherwise the results cannot be compared.

“Connection refused” and “connection timed out” mean different things. A refusal usually means that packets reached the target host but no service is listening on the specified port, or an intermediate device actively rejected the connection. A timeout may mean that packets never arrived, the return path was interrupted, or the service did not respond. Check the port and remote service first for a refusal; check address resolution, the network path, and the firewall first for a timeout. If the logs show repeated retries at short intervals, pause the node instead of letting the client reconnect indefinitely and bury the original error.

Order for checking TLS and transport parameters

A TLS-enabled configuration involves at least the remote address, server name, and certificate match. The server address can be an IP address or a domain name; the server name is generally used during the TLS handshake, and the two do not have to be identical. Leaving the server name blank, entering a node label, or using the wrong domain during manual editing will cause the handshake to fail. For WebSocket, also check Host and path; for gRPC, check serviceName; for REALITY, verify the public key, short ID, server name, and flow-control fields. Do not hide field errors by disabling certificate verification: it may remove the visible symptom without proving that the configuration is correct.

IPv6 can also cause intermittent timeouts. A domain may return both IPv4 and IPv6 addresses while the current network has only partial IPv6 connectivity. Typical symptoms include a long wait on the first connection followed by fallback to IPv4, or a node that works intermittently. Temporarily preferring IPv4 in the client DNS or system network can help verify the cause, but do not delete all IPv6 configuration immediately. After confirming the cause, choose the preferred strategy based on the network’s actual capabilities.

If a node connects but a particular website times out, check whether the target domain is being incorrectly routed direct, matches a blocking rule, or resolves to an address inconsistent with the routing rules. Temporarily add the domain to an explicit proxy rule and place it before broader rules. After changing the rules, restart the core or reload the configuration, then use the logs to confirm the matched outbound tag. For the order of domain, ip, and geosite rules, continue with V2Ray Routing Rules in Practice.

After applying a fix, verify at least three types of requests: resolve the node server’s domain, access an ordinary HTTPS site, and maintain a connection for several minutes. One successful handshake is not enough to show that the problem is gone. If the connection drops at fixed intervals, continue checking network changes, router connection tracking, mobile power-saving policies, and server-side idle timeouts instead of simply increasing the client connection timeout.

A subscription update has three separate stages: the client requests the subscription URL, the server returns content, and the client parses and writes the node list. Error messages often show only the final result, so determine whether the request was sent, whether the HTTP status was normal, and whether the response used a format supported by the client. An empty node list is not necessarily a network problem; the subscription may be expired, the URL may be incomplete, the response may be a login page, filters may hide every node, or parsing may have encountered invalid formatting.

Check the URL itself first

When copying the subscription URL again, use the source page’s full-copy action instead of selecting it manually. Check the protocol, path, query parameters, and final characters. Chat apps and document editors may replace connection characters or append a period, line break, or space. If the URL contains temporary credentials, do not include it in public logs or screenshots. Confirm that the system time is accurate, because some subscription services validate request time and clock drift can also affect HTTPS certificate validation.

In v2rayN, update one specified subscription first instead of all groups at once. This shows whether the failure belongs to one URL or to the network generally. If the specified subscription fails, keep the error message and check the HTTP status in the logs. If every subscription fails, check the system proxy, direct connectivity, DNS, and whether the client is incorrectly sending the request through a node that is not yet available. Some situations require a direct connection to fetch the subscription, while others require an existing proxy; choose the update method based on the source’s actual reachability.

curl.exe -L --connect-timeout 15 "https://example.com/subscription?token=xxxx" -o subscription.txt

The URL in the command only illustrates the request structure. When testing, do not record or share complete credentials in a public terminal. If the downloaded file is an HTML login page, an error message, or empty, the client cannot generate nodes. If it is a long encoded string or a set of node links, check whether the client supports that format. HTTP 301 and 302 indicate redirects, and -L follows them; 401 and 403 usually involve credentials, permissions, or request conditions; 404 means the path does not exist; 429 means too many requests, so stop refreshing and try again later; 5xx more often indicates a temporary problem on the subscription server.

Content downloaded but parsing failed

If the logs show a successful download but the node list is still empty, check the subscription group’s filters. An overly narrow regular-expression filter may exclude every node, and deduplication may merge similarly named nodes. Disable filtering and update again to see whether the raw nodes appear. If they do, restore the filters one by one. Parentheses, plus signs, and other regular-expression characters in node names have special meanings, so copying a name directly does not always match it literally.

The subscription format and the client core are separate concerns. v2rayN manages desktop configurations, v2rayNG uses the Xray core, and v2flyNG uses the v2fly core; some transport or protocol fields in the same subscription may be recognized by only some clients. If an update succeeds but certain nodes fail to import, inspect the parsing log and confirm the node type instead of repeatedly deleting the subscription. On Android, v2rayNG and v2flyNG can be compared for compatibility, but do not start both local VPN connections at the same time.

When a subscription URL has expired, obtain a new one through the original provider instead of modifying the token or guessing the path. Deleting the old URL and immediately creating another does not fix a server-side permission problem. If a browser can retrieve the content but the client cannot, check user-agent restrictions, the system proxy path, and TLS logs. If the client succeeds but the browser fails, browser extensions, cache, or an independent proxy setting may explain the difference. See the Download page FAQ to confirm the client choice, then return to this chapter and isolate the request, response, and parsing stages.

After a fix, do not rely only on the “Update successful” message. Confirm that the node count is reasonable, the update time changed, old nodes were replaced as expected, and two nodes show the correct server address and protocol fields. Then select one node and run a connection test. A successful subscription update only proves that configuration data reached the client; it does not mean every node can establish a network connection. For connection failures, return to the previous chapter and check the timeout and handshake stages.

Speed issues must first be separated into insufficient bandwidth, high latency, packet loss, per-connection limits, and client resource bottlenecks. A slow webpage does not necessarily mean low download bandwidth, and a high speed-test result does not prove stable interactive latency. Keep the test time, target file, network, and node fixed; repeat at least three times to avoid mistaking target-site congestion or brief wireless interference for a client problem. Do not run multiple speed tests at once, as they compete for bandwidth and change the results.

Establish direct and proxied baselines

First disable the proxy and test direct latency, download speed, and packet loss on the same network, then enable one node and repeat the tests. If the direct connection is already unstable, address Wi-Fi signal, router load, Ethernet negotiation, or the ISP network first. If direct access is stable but every node is slow, check local CPU usage, antivirus network scanning, the TUN driver, and MTU. If only one node is slow, the likely causes are its route, remote load, or the path from the node to the target.

Testing should cover both small requests and sustained transfers. Small requests reveal DNS, handshake, and time-to-first-byte behavior; sustained transfers reveal stable throughput. If the first page load is slow but later resources are normal, DNS or TLS setup is often responsible. If a download starts fast and then falls, possible causes include remote throttling, wireless congestion, packet-loss retransmissions, or a CPU limit. If speed repeatedly drops to zero and recovers, check network changes, mobile power saving, and connection rebuilding.

Check transport, MTU, and routing

TUN mode adds virtual-adapter and routing steps. If the system proxy works normally but TUN is noticeably slower, check the virtual network adapter driver, strict routing, IPv6, and MTU. An MTU that is too large can cause fragmentation or packet loss on part of the path, producing normal small requests but stalled large responses. Gradually lower the TUN interface MTU for comparison, changing only one value at a time and reconnecting after each change. Do not set the MTU too low, as additional fragmentation reduces efficiency.

Rule-based split routing can also make “some websites slow.” The target domain may go direct while images, scripts, or APIs on the page go through the proxy, leaving the two exits with different DNS results and connection states. Open the core access log and check the outbound tags matched by the domains used on the same page. If global proxy mode restores speed, the node itself works and the domain rules should be corrected. If global mode is still slow, continue checking the route and transport parameters. Stale GeoIP and GeoSite data can also misclassify traffic; see How to Update GeoIP and GeoSite Databases.

Client-side encryption, TLS, and traffic forwarding consume CPU. On low-power devices or routers, a saturated single core can limit bandwidth. On desktop systems, watch CPU and memory during a transfer to determine whether the core process is responsible or whether the browser, sync software, or security scan is consuming resources. If CPU capacity is available but speed remains low, do not blindly increase concurrency or the connection count, as higher concurrency may worsen packet loss.

For wireless tests, stay close to the access point and pause high-volume sync tasks. If 2.4 GHz and 5 GHz perform very differently, fix the local wireless environment first. When comparing networks, record the network type and time period; do not attribute differences under different conditions directly to the protocol. After making changes, restore the original routing mode and test browsing, video, large files, and long-lived connections separately. If only one type of traffic is affected, continue by examining its target and connection model.

DNS problems often appear as unreachable domains, intermittent access to the same site, a successful proxy connection followed by incorrect routing, or different results in a browser and the command line. The goal is not simply to replace one DNS address, but to determine who sends the query, where it goes, which address comes back, and how that address enters routing decisions. System DNS, the client’s built-in DNS, browser secure DNS, and TUN interception may coexist. Multiple resolution paths can produce inconsistent results.

Determine first whether DNS is the problem

With the client off, query the target domain using a system command; then turn the client on and repeat the query. Record the returned IPv4 and IPv6 addresses and the resolution time. If the system query fails but a specified public DNS succeeds, the issue may be local DNS or the router. If the command line succeeds but the browser fails, check browser cache, independent DNS settings, and extensions. If resolution succeeds but access fails, compare the address actually used in the logs with the query result.

nslookup example.com
nslookup example.com 1.1.1.1
ipconfig /flushdns

nslookup shows results from the system or a specified server. Flushing the system cache only clears records maintained by the operating system; it does not clear browser or client-internal caches. After flushing, fully close the test application and reopen it. If the client uses FakeDNS, it may return a reserved address as part of its mapping mechanism; do not judge that address like an ordinary public IP. Check whether the core controls the FakeDNS mapping and whether the target traffic still enters the corresponding proxy entry point.

Understand the order of DNS and routing

Routing rules can match domains or the IP addresses returned after resolution. If the system resolves a domain before it reaches the core, the core may see only an IP, preventing domain rules from working as intended. If the core performs resolution, it can retain the domain information and choose different DNS servers and exits according to the rules. Make the resolution strategy explicit; do not depend on conflicting system, browser, and client DNS settings at the same time.

The simplified Xray-style DNS fragment below illustrates the structure of server lists and query strategies. Adjust the actual addresses and policies for the network in use. Back up the original configuration before editing, and confirm whether the graphical client regenerates the file when settings are saved.

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

queryStrategy controls which address families are returned. Setting it to IPv4-only can help verify whether the IPv6 path is abnormal, but it should not be fixed permanently without testing. If the network has stable IPv6, retaining dual-stack access may provide a better route. If IPv6 offers an address but no reliable exit, resolving an AAAA record may create a long wait. Base the decision on system routes and connectivity tests, not merely on whether the network adapter displays an IPv6 address.

With split DNS, the resolution exit should be logically consistent with the access exit. Domains routed directly should generally use DNS that is reliably reachable from the direct network, while proxied domains can be resolved by the core through the proxy exit. If a local DNS server first returns a location-specific address and the request is then sent through a remote proxy, the target may return an unsuitable content endpoint. Conversely, resolving every domain remotely may give local services unnecessarily remote addresses. Base the rules on the actual access path.

If only a few domains are affected, use explicit domain rules and a specified DNS server for a minimal test instead of rewriting the entire DNS setup. Once the rule is confirmed, expand it to a geosite category. After updating the database, check that the rule names still exist and that the client loaded the correct file. For data-file locations, loading behavior, and post-update verification, see How to Update GeoIP and GeoSite Databases.

Final verification should cover system queries, client logs, and actual access: are query results stable, do the logs show the expected DNS server and outbound, and does the browser connect to the corresponding address? Only when all three agree is the resolution path clear. If the target domain’s DNS request is entirely absent from the logs, the query may be happening outside the core; continue by checking system, browser, or TUN interception settings.

A system proxy writes a proxy address and port to the operating system. Only applications that actively read those settings will use it. When the client says “System proxy enabled,” that does not mean every process is being intercepted. Browsers usually support system proxies, while some command-line tools, games, store apps, and software with its own network stack may ignore them. When one app is unaffected, first confirm that other apps work, then determine whether the system setting failed to apply or the target app simply does not use it.

Check the local entry point and system settings

In v2rayN, note the HTTP and SOCKS inbound ports, then verify that the system proxy points to 127.0.0.1 and the correct port. The port must not be occupied by another program and must not be mistaken for the remote node port. Use the netstat command from the previous chapter to confirm the listening process, then test with an explicit proxy argument. If the explicit proxy works but the browser fails, the core and node are working; the issue is with the system proxy setting, browser policy, or an extension.

curl.exe -x http://127.0.0.1:10809 https://example.com/
curl.exe --socks5-hostname 127.0.0.1:10808 https://example.com/

The first command tests through an HTTP proxy; the second uses SOCKS5 and lets the proxy resolve the domain. Replace both ports with the values actually configured in the client. If HTTP works but SOCKS fails, check the SOCKS inbound. If SOCKS works but HTTP fails, check the HTTP inbound or mixed port. If both work but the target app does not, the app probably does not read the system proxy or its internal settings override the system configuration.

A browser proxy extension may override the system proxy. Temporarily disable extensions and close every browser process before reopening it. Some browsers use secure DNS independently, so DNS may follow a different path even when HTTP traffic uses the system proxy. Enterprise policies, family-safety software, and network filters may also rewrite proxy settings; check whether the system setting is immediately restored after being enabled.

Distinguish the system proxy from TUN

The system proxy suits applications that support HTTP or SOCKS proxies, keeps the scope clear, and is easy to undo. TUN mode uses a virtual network adapter and routing to capture more traffic, making it useful for applications that ignore the system proxy, but it introduces DNS interception, route priority, MTU, and driver-compatibility issues. Do not permanently enable TUN just because one app ignores the system proxy. First check whether the app offers its own proxy setting; enable TUN with a minimal configuration only when full traffic capture is genuinely needed.

If enabling TUN cuts off all internet access, first disable the system proxy to avoid overlapping access paths. Then check whether the virtual adapter was created, whether the default route was added, and whether the local-network subnet was incorrectly sent through the proxy. Keep direct rules for remote desktop, local shares, and router-management addresses; otherwise TUN may sever local access. If other virtual adapters exist, check route priority, especially interfaces created by containers, virtual machines, and enterprise networking software.

If browsing still fails after exiting the client, open the system network settings, disable the manual proxy, and check whether an automatic configuration script still points to the old address. Then reopen the browser. If the proxy setting keeps returning, inspect startup items and other networking tools. In v2rayN, use “Clear system proxy” instead of merely closing the window; closing may only minimize the client to the tray while the core continues running.

After the fix, test a browser that follows the system proxy, a command-line request with an explicit proxy argument, and the application that originally failed. Together, the results show whether the problem is in the system settings or the application itself. For the traffic scope and selection of the three proxy modes, see System Proxy, Global Mode, and Bypass Mainland China Mode Explained.

A client window crash, a core process exit, and an unresponsive interface are three different problems. A window crash may involve graphics runtimes, the configuration database, or UI components. The core usually exits because of an invalid generated configuration, a port conflict, a non-executable core file, or insufficient permissions. An unresponsive interface may result from a large node list, log refreshes, subscription parsing, or security-software scanning. Before troubleshooting, confirm whether the graphical client or the core process actually exited.

Save logs and reproduction conditions

Do not clear the configuration or repeatedly reinstall immediately after the first crash. Record the action that triggered it, such as starting the core, updating a subscription, opening settings, switching TUN, or importing a configuration. Save the client log, core log, and system-event timestamps, along with the routing mode and node type in use. A reproducible problem is easier to isolate than an intermittent crash. If it happens on the same action every time, inspect the configuration or system component read by that action first.

If the core exits immediately after v2rayN starts, disable the system proxy first to prevent a dead local port from cutting off internet access. Check the first error in the core output; common categories include invalid JSON syntax, incorrect field types, missing routing tags, an occupied inbound port, and file-access failures. Later retry messages are usually consequences. If the graphical interface generates the configuration, switch back to the default routing and DNS, then select a regular subscription node to determine whether custom settings are responsible.

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

The fragment above shows a valid SOCKS inbound structure for checking field types and JSON punctuation; it is not a complete outbound configuration. JSON does not allow trailing commas, strings must use double quotes, and the port must be a number. If manual validation fails, restore the configuration generated by the client instead of editing the same value in multiple places. A graphical client may overwrite temporary files at startup, so directly editing a generated file is usually not a lasting setting.

Ports, permissions, and the runtime environment

A port conflict prevents the core from listening. After using netstat -ano to find the process occupying the port, identify its purpose instead of terminating every network process. You can change the local inbound port in the client for verification. If the new port works, the original port was occupied; then decide whether to keep the new port or close the conflicting program. After changing the port, update the system proxy and in-app proxy address as well, or they will continue connecting to the old port.

Desktop clients depend on the appropriate runtime environment. If the window will not open at all and system events report a runtime error, revisit the requirements for the desktop and classic WPF editions on the Windows packages page. Do not mix program files and configuration files from different directories or overwrite only part of an installation. During an update, exit the client and core normally, keep a configuration backup, and test the new package in a separate directory.

Security software may block the core from creating a process, listening on a local port, or creating a virtual adapter. Review its block records and the file source, then allow only the required programs and scope. Do not disable all system protection as a permanent solution. If the client works normally but crashes in TUN mode, focus on the virtual adapter driver, administrator permissions, and other network-filter drivers. If it becomes unresponsive only during subscription updates, check the node count, filter expressions, and returned subscription content.

When configuration files are corrupted, back up the original directory and create a fresh configuration so the client can generate default files. Add one node manually for testing. If the new configuration works, migrate subscriptions, routing, and settings one at a time instead of copying the old directory wholesale. If a crash returns after migrating one item, its source is identified. If the fresh configuration still crashes, check the runtime environment, permissions, graphics driver, and system logs.

After troubleshooting, verify five actions: cold start, subscription update, node switching, enabling the system proxy, and normal exit. After a normal exit, confirm that the system proxy was cleared; after restarting, confirm that the configuration loads correctly. One successful connection does not prove that the configuration database and exit flow are healthy. For a complete check of the Windows installation and runtime environment, see The Complete v2rayN Windows Installation and Configuration Guide.

On Android, v2rayNG and v2flyNG capture traffic through the system VPN interface. In addition to node configuration, failures often involve background restrictions, Private DNS, battery policies, network changes, and other VPN apps. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. They can be compared for core compatibility, but only one active VPN connection should be kept at a time. During troubleshooting, fully stop the other client instead of merely sending its interface to the background.

The connection button succeeds but apps cannot connect

First check whether the VPN icon appears in the status bar, then check the client log for a created local VPN interface. If the icon is absent, system authorization may be incomplete, another VPN may be active, or the client may be blocked by the system. If the icon is present but every app is offline, check the node, DNS, and routing. If only some apps fail, check per-app proxy settings, bypass lists, and the app’s own network settings.

Per-app proxy settings often produce the opposite result when their modes are misunderstood. “Proxy only selected apps” and “Bypass selected apps” have opposite meanings, and an app’s identifier may change after an update or reinstall. Disable per-app mode first so every app uses the same path; once the basic connection works, add apps back one by one. If an app still connects directly after being selected, check whether it uses a separate process, a system component, or an embedded service.

Android Private DNS can conflict with the client’s DNS interception. Symptoms include a node showing as connected while domain requests wait for a long time, even though some IP addresses are reachable directly. Temporarily set Private DNS to Automatic and reconnect the client for testing. If the problem disappears, decide whether system Private DNS or the client should handle resolution; do not leave both in an unclear chain. The browser may also use its own secure DNS, which must be checked separately.

Background disconnects and network changes

Disconnects after the screen locks are usually related to battery optimization, background-activity limits, or system cleanup. Allow the client to run in the background and check whether power-saving mode restricts VPN operation. Settings names vary by device, but the goal is the same: allow the client and core process to keep the network active after the screen locks. Do not enable autostart and persistent background operation for multiple similar clients, as they may compete for VPN access and create confusing states.

When switching from Wi-Fi to a mobile network, the existing connection’s local address and route change. Some nodes reconnect automatically, while others remain tied to the old network. If traffic stops after the switch, stop the connection in the client, wait for the network to stabilize, and start it again. If this happens frequently, check the logs for network-unavailable messages, interface closures, or DNS timeouts. Record “fails after a network switch” separately from “fails continuously on a fixed network”; the troubleshooting paths differ.

When a subscription update fails, first confirm that the subscription request opens in a browser on the current network, then check the client’s update log. Mobile networks may restrict background data, roaming data, or data-saver mode. If the subscription updates successfully but nodes cannot connect, use the timeout chapter in this manual to check the address, port, TLS, and transport fields. For mainstream devices released after 2015, arm64 packages are usually the best first choice; when the architecture is unknown, use the universal build. See Android client downloads for the available entry points.

v2rayNG and v2flyNG support different core features. If a node works in v2rayNG but fails in v2flyNG, do not immediately blame the network; first compare whether the protocol and transport fields are supported by the respective core. A comparison test must use the same network, node, and DNS conditions, with the other client fully stopped. If both clients fail, inspect the node and system network. If only one fails, save the first core error from that client to assess compatibility.

Final mobile testing should cover foreground access, recovery after screen lock, Wi-Fi-to-mobile switching, subscription updates, and per-app rules. Test each step separately instead of changing every system setting at once. Once the basic connection is stable, restore Private DNS, battery policies, and app lists. If the problem returns after restoring one item, its conflict is identified. Users who have not completed their first subscription import should return to the Getting Started guide and follow the main setup path instead of treating an incomplete initialization as a runtime failure.