v2rayN Setup Guide: From Subscription to Connection Test
Get one connection working before changing routing or DNS. Follow the steps in first-use order. If you already have the installer and a valid subscription URL, the basic checks take about 10 minutes; actual time depends on your network and how quickly the subscription responds.
Before you begin, choose an installer for your operating system from the client downloads page, install it, and open the client. Once the main window appears, you’re ready to continue; you don’t need to edit configuration files first. You’ll need to obtain a subscription URL separately. The client reads and uses configurations; installing it does not provide a connection service.
Before setting up the client, quit any other proxy or VPN apps that are handling network traffic, and note your current system proxy settings. When multiple apps change proxy, routing, or DNS settings, test results are harder to interpret. Each step below has a specific checkpoint: move on only after the current step works. That way, if something goes wrong, you won’t have to guess which of several changes caused it.
Step 1: Import a Subscription and Update the Configuration List
First, check whether you have a subscription URL or a single configuration share link. A subscription is usually a complete HTTPS URL that returns a set of configurations, which you can refresh later. A single share link may start with vmess://, vless://, or trojan:// and imports one specific configuration. Use the right import option for each; don’t paste a single share link into the subscription URL field.
v2rayN: Add a Group, Then Update the Subscription
In the main window, open “Subscription Groups” or a similarly named menu, then go to “Subscription Group Settings” and choose Add. Enter an easy-to-recognize label, such as “Daily use,” and paste the full subscription URL into the URL field. Check that there are no extra spaces, line breaks, or punctuation from a chat app at either end. Save the settings and return to the main window.
Saving the group only stores the URL. You still need to update the subscription before configurations appear in the list. Open the subscription menu and choose Update current group or Update all subscriptions. If this is your first time and you don’t have a working proxy yet, try updating without a proxy first. If your current network can’t reach the subscription URL, update through a proxy only if you already have a working proxy connection.
When the update finishes, switch to the group you just added and check that configurations appear. For now, confirm that the list isn’t empty and that you’re viewing the expected group; don’t connect yet. If the update reports success but the list is empty, check the group filter, then review the update log for an unsupported format, an empty response, or a parsing error. Being able to open a subscription URL in a browser doesn’t necessarily mean the response is in a format the client can read.
v2rayNG: Save the URL in Subscription Group Settings
On Android, open the v2rayNG menu and select “Subscription Group Settings.” Tap Add, enter a label and subscription URL, then save and return to the main screen. From the menu, run Update subscriptions. Updating usually isn’t done from the URL editing screen, so configurations not appearing immediately after you save doesn’t necessarily mean something went wrong. Wait for the update to finish, then check the list and group filter on the main screen.
For a single share link, copy the full link and use the client’s “Import from clipboard” option or a similarly named feature. In v2rayNG, this is usually under the Add button on the main screen. The imported configuration should appear in the list. You can also import from a QR code, but a cropped screenshot or obscured text can cause scanning to fail. The original link is usually easier to troubleshoot.
You should now see at least one configuration in the main list. Next, decide how apps will send traffic to the client, then select a configuration and connect.
Step 2: Choose a Proxy Mode and Routing Rules
“Proxy mode” can be confusing because it often refers to two different things: how apps connect to the client and how the client routes incoming requests. A system proxy, a manually configured local proxy address, and TUN are connection methods. Routing rules decide whether traffic goes direct or through a proxy based on its domain or IP. Keep these two layers separate to make the checks that follow more straightforward.
First Desktop Connection: Start with the System Proxy
In v2rayN, find “System Proxy” in the main window’s status bar or menu. Common options include Clear system proxy, Automatically configure system proxy, and Do not change system proxy. Locate the control now so you know where to enable and clear it. After confirming in Step 3 that the core is running, choose Automatically configure system proxy. This usually points your system proxy to the client’s local listening port; it does not select a remote configuration for you.
Browsers and some apps use the system proxy, while others may have their own network settings. So enabling the system proxy doesn’t mean every app will use the same route. For your first test, use a browser that follows the system proxy and temporarily disable any browser extension that manages its own proxy. If your workplace network requires a specific proxy, note its current settings before making changes and restore them afterward as needed.
Next, find “Routing” or “Routing settings” and choose a built-in preset that fits your everyday needs. Preset names vary by version, so read the rule descriptions rather than relying on labels like “Global” or “Bypass.” For regular use, start with a preset that sends local network traffic and commonly accessed direct destinations straight through. To check whether a specific destination is affected by routing, you can temporarily compare it with a broader proxy rule, then restore your original preset.
First Android Connection: Keep the Default Connection Method
v2rayNG typically uses the system VPN interface to handle app traffic. For your first run, keep the default connection method and avoid enabling complex per-app filters or custom routing. If per-app proxy rules are already configured, check that your test browser isn’t excluded. An excluded app won’t use the proxy just because the main screen says Connected.
The VPN icon means the system has established a local connection to the client; it doesn’t guarantee that the remote configuration works. Routing rules may still send some destinations directly, so check access in practice. The same applies on desktop: enabling the system proxy only provides the traffic entry point. It can’t fix an incorrect remote address, authentication settings, or transport configuration.
You don’t need to enable TUN or copy a full set of DNS settings from the web at this stage. Make as few changes as possible and get browser access working first; add features one at a time as needed. To learn about connection scope and routing order, see Inbound Configuration and the Routing Reference. Once you’ve chosen a mode, keep those settings and move on to the connection test.
Step 3: Select a Configuration and Connect
Return to the configuration list and choose one configuration to test. Don’t switch between several before checking the result. In v2rayN, right-click the entry and choose “Set as active server” or a similarly named option; some versions also let you double-click an entry. Check the active indicator, status bar, or log to confirm. Selecting a row doesn’t necessarily make that configuration active.
Test a Real Connection, Then Check the Logs
In the entry’s right-click menu or the test menu, look for “Test server real connection latency” or a similarly named option, and test a few entries first. A real connection test attempts to reach a test destination through the configuration, so it’s closer to actual use than a TCP test that only checks whether a port can be reached. Test results depend on the destination and timeout settings; one number can’t predict access to every site.
If a TCP test succeeds but the real connection test times out, the port may be reachable while protocol authentication, transport, the remote service, or access to the test destination still fails. Conversely, a single failed real connection test may just mean the test destination is temporarily unavailable. Keep the current configuration and use the browser check in the next step before drawing conclusions. Don’t assume the entry with the lowest latency will always work.
After setting the configuration you want to use as active, check the logs or status at the bottom of the client. Once the core is running, there usually isn’t a separate “Connect” button to find; on desktop, the connection typically involves activating a configuration, running the core, and setting the system proxy. Now switch the system proxy option you located in Step 2 to Automatically configure system proxy, then check for startup or listener errors.
If the log says a local port is already in use, check whether you opened the client twice or another proxy app is still running. Close duplicate instances first, then restart the current client instead of changing ports at random. Any proxy port configured manually in an app must match the core’s listening port. If they differ, the browser will connect to the wrong endpoint. See the inbounds section for field details.
v2rayNG: Connect and Approve the System Request
On Android, tap the configuration you want to use and confirm it’s active, then tap Connect on the main screen. The first time you connect, Android will usually show a system VPN request. Review and approve it, then wait for the main screen to show that you’re connected. If you denied the request, start the connection again in the client. Don’t mistake incomplete system approval for an invalid subscription.
If another VPN app is active on your phone, disconnect it before testing v2rayNG. Once connected, check the client’s logs or connection test for configuration parsing failures, refused connections, or authentication errors. The connection status on the Android main screen only shows that the client is running; test access in a browser to confirm that the route actually works.
If the client reports an error as soon as you start it, note whether it happened while “starting the core” or “connecting to the remote server.” For the former, check the local configuration and ports first; for the latter, check the network and subscription settings. Before sharing logs, redact addresses, user IDs, and subscription details. For further help, see Connection Troubleshooting. If there are no obvious startup errors, continue to the final step.
Step 4: Verify That the Proxy Is Working
Open a new browser window and visit a trusted HTTPS site you know. Don’t just refresh an old page that’s already fully loaded; caching can make it appear to work without sending a new request. First test a destination that should go through the proxy, then a commonly used destination that should connect directly under your current rules. Access to both is a better indicator of everyday readiness.
Check the Result Alongside Routing and Logs
If the browser says it can’t connect to the proxy server, start by checking the local setup: is the client still running, is anything listening on the port configured for the system proxy, and does the browser have a separate manual proxy setting? This error often occurs before the request reaches a remote server, so repeatedly updating the subscription usually won’t help. If the page connects but keeps loading, check the logs for remote connection, DNS resolution, and destination server responses.
If the client’s real connection test succeeds but the browser still can’t access a site, first check whether the browser follows the system proxy, then check whether the current destination is routed directly by your rules. On Android, check whether a per-app rule excludes the browser. Don’t change routing, DNS, and protocol settings all at once. Change one thing at a time and repeat the same test so you can compare results.
Client logs may show the destination domain and selected outbound, which can help you understand the request path. The details depend on the log level, though, and a lack of request details doesn’t necessarily mean the request bypassed the client. If needed, temporarily increase log verbosity, then restore the usual level when you’re done to avoid recording excessive browsing details. See the policy configuration reference for logging and policy fields.
Checking your public IP can be a useful additional test, but it isn’t conclusive on its own. The IP lookup site may be routed directly or show cached results, and the exit IP for one destination doesn’t tell you whether every app uses the same route. Verify a specific app and destination, not just the connection icon on the main screen. If only one site has a problem, troubleshoot that destination rather than assuming the entire setup is broken.
When You’re Done: Restore Normal Network Access
At the end of a desktop test, clear the system proxy in the client before quitting. If your network requires a specific proxy, restore the settings you noted earlier. This prevents your browser from trying to connect to a local port that stopped listening when the client closed. If no sites open after you quit, check for leftover system proxy settings first, then check the network. There’s no need to reinstall right away.
On Android, tap Disconnect and confirm that the client status and system VPN icon change, then test regular network access. Reconnect once to make sure you can use the client again without importing the subscription. The URL stays saved in its group, so you only need to update it when necessary. Don’t delete and re-add the group every time unless you specifically need to clear or reconfigure it.
Make a note of the current group, active configuration, connection method, and routing preset. If a problem comes up later, compare against these settings you’ve already tested. After changing networks, updating the subscription, or adjusting rules, run a quick access check again rather than relying on results from an earlier test.