Quick v2rayN and v2rayNG Setup Guide

Step 1

Import the subscription and update the node list

First, add the subscription URL to the client. In the v2rayN desktop app, open the “Subscription Groups” menu at the top and enter the subscription group settings. Choose Add, enter an easy-to-recognize name such as “Common subscription” in the remarks field, and paste the complete URL into the subscription URL field. Check that there are no extra spaces at either end, save the settings, and return to the main window. Open the Subscription Groups menu again and choose Update current subscription or Update all subscriptions.

In the v2rayNG Android app, open the menu in the upper-left corner, find the subscription group settings, and tap the Add button in the upper-right corner. Enter a remark and paste the subscription URL, save it, and return to the subscription list. Select the group you just created and run Update subscription. Keep the client in the foreground until the status message finishes. Button positions may vary slightly between versions, but look for “Subscription Groups,” “Update subscription,” or a similar entry.

After the update succeeds, return to the server or node list. At least one selectable entry should now appear; its name comes from the subscription. Do not rely only on an “Update complete” message—check that new items were actually added to the list. If it is still empty, reopen the subscription editor, confirm that the URL is complete, and update it again. If the client reports a network error, format error, or empty response, do not move on to proxy mode yet, because the remaining steps require a valid node.

Once the node list appears, select a regular node as the current server. On desktop, you can usually double-click an entry, right-click it to set it as the active server, or select it and use a shortcut. On Android, tapping the node name usually switches to it; the selected item may change color, show a check mark, or display a different status. This only selects the configuration for the connection—it does not enable the proxy yet.

Step 2

Choose the system proxy and rule-based mode

Once the subscription and node are ready, decide which connections the client should handle. For a first setup, the goal is to establish a testable route, so desktop users should enable the system proxy and keep routing on the client's rule-based mode. Rule-based mode uses existing rules to determine how connections are routed and is a suitable starting point. Global mode sends more connections through the proxy and can help with short troubleshooting sessions, but it should not be used as a long-term setting before the node is confirmed.

In v2rayN, check the status bar at the bottom of the main window or the system tray menu. Find “System Proxy” and choose automatic system proxy configuration or an equivalent enable option. The system proxy status usually changes color or displays the active mode. Then find the “Routing” or “Rules” settings and select the client's built-in rule profile. If the interface already shows rule-based mode, do not switch it repeatedly. Keep the local listening port at its default value and do not enable multiple traffic-capture methods at once.

In v2rayNG, the basic connection is established through the system VPN service. For the first test, keep routing on the default rules or the commonly used rules that bypass the local network. Avoid creating complex custom rules yet. If per-app proxying is enabled, confirm that the browser you want to test is included in the proxy scope. If unsure, temporarily disable the per-app restriction, then configure it by app after connectivity is verified. Battery optimization, background operation, and per-app settings are stability adjustments to handle after the basic connection works.

A common mistake when choosing a mode is assuming that a client showing “started” means system traffic is being routed through it. On desktop, confirm both the core process and the system proxy switch. On Android, confirm that the connection button's system authorization has been completed. The interfaces differ, but the logic is the same: the node determines “where to connect,” while the mode determines “which traffic enters the connection.” Both must be clear before the connection status means anything.

If you previously changed TUN, DNS, or the local port and the interface no longer matches this guide, restore the default settings and restart the client first. For detailed choices involving rule matching, DNS handling, TUN mode, and custom routing, see the protocol manual. This step keeps only the minimum settings required for a first connection.

Step 3

Start the client and establish the connection

Now establish the connection. In v2rayN, the core usually starts automatically with the client, but check the status area at the bottom to confirm that the current server name, system proxy status, and runtime message have updated. If the core has not started, use the start entry in the main menu or tray menu. Then confirm that the system proxy is enabled. You can minimize the window, but do not exit the program before the first verification is complete.

In v2rayNG, select a node and tap the connect button at the bottom of the main screen. During the first connection, the system displays a network connection permission dialog; approve it before the client can establish local traffic capture. After authorization, return to the main screen and check for a connected message on the button, at the top, or in the notification area. If the button immediately returns to a disconnected state, open the log and read the last few lines instead of tapping repeatedly.

While connecting, the client reads the node parameters, resolves the server address, and completes the transport handshake. Normally, the interface changes from “Disconnected” to running or connected. Some clients offer latency tests, but a successful latency test only confirms a response to a specific probe and cannot replace browser testing. A failed test does not necessarily mean the node is unusable. For this step, confirm only the client process and connection state; check the actual result in Step 4.

If the connect button does nothing, wait a few seconds and check the status area. If a port is already in use, close other similar clients and restart; if configuration parsing fails, return to Step 1, update the subscription, and select the node again. If you see a handshake or certificate error, first verify the device's system time and time zone, then check that the node parameters were delivered correctly by the subscription. For repeated crashes or runtime-library messages, use Troubleshooting and check the startup issues section.

Run only one client during the first test. Multiple proxy tools can modify the system proxy or occupy the same local port, causing the interface state and actual traffic to disagree. Close the other tools, restart the current client, reselect the node, and enable the connection again. This reduces port conflicts and repeated overwrites of the system proxy.

Step 4

Verify the proxy status and browser access

Once the connection looks normal, perform a real access test in a browser. Open a new window and visit a familiar page that normally requires a proxy connection. Do not merely refresh an existing tab, because the browser may retain old cache, connections, and DNS results. After the page loads normally, open a second, different site to confirm that the result is repeatable.

If browser access works, return to the client and check the connection log. It should show new outbound entries without a continuous stream of failures. On desktop, you can temporarily disable the system proxy and refresh the page to compare the result, then enable the system proxy again. On Android, disconnect once, test again, and reconnect. This comparison helps confirm that the page is going through the current client rather than another network path.

If the client shows connected but the browser behaves the same, check the following in order. First, verify the current node: make sure the selected item has not switched back to another configuration. Second, verify traffic capture: in v2rayN, check that the system proxy is still enabled; in v2rayNG, check that the browser being tested is within the per-app scope. Third, restart the browser and test again to rule out an old connection. Fourth, switch to another node in the subscription, leave all other settings unchanged, and reconnect.

If none of the nodes work, return to the subscription group, run an update, and verify the device's system time. A time difference can affect the TLS handshake, while an expired subscription or abnormal response can disable multiple nodes at once. If only one node fails while others work, you usually do not need to change the client's global settings; keep the working node and test the failed entry again later.

After verification succeeds, do not keep testing in global mode. Restore the routing mode you plan to use long term, then open your usual apps one by one to confirm their access scope. Before exiting the desktop client, disable the system proxy so the system does not retain an unusable proxy address. On Android, use the client's disconnect button when stopping. If it suddenly stops working later, follow the same order: update the subscription, select a node, check the proxy switch, and finally inspect the logs.