v2rayN and v2rayNG
Subscription Setup

v2rayN: Add a Subscription Group and Update

After opening v2rayN, find “Subscription Groups” or a similarly named subscription management entry in the top menu, then open “Subscription Group Settings.” Menu layouts may vary slightly by version, but the form usually includes “Alias” and “Optional Address.” Use the alias to identify the node group locally, such as “Daily Nodes.” Paste the complete subscription URL into the address field. Check the beginning, end, and middle for spaces before clicking Add or Save.

Saving a subscription group only records the URL; it does not write nodes to the server list. Return to the main interface, open the subscription menu again, and choose “Update All Subscriptions” or update the group you just added. The client will request and parse the subscription content. When the update finishes, the main list should contain server records, usually showing an alias, address, port, transport, or node type. Once the list appears, subscription import is complete.

If the main list is still empty, return to the subscription group settings, confirm that the URL was saved, and run another update. Do not use a web dashboard URL, payment page URL, or explanatory text as the subscription link; the client needs the dedicated URL provided by the service. If the link was split across two lines during copying, copy the complete content again instead of manually joining similar-looking characters.

v2rayNG: Create a Subscription from the Side Menu

Open v2rayNG, tap the menu button in the top-left corner, and open “Subscription Group Settings” from the side menu. Tap the Add button in the top-right, enter an identifiable remark, and paste the complete subscription URL into the address field. Some versions also show options such as automatic updates or updating only the current group; for the first setup, leave their defaults unchanged. Save after checking the input, then return to the subscription group list.

Return to the main page and choose “Update Subscription” from the top-right menu. After a successful update, the page lists selectable nodes, usually with a name and protocol details. If there is more than one subscription group, make sure you update the group just added. Node names come from the subscription, so their length, region labels, and order may vary; there is no need to rename them individually.

A successful subscription update does not mean every node will connect. The subscription only writes configuration to the client; node availability must be assessed during connection and verification. For the differences between subscriptions and single-node sharing links, update strategies, or node fields, continue with the complete configuration guide; you do not need to understand the full JSON structure for basic setup.

Once subscription nodes appear, decide how traffic should be handled before selecting a specific node. Common modes are rule-based routing, global proxy, and direct connection. Rule-based routing uses domains, address ranges, or predefined categories to choose proxy, direct, or block actions. Global proxy sends most traffic within the proxy scope through the current node, while direct connection bypasses proxy nodes. Different clients may call these options “Routing,” “Predefined Rules,” “Global,” or “Bypass LAN,” but the principle is the same: identify which outbound the active rules send each request to.

v2rayN: Configure Routing Mode and System Proxy Separately

In v2rayN, “Routing Mode” and “System Proxy” are separate settings. Routing mode determines how traffic is distributed after entering the core, while the system proxy determines whether browsers and applications that follow system settings send requests to v2rayN. For the first setup, choose the client's predefined rule-based routing option and leave custom rules unchanged. Then return to the main interface and use the tray or system proxy menu to enable automatic system proxy configuration; only then is the connection setup complete.

If you select routing rules without enabling the system proxy, the core may be running while the browser continues using the original network. Conversely, if the system proxy is enabled but the outbound is set to direct, requests enter the client without passing through the selected proxy node. On desktop, check these two switches separately rather than relying only on whether nodes appear in the main interface.

v2rayNG: Choose Routing, Then Start the System Session with Connect

v2rayNG usually offers predefined rules under Settings or Routing Settings. For the first setup, choose a rule-based routing option and return to the node list after saving. Android does not have a separate desktop-style system proxy menu; tapping Connect prompts the client to establish a VPN session. Once the system approves it, traffic from apps within scope enters the client. If Settings includes per-app proxying, leave it off during the first test and restrict apps only after the basic connection works.

After choosing rule-based routing, select the active node from the list and start the connection. The mode does not choose a server automatically or prove that a node works. Advanced domainStrategy, domain categories, IP ranges, DNS routing, and multiple outbounds belong to the configuration-file layer. See the routing chapter in the complete configuration guide for those fields and examples; keep this page's setup lightweight.

Choose One Node First

Select one node from the subscription list for the initial test. Its name identifies the configuration source but does not prove connection quality. Choose any node with complete information, connect, and wait a few seconds before checking its status. Avoid switching rapidly between nodes: changing nodes before the previous connection finishes mixes startup and shutdown entries in the log, making the failure point harder to identify.

Some clients offer latency tests or real-connection tests. Use their results for initial screening, but remember that they are not the same as browsing: a successful latency test only means the target responded through that test method; it does not confirm DNS, routing, and application proxying. A missing result may also reflect the test address, network restrictions, or temporary node status. After selecting a node, complete the system proxy or VPN session and perform a real access test.

v2rayN: Set the Active Server and Enable the System Proxy

In v2rayN's server list, double-click the target node or choose “Set as Active Server” from its context menu. The active item is usually marked by a color, icon, or status-bar text. Then open the v2rayN tray icon in the desktop notification area, open the system proxy menu, and choose automatic system proxy configuration. Depending on the version, this may be called “Set System Proxy,” “Auto Configure System Proxy,” or something similar. The goal is to make applications that follow system settings send requests to v2rayN's local inbound port.

Afterward, watch the status bar or log area at the bottom of the main interface. Normally, the core starts and shows the local port in use, the configuration load result, and active node information. If there is a configuration parsing error, port conflict, or core startup failure, do not test websites yet; resolve the startup issue from the logs. A port conflict is often caused by another proxy client still running. Closing the duplicate program and restarting v2rayN is usually clearer than changing several ports at random.

v2rayNG: Select a Configuration and Tap Connect

In v2rayNG's main list, tap the target node to select it, then tap the circular Connect button at the bottom. On the first connection, the system displays a VPN confirmation dialog. After approval, the status bar shows a connection indicator and the client button changes state. This approval only means Android allows v2rayNG to handle traffic; whether the node communicates successfully still requires checking the logs and real access.

If the client immediately returns to a disconnected state after you tap Connect, open the v2rayNG log page and inspect the last few lines. Common causes include an unresolvable address, connection timeout, incomplete configuration parameters, or an incorrect system clock. Do not copy a complete subscription URL or node credentials into a public support post; retain only the protocol type, client version, error category, and steps that triggered the issue.

At this point, the basic client-side path is established, but button color alone is not enough. Confirm that requests follow the expected route by checking status, logs, and real access in that order. Test one variable at a time and return through the same sequence when something fails; this avoids repeated imports and reinstalls.

Layer 1: Check Client Status

First confirm that the client is still connected. v2rayN should show an active server, no recurring startup failures in the logs, and an enabled system proxy in the tray. v2rayNG should remain connected instead of disconnecting within seconds. If the client itself has stopped, there is no need to inspect the browser; return to the previous step and address the node or core startup issue.

When reading logs, focus on the most recent errors rather than treating every message as a failure. A normal connection may include configuration loading, DNS initialization, routing, and connection-close entries. The actionable items are repeated timeouts, connection refusals, DNS resolution failures, or port conflicts that coincide with your actions. If the log is long, disconnect, clear removable old entries, and reconnect once to isolate the current error.

Layer 2: Test Real Web Access

Keep the client connected, fully close and reopen a browser that follows system proxy settings, then visit a basic page that normally opens to confirm the underlying network still works. Next, visit a target page that should use proxy rules and check whether it loads. Reopening the browser makes it read the latest system proxy state, especially after v2rayN has just enabled the system proxy while an existing process may still use the old connection.

If basic pages open but the target page does not, the browser has probably read the system proxy and the issue is more likely the node, DNS, or routing rules. If no pages open, first check whether the node is unavailable, whether the system proxy port matches the client's listening port, and whether the client exits immediately after startup. On Android, also confirm that a battery-saving policy has not stopped the connection session.

Layer 3: Compare Modes

If some access fails under rule-based routing, temporarily switch to global proxy and test the same target. If global proxy works but rule-based routing does not, the node path is usually functioning and the issue is in route matching or DNS routing. If neither mode works, return to the node, subscription content, and network connection layers. Switch back to rule-based routing after the comparison so a temporary test state does not become the long-term configuration.

Another useful comparison is a second node from the same subscription. Disconnect first, select the second node, reconnect, and repeat the same web test. Changing only the node—not routing or DNS—shows whether the problem follows that node. If the second node works, the client's overall configuration is likely sound and only the original node needs attention. If several nodes behave the same way, inspect local settings next.

After verification, keep the current configuration as a known-good baseline. When adding custom routing or DNS settings later, change one group of parameters at a time and repeat this section's verification steps. If a problem appears, you can quickly return to the most recent working state. For the full relationship between inbounds, outbounds, routing, and DNS, see the V2Ray Configuration Guide.