v2rayN Subscription Setup and Proxy Settings
Start with a valid subscription URL, then import it, choose a mode, connect, and verify the connection. Get one connection working before trying TUN, advanced routing, or automatic updates.
Before you begin, choose the right client for your device from the download center, install it, and open the main screen. If you're using the desktop archive, extract all of its contents to a fixed directory you can read and write to. Don't launch the app from the archive preview. During initial setup, close other proxy tools that may be routing traffic, and keep your regular internet connection available to avoid multiple apps changing system settings at once.
This guide assumes you already have a valid subscription from a trusted provider. The client reads configurations and establishes connections; it doesn't come with a working service. You can't skip straight to connecting without a subscription or manually entered configuration details. Subscription URLs may contain account identifiers, so don't post them in public forums or upload the full URL to unfamiliar websites when troubleshooting.
Step 1: Import a subscription and load your configuration list
Use the copy option on your subscription provider's account page to get the complete subscription URL. A subscription URL is a web address the client requests; a single configuration link describes just one connection, and the two serve different purposes. Don't paste the account page URL, its title, or a block of text with instructions into the subscription field. Check the beginning and end of the copied URL in a temporary local text field to make sure it has no extra spaces, line breaks, or missing characters, then add it to the client.
Import a subscription in v2rayN
In the v2rayN main screen, open the Subscription Group menu, choose Subscription Group Settings, and add a group. Give it a recognizable name, such as “Everyday use,” then paste the subscription URL into the address field, make sure updates are enabled for the group, and save. This only adds the subscription URL; it's normal for no configuration entries to appear yet. Run an update to fetch them.
Return to the main screen and choose the relevant update command from the Subscription Group menu. If your current network can access the subscription URL directly, try “Update subscription (without proxy)” first. Use an update through a proxy only if the URL requires an existing working connection. If this is a fresh install with no working configurations, choosing the proxy option won't fix a failed download. After the update, select the group you added and check that the list contains configuration names and protocol types, not just the group title.
If you have a single configuration link, use an option such as “Import from clipboard” rather than saving it as a subscription URL. Importing a single configuration usually doesn't create a subscription that can be refreshed, and server-side changes may not sync automatically. If a subscription group with the same name already exists, check and edit its URL rather than adding duplicates that make it hard to tell which entries came from which update.
Import a subscription in v2rayNG
From the v2rayNG main screen, open the menu, go to Subscription Group Settings, tap the add option, enter a name, paste the subscription URL, and save. Back on the main screen, open the menu and choose Update subscription or the equivalent update command. Keep the app in the foreground while it updates and wait for the result. On success, configuration entries should appear in the main list or under the relevant group. Saving the URL doesn't mean the server configurations have been fetched.
If v2rayNG offers an option to update through a proxy, make the same choice as you would on desktop: use it if an existing working connection is needed to reach the URL. For a first-time setup, check whether your regular network can fetch the subscription. If the list is empty, check that you've selected the right group and cleared any search filters, then confirm the subscription hasn't expired and the URL is complete. Don't update repeatedly in quick succession or delete all existing configurations without a backup.
At this stage, you should have at least one complete configuration entry from a known source in the client list. Don't worry yet about whether every entry connects, and don't rush to sort or test them all. Keep one configuration ready to use, then move on to choosing how the app's traffic will reach the client.
02 / Proxy entry points and routing
Step 2: Understand the difference between system proxy and routing mode
These settings do different jobs. The system proxy tells apps that follow system settings where to send requests. Routing rules decide whether requests that reach the core use the proxy, connect directly, or use another outbound route. Choosing a routing preset doesn't mean every app is connected to the client, and enabling the system proxy doesn't mean every request will use a remote exit.
v2rayN: Start with the system proxy
For your first setup, start with the system proxy and leave TUN off. Find the system proxy option in the main screen or tray menu and choose “Set system proxy automatically.” “Clear system proxy” removes the proxy settings, while “Do not change system proxy” leaves the current settings as they are; the latter isn't suitable for confirming a fresh automatic setup. Some apps only read system proxy settings at launch, so fully close and reopen them after making changes.
Next, check the routing settings or preset. For everyday use, you can start with one of the client's common rules, but check what each rule actually does because presets can vary by version. Don't rely on the preset name alone. If troubleshooting with a temporary rule that sends all connected requests through the proxy, note your original preset and restore it when you're done. “All” applies only to requests that reach the client; it doesn't mean every program on your system is intercepted.
v2rayNG: Check which apps are included
On Android, traffic usually enters the client through the system VPN interface, so you don't need to follow the desktop steps for automatically configuring a system proxy. In settings, check whether per-app proxy or a similar feature is enabled. If only some apps are selected, an unselected browser may bypass the client. If the setting instead bypasses selected apps, it works the other way around. For your first test, use a default scope that's easy to understand, and keep in mind that work profiles and other separate environments may have additional restrictions.
Then check the routing settings and choose rules that suit your needs. If a site's traffic matches a direct-connection rule, it should keep using its regular route; don't use that site's result alone to decide whether the connection works. Avoid changing DNS, transport settings, and multiple rule sets at once, or you won't know which change affected the result. First establish a repeatable baseline, then make changes one at a time as needed.
Save TUN for after the basic connection works
TUN uses a virtual network interface to route traffic. Its coverage differs from a regular system proxy, and it also requires appropriate permissions and routing and DNS settings. You don't need to enable it just to get a browser connected for the first time. If an app doesn't read system proxy settings, complete this guide's verification first, then consult the technical documentation for the right way to route its traffic. This helps avoid mistaking an entry-point issue for a protocol issue.
Step 3: Select a configuration and connect
Once subscription entries have appeared and you've chosen a proxy entry point, start the connection. A name in the configuration list is just a label; it doesn't mean the connection will work or that its transport settings match the current core. For your first attempt, choose an entry your subscription provider says is usable. Don't manually change the port, user ID, transport type, or security layer. These fields need to match as a set, and changing just one can break a working configuration.
v2rayN: Set an active server and check that the core is running
Select the configuration you want to use in the list, then choose “Set as active server” from the right-click menu or use the equivalent option. Some versions also let you double-click an entry. You should then see an active status marker or a change in the current server details on the main screen. A row highlighted as selected doesn't necessarily mean it became the active server, so check the status shown by the client.
Make sure the core is running, then confirm that the system proxy is still set to “Set system proxy automatically.” Some versions reload the core when you switch active configurations, so there may not be a separate connect button. Open the logs and check for configuration loading errors or listener failures. A running core only means the local service is ready. Many protocols connect to the remote server only when you make a real request, so this alone doesn't confirm the server is reachable.
If the logs say a local listening port is already in use, close another instance of the client or stop the program using that port. Don't repeatedly restart every network component. If the protocol or security layer isn't supported, check that the core matches the subscription requirements. For example, REALITY is a security layer; changing the protocol name to VLESS won't add support for it. The client, core, and server settings all need to match. See the protocol and core technical reference for details.
v2rayNG: Select a configuration and approve the system request
On Android, select the configuration you want in the main list and make sure the active marker is on the right entry. Then tap the start button on the main screen. The first time you run it, Android usually displays a system VPN connection request. Read the prompt and approve it so the client can create a system network interface. This uses the traffic-routing capability provided by Android; it doesn't mean your subscription provider supplies a separate VPN protocol.
After starting, check the button, the service notification, and the system connection indicator. If you denied the request, return to the main screen, start the connection again, and approve it. If another app is already using the device's VPN interface, stop that connection first. A notification icon alone doesn't prove the remote connection works; verify it with an actual request in the next step.
If the client stops immediately after starting, check its logs for the first error, not just the final shutdown message. Note the error type and the steps that triggered it. Before sharing a screenshot, hide the subscription URL, server address, and user ID. Permission, configuration compatibility, and remote timeouts require different fixes. For further help, visit Troubleshooting. Don't change every setting at once without knowing what went wrong.
Step 4: Test a request and confirm the proxy is working
For the test, use a browser that's affected by the current settings. On desktop, choose one that follows the system proxy and doesn't have an extension overriding it. If the browser has its own network settings, make sure it's set to use the system proxy. On Android, confirm that the browser is included in the proxy app scope you set in the previous step. Reopen the browser and visit a known, reachable HTTPS page instead of simply refreshing a fully cached tab.
Compare the page result with the client logs
A page loading is a useful first result, but you should also confirm that the request followed the expected route. Open the client logs and look for an entry matching the time of your visit and the target domain. If the current log level doesn't show request details, temporarily raise it enough to see routing results, then restore it afterward. Log formats vary between cores, so don't look for one exact message. Check for handshake or DNS failures and unexpected outbound selection.
If the current routing rules send this site directly, the page loading successfully doesn't prove the remote proxy is working. Test a destination that your rules send through the proxy, or note your original settings and temporarily choose a routing preset that's easier to verify. Don't permanently disable direct-connection rules just to get a particular test result. A built-in latency test isn't a complete check either: its requests may take a different route from your browser traffic.
If needed, compare the same trusted exit-IP lookup before and after connecting, but don't treat an IP change as the only test. Routing rules may send the lookup directly, and browser connection reuse can affect what you see. Conversely, a changed exit IP doesn't prove that every app is connected. Check separately whether the app reaches the client, which route the request takes, and whether the remote server responds. That's more useful than repeatedly clicking Connect.
If verification fails, change one thing at a time
If there are no relevant log entries, first check the system proxy, the browser's own settings, or the Android app scope. If a request appears in the logs but the remote connection fails, check the selected configuration, subscription status, and local device time. If only certain domains fail to resolve, keep other settings unchanged and investigate DNS. You can compare with another known working configuration, but repeat the same request after each change so the results are comparable.
If regular websites work but one app doesn't, first check whether that app supports the system proxy, uses its own connection method, or runs in a separate app environment. Don't assume the entire subscription is broken. For details on TUN, DNS routing, or protocol fields, see the technical reference. For specific errors or subscription update issues, visit Troubleshooting. For this guide, you only need to confirm that one working configuration handles the requests you expect it to.
When you're done, stop traffic interception before closing the client
When you're done with v2rayN on desktop, choose “Clear system proxy” first and confirm your regular network works again before exiting the client. Closing the window may leave the app running in the system tray. If you end the process first and leave the system proxy pointing at a local port, your browser may keep trying to connect to a service that's no longer running. If you can't get online after closing the client, check for leftover system proxy settings rather than deleting network settings.
On Android, tap Stop on the v2rayNG main screen and confirm that the service notification and system connection indicator have cleared. If the connection only drops after the screen has been locked for a while, check Android's background activity and battery management settings; there's no need to change every battery-saving option during initial setup. Note the working configuration name, routing preset, and traffic entry method. After the next subscription update, make sure the active configuration is still there and repeat a real-world connection test.