Common v2rayN and v2rayNG questions

V2Ray usually refers to the protocols, cores, and tools in the Project V ecosystem, rather than a single graphical client. v2rayN is a desktop client for Windows, macOS, and Linux that manages servers, subscriptions, routing, and the system proxy; v2rayNG is an Android client that typically uses the Xray core. The client provides the interface, while the core it invokes handles connections and traffic.

No. An installer puts v2rayN, v2rayNG, or v2flyNG on your device. A subscription URL is generated by a network service provider and delivers server configurations to the client. After installing the client, you still need to import a valid subscription or enter the server details manually. This site provides client installation and configuration guidance; it does not generate subscription URLs, and an installer cannot replace server configuration.

A system proxy uses the operating system's proxy settings to handle traffic from applications that read those settings. It is simple to configure and works well for browsers and most desktop programs. TUN mode uses a virtual network interface to handle a broader range of traffic, including traffic from apps that ignore system proxy settings, but it requires higher privileges and can conflict with other virtual interfaces, network filters, or security policies. For everyday use, start with the system proxy.

Choose v2rayN for Windows, macOS, and Linux; its interface and subscription management are broadly consistent across desktop platforms. For Android, v2rayNG is usually the first choice. If a subscription specifically depends on v2fly core behavior, use v2flyNG instead. Menus vary between clients, but the basic workflow—update subscriptions, choose a node, start the connection, and configure routing as needed—is similar.

The desktop edition uses a newer cross-platform interface and suits users who want a similar workflow across desktop operating systems. The classic WPF edition uses the traditional Windows interface and suits users familiar with its older menus and tray controls. Both manage subscriptions, nodes, and cores. Do not run both editions at the same time, or they may overwrite each other's local listening ports and system proxy settings.

Open System Information or About This Mac and check the chip or processor section. If it lists an Apple M-series chip, choose the Apple Silicon arm64 package. If it lists an Intel processor, choose the x64 package. Choosing the wrong architecture can prevent the app from launching or require an additional compatibility layer. Confirm the hardware architecture before downloading; it is more reliable than guessing from the OS version.

Most mainstream Android phones released after 2015 use the arm64 architecture, so the arm64 package is usually the best first choice and is typically smaller. Choose the universal package if you cannot confirm the processor architecture, have an older device, or the arm64 package is reported as incompatible. The universal build supports more architectures, so it may be larger, but its features are generally the same as the arm64 build of the same version.

Check first for spaces or line breaks around the URL, or signs that a chat app truncated it. Make sure you are importing it into a subscription group, not a single-server configuration window. Then open the URL in a browser to confirm it still returns content, and verify that the device clock is accurate. If the provider requires special request parameters or has replaced the URL, use the latest complete link; the client cannot repair an outdated URL automatically.

Fully exit the client first, grant the administrator, network extension, or virtual network interface permissions required by the operating system, and restart it. If the problem persists, check whether another proxy tool, virtual machine network, container network, or security program is using the same capability. During troubleshooting, close other virtual-interface programs and test with only one client. Once the system proxy works, enable TUN separately.

Create a subscription group, enter the complete subscription URL, and save it. Then choose Update current subscription or Update all subscriptions. When the update finishes, check that nodes appear in the server list, select one as the active server, and enable the system proxy or required connection mode. Future updates should target the original group. Avoid repeatedly creating groups with the same name, which can cause duplicate nodes and confusing selection states.

A global proxy sends all traffic within the client's scope through the current proxy exit. It is useful for temporarily checking whether routing rules are causing access problems, or when a single exit is genuinely required. For everyday use, route traffic by domain, address, and local-network scope to avoid sending LAN devices, system updates, or services that do not need a proxy on an unnecessary detour. After changing modes, reopen the target app before testing again.

It depends on the client version, group settings, and subscription contents. Subscription updates usually rebuild the list using server identifiers. If the provider changes a node name or parameters, the old entry may be replaced. The current node is usually retained when it still matches; otherwise, you must select a node again. Put important custom servers in a separate group instead of mixing them with automatically updated subscription entries.

Different tests use different target addresses, protocol stages, and timeout conditions. Basic latency may measure only the time needed to establish a connection; actual latency also includes the proxy handshake and target request. Download speed is additionally affected by exit bandwidth, the target server, network congestion, and device performance. Use latency numbers only for initial screening, and judge the final result by access to the target site and connection stability.

During initial setup, briefly use global mode to confirm that the node and core path work correctly. Once access is confirmed, switch to rule-based routing. Rule-based routing chooses direct connection, proxy, or block actions according to domains, IP addresses, and rule sets, making it better for long-term use. If only some sites fail after switching, check the matching routing rules and DNS results before replacing all nodes.

Confirm that the device itself has a working internet connection, then check the system time, server address, port, transport, TLS, SNI, and user identifier. Review the core logs to distinguish DNS resolution failures, refused connections, handshake failures, and wait timeouts. If every node in the same subscription times out, check the local network and subscription configuration. If only a few nodes time out, those servers are more likely to be having issues.

Check the path in order: confirm that the current node is set as the active server, verify that the system proxy or TUN is actually enabled, and check whether the browser has its own proxy settings. Then review the core logs for DNS, routing, or handshake errors. Temporarily switch to global mode for comparison. If global mode works but rule mode does not, the problem is usually in the routing rules or DNS configuration.

Some apps do not read operating-system proxy settings, while others cache old settings at startup. Close the target app, confirm that the system proxy points to the local address and port currently used by v2rayN, and reopen the app. Also check whether the app has its own direct-connection or proxy settings. If it consistently bypasses the system proxy, use TUN after confirming permissions and compatibility instead of stacking multiple proxy tools.

Confirm that you are updating the correct group, then check that the subscription URL is complete, has not expired, and that the device clock is accurate. An empty list does not necessarily indicate a client failure; the provider may have returned empty content, authentication may have expired, or the subscription format may have changed. Check the update log for HTTP status codes, parsing errors, and timeout details. Do not keep creating new groups; fix the original URL and run the update again.

Open the client's log window and find the earliest error from the current startup attempt. If a port is already in use, close the program using it or change the local listening port. If configuration parsing fails, undo recent changes to routing, DNS, or manual server parameters. If required fields are missing, import the configuration again from a valid subscription. Do not focus only on the final exit message; the actual cause is usually the first error immediately before it.

Possibly. Test several domains through the same node to see whether the issue is limited to a particular domain or rule group. Check the client's DNS settings, the system cache, domain matching in the routing rules, and whether the result is resolved directly or through the proxy. After making changes, clear the system DNS cache and restart the target app. If global mode restores access, continue checking the routing and resolution path rather than reinstalling the client.