First setup · about 10 minutes

V2Ray Client Subscription Import and First Connection

Complete the basic setup in this order: import a subscription, choose a proxy mode, connect to a node, and verify the result. Treat the visible result of each step as the checkpoint for the next, so there is no need to reinstall the client whenever something goes wrong.

Download v2rayN Start setup

Desktop client v2rayN

Android client v2rayNG

Completion check Connection and IP results match

Step 1

Import the subscription and confirm the node list

At this stage, check only two things: whether the client can save the subscription URL and whether nodes appear after an update. Do not change routing, DNS, or TUN settings yet.

Copy the complete subscription URL first

Copy the client subscription URL from the subscription provider’s management page. Include everything from the protocol prefix through the final parameter; for example, token=xxxx in the URL is part of the subscription data. Do not copy only a truncated section from the browser address bar, and do not paste the subscription URL into a search box to test it. Treat the URL as private configuration data rather than posting it in screenshots, forums, or chat groups.

If the provider offers several entry points, choose one labeled general subscription, V2Ray subscription, or compatible with v2rayN and v2rayNG. QR codes are convenient for mobile scanning, while text URLs are easier to paste on desktop. Both formats carry the same type of configuration data, so there is no need to import both.

Create a subscription group in v2rayN

After opening v2rayN, open Subscription Group from the top menu and choose Subscription Group Settings. In the dialog, add a record, paste the complete URL into the subscription URL field, and enter an easy-to-recognize note such as the provider name or intended use. The group name helps filter a large node list but does not affect the connection. For a first setup, you can keep the default group or use the same name as the note.

Save the settings, return to the main window, open the subscription menu again, and choose “Update all subscriptions” or update the group you just added. Once the update finishes, the main window should show several server records, commonly with columns for alias, address, port, transport, and security type. You do not need to understand every column yet; simply confirm that the list is no longer empty and that subscription parsing errors are not appearing repeatedly.

Add a subscription in v2rayNG

Open the v2rayNG side menu, go to subscription settings, and tap the add button. Enter a note and paste the subscription URL, save it, return to the subscription list, select the new entry, and update it. After a successful update, return to the main screen and the nodes should appear in a list. If the list still shows older content, refresh the configuration from the main menu or leave the page and reopen the node list.

When importing by QR code on mobile, make sure the scan is recognized as a subscription URL rather than a single VMess or VLESS node. A single-node configuration adds only one server record, while a subscription URL can be updated centrally later. If you see only one node even though the service page clearly offers multiple routes, return to subscription settings and check the import type.

How to tell this step is complete

The client has saved the subscription group, a manual update completes without recurring errors, and the main node list contains at least one selectable server record.

What to check when no nodes appear after an update

Reopen subscription settings and make sure there are no spaces at either end of the URL, no parameters were lost during copying, and the newly added group is enabled. Run another manual update and note whether the client reports a failed network request, empty content, or an unrecognized format. Each points to a different cause: request failures usually involve the current network or URL reachability; empty content calls for a subscription-status check; an unrecognized format means you should confirm that you copied the client subscription URL rather than the management-page URL.

Do not keep switching proxy modes at this stage. Without an available node, changing the system proxy will not make subscription content appear. For more on subscription status, update intervals, and node fields, see FAQ and the glossary; multiple subscription groups, server filtering, and automatic update strategies are covered separately in the advanced handbook.

Step 2

Choose the system proxy and routing mode

Once the subscription has produced nodes, decide which traffic the client should handle. For a first connection, use the system proxy and rule mode to establish a clear, easy-to-troubleshoot baseline.

First, separate the two settings

Two v2rayN settings are often discussed as if they were the same. The first is the system proxy state, which determines whether apps that follow the operating system proxy send requests to v2rayN. The second is the routing mode, which determines whether requests entering the client use proxy, direct, or blocked outbound routing. The first controls whether traffic enters the client; the second controls where it goes afterward. Changing only one can produce results that differ from what you expect.

For a first setup, use the v2rayN bottom status area or tray menu to enable automatic system proxy configuration, then set routing to rule mode. Names may vary slightly between versions; rule mode commonly bypasses the local network and usual direct-connection targets while sending other requests through the active server. Check the bottom status bar afterward: both the system proxy and routing labels should reflect the current settings.

When to use global mode

Global mode sends requests entering the client through the current proxy by default. It is useful for a short comparison test: if a page does not open as expected in rule mode, switch to global mode temporarily and refresh the same page. If global mode works but rule mode does not, the issue is more likely a routing match. If both fail, return to the node, subscription, and network-connectivity checks.

Global mode does not mean every program on the system will automatically enter the client. Some programs ignore system proxy settings, some use their own network stack, and others have built-in proxy options. Check the program’s own proxy settings first; if more traffic truly needs to be captured, evaluate TUN mode instead of repeatedly switching between rule and global modes.

Choosing a mode in v2rayNG

In v2rayNG, choose rule mode under Settings or Routing settings first. Return to the main screen and tap the connection button to establish a system-level VPN tunnel; Android will display a permission prompt. Allow it on the first connection, or traffic will not enter the client even when a node is selected. This system authorization only creates the tunnel; v2rayNG still processes traffic according to its current routing rules.

If you only need to verify that the subscription and nodes work, keep the default rules. Custom domain rules, app routing, DNS paths, and FakeDNS change several variables at once and are not suitable for a first connection. Finish the four steps on this page, confirm a stable baseline connection, and then change one variable at a time in the advanced handbook.

How to tell this step is complete

v2rayN shows that the system proxy and rule mode are enabled, or v2rayNG has a rule configuration selected and permission to establish the system tunnel.

After choosing a mode, the client knows how to receive and process traffic, but it still does not know which server to use. Test the nodes next, then set a confirmed working record as the active server. This keeps a mode-setting problem separate from an unavailable-node problem.

Step 3

Test nodes and establish a connection

A node name may hint at a region, multiplier, or protocol, but it does not prove that the node works. Run a real connection test before connecting, then choose an active server from the successful results.

Use real connection latency to remove failed nodes

In the v2rayN main list, select several candidate nodes, open the context or test menu, and run “Test server real connection latency.” The test completes an actual proxy handshake using each node’s configuration, making it closer to the conditions of a browser connection than a basic network ping. Successful records show the connection time; failed records usually show a timeout, error, or empty result.

Do not simply choose the smallest number. For a first connection, stable results matter more than the lowest latency, along with whether the node’s protocol, region, and subscription label fit your needs. Test two or three candidates again to rule out temporary network jitter. If a node responds once but then repeatedly times out, switch to another node so you can finish the setup more reliably.

Basic ping, real connection latency, and download speed measure different things. Ping reflects basic network round-trip time; real connection latency includes the proxy handshake; download testing uses actual traffic and is affected by server bandwidth, route congestion, and the local network. For a first connection, a successful real connection latency test is enough—you do not need a full download test yet. See Latency Test Explained for the detailed differences.

Set a successful test result as the active server

In v2rayN, double-click a node that passed the test or choose “Set as active server” from the context menu. The node row will usually gain a color, icon, or status marker, and the bottom status area will show the current server. A single click normally only selects the record and may not change the active server, so use the status marker as confirmation.

After confirming the active server, check that the v2rayN core is running. Normally, starting the client or switching nodes produces log entries for configuration loading, core startup, and the local listener becoming available. If the logs repeatedly show startup followed by exit, stop switching nodes and inspect the message nearest the error. A port conflict, an incompatible configuration field, and a local security tool blocking the process are different problems; repeatedly updating the subscription will not locate the cause.

Select and connect to a node in v2rayNG

Return to the v2rayNG main list and tap a node record to make it the current configuration. Its selected state should change. Then tap the connection button on the main screen; when the tunnel is created for the first time, the system will ask for connection permission. Allow it and wait for the status icon to show Connected. If the client offers a test option, test the current node before enabling the tunnel.

A connection button showing that it is enabled only proves that the local tunnel exists; it does not by itself prove that the remote node works. Do not stop checking here. Keep the active node and mode unchanged, then verify them in the next step using both browser results and client logs. If no pages load after connecting, disconnect first, switch to a node that passed the real connection test, and try again instead of stacking more configuration changes.

How to tell this step is complete

At least one node has passed the real connection test and been set as the active server. The client core or system tunnel is connected, and the logs are not repeating the same error.

The shortest troubleshooting order when every test fails

Update the subscription once and confirm that the node records come from the currently enabled group. Then check that the device time and time zone are correct, since a significant clock offset can affect some protocol handshakes. Fully exit and reopen the client, then test one node only. If all tests still fail, record the stage and key message where the error appears and compare it with the troubleshooting categories in the FAQ. Do not delete all configuration at this point; keeping the subscription and logs makes it easier to identify the failing layer.

Step 4

Verify that browser traffic uses the proxy

The final verdict does not come from a button color. Check the client status, browsing results, and egress information together. Keep the node and mode unchanged during verification so the results remain comparable.

Test in a new browser window

Once connected, open a new browser window or private window and visit a familiar IP-check page. A new window reduces the effect of existing connections, caches, and extension settings. Note the displayed egress address and region, then disconnect the client and refresh the same page for comparison. If the result changes as expected and pages load reliably while connected, browser traffic is using the current proxy path.

Do not rely on a single tab that has been open for a long time. The browser may reuse an existing connection, and the page may have cached the earlier result. If the IP-check page shows no change, close the tab and open a new window, then make sure the browser is not using a separate proxy extension. An independent extension can override the system proxy and make v2rayN mode changes appear ineffective.

Use logs to confirm that requests enter the client

Keep the test page open and watch the log area in v2rayN. If refreshing the page creates a new connection entry, the request has reached the client; if the page still does not load, continue with the node handshake, DNS, and routing checks. If the logs do not change at all, check the system proxy, browser proxy settings, and whether the target program follows the system proxy before changing protocols.

The same approach applies to v2rayNG: the connection should remain enabled, the system status area should show that the tunnel is active, and refreshing the page should change the client logs or traffic counters. If browsing works after disconnecting but every request fails after connecting, traffic is probably entering the client but the current node or configuration cannot complete the outbound connection. If there is no difference before and after connecting, first check the selected node, tunnel permission, and routing mode.

Run one more real-world browsing check

After confirming the IP result, open two or three sites you normally use and check the home page, image resources, and subsequent navigation. Testing only an IP-check page does not cover every DNS and connection scenario. The first setup is complete when ordinary pages load continuously, the client logs show no recurring errors, and the egress result returns to its original state after disconnecting.

If some pages work while others fail, do not assume the entire client is broken. Temporarily switch to global mode for comparison: if global mode works, inspect routing matches and DNS settings; if it still fails, switch to a node that passed the real connection test. Restore rule mode afterward so your everyday configuration remains distinct from troubleshooting.

How to tell this step is complete

The egress result in a new browser window differs from the disconnected state, ordinary browsing works, the client logs show the corresponding requests, and the result returns after disconnecting.

Change only one variable after setup

After the basic connection passes verification, configure automatic subscription updates, node groups, routing rules, or TUN mode as needed. Change one major setting at a time, then repeat the “connect—check logs—verify egress” process. This makes it easy to identify the change that caused an issue without rebuilding the entire configuration.

Subscription groups, server filters, DNS paths, FakeDNS, TUN mode, and custom outbounds are interrelated, so changing several at once makes troubleshooting much harder. These topics are separated by chapter in the advanced configuration handbook. Check the glossary for protocol names, core relationships, and routing terms; for a specific error message, use the FAQ to troubleshoot by issue type.