Quick Start / Four-Step Setup

Import a v2rayN Subscription
and Test Your Connection

Use an existing subscription to import nodes, choose a mode, connect, and verify access. For your first setup, get one clear traffic path working before trying custom routing or TUN.

Before you begin, make sure the client is installed and opens to its main screen. If it isn’t installed yet, choose the right installer for your device on the client downloads page, then return here. These steps assume you already have a subscription: the client reads configuration and connects to a server; installing it does not automatically provide usable server details.

Have a subscription URL from a trusted source that is still valid, and make sure your current network can load ordinary websites. Subscription URLs often contain credentials for accessing configuration, so treat them as sensitive. Don’t post them in public comments, screenshots, or online conversion tools. If you need help troubleshooting, share only redacted fields and error messages—not the full subscription URL.

This guide focuses on getting a first connection working. You don’t need to write JSON by hand or understand every protocol first. After each step, confirm that the expected result appears before moving on. That makes it easier to pinpoint whether an issue occurred during import, startup, or actual access.

Step 1: Import a Subscription and Check Your Nodes

First, identify what you have. A URL starting with https:// that retrieves multiple nodes is usually a subscription link. Content starting with vmess://, vless://, or trojan:// is usually a share link for a single node. These may use different import options; pasting a share link into a subscription URL field can cause updates to fail. If your provider supplies a complete configuration file, use an import option supported by the client instead of treating the file contents as a URL.

Add a Subscription Group in v2rayN

Open the v2rayN main window and find the subscription group menu. Open Subscription Group Settings or a similarly named management window, then click Add. Enter a recognizable name for the group and paste the full subscription URL into the address field. Check for extra spaces, line breaks, or punctuation added by a chat app at either end. Save the settings and return to the main window.

Saving the URL only tells the client where to get the subscription; it doesn’t fetch any nodes. Next, use the subscription menu to update the current group, or choose Update from the group’s right-click menu. If you don’t have a working connection yet, try updating without a proxy first. Use an update option that routes through an existing proxy only if the subscription provider specifically requires it. When the update finishes, nodes should appear in the main list. Select the new group to view them.

Add a Subscription Group in v2rayNG

Open the side menu and select Subscription Group Settings. Tap Add, enter a group name and subscription URL, then save. Return to the main screen and use the top-right menu to update the subscription. When the update completes, check that new configurations appear in the list. If you only have a share link for one node, copy the full link and use the main-screen Add menu to import it from the clipboard. You don’t need to create a subscription group for a single node.

After importing, open a node’s edit or details screen. Confirm that the server address and port aren’t empty, and that the protocol, transport, and security settings were filled in from the subscription. Don’t change fields such as SNI, transport path, or service name based on guesswork; these values generally need to match the server. If any fields are missing, first check whether the client supports the subscription format before importing it again.

You’re done with this step when nodes appear in the list and you can open their details. Seeing a node name doesn’t mean the connection works, but it does confirm that the configuration has been imported. Keep the imported settings unchanged for now; next, you’ll choose how traffic reaches the client.

Step 2: Choose a Proxy Mode and Routing Preset

“Proxy mode” often refers to two different things: how app traffic reaches the client, and which outbound route it takes once it gets there. The first involves the system proxy, per-app settings, or a virtual network interface. The second involves global proxying, direct connections, and rule-based routing. For your first setup, check these separately instead of turning on several options at once.

Start with the System Proxy on Desktop

Find the System Proxy option in the v2rayN status area at the bottom of the window or in the tray right-click menu. To route traffic from browsers and other apps that follow system settings, select Set system proxy automatically or an equivalent option. The client points the system proxy to a local listening address. Don’t enter the remote node’s server address and port in the system proxy settings; they’re different endpoints.

The system proxy doesn’t route traffic from every app. Some programs use their own network settings, while others ignore the system proxy and may still connect directly. That alone doesn’t mean something is broken. For your first test, use a browser that follows system proxy settings and temporarily disable extensions that override them. This avoids routing the same request through two separate proxy configurations.

Confirm VPN Routing on Android

v2rayNG typically routes traffic through Android’s VPN interface and prompts you to authorize the connection when you start it. Here, VPN refers to Android’s built-in way of routing traffic; you don’t need to install another tool. If the settings include options to proxy or bypass selected apps, make sure your browser isn’t excluded during initial setup. Otherwise, the client may show as connected while browser traffic bypasses it.

Once you’ve chosen how traffic enters the client, check its routing settings. Read the description before choosing a built-in preset: rule-based routing uses domains or addresses to decide whether to connect directly or through the proxy, while global proxy mode generally sends regular traffic entering the client through the proxy. To keep things simple, briefly test with a clearly described global proxy preset. After confirming the connection works, switch to a rule-based preset that suits your needs. Global proxy mode still affects only traffic that reaches the client; it won’t automatically route apps that bypass it.

For your first attempt, don’t enable TUN, import custom rules, change DNS, and add another proxy tool all at once. Multiple traffic interception layers can create routing loops, and rule changes can hide the original connection issue. For more on routing boundaries, rule order, and DNS behavior, see the system guide. For now, stick to a basic setup that’s easy to reproduce.

At this point, you should be able to answer two questions: how does the test app send traffic to the client, and which outbound route should the test request use? Once you’ve confirmed both, select an active node and connect.

Step 3: Select an Active Node and Connect

You can keep multiple nodes in your subscription list, but each test needs one clearly selected configuration. Choose the node whose settings you just checked. Don’t switch between several nodes during the same test, or it will be hard to match logs and access results. Speed or latency tests can be useful, but they don’t replace loading an actual webpage.

Activate a Node and Check Core Status on Desktop

In the v2rayN node list, select your target node and use the right-click menu to choose Set as active server or an equivalent option. Some versions let you double-click instead. Check the list indicator or status area to confirm that the active configuration has changed. The client usually reloads the core when you switch nodes. If the status still shows stopped, use the option to start or restart the service.

Open the logs and first check whether the core started successfully. If you see an error such as a port already in use, a configuration parse failure, or a missing required data file, fix the startup issue before testing the node in a browser. For a port conflict, check whether the client was started twice or another tool is using the same local listening port. Close the duplicate process and try restarting once; don’t change a series of ports at random.

Once the core is running, check that the system proxy you selected in Step 2 is still active. The core can run normally while another app overrides the system proxy, preventing the browser from sending requests to it. The system proxy should point to the local listening endpoint the client is actually using. Don’t copy a fixed port from another guide; the value may vary by version or settings.

Authorize and Start the Service on Android

On the v2rayNG main screen, select the target node to make it the active configuration, then tap Connect. The first time you connect, Android will ask for permission to establish a VPN connection. Confirm that the request comes from the client, then allow it. Check the connection status in the client and Android’s VPN indicator. A change in the Connect button’s status means the local service has started, but you still need to verify access in the next step.

If another VPN connection is already active, disconnect it before testing to prevent the two connections from replacing each other. If the client stops immediately after starting, open its logs and note the first error—not just the final “stopped” message. When using Android’s VPN interface, you don’t need to grant unrelated high-level permissions for a regular connection.

Errors after startup can occur at different stages. A configuration parse failure happens before a connection is established. A timeout, handshake failure, or name resolution error during access means the process has reached a later stage. Keep the current mode and node unchanged, then test one specific request in the next step. Use the result to decide whether to change nodes or check the configuration.

Step 4: Verify the Connection and Restore Your Usual Settings

Don’t rely only on a tray icon or Connect button to verify the connection. A more reliable check combines three things: the client is running, the request actually reaches the client, and the request uses the expected route. Open a known-working HTTPS page and reload it. If the browser is showing a cached page, open a new window or make a fresh request so you don’t mistake old content for a result from the current connection.

Match the Request Time to the Logs

Open the client logs, then visit a test page in your browser. Check whether a matching domain or connection entry appears at the same time. The level of detail depends on the log settings. If no entry appears, first check whether access logging is enabled rather than assuming the node has failed. If the logs show an outbound tag, compare it with the routing you chose in Step 2: requests that should use the proxy should go through the proxy, and requests that should connect directly should use the direct route.

If needed, use a public IP lookup page from a trusted source as an additional check, and compare results using the same app and test conditions. A lookup reflects the route used for that request only; it can’t prove that every app on your device uses the proxy. With rule-based routing, different domains may use different routes as expected. An unchanged IP on a page routed directly doesn’t mean the whole setup is inactive.

Narrow Down the Issue Based on What You See

If the client doesn’t show a browser request, check the system proxy, the browser’s own proxy settings, or Android’s per-app routing list. If the request reaches the client but the logs show a timeout connecting to the remote server, check the node address, port, current network, and subscription status. For a handshake error, check the node’s security settings and your system time. Don’t disable certificate verification as a substitute for fixing the configuration.

If only some domains fail to load, keep the same node and check whether those requests match different rules, then review any DNS-related messages. If no regular webpages load even after you exit the client, first check your local network and make sure the system proxy wasn’t left enabled. Change one setting at a time, then repeat the same test request. Changing the node, DNS, and routing together makes it difficult to tell what helped or caused the failure.

Once the basic connection works, switch from the temporary global proxy test to a rule-based preset for everyday use. Then test pages expected to connect directly and through the proxy, and check whether each uses the right route. Before adding rules or enabling TUN, read the routing and traffic interception section of the system guide. A single page loading successfully doesn’t verify every advanced setting.

Disconnect and Keep a Reproducible Setup

When you’re done on desktop, clear the system proxy in v2rayN before stopping the service or exiting the client. Otherwise, apps may keep sending requests to a local port that’s no longer open. On Android, tap Disconnect and confirm that the system VPN has stopped. If the connection later drops in the background, check whether battery management is restricting the client before changing all background permissions.

For routine maintenance, update subscriptions as needed, provided the source is trusted, and check whether the active node changed after an update. When reporting an issue, note the mode you used and the first relevant error; redact any credentials in the URL before sharing. To review the setup, start with the subscription import steps. For details on core differences, routing order, and how TUN works, see the system guide. You don’t need to rewrite the entire configuration just to make your first connection.

Next Steps

After verifying your basic connection, choose the next setting based on what you need.

Routing and TUN Setup

Understand how traffic interception, rule matching, and outbound routes work together before adding custom settings.

Read the system guide →

Choosing a Client

Compare clients by device use and core requirements so you don’t mistake a configuration issue for a reason to switch software.

Compare clients →