v2rayN Subscription Setup and Connection Guide
Import a subscription → choose a proxy mode → connect to a node → verify the connection. Get the basics working in about 10 minutes, then adjust routing and TUN to suit your apps.
Before you start, choose an installer for your device from the client downloads page, then install and open the client. You will also need a valid subscription URL from your service provider or a complete node share link. Installing the client does not create a remote server or provide usable nodes automatically. If you don't have a configuration yet, arrange a source for one before continuing.
During initial setup, keep just one proxy client in control of your network. Temporarily disable other proxy switches or VPN connections. Check that your device's date, time, and time zone are correct, then open a familiar website without a proxy to establish a baseline. If something goes wrong later, you can tell whether the issue was already present or caused by a setting you changed.
Step 1: Import a Subscription and Check the Node Source
A subscription URL fetches node configurations. It is not a regular website homepage or a link to your account dashboard. Use the client subscription URL provided by your service, preferably by clicking its copy button to avoid missing trailing parameters or adding spaces. Subscription URLs often contain account information, so don't share the full address in public screenshots, group chats, or bug reports.
Add a Subscription Group in v2rayN
Open the main window and go to Subscription Group Settings under the Subscription Group menu. Add a group, enter a recognizable label, and paste the subscription URL into the address field. Leave other options at their defaults for now. Save and close the settings window, then open the Subscription Group menu and update the group you just added. If you don't have a working proxy connection, first try the option to update without a proxy. If the menu offers different update routes, choose the appropriate one instead of clicking every option in succession.
After the update, nodes from that group should appear in the main list. Check that the group filter is set to the one you just added, and confirm that node labels, protocols, and server addresses are shown. An “Update complete” message with an empty list doesn't necessarily mean you have usable configurations: a filter may be hiding the nodes, or the response may not contain entries supported by the client. Clear the list filter first, then check the update log.
Add a Subscription in v2rayNG
Open Subscription Group Settings from the side or overflow menu, tap Add, enter a label and subscription URL, and save. Return to the main screen, update subscriptions from the overflow menu, then check the group. Saving only stores the URL; you still need to update the subscription to fetch nodes. If no nodes appear after saving, make sure you haven't skipped that step before reinstalling the app.
For a single-node link starting with vmess://, vless://, or trojan://, use an option such as Import from clipboard instead of saving it as a subscription URL. A share link describes one node; a subscription URL returns a set of configurations that can be updated. Both can appear in the node list, but only a subscription group can fetch changes from the original URL. See the glossary for related terms.
This step is complete when nodes appear in the list and you can identify their group. If the update fails, check whether the subscription has expired, whether the URL was copied in full, and whether your current network can reach the subscription service. Changing server ports at random won't fix a subscription issue. See troubleshooting for help interpreting logs. Once the list looks right, decide which traffic should enter the client before connecting to a node.
Step 2: Choose a Proxy Mode and Understand Traffic Handling
Proxy settings have two layers. The first controls how traffic reaches the client, usually through a system proxy or TUN. The second controls what happens after traffic enters the core: routing rules send it through a proxy, direct it, or block it. If you see “Global” in the interface, check which menu it belongs to. Global routing usually sends requests that have already reached the core through a proxy outbound; it does not guarantee that every app on your device is being captured.
Start with the System Proxy on Desktop
For your first setup, leave TUN off. In the v2rayN main window or tray menu, find System Proxy and look for an option such as Set system proxy automatically. This points the operating system's proxy address to the client's local listening port, making it a good first choice for testing browsers and other apps that follow system proxy settings. To check the port manually, open the settings for inbound connections or local listeners and use the HTTP, SOCKS, or mixed port shown there. Don't copy a port number from another guide.
If the core isn't running yet, turning on the system proxy may temporarily stop your browser from loading pages. You don't need to test at this stage: choose a mode and continue to the next step, or locate the toggle and enable it once the node is running. Don't choose an option that only keeps an old proxy configuration as a substitute for initial setup. If you previously set a system proxy manually, note its original value so you can restore it later.
| Setting | What It Does | For First-Time Setup |
|---|---|---|
| System proxy | Provides a local proxy endpoint for apps that read system proxy settings. | Use it for a basic browser test. |
| Routing rules | Choose the outbound route for requests that have entered the core. | Start with a standard routing preset. |
| TUN | Uses a virtual network interface to capture traffic covered by the configuration. | Consider it after the basic connection works. |
Choose a Route, Then Check How Android Works
In routing settings, start with a standard preset, such as bypassing LAN and mainland China addresses. Preset names vary by version; read what each rule does instead of stacking unfamiliar custom rules. If a test destination is routed directly, your browser's apparent exit location won't change, but that doesn't mean the system proxy failed. To rule out routing as a factor, temporarily switch to global proxy routing for comparison, then restore your original rules.
For a first run in v2rayNG, check that the mode is set to VPN in Settings, then approve the system prompt when connecting. This uses Android's VPN interface to capture traffic; it does not start a separate remote VPN service. If you've configured per-app proxying before, make sure the test browser isn't excluded. For your first test, keep the default app scope and avoid adding app lists or custom routing rules.
TUN can handle apps that ignore system proxy settings, but may require permissions, a virtual interface, and DNS configuration. It's not essential for your first connection. Start with the system proxy path to make issues easier to isolate. For more on domain matching, direct connections, and DNS, see routing and DNS terms. Next, choose a working node and start the core.
Step 3: Choose a Working Node and Connect
Return to the node list and test a few nodes from a known source rather than checking every entry at once. In v2rayN, right-click a node and look for Real Connection Test or a similarly named option. It sends a request to a test destination through the node, so it more closely reflects real usage than a basic TCP test. Results still depend on the test site, network conditions, and service policies, so treat them as a snapshot of current availability.
A successful TCP test only means a connection could be made to the specified address and port. It doesn't confirm that authentication, encryption, or access to the destination will work. A failed real connection test may also mean the test site is unreachable, not that the whole subscription is unusable. Prefer a node that passes the real connection test, then verify it in a browser. Don't keep switching nodes based on one latency reading or run several speed tests at once; the tests themselves use connections.
Set the Active Server and Check the Core
In v2rayN, right-click a node and select Set as active server or a similarly named option. Confirm that the active marker changes. The client usually reloads the core configuration when you switch nodes. If the interface has a start, restart, or status control, use it to check that the core is running. Make sure the system proxy you prepared earlier is enabled. Selecting a node and setting it as the active server may be separate actions; check the active marker and logs.
Open the log panel or page below the main window. Look for configuration parse errors, ports already in use, or the core exiting during startup. If another app is using the local listening port, close it and restart the core. If you must change the port, also update any proxy address you entered manually in other apps. After a startup error, repeatedly refreshing a webpage will only produce more failures to connect to the local proxy.
Start and Authorize the Android Client
On the v2rayNG main screen, tap the node you want to use and check that it's selected, then tap Start. The first time you connect, Android will ask for VPN permission. Verify which app is requesting access, then approve it. Return to the main screen and check that the connection status has changed before opening your test browser. A connection icon in the notification bar only confirms that local traffic capture is active; you still need to test access to the remote node in the next step.
If the connection stops immediately, check the client logs for missing configuration fields or protocol compatibility issues. If it keeps timing out, try another node in the same group and confirm that your device's time is correct. Don't guess the UUID, password, server name, or REALITY settings; they must match the server. Get node parameters from your configuration provider rather than piecing them together from another node.
When troubleshooting for the first time, change one variable at a time: try another node, then another network if that fails, and only then check configuration details. Repeat the same test after each change so you can see what made a difference. Once the core is running, the active node is clear, and traffic capture is enabled, move on to the final step. For more complex protocol errors or background interruptions on mobile, see systematic troubleshooting.
Step 4: Verify the Proxy Connection
In a browser that you know follows system proxy settings, open an HTTPS test page and watch the client logs at the same time. For the first check, open a fresh page; use a new private window if needed to reduce interference from cached content or existing connections. If the browser has a separate proxy extension, temporarily disable it or set it to follow the system. Otherwise, the extension may override your system proxy settings and make the results misleading.
A page loading is the first check; destination and outbound entries in the logs are the second. If the current log level shows connection details, look for the domain you visited and whether the request went through the proxy or direct. Don't leave verbose logging on longer than necessary. If the default level isn't enough, raise it briefly, then restore it after checking. Before sharing logs, hide subscription URLs, node credentials, and other private information.
Use an Explicit Proxy Request to Isolate the Problem
To distinguish between “the node is unreachable” and “the system proxy isn't reaching the app,” use curl in a terminal and specify the local proxy explicitly. First, check the actual HTTP listening port in the client settings. The 8080 below is only an example; replace it with the port shown in the interface before running the command. If the client only has a SOCKS listener enabled, this HTTP example won't work as written. Make sure curl is available in your terminal.
curl --proxy http://127.0.0.1:8080 --head --max-time 15 https://example.comThis command requests a public example site to check whether the specified proxy can return HTTP response headers; it is not a speed test. A response confirms only that this request worked, not that every app, domain, or UDP connection is using the proxy. If your routing rules send the domain directly, the request may still use a direct outbound connection. To test proxy routing, temporarily switch to global proxy routing and check the logs as well.
If the explicit proxy request works but the browser doesn't, check that the system proxy is enabled, the browser follows system settings, and no extension overrides them. If the local proxy address can't be reached, check the port and core status. If the local proxy connects but the handshake or request then fails, inspect node, routing, and DNS logs. This is more likely to pinpoint the problem than switching TUN, DNS, and protocol settings all at once.
Keep a Record of What Works and Disconnect Safely
Once the connection is verified, note the working subscription group, active node, routing preset, and traffic capture mode. There's no need to record full service credentials. Then restore any routing rules or app scope you need, one change at a time, repeating the same page test after each change. Only set up a separate proxy for an app if you know it ignores system proxy settings, or read troubleshooting: traffic capture and DNS to decide whether TUN is needed.
When finished on desktop, choose Clear system proxy or an equivalent option in the client before closing it. This prevents the operating system from sending requests to a local port that is no longer available. Even if the client cleans up automatically on exit, check your system network settings after your first session. In v2rayNG, tap Stop and confirm the connection has ended. If your system is set to always-on VPN or to block connections without a VPN, check those options as needed.
You've now checked subscription access, traffic capture, node connectivity, and browsing separately. If a subscription update later fails, an app can't connect, or speeds drop, take the last known working settings and the specific error to troubleshooting instead of reinstalling from scratch. For details on VMess, VLESS, REALITY, or core differences, see the glossary. Keeping the first connection process short and repeatable makes issues easier to isolate.