v2rayN / v2rayNG Setup Guide

This guide assumes the client is already installed and that you have a working subscription URL. Use v2rayN on desktop devices and v2rayNG on Android devices. A subscription URL is usually a complete link beginning with https://, supplied by your service provider. It is not a single node name or the username and password for a login page. When copying it, select the entire URL from beginning to end and avoid including spaces, line breaks, or punctuation automatically added by chat apps.

After launching the client for the first time, do not rush to change the port, DNS, Mux, or transport settings. Nodes in the subscription already include the protocol, server, port, authentication details, and transport method. Changing any of these manually can make the client configuration inconsistent with the server. For a quick first setup, simply confirm that the client opens, the system clock is accurate, and the network can access ordinary websites, then follow the four steps below.

If the client is not installed yet, go to the Download Center and choose the appropriate platform. Use v2rayN on Windows, macOS, and Linux; use v2rayNG on Android. Return to this page after installation. The design differences between protocols, the relationship between the V2Fly and Xray cores, and when to use VMess, VLESS, Trojan, and REALITY are covered in the Protocol Manual; you do not need to master them all before making your first connection.

In the v2rayN desktop app, open “Subscription Groups” or the subscription management entry in the top menu, then create a subscription group. Use a recognizable name for the note, such as the service name or intended use, and paste the complete subscription URL into the address field. Save it, return to the main screen, and select “Update All Subscriptions.” The client will fetch the subscription and convert its server configurations into a list. When the update finishes, one or more nodes should appear in the main window, usually with details such as the node name, protocol type, address, and port.

In v2rayNG, open “Subscription Group Settings” from the side menu, tap the add button, enter a note, and paste the subscription URL. Save it, return to the server list, and select “Update Subscription” from the menu. Keep the app in the foreground while it updates and wait for the notification to finish before checking the home screen. On success, an empty server list becomes a selectable list of nodes. If the subscription contains groups, nodes for different purposes may be distinguished by name prefixes.

After importing, inspect the list before connecting. Make sure node names display normally rather than as an unreadable block of URL text; confirm that at least one entry is present and that the protocol column shows VMess, VLESS, Trojan, or another supported type. If the list is still empty, reopen the subscription editor and check for spaces at either end of the URL, then verify the system date, time, and time zone. Some subscription URLs expire; after expiration, request a new one from the service provider.

Once the node list appears, the first step is complete. The client has only saved the configuration; system traffic is not yet passing through the active node. Next, decide which requests the client should handle by choosing a proxy mode and routing method.

Proxy mode determines which traffic the client takes over. For a first setup, start with the client's preset rule mode. It uses built-in routing rules to decide whether a request connects directly or goes through the proxy, making it suitable for everyday use and easy to check. Global mode sends more requests through the current node and can help briefly determine whether routing rules affect a page, but before using it long term, understand its impact on local services, LAN resources, and commonly used apps.

In the v2rayN desktop app, first check the “System Proxy” status at the bottom of the window or in the tray menu. After enabling automatic system proxy configuration, browsers and apps that follow the system proxy settings will send requests to v2rayN’s local listening port. Then choose a preset rule set in the routing settings. Menu wording may vary slightly between versions, but the criteria are the same: the system proxy must clearly be enabled, and one rule set must be selected as current.

If an app does not read the system proxy, its traffic will not change automatically just because v2rayN is running. Start with a standard browser for verification, and do not change TUN mode, the app's own proxy, and the system proxy at the same time. Adjusting several entry points together makes troubleshooting harder because you cannot tell which layer took effect. Once the basic connection is stable, read the routing and client sections in the Protocol Manual to decide whether broader traffic handling is needed.

In v2rayNG, open the routing configuration in Settings and choose the preset rules provided by the app. When connecting on Android, a system-level VPN connection is created, and the system sends the selected traffic to the client. If options such as “Bypass LAN” or per-app routing are available, keep their defaults during the first setup. Stabilize browser requests first, then adjust the app scope one setting at a time to avoid confusion from overlapping rules.

Rule mode is not a protocol type. Labels such as VLESS and VMess describe how the client communicates with the server; rule mode describes how local traffic chooses an exit. They operate at different layers, so changing routing rules does not require changing the node protocol. Save the mode selection, return to the node list, choose the server to use, and start the connection.

The node list often contains several candidates. Run a latency test first as a reference for whether the current network can reach the server. Latency depends on the local network, server distance, route conditions, and test method, so the lowest number does not necessarily mean the highest real-world download speed. For the first connection, choose a node that returns a result and has complete protocol information. If several nodes work, prefer one with a clear purpose in its name and a relatively nearby location.

In v2rayN, select a node and choose “Set as Active Server” or double-click its entry. The selected node usually shows a color, icon, or status change. Confirm that the core has started, then check the system proxy status again. Some versions show the active server, local listening port, and runtime status at the bottom of the window. You can also open the log window; a normal startup typically includes entries for loading the configuration, starting the inbound listener, and initializing connections.

In v2rayNG, tap a node name to make it the current configuration, then tap the circular connect button on the home screen. The first connection of this type may trigger a system authorization prompt; review it and allow the connection. When the button changes state and the status bar shows a connection indicator, the system is sending traffic to v2rayNG. This confirms only that the local tunnel is established; verify server-side forwarding through the next browser test and the logs.

Do not switch rapidly between multiple nodes while connecting. After stopping one, wait until its status has fully ended before choosing another and reconnecting; otherwise, the old connection shutdown, local port recreation, and new configuration loading may overlap. If you just changed the system proxy on desktop, close and reopen the browser so it reads the system settings again. On Android, leave the client running in the background before testing with a browser.

If a node test returns no result but a webpage opens after connecting, do not draw a conclusion from a single test; some servers handle test requests differently from real webpage connections. Conversely, a latency result does not prove that the full connection works if webpages consistently fail. Latency testing answers only part of the reachability question; real requests and client logs remain the final reference.

Keep the client connected and open a new browser window. Visit an ordinary webpage first to confirm that proxy settings have not disrupted the local network, then visit a page that should be handled by the current rules. Do not look only for a loading animation; check the client for new connection records or traffic changes as well. If the logs show the target domain, an outbound connection, or a routing match while the page opens, the browser request has reached the client.

The most common desktop verification issue is that the browser is not reading the system proxy. Close all browser windows and restart it, then check whether the browser has another proxy extension or a fixed port configured. If it supports “Use system proxy,” make it follow the system settings. v2rayN’s local port only needs to be entered when configuring an app manually; a standard browser using the system proxy usually does not require a separate port.

On Android, confirm that v2rayNG still shows a connected status and check whether the current app is within the allowed handling scope. If per-app proxying is enabled, the browser may not be selected. For the first test, restore a simpler default scope, confirm the connection, and then configure it again. When switching between mobile data and Wi-Fi, an existing connection may need to be recreated; after the network changes, stop v2rayNG once and reconnect to the current node.

You can also use a before-and-after comparison to locate the problem. Disconnect, refresh the same page, and record the result; reconnect, refresh it again, and check whether the logs contain a new request. Different results indicate that the proxy entry point and routing are taking effect. Identical results mean you should first check the system proxy, app scope, and routing rules rather than immediately changing the node protocol.

Once verification succeeds, the basic setup is complete. Daily use generally requires only updating the subscription, choosing a node, and controlling the connection. Updating a subscription does not guarantee that the current node will remain available; if the active node is removed, choose another from the updated list. When changing TUN, DNS, split-routing rules, or protocol settings, change one item at a time and preserve the previous state so you can restore it if the result is unexpected.

When pages will not open, connections time out, or the list is empty, checking in a fixed order is more effective than changing several settings at once. Confirm that the ordinary network works, then update the subscription; next verify the system time and choose another node; then confirm that the proxy entry point is enabled, and only afterward inspect protocol settings and runtime logs. This moves from external conditions toward the client internals and reduces repeated work.

An occasional single connection failure in the logs does not necessarily mean the entire client has stopped working. Webpages often request multiple domains, and some analytics, image, or background endpoints may fail independently. Judge the situation by whether the main page opens, whether similar errors keep recurring, and whether the active node still has normal connections. For a complete guide to protocol selection, core differences, subscription compatibility, and routing design, continue with the Protocol Manual.

After the first setup, daily operation can be reduced to four tasks: update the subscription regularly, choose a node with a normal status, confirm the proxy entry point and routing mode, then verify through the browser and logs. Use the same order after a client update, network change, or subscription change. A fixed workflow is more reliable than memorizing many switches because every step has clear inputs and observable results.

If you are only changing nodes, you do not need to import the subscription again; if you are only adjusting routing, you do not need to change the server protocol. Keeping subscriptions, nodes, proxy entry points, and routing rules conceptually separate makes future troubleshooting clearer. To reinstall or switch platforms, visit the Download Center; to compare VMess, VLESS, Trojan, REALITY, V2Fly, and Xray, see the Protocol Manual.