v2rayN Setup Guide: From Subscription Import to Connection Verification

Open the main window in v2rayN, find “Subscription Groups” or a similarly named menu item, open the group settings, and choose Add. Use a recognizable service name for the group; paste the complete subscription link into the URL field. Leave other options at their defaults for now, make sure the URL was not truncated, and save. Saving creates a local subscription record only; you must also run an update before the client reads the server configuration from the URL.

Return to the main interface, open the subscription menu, and choose Update current group or Update all subscriptions. The status bar or log area usually shows the result. When successful, several entries appear in the server list with protocol details, address aliases, or notes from the provider. The number of entries depends on the subscription and does not by itself indicate quality. For now, confirm that the list is no longer empty and that there are no obvious parsing errors.

On Android in v2rayNG, open “Subscription Group Settings” from the side menu, tap Add, enter a name, paste the URL, and save. Return to the server list and choose “Update subscriptions” from the menu. When the update finishes, the server entries appear in the list. Existing manually added configurations may remain alongside the new entries; use the group name to tell them apart rather than deleting anything.

Read the message first when an update fails

If the interface reports an invalid URL format, remove spaces before and after the URL and copy it again from the source page. If it reports a connection failure or timeout, confirm that the current network can reach the subscription source and that the system clock is accurate. If the update appears complete but the list is still empty, the subscription may have returned no valid entries, or a group filter may be hiding the new content. Do not click Update repeatedly in quick succession; it will not fix an invalid URL and can make multiple log entries harder to read.

Subscription updates can fail for many reasons, including an expired URL, an update request that requires an already established proxy, or a client port conflict. If the message is inconclusive, follow the subscription update troubleshooting steps. Once the server list appears normally, move on to choosing a proxy mode.

Once server entries appear, decide which application traffic should go through the client. Keep two concepts separate: the server determines where traffic goes, while the proxy mode determines which traffic enters the client. Selecting a server without enabling the right proxy entry point may leave the browser or other applications using the original network path.

On desktop in v2rayN, start by choosing “Set system proxy automatically” from the system proxy menu, then use rule mode for split routing. Most browsers and desktop apps that read the system network settings will follow this configuration. Rule mode uses the client's routing rules to choose how each connection is handled and suits everyday use. Global mode sends more requests through the same outbound and can help briefly determine whether a rule match is causing an access issue, but it is not recommended as a long-term way to reroute all traffic without a specific need.

TUN mode uses a virtual network interface to take over a broader range of system traffic, making it useful for programs that do not read system proxy settings. It usually requires additional system permissions and may conflict with other virtual networking tools. There is no need to enable TUN during the first setup: verify the subscription and server with the system proxy first to narrow the problem. If the browser works but a standalone program never changes, then consider switching to TUN mode.

On Android in v2rayNG, tapping Connect creates a system-level VPN channel, while routing settings determine which connections use the selected server. For the first test, keep the client's preset rules and avoid changing domain policies, app filters, and custom routes at the same time. Change one option at a time and verify the result before continuing; this makes later problems easier to trace.

How to choose the right mode

If you only need to confirm that the subscription works, system proxy and rule mode are sufficient. If the browser works but a command-line tool, game launcher, or standalone app bypasses the client, first check whether that application has its own proxy settings, then decide whether TUN is necessary. To understand the relationship between domain rules, IP rules, and outbound tags, see the routing chapter in the configuration reference; this guide does not cover complex rule writing.

After setting the mode, do not test several applications at once. Keep one browser window as a consistent test target, then continue to step three to select a specific server and start the connection. This separates traffic-capture problems from server connectivity problems.

Return to the server list and select a subscription entry. In desktop v2rayN, double-click the target entry or use its context menu to set it as the active server. The selected entry is usually marked by a color, check mark, or status-bar text. Then confirm that the client core is running and that the system proxy status matches the choice made in step two. Clicking a row once does not always switch the active server, so rely on the current server name shown in the status area.

On Android in v2rayNG, tap a server entry to make it the current configuration, then tap the connection button on the main screen. The first time the system creates the channel, it displays a connection permission prompt; after approval, the button and status area change. A system network-channel indicator usually also appears in the top status bar. If the client immediately returns to a disconnected state, open the client log and read the final lines instead of switching servers repeatedly.

When the server list is long, use the client's testing feature to filter out entries that cannot establish a basic connection. Test results reflect network conditions at that moment, do not predict long-term performance, and cannot replace real access testing. After choosing an entry that passes the basic test, set it as the active server and inspect the connection log. Normally, the core shows the local inbound port and loaded configuration after startup. If you see timeout, rejected, or configuration parsing errors, record the key terms.

The connection button is on, but access still fails

A connected status only means that the local channel and client process have started; it does not guarantee that the remote server is available. First switch to another entry from the same subscription for comparison. If every entry fails at the same point, check the local clock, network connection, client permissions, and whether the subscription was just updated. If only one entry fails, the problem is more likely limited to that entry's service status or parameters.

Do not change the port, DNS, routing, and core options simultaneously while troubleshooting. Changing several variables at once makes both success and failure difficult to attribute. For clear English errors in the log, consult common V2Ray runtime log errors. For a broader fault classification, visit Troubleshooting in the help section.

After the connection is established, do not rely only on the client's button color. Verify it at three levels: local status, browser access, and the target application. First check the client: the active server name is correct, the core keeps running, and the log does not repeatedly show connection failures. Next, open a new browser window and visit the page normally used for testing. A new window reduces interference from old connections, cached data, or existing sessions.

If the target page opens normally, return to the client and check whether the log contains a corresponding new connection record. New inbound, routing, or outbound entries show that the browser request entered the client. In rule mode, some connections may be classified as direct; that is an expected routing result. The important point is that destinations requiring a proxy use the expected outbound, not that every log entry follows the same path.

After the browser test passes, open the application you actually need to use. If the browser works but the target application does not, the server path is usually available and the issue is whether the application reads the system proxy. Check its network settings for “Use system proxy” or manual proxy options. Desktop command-line programs often need proxy environment variables configured separately; browser success does not mean the terminal will follow automatically. When you need to distinguish browser and terminal checks, read the separate checklist for a system proxy that is not taking effect.

Run a restoration test when finished

Once access works, disconnect deliberately and see whether the browser returns to its original network path, then reconnect once. This brief disconnect-and-reconnect test confirms that the client truly controls the system proxy and can reveal whether the desktop client restores the system proxy after exiting. When finished, keep the client status, system proxy status, and actual usage needs aligned.

If you plan to use rule mode long term, learn subscription updates, server switching, and basic routing next; there is no need to edit the underlying JSON immediately. Complex DNS settings, policy objects, and custom inbounds are better handled after the basic workflow is stable. See the V2Ray configuration file reference for the relevant structures. The first connection workflow is now complete.