v2rayN Interface Guide: Server Lists, Subscription Groups, Logs, and Settings

Understand the Main Window’s Four Layers

The v2rayN main window may look busy, but it can be broken down from top to bottom into four layers: menu and toolbar actions, subscription groups, the server list, and the bottom status and log area. Once you have this map, most tasks belong to a specific section instead of being hidden across multiple menus.

The top menu handles server additions, subscription maintenance, and settings. The middle section shows nodes in the current group. The bottom status bar reports the active server, system proxy, and routing mode. The log window records core startup, port listening, connection establishment, and errors, making it the main place to identify where a problem occurs.

Button labels or toolbar layouts may change across 7.x releases, but the core objects remain the same: subscription groups store sources, the server list stores expanded nodes, the active server determines the current outbound, and the system proxy determines whether other applications hand their traffic to v2rayN.

• Menu bar: Add servers, update subscriptions, open settings, and view runtime logs.
• Group area: Separate subscription sources and control which nodes appear in the current list.
• Server table: Show fields such as alias, address, port, protocol, transport, and latency.
• Status area: Confirm the current server, system proxy mode, routing rules, and core status.

Server List: Node Details and the Active Server

The server list is not a connection history; it is the collection of nodes imported into the client. Each row usually represents a VMess, VLESS, or another configuration supported by the current core. Common columns include alias, address, port, transport protocol, security type, latency result, and subscription group. If the columns are cramped, start with the alias, protocol, and test result rather than expanding every field.

A single click only selects a row. It becomes the default outbound only after you double-click it or use the context menu to set it as the active server. To verify the switch, check the current-server field at the bottom instead of relying on the table highlight. Highlighting is for batch actions; active status controls real connections.

1. Select a Group

   Select the intended source in the subscription group area first, so you do not choose the wrong record among several nodes with the same name.

2. Update Subscriptions

   Open “Subscriptions” → “Update All Subscriptions” and wait for the list to finish adding, modifying, or removing entries.

3. Test Latency

   Select a candidate node and run a latency test. Testing twice in succession helps avoid a false conclusion caused by a single network spike.

4. Set as Active

   Double-click the target row, or choose Set as Active Server from the context menu, then check that the name at the bottom changes as well.

5. Enable the Proxy

   Confirm that the core has started, then choose whether to configure the system proxy automatically or leave the current system proxy unchanged.

The latency value only shows how long the test request took to make a round trip; it is not a download-speed measurement. A node showing 80 ms will usually respond faster than one showing 250 ms, but actual throughput still depends on server bandwidth, congestion, transport, and the destination site. If the test times out, first check whether the subscription has expired, then look in the logs for resolution, handshake, or connection-refused errors.

Subscription Groups: Links, Updates, and Node Ownership

Subscription groups store the subscription name, URL, and update behavior. Adding a subscription does not immediately create a server list: after saving the group, you must run an update so the client can request the content, parse the nodes, and add them to the list. If a link has been added but no servers appear, first check whether the update was actually run.

When updating a subscription, v2rayN adjusts the nodes according to the returned content. If the server removes a node, the local list may change after the update as well. Before manually editing a node’s note or parameters, check whether a later update will overwrite the change. For configurations that must be kept long term, create them separately instead of relying on a subscription group to preserve custom fields.

• Update All Subscriptions: Best for routine refreshes; processes every enabled group at once.
• Update Current Subscription: Best when checking one source, avoiding unnecessary network requests.
• Delete Group: Confirm whether its nodes will be removed too, so you do not accidentally delete the active server.
• Subscription Note: Record the source and purpose, such as “daily routes” or “temporary testing,” rather than using a number alone.

Log Panel: Trace Connection Problems from Startup Records

The log panel is easiest to read in chronological order. Find the latest core startup or restart entry, check that the local listening port was created, and then see which routing rule handled the target connection. Do not randomly search hundreds of old lines for errors; a failed connection from an earlier node may have nothing to do with the current one.

During a normal startup, the logs usually show the core version, configuration loading, and local listening information. Using the local mixed port 10808 as an example, a successful listener means v2rayN has provided a local proxy entry, but it does not prove that the remote node works. Remote handshakes, domain resolution, and route matching must be confirmed in later connection records.

For troubleshooting, run one minimal reproduction: clear the visible logs, select one node, restart the core, and open only one test page. The resulting records will be shorter and easier to follow. If switching to another node makes the error disappear, the cause is more likely the node parameters or remote route. If no node can open a local listener, check the local port and settings first.

1. Note the active server name shown at the bottom so you do not switch nodes accidentally during testing.
2. Make sure the local port in the logs matches the port entered in your browser or other applications.
3. Identify whether the error occurs during resolution, connection, TLS handshake, or route matching.
4. Change one variable at a time and test again—for example, change only the node, not the port and routing simultaneously.

Settings: Core, Ports, System Proxy, and Routing

Common settings are under “Settings” → “Parameters.” New users do not need to adjust everything at once. Start by confirming the core type, local listening port, startup behavior, and system proxy policy. Protocol parameters supplied by a subscription usually do not need to be rewritten manually; changing the transport without understanding it can break an otherwise complete configuration.

The exact path for Core Type is “Settings” → “Parameters” → “Core Type.” If subscription nodes use VLESS, Reality, or specific Xray fields, choose the Xray core that recognizes them. After switching cores, restart the core once and verify the loaded core name and version at the top of the logs; do not rely on the dropdown alone.

The local port provides a proxy entry on the local loopback address only. A common setup uses 127.0.0.1:10808. When configuring a proxy manually in a browser or another application, the address and port must match v2rayN’s settings. If you change the port to 10818, update every manual configuration as well, or the application will continue connecting to the old port.

• Configure the system proxy automatically: Useful when desktop applications that follow system settings should share the current proxy.
• Do not change the system proxy: Useful when an individual application already has 127.0.0.1 and the local port configured manually.
• Global routing: Convenient for briefly checking node connectivity, but not a substitute for routing rules maintained over time.
• Rule-based routing: Choose an outbound based on domains, IPs, geosite, and other conditions; rule order affects the final result.

A Complete Workflow: From an Empty List to a Working Setup

When using v2rayN for the first time, the hardest part is often not finding a button but doing things in the wrong order—for example, enabling the system proxy before choosing an active server, or saving a subscription without updating it. A fixed workflow gives every step a clear verification point.

1. Confirm the Core

   Open “Settings” → “Parameters” → “Core Type,” choose the Xray or v2fly core that matches the subscription protocols, and save.

2. Create a Group

   Open the “Subscriptions” management page, create a group, add a clear note, and paste the complete subscription link.

3. Fetch Nodes

   Run “Subscriptions” → “Update All Subscriptions,” then confirm that nodes appear in the server list without parsing errors.

4. Choose a Node

   Test at least two candidates and choose the active server based on latency, stability, and the log results.

5. Check the Outbound

   Enable the required system proxy mode, open one target page, and confirm in the logs that the connection used the expected outbound.

If the final step fails, return to the checkpoint closest to the error. An empty list points to subscription updates; a core that will not start points to Core Type and port settings; failure on only one node calls for comparing node parameters; if every node starts but the target connection goes direct, check the routing mode and rule priority.

Once the interface is familiar, daily use can be reduced to three actions: update subscriptions, choose the active server, and confirm the system proxy status. Settings and logs do not need to be opened every time, but when something goes wrong, check them first for facts instead of repeatedly switching nodes and guessing.