v2rayN and v2rayNG Setup Guide

Before you begin, prepare an installed client and a working subscription URL. Use v2rayN on desktop and v2rayNG on Android; if neither is installed, visit the installation package page and choose the version for your platform. A subscription URL is usually a URL beginning with https://. It is different from a single vmess:// or vless:// share link: a subscription URL represents a group of server configurations that can be updated, while a share link usually represents one configuration.

Do not start by changing TUN, Mux, routing rules, and core options all at once. The goal of the first setup is to confirm that the client can read the subscription and run one server configuration through the most basic proxy entry point. Change one setting at a time so it is easier to identify whether a problem comes from the subscription format, server configuration, proxy mode, or a local software conflict. This guide does not require you to write complete JSON or cover every transport field. If you have a native JSON configuration or need to compare VMess, VLESS, Trojan, Shadowsocks, and REALITY, see the protocol and core technical reference.

The first step is to handle the subscription source. The subscription name is a local label, so use a purpose that is easy to recognize. Paste the complete subscription URL without leading or trailing spaces. Saving a subscription does not retrieve the server list; you must run an update afterward. A successful update is indicated by one or more server configurations appearing in the client's main list, usually with an address label, protocol type, or group name.

Add a Subscription in v2rayN

Open the v2rayN main window, find “Subscription Groups” in the top menu, and open “Subscription Group Settings.” Add a new group, enter an identifiable name in the alias or notes field, paste the complete subscription URL, and save it. Return to the main window, open “Subscription Groups” again, and choose “Update All Subscriptions” or the update command for the selected group. During the first update, if no usable proxy is available, choose an option such as “Update Without Proxy.” The client will request the subscription URL directly and write the parsed configurations to the server list.

When the update finishes, check the main list rather than relying on a notification that disappears quickly. The list should show columns such as server label, address, port, and protocol. If it is still empty, return to the subscription group settings and check whether the URL was truncated, whether you pasted a webpage address instead of a subscription URL, and whether the group is enabled. Do not keep clicking Update repeatedly; repeated requests cannot repair an invalid format. You can first paste the URL into a browser address bar to confirm that it returns text, then update it again in the client.

Add a Subscription in v2rayNG

Open v2rayNG, tap the top-right menu, open “Subscription Settings,” and tap the Add button. Enter the subscription label and URL, save them, and return to the configuration list. Then choose “Update Subscription” from the menu. In some versions, this entry appears as a refresh icon or “Update Subscription Settings.” After the update, selectable entries will appear in the configuration list. Each usually shows a server label, and the selected entry is marked clearly.

If v2rayNG reports that the subscription content cannot be parsed, do not move on immediately. The subscription may return aggregated base64 content, a collection of individual share links, or a format intended for a specific client; compatibility varies between formats. First confirm that the provider explicitly supports v2rayNG, then check whether the URL requires an authenticated session, has expired, or picked up line breaks during copying. If there is only one share link, you can use “Import from Clipboard,” but this will not create an automatically updated subscription group. For the structural differences between base64, native JSON, and share links, read V2Ray Subscription Formats Explained.

Once the server list appears, select one configuration, but do not enable every advanced feature at once. The next decision is how traffic enters the client: on desktop, start with the system proxy; on Android, use the system connection authorization to establish the TUN interface. The proxy entry point and protocol type are separate concepts. VMess or VLESS describes how the client connects to the server, while the system proxy or TUN describes how local app traffic enters the client.

The two common entry points in v2rayN are “System Proxy” and “TUN Mode.” The system proxy changes the operating system's HTTP and SOCKS proxy settings, so browsers and software that follow system proxy settings can usually use it directly. TUN mode creates a virtual network interface and can handle more software that does not read system proxy settings. For a first setup, enable the system proxy, confirm that the subscription and server work, and then decide whether to switch to TUN based on the apps you need to cover. This separates connection issues from virtual network adapter and permission issues.

v2rayN: Start with Automatic System Proxy Configuration

In the v2rayN main window's bottom status bar or system tray menu, find “System Proxy” and select “Automatically Configure System Proxy.” After it is enabled, the status text or tray icon will usually change. The client writes its local listening address to the operating system's proxy settings, so common browsers do not need a port entered separately. Do not manually edit the address and port on the system proxy page afterward. Manually entered values may remain when the client closes or the mode changes, making later troubleshooting harder.

The system proxy also works with routing rules to determine which requests go through the proxy and which connect directly. For an initial test, keep the client's preset routes; there is no need to import a large rule set. If the interface offers “Global,” “Rules,” or custom routing options, start with the standard rules mode. Use global proxy mode temporarily only to compare whether a particular app is being bypassed by routing. Global proxy mode sends matched traffic to the current server, but it does not mean every program reads the system proxy. Software that ignores system proxy settings may still require TUN.

When to Use v2rayN TUN Mode

If the target software does not follow system proxy settings, or you need more TCP and UDP traffic to enter the routing engine, disable the system proxy for testing and enable “TUN Mode” instead. The first activation may require administrator permission and installation or startup of related network components. After enabling it, keep the default stack and MTU; do not also change strict routing, DNS hijacking, or custom adapter parameters. If the client reports insufficient permissions, exit and relaunch it using the permission-elevation method allowed by the system, then enable TUN separately.

The system proxy and TUN can coexist in some configurations, but beginners should not test them together. When both are enabled, even a working page does not make it easy to tell which entry point handled the traffic. Complete the four steps in this guide with the system proxy first. If broader app coverage is truly needed, disable the system proxy, enable TUN, and repeat the connection and verification steps. For the full relationship between the TUN stack, DNS routing, and process-based split routing, see the routing chapter in the protocol manual.

v2rayNG: Confirm Connection Authorization and Routing Settings

When v2rayNG starts a connection, it creates a system-level TUN interface, so you do not need to enable a separate “System Proxy” as you would on desktop. The first time you tap the start button, the system displays a connection request; the client can take over traffic for the selected apps only after you confirm it. If authorization was previously denied, tap the start button again and follow the system prompt. The “Routing Settings” page controls how different destinations choose an outbound connection. Keep the defaults at first, and do not enable per-app routing, bypass rules, and custom DNS at the same time.

Mux multiplexing is not required to establish a connection. It attempts to reuse connections in some scenarios, but its suitability depends on server capabilities, the protocol combination, and the type of traffic. Keep the default setting during the initial setup and compare it later as a single variable after the basic connection is stable. Protocol-related fields such as REALITY and XTLS Vision should also come from the subscription configuration; do not rewrite them manually for “optimization.” A mismatched combination of fields will usually cause the server handshake to fail immediately.

Once the proxy entry point is ready, identify the active server. When the subscription contains multiple configurations, the client cannot know which one you want to use; select the target entry first, then start the connection. There is no need to chase complex latency-test results at this stage. Choose one configuration with a clear label and complete protocol fields for the connectivity test.

Active Server in v2rayN

In the v2rayN main list, click a server configuration, press Enter, or use the context menu to choose “Set as Active Server.” The active item is usually marked by a color, icon, or status column. Then check the status bar at the bottom of the window and confirm that the current server name matches your selection. If the system proxy is already configured automatically, the client will usually load this configuration after it is made active. If the bottom bar says the core is not running, restart the core or the client from the menu.

Next, open the log area. During a normal startup, you should see messages for loading the configuration, creating the local listening port, and completing core startup. The local port in the log connects the client to the system proxy; do not copy it into the subscription settings. If you immediately see failed, invalid, timeout, or a port-conflict message, note whether the error occurred while loading the configuration or connecting to the remote server. Configuration loading failures usually involve field formatting or core compatibility; port conflicts commonly mean another proxy program is still running.

Current Configuration in v2rayNG

In the v2rayNG configuration list, tap the target entry to make it current, then tap the circular start button at the bottom. Confirm the connection request in the system dialog the first time you start it. After the connection is established, the button state will change and the notification area will usually show that the connection is running. When you return to the list, the selection marker should still be on the same server. If it stops immediately after you tap it, open the logs from the menu and check whether the failure involves configuration parsing, DNS, the handshake, or a connection timeout.

If the subscription contains multiple servers and the first one cannot connect, try another and repeat the test. Confirm that the active selection actually changes each time. Do not batch-edit the ports, transport methods, or TLS fields of every entry; these fields are determined by the server configuration. If several entries fail at the same stage, the subscription content, client core, or local network entry point is more likely at fault. If only one entry fails, first consider that configuration itself unavailable.

After starting the connection, wait a few seconds for DNS and the local listener to stabilize before verifying it. A running status icon only shows that the client process has started; it does not by itself prove that requests are leaving through the target outbound connection. Proper verification should check the page, system proxy status, and client logs together, with at least two of them confirming the same result.

For verification, start with a normal HTTPS page rather than testing multiple browser extensions, command-line tools, and specialized apps at once. With v2rayN and the system proxy, use a browser that follows system proxy settings; with v2rayNG, use a regular browser. After opening the page, return to the client logs and look for a new connection record. If the page loads and the logs simultaneously show the target domain or an outbound connection, the request has entered the client.

Check the v2rayN System Proxy Status

Open the system proxy menu in v2rayN again and confirm that “Automatically Configure System Proxy” is still selected, rather than “Clear System Proxy” or “Do Not Change System Proxy.” Then check the operating system's proxy settings: the address should point to the local listening address, and the port should match v2rayN's current local port. This is for inspection only; do not overwrite the values manually. If the browser has been open for a long time, fully quit the browser process and relaunch it so it reads the system proxy settings again.

If the browser page is unchanged and the v2rayN logs show no new requests, the problem is usually before the client: the browser may be using an independent proxy extension, ignoring system proxy settings, or another network tool may have overwritten them. Temporarily disable browser proxy extensions, then clear and automatically reconfigure the system proxy. If the logs show requests but report a handshake failure, connection timeout, or remote closure, the traffic has reached the client; focus troubleshooting on the active server, protocol fields, and local network.

Check TUN and v2rayNG Status

When using v2rayN TUN or v2rayNG, first confirm that the system status area still shows the connection running. Open a regular page and check the client logs. If the request enters routing but the page does not finish loading, focus on DNS and routing settings. If there is no request in the logs, check whether system connection authorization is still valid and whether per-app proxying excludes the current browser. For the first verification, disable per-app filtering so ordinary traffic passes through the client; after it works, add split-routing conditions one at a time.

After a successful positive test, perform a shutdown test: stop the client connection or clear the system proxy, refresh the same page, and check whether the client logs stop producing new entries. This confirms that the page actually depends on the current client connection rather than browser cache, an independent extension, or another background program. Restart the connection after testing and confirm that the status returns. Before closing v2rayN, if you no longer need the proxy, choose “Clear System Proxy” to prevent the system from retaining an invalid local listening address.

Confirm That Subscription Updates and Connections Are Separate

A successful subscription update only means that the client retrieved and parsed the configuration list. A running connection only means that the core loaded the active configuration. A page request entering the logs and completing normally is what confirms the full working chain. When troubleshooting, check in order: whether the list contains configurations, whether the active server is clear, whether the proxy entry point is enabled, whether the core is running, whether the request enters the logs, and whether the outbound connection succeeds. Do not skip these states and repeatedly switch protocols.

For everyday use, simply update the subscription periodically, select an active server, and confirm the proxy entry point status. If you plan to configure custom routing, process-based split routing, DNS, Mux, REALITY, or a different core, change one option at a time and repeat the verification process in this section after each change. For a full comparison of protocols and core compatibility, continue with the protocol manual.