v2rayN Setup Guide: From Subscription Import to Connection Verification

Add a subscription in v2rayN desktop

Open the v2rayN main window and find “Subscription Groups” or the subscription management entry. The menu location may vary slightly between versions: some place it under the top “Subscription Groups” menu, while others put it in the subscription section of the left navigation. In the management page, choose Add, give the subscription an identifiable name such as “Primary subscription,” and paste the complete URL you copied into the URL field. The name only distinguishes the group on this device; it does not change the server configuration.

After saving, return to the main window, open the subscription menu, and choose “Update all subscriptions,” or update the group you just created. When the update finishes, several node rows should appear in the main list, usually showing fields such as an alias, address, port, transport, or protocol. For now, simply confirm that the list is not empty; there is no need to guess which node is fastest from its name. Once the window shows an update-complete message and the list contains entries, continue to the next step.

Add a subscription in v2rayNG for Android

Open v2rayNG, open the top-right menu, and find “Subscription group settings” or a similarly named subscription management option. Tap Add, enter a label, and paste the subscription URL. Save it and return to the main screen. Open the menu again and update the subscription. Keep the network available during the update. When it finishes, node entries should appear on the main screen; the selected item is usually indicated by highlighting, a check mark, or a separate current-configuration area.

If pasting the URL produces an invalid-address error, first check for spaces or line breaks at either end. Place the cursor at the end of the field and make sure punctuation from a chat app was not copied along with the URL. If saving succeeds but the list remains empty after updating, do not proceed to the connection step because the client has no usable configuration. Confirm that the subscription URL is still valid, then check the client log for an HTTP status, parsing error, or timeout. For a systematic subscription failure checklist, see the subscription section of the troubleshooting guide.

Understand the system proxy state on desktop first

In v2rayN, start by finding the “System Proxy” menu. For the initial setup, choose “Auto-configure system proxy” or the equivalent option in your version. Once enabled, v2rayN points the system proxy to a local listening port, so browsers and apps that follow system proxy settings send requests to the client. The taskbar or window status area usually indicates that the system proxy is enabled, and the active menu item is marked as selected.

“Clear system proxy” removes the system proxy set by the client and is useful when stopping the client to restore the network environment. “Do not change system proxy” leaves v2rayN's local proxy port running without actively modifying the operating system settings, which is generally for apps configured with a manual proxy or systems managed by another network tool. For a first setup, the third option is not recommended: the node may be running while the browser sends no traffic to v2rayN, making it look like the connection failed.

The system proxy and routing rules operate at different layers. The system proxy sends app traffic into the client; routing rules decide whether requests inside the client use a proxy outbound, a direct outbound, or a blocked outbound. Keep the default routing rules for the initial setup. After basic connectivity is verified, learn about domain routing, IP rules, and DNS policies as needed. See the routing and split-tunneling section of the glossary, or the system proxy not working section for a complete troubleshooting process.

Confirm connection authorization on Android

v2rayNG works differently on mobile: after you tap Connect, it uses Android's VPN interface to handle app traffic. The first connection usually triggers a system connection request; after you approve it, a system connection indicator appears in the status bar. This authorization only allows v2rayNG to create a local traffic tunnel; it does not mean the remote node is usable, so continue through the third step and watch the client status.

If v2rayNG offers an “App proxy” setting, leave it off during the initial setup so normal apps use the same connection path. Per-app rules are better configured after the basic connection is stable; otherwise, the browser may work while the target app bypasses the proxy. Keep the default routing mode as well, and do not change predefined rules, DNS, FakeDNS, and bypass lists at the same time.

Choose a node for the first test

Return to the node list and choose a node with a clear name and complete configuration. In v2rayN, double-click the node or use the context menu to set it as the active server; the status bar at the bottom usually shows its name afterward. Some versions use a different row color, a check mark, or a marker at the start of the row. In v2rayNG, tap a node entry to make it the current configuration; the selected name appears on the main screen.

There is no need to run repeated latency tests for the first connection. A latency figure reflects only a particular probe and cannot fully represent webpage loading, DNS resolution, or sustained transfer performance. If the subscription provider gives clear guidance on node usage, follow it. Otherwise, choose any node with a normal status and complete the process. Step four will verify actual usability through real requests.

Start the core and watch the status

On desktop, Core usually starts automatically after the active node is selected and the system proxy is enabled. If your version has a separate start button, click it. In the bottom status bar or log area, look for messages showing Core startup and the creation of a local listening port. A healthy state should not repeatedly show configuration parsing failures, port conflicts, handshake failures, or process exits. An occasional retry does not necessarily mean the service is unusable; what matters is whether subsequent requests can connect.

In v2rayNG, tap the Connect button on the main screen. The first connection displays a system authorization dialog; approve it and return to the client. The button should change from disconnected to connected, and a connection indicator should appear in the system status area. If it immediately returns to disconnected, open the log and inspect the latest error instead of tapping repeatedly. Common causes include incomplete node fields, an incorrect system clock, a temporarily unreachable remote endpoint, or a network that cannot establish the required connection.

If the log says a local port is already in use, first exit other clients that may be using the same proxy port, then restart v2rayN. Do not change several ports to new values at random: the system proxy, browser manual proxy, and client listening port must agree. If the log points to certificate, SNI, or REALITY parameters, first try another node from the same subscription to narrow down the issue. Check the system environment or subscription configuration only when all nodes show the same error.

Start with a new browser connection

After enabling the proxy, close existing test tabs, open a new window, and visit a stable HTTPS page. The browser may reuse a connection established before the proxy was enabled, so refreshing an old page may not accurately reflect the current proxy state. Once the page loads normally, visit the target page that should use the current node and check that it continues to load rather than displaying only cached content.

If neither ordinary pages nor the target page can be reached, do not change protocol parameters yet. On desktop, return to v2rayN and check that the system proxy is still enabled, the active node has not changed, and Core is still running. On Android, check that v2rayNG remains connected and that the target app is not excluded by per-app rules. Then inspect the latest log to see whether requests are entering the client. No new requests in the log usually means traffic is not reaching the client; requests that consistently time out point more toward a node or network-path problem.

Separate DNS problems from node problems

A common pattern is that some sites open while others fail to resolve, or a page remains stuck on “Looking up address” for a long time. Separate DNS resolution from proxy connectivity when this happens. First switch to another node in the same subscription. If every node fails only for domain-based access while direct IP requests still receive responses in the log, inspect the client's DNS settings and system cache. During the initial setup, do not enable FakeDNS, custom remote DNS, and complex domain rules together; restore the default DNS behavior and complete the basic verification first.

Another pattern is that the browser works but a particular desktop app does not. The app may ignore system proxy settings, or it may have kept a long-lived connection from before the client started. Fully quit and reopen the target app. If it still does not work, check whether it has its own proxy settings, or learn about transparent proxy and TUN-style traffic handling. This lightweight guide does not cover complex interception setups; see the troubleshooting guide for the recommended diagnostic order.

Use a disconnect test to confirm the setup boundary

After a successful positive check, perform a brief reverse check: note the current access state, temporarily clear the system proxy or disconnect v2rayNG, open a new browser connection, and observe the change before enabling it again. This helps confirm that test traffic is actually passing through the client rather than coming from an old cache, an existing connection, or another network setting. Restore the connection when finished; there is no need to delete the subscription or nodes.