v2rayN Setup Guide
Import a Subscription and Verify Your Connection

Import a Subscription and Update the Group

Copy the complete subscription URL first. Use the copy button on your service's management page rather than piecing it together from a chat preview, screenshot, or truncated browser text. A subscription URL usually contains access credentials and is not the same as a link to a single node: it retrieves and updates a group of nodes, while a single-node link typically imports just one configuration. If you have a QR code or single-node link, use the corresponding import option instead of pasting it into the subscription URL field.

Add a Subscription Group

Open v2rayN, go to “Subscription Group” > “Subscription Group Settings,” and add a group. Enter a recognizable name, such as “Daily,” in “Alias,” then paste the subscription URL into “Optional address Url.” Check for extra spaces, line breaks, or quotation marks, and make sure the group is enabled. For your first setup, leave “Filter (regex)” blank and keep the default User-Agent to avoid filtering out nodes or changing the response format.

“Auto-update interval (minutes)” controls scheduled subscription updates; it does not establish the current connection. You can leave it alone for the initial setup and update manually after saving to check the result. If you want scheduled updates, choose an interval that suits your usage and check whether zero means disabled in your version. Don't enter a node port or connection timeout here; neither setting controls the update schedule.

Update the Subscription and Check the Results

After saving the group, return to the main window and choose “Update all subscriptions (without proxy)” from the “Subscription Group” menu. The client will fetch the subscription URL and add the returned configurations to the server list. When it's done, switch to the group you just created and check that nodes appear. Then review the log for request or parsing errors. Saving a URL does not mean the subscription has been fetched successfully.

If the URL is only accessible through an existing proxy and you already have a working connection, try “Update all subscriptions (through proxy).” If this is your first setup and you don't have a working proxy, repeatedly trying the through-proxy option usually won't help. Check that the URL is still valid, that your current network can reach the service management page, and that the client supports the subscription's response format. Don't disable certificate verification just to get one update to work.

If the update reports success but the list is empty, clear any search terms, check that you selected the right group, and look for filter rules. If the log shows an access, expiration, or parsing error, copy the URL again from the service management page. Updating a subscription can replace existing entries, so save a copy before editing subscription nodes manually; otherwise, your changes may be overwritten by the next update.

In v2rayNG, open “Subscription group settings,” add a group, enter a remark and URL, and save. Return to the main screen and update the subscription. Continue once configurations appear in the list. If the log contains the full subscription URL, hide its access credentials before sharing a troubleshooting screenshot. The example https://example.com/sub?token=xxxx only illustrates the format; it cannot be used to retrieve nodes.

Choose a System Proxy and Routing Mode

Once nodes appear in the subscription list, decide how app traffic enters the client, then how traffic is routed after it enters. These are separate questions: the system proxy or TUN handles the entry point, while routing rules choose between direct and proxy outbound connections. “Global proxy” usually refers to routing; it doesn't mean every app's traffic is being captured. Switching to global routing may not change an app's connection path if that app doesn't use the system proxy.

Use the System Proxy for Your First Connection

In v2rayN, choose “Set system proxy automatically” from the system proxy menu. This option may be at the bottom of the main window or in the tray icon menu. Apps that follow the system proxy settings will then send requests to the client's local listening port. For your first test, use a browser that follows the system proxy and disable extensions that might override proxy settings.

Leave TUN off for now, and don't run another proxy client at the same time. If multiple programs keep changing the system proxy, its address and port may point to a different process. If you previously set a manual proxy, note its original values, then confirm the current settings match v2rayN's listening address. Don't copy a fixed port from another guide; use the value shown in the current client settings and log.

Keep a Clear Routing Preset

Next, choose an existing preset in the routing settings. For everyday browsing that distinguishes direct from proxy traffic, use a client preset that bypasses the relevant address ranges. To check whether a rule is sending a particular destination direct, temporarily switch to a global proxy preset and test again. Preset names vary by version, so check the rules and default outbound instead of relying on the label. Note your original setting and restore the mode you want for everyday use when you're done.

TUN is useful when you need to route traffic from more apps, but it also involves permissions, a virtual network adapter, DNS, and routing. First confirm the node works with the system proxy, then enable TUN separately by following the TUN mode setup guide. Changing the system proxy, TUN, and custom DNS all at once makes it difficult to identify the cause of a connection failure.

In v2rayNG, the usual way to connect is to start the system VPN service, not to look for “Set system proxy automatically” as you would on desktop. The first time you tap Connect, Android asks you to approve the connection; approve it to start the service. Routing settings still control traffic splitting. If per-app proxying is enabled, make sure the browser you're testing is included. Seeing the VPN status only confirms that the service started; it doesn't mean the remote node can complete requests.

Test Nodes and Set an Active Server

Now that you've chosen the traffic entry point and routing preset, pick a candidate node from the subscription. Test a few entries rather than repeatedly testing the entire list. Node names may describe a region, route, or purpose chosen by the subscription provider; the name alone doesn't tell you whether a node is fast or available. For the first connection, use a standard node recommended by the service with all required settings in place. Skip configurations that require extra conditions for now.

TCPing vs. Real Connection Latency

Select a candidate in the server list, open the context menu, and run the option for testing real connection latency. It uses the configuration to make an actual request to a test destination, so it more closely reflects real use than simply probing an address and port. The result still depends on the configured test URL and timeout: a temporarily unreachable destination can cause a failure. Treat a successful test as one way to identify a candidate; investigate the logs if it fails.

TCPing mainly checks whether a connection can be made to a destination address and port. It doesn't fully test proxy protocol authentication, encryption negotiation, or the final web request. A TCPing result doesn't rule out issues with the user ID, transport settings, or server configuration that prevent a real connection. Don't confuse the two tests or focus only on a low latency result while ignoring repeated failures or intermittent timeouts.

Activate the Node and Check the Logs

Once you have a node that passes the test, choose “Set as active server” from its context menu; some v2rayN versions also let you double-click an entry. Check the selected or active marker in the list and the server information in the status bar. Activating a node applies its configuration and may restart the core. Wait for the log output to settle, then confirm the system proxy is still set as expected. A highlighted row alone doesn't mean the node is active.

If the log repeatedly shows the core exiting, a port conflict, or a configuration parsing error, stop switching nodes and fix the local startup issue first. If the core isn't listening, the browser will report a proxy connection failure even if the subscribed node itself works. See FAQs and troubleshooting for help with port conflicts, startup permissions, and configuration errors. For platform-specific steps, see the in-depth guides.

In v2rayNG, tap a configuration to select it, then tap Connect. If you're already connected, reapply the configuration as prompted; you may need to stop and restart the connection. Check the log for recurring errors, then use the client's connection test. This only confirms that you've selected a configuration and started the connection; the next step is to verify that an app's traffic actually uses it.

Verify the Connection and Check Your Exit IP

Finish by testing a real request through the full connection path. Don't rely on the Connect button color, tray icon, or VPN status alone. A reliable check answers three questions: Is the core running? Is the test app sending requests to the client? Is the request using the expected proxy outbound? A real connection latency test covers only part of this, so also check a web request and your exit IP.

Test a Real Web Request First

Open your test browser in a new tab and visit a destination that should use the proxy under your current routing rules. Don't rely on refreshing a cached page or seeing the homepage load; try another page on the same site and check that requests continue to succeed. Also check the client log for related activity. How much detail appears depends on the log level, so the absence of individual request entries doesn't necessarily mean failure, but recurring errors need attention.

If the client test succeeds but the browser can't load pages, check whether the browser uses the system proxy, whether an extension overrides it, and whether routing sends the destination to the expected outbound. If only one site fails, test another before concluding that the entire node is unavailable. The destination site, DNS results, or routing rules could be causing a localized issue.

Check Your Exit IP Using the Same Routing Mode

Next, use a trusted IP lookup page to check the exit address for the current request and compare it with the expected node exit. The lookup page is also subject to routing rules: if it goes direct, seeing your local network's exit IP is normal and doesn't mean the proxy is broken. To avoid ambiguity, temporarily switch to a global proxy preset so the browser's lookup request clearly uses the proxy, then reload the page. Restore your original routing preset when you're done.

The exit address may not match the server address in the node configuration. The server may use a relay or a separate exit, and geolocation databases can be inaccurate, so don't compare region names alone. Consider the service documentation, changes in the address you see, and the actual browsing results together. A complete first-connection check includes a successful subscription import, a successful real connection latency test, working web requests, and an expected exit IP.

Compare the Connection With the Proxy Off

When you're done testing on desktop, choose “Clear system proxy” and check whether requests from a browser that follows the system proxy return to their previous path. This doesn't stop the core and may not affect apps with their own proxy settings. On Android, stop the v2rayNG connection and reopen the lookup page to compare. If the destination is accessible without a proxy, it's normal for the page to keep loading after you disconnect. Check whether the route and exit IP change as expected.

Once you've confirmed the result, restore your preferred proxy state and routing preset, and note the working subscription group, active node, and connection method. If a problem comes up later, check things in the same order: subscription updates, then the core and node test, then the app entry point and routing. Change one setting at a time and test again; that's usually easier than reinstalling the client, changing DNS, and switching every mode at once.