v2rayN Setup Guide

Step 01 / Get Configurations from a URL

Import a Subscription and Update Configurations

Open your subscription provider’s dashboard and copy the full subscription URL for client import. It’s usually a long URL and may contain a personal access token. It’s different from the dashboard URL, your account sign-in URL, and an individual server share link. Copy it without leading or trailing spaces, quotes, or line breaks. Never post a token-bearing URL in a public forum.

Add a Subscription Group in v2rayN

Return to the v2rayN main window and open the menu for Subscription Groups. Open the group manager and choose Add Subscription. Give the group a recognizable name, such as “Daily subscription,” then paste the full URL into the subscription address field. Leave other options at their defaults for now. Check that the URL is complete, then save. If your version uses Subscription Group Settings as the menu entry, use it to create a group with the URL.

Saving the URL only records where to fetch configurations; it doesn’t import any servers yet. Return to the main window and select Update All Subscriptions. Wait for the result message and server list to refresh. Configurations should appear under the group before you can select a server. There’s no need to edit individual protocol settings yet—keep the original subscription configurations to reduce variables during your first connection.

Where to Find Subscriptions in v2rayNG

In v2rayNG, open Subscription Group Settings from the menu. Use Add to enter a name and subscription URL, save, and return to the configuration list. Then select Update Subscription from the menu. If your provider gave you a single share link, use the import-from-clipboard option instead; don’t enter an individual link as a subscription URL that you expect to update. Both methods can add configurations to the list, but they update differently.

If the update fails, first use a regular browser to check that your current network can access websites. Then check whether the URL has expired and your service account is still active. Before you have a working proxy, subscription updates that rely on an existing proxy may not work; if available, choose the client’s option to update without a proxy. If it still fails, stop here and see subscription troubleshooting. Changing proxy modes won’t help if there are no valid configurations in the list.

You’re ready to continue when the subscription group contains selectable configurations and the update completes without persistent errors. Next, choose how your apps’ traffic will reach the client.

Step 02 / Choose How Traffic Enters

Choose a Proxy Mode and Routing Rules

In v2rayN, System Proxy tells apps that follow your system settings which local proxy to use. Routing determines which outbound route the core uses after a request reaches it. These are separate settings. For your first setup, use the system proxy with the default routing rules. Confirm that your browser works before trying TUN or custom routing. Change one network setting at a time.

On Desktop, Start with Auto Configure System Proxy

Find the system proxy option at the bottom of the main window or in the tray menu, then choose Auto Configure System Proxy. Apps that follow your system proxy settings will use the local proxy provided by the client. You still need an active server and a running core; changing this option alone doesn’t establish a remote connection.

Know the difference between the other common options. Clear System Proxy removes the system proxy settings configured by the client. Do Not Change System Proxy leaves the current system settings as they are; it doesn’t clear them or guarantee that apps are using a proxy. If you choose the latter during initial setup, an old proxy address may remain, so it’s not a good starting point for this guide.

Keep the default routing rules, or choose a commonly used preset provided by the client. Don’t delete rules such as direct access to your local network just to test the connection. If a website still connects directly, check which rule it matches. See the glossary for the difference between global proxy and rule-based routing. For now, choose a clear setting that you can restore.

On Android, Keep the Default VPN Settings

v2rayNG normally routes traffic through Android’s VPN interface. Keep the default settings for now, and check whether another VPN app is connected. If one is, disconnect it first to prevent the apps from replacing each other’s connection. If you’ve configured per-app proxying, make sure your test browser is included; otherwise, the client may show as connected while the browser continues to use its usual network path.

You’re ready to continue when the desktop client is set to Auto Configure System Proxy with a routing preset, or Android is using its standard VPN connection and your test app is included. Next, select a server and connect.

Step 03 / Start the Active Server

Select a Server and Connect

Return to the server list and select a configuration from the subscription group you just imported. For your first test, choose one your provider has marked as available and that works with the client’s current core. A location in the name is just a label; it doesn’t guarantee that the server is available. There’s no need to test every configuration—start by getting one connection working.

On Desktop, Check the Active Server and Core Log

In v2rayN, select the configuration and choose Set as Active Server from the right-click menu, or use the equivalent option in your version. Some versions let you double-click a configuration to select it. Check the active indicator rather than assuming a highlighted row has been activated. Then check the current server name in the status area to confirm it matches your selection.

Open the client’s log and check that the core starts normally. Log messages vary by version, so don’t look for one exact success message. Check for repeated startup failures, port conflicts, or configuration parsing errors. If an error appears, note its exact wording instead of repeatedly restarting the client or changing server settings at random. A successful core startup means the local process is ready; make a real webpage request in the next step to test remote access.

If the selected configuration reports an unsupported protocol or field, check whether the client needs an update and which core the configuration requires. Don’t keep switching cores based on the configuration name, and don’t guess at missing parameters. Subscription configurations should be maintained by the provider. For compatibility guidance, see the client and core notes in the FAQ.

On Android, Tap Connect and Approve the Request

Select the configuration in v2rayNG and confirm it’s marked as selected, then tap Connect. The first time you connect, Android displays a VPN connection request. Check that v2rayNG is the app making the request, then allow it. Return to the client and confirm that its status has changed from disconnected.

The Android VPN indicator means traffic has been routed into the VPN interface; it doesn’t guarantee that the remote server is reachable. If the connection drops immediately, check the client log and make sure another VPN app isn’t taking over. Don’t change battery settings, DNS, and routing all at once. Use the current error to identify one issue at a time. Once the connection stays up, test it in a browser.

You’re ready to test when the desktop client shows the intended active server and the core is running, or the Android connection stays up. There’s no need to wait for a particular “success” number before making a real request.

Step 04 / Test with a Real Request

Test the Connection and Exit Cleanly

Open a browser that follows your system proxy settings. Visit a site that normally loads reliably, then visit the site you need to access through the proxy. Use a new tab and refresh to avoid mistaking cached content for a new request. Loading one page confirms only that request worked; it doesn’t prove that every app is using the proxy. Test the apps you actually plan to use.

Use Connection Logs to Check the Request Path

Watch the client’s log or connection records as the page loads. If the current log level records access requests, you should see an entry close to the time of your request. With rule-based routing, some requests going direct is normal. Check the route used by the target rather than expecting every entry to show a proxy. Logs vary by core and settings, so an empty log alone doesn’t prove the connection failed.

On desktop, you can make a controlled comparison. Note the current settings, select Clear System Proxy, and request the same site in a new tab. Then restore Auto Configure System Proxy and repeat the test. Compare the page results with the client’s connection records. If the site is accessible without a proxy, it’s normal for both tests to succeed—that doesn’t mean the settings had no effect. Browser extensions that manage proxies can interfere, so note their settings and temporarily pause their proxy features first.

On Android, keep the same network and refresh the target page once while connected and once after disconnecting. Compare the results with the client’s connection records. If per-app proxying is enabled, test an app that’s included. If some apps work and others don’t, check which apps are covered and review their own settings before replacing all your subscription configurations.

Choose Your Next Step Based on What You See

If the browser works but command-line tools behave the same, check whether they read the system proxy settings. They may use their own proxy options or environment variables. If the browser can’t access the site either, check the active server, system proxy mode, and core log, then compare with another known-working configuration. If only domain lookups fail while other requests work, investigate DNS. Avoid changing several settings before you’ve identified the issue.

You’ve completed the basic setup when your target app can make a real request and you understand how its traffic reaches the client and which route it takes. Note the subscription group, active configuration, and proxy mode so you can reproduce the setup later. Don’t record or share your full subscription token. Before sharing logs for help, redact personal credentials and other sensitive details from URLs.

Next time, open the client, confirm the active configuration, and enable the connection mode you need. If your provider announces a configuration change, return to step one and update the subscription; there’s no need to create the same group again. Once everything is working reliably, learn about routing or TUN one setting at a time. Retest after each change and keep a known-working setup to fall back on.

After the Initial Setup

For menu terminology, see the glossary. For common questions about using the client, see the FAQ. If you can reproduce a node timeout, subscription update failure, system proxy issue, or DNS problem, open the Troubleshooting guide and follow the steps for that symptom. That’s all you need for the basic setup—there’s no need to enable every advanced option.