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

First, understand the main window layout

The v2rayN main window is more than a simple node list. It handles both configuration management and runtime control: the upper section stores, filters, and selects servers; the lower section shows Core output; menus and status controls manage the system proxy, routing mode, and application settings. Understanding each area’s role is more useful than memorizing button locations.

This guide uses the common v2rayN 7.x desktop interface as a reference. Minor releases may change button labels or placement, but the workflow remains the same: subscription groups manage configurations, the server list selects a node, logs confirm runtime status, and settings control the local entry points. If the window is narrow, some commands may be tucked into an ellipsis menu.

• Top menu: Server, subscription group, settings, help, and other commands are collected here, making it the primary entry point for the full feature set.
• Subscription group area: Configurations are organized by subscription source, determining which set of servers appears in the current list.
• Server list: Shows remarks, addresses, ports, protocols, transport methods, and other details, while marking the active server.
• Logs and status area: Shows Core startup, listening ports, connection establishment, routing matches, and error messages.

How to read each server-list column

The server list is an index of local configurations; it does not mean all servers are connected at once. Normally, one configuration is marked as active, and v2rayN uses it to generate the Core runtime configuration. Clicking a row only selects it. Double-clicking or choosing “Set as Active Server” changes the configuration in use, although the exact behavior may depend on the current shortcut settings.

The most useful columns to check first are “Alias or Remark,” “Address,” “Port,” “Protocol,” and “Transport.” The remark identifies the node; the address may be a domain or server address; the port is the remote service port, not the local 10808 port; common protocols include VMess, VLESS, Trojan, or Shadowsocks; and transport may show TCP, WebSocket, gRPC, and more.

Latency results need to be read in context. A TCP connectivity test only shows that the target address and port accept a basic connection. A real latency test usually goes through the local proxy and remote node to reach a test address. A timeout does not necessarily mean the configuration is permanently unusable; the test address may be unreachable, DNS resolution may be failing, or the current network may restrict that port.

How to organize nodes with subscription groups

Subscription groups answer two questions: where configurations come from and how they should be updated together. One subscription URL usually maps to one group. When updated, v2rayN fetches the remote content and refreshes that group’s server entries. Manually added nodes can go in a separate group, making their source easier to distinguish during subscription updates.

Group names do not have to copy the subscription URL. Use recognizable labels such as “Daily,” “Office Backup,” or “Manual Config.” A group is only a management boundary; servers in the same group do not work simultaneously. Selecting a group changes the list view, while selecting the active server changes the connection configuration in use. Keep these two actions distinct.

1. Open the “Subscription Groups” menu at the top and enter the group settings screen.
2. Create a group, enter an easy-to-recognize alias, and paste the complete subscription URL.
3. Save it, then choose “Update All Subscriptions” or update only the current group.
4. Return to the main window, switch to the relevant group, and check that its server entries appear.
5. Select the target entry, choose “Set as Active Server,” and watch the logs for the Core to restart.

How to read connection status in the log

Logs are the most direct evidence when troubleshooting v2rayN. They usually combine client control messages with Core output: the former describes configuration generation, process startup, and system proxy changes; the latter covers listening ports, outbound connections, DNS queries, and routing results. A scrolling log does not prove that the connection succeeded—look for meaningful status lines.

A normal startup usually passes through three stages: reading the configuration, starting the Core, and beginning to listen on local ports. Only when a browser or another application sends a request will the log show connections to a target domain or address. If you see successful listening but no later requests, check that the application is actually using the system proxy or the manually configured local proxy port.

Startup sequence example
[Info] Core process started
[Info] SOCKS listening at 127.0.0.1:10808
[Info] HTTP proxy listening at 127.0.0.1:10809
[Info] accepted tcp connection to example.com:443
[Info] routing request through proxy outbound

Warnings in the log also need context. If a failed test is followed immediately by a normal connection, only that target may be unreachable. If the Core process keeps exiting or every startup reports invalid configuration fields, inspect the active server’s protocol and transport parameters. When troubleshooting, preserve the full segment from before startup through the error instead of capturing only the final line.

• No listening information: Check whether the Core started successfully and whether configuration generation reported an error.
• Listening is active but there are no requests: Check the system proxy, or verify that the application proxy points to 127.0.0.1 and the correct port.
• Requests appear but keep timing out: Switch to a server that has passed testing and check whether the current network can reach the remote port.
• Only some websites fail: Check routing rules and DNS instead of immediately deleting every subscription.

The most useful settings to check

Settings affect v2rayN as a whole, not an individual server configuration. For a first setup, focus on the Core type, local ports, startup behavior, and system proxy options. Changing several items at once makes troubleshooting harder. A safer approach is to change one item at a time, save it, and watch the log for a complete normal restart.

The Core type determines which engine interprets the current configuration. For everyday VMess, VLESS, Trojan, and Shadowsocks configurations, Xray Core generally covers the most common features, especially nodes using VLESS, Reality, or XTLS Vision parameters. If an existing configuration runs normally, there is no need to switch Core types repeatedly just because several options are available.

1. Open Parameter Settings

   From the main window, go to “Settings” → “Parameter Settings” and note the current ports and startup options first.

2. Confirm the Core

   Go to “Settings” → “Parameter Settings” → “Core Type,” and choose a Core that supports the required features for the current protocol.

3. Check the local ports

   Check the SOCKS and HTTP entry points. If the interface shows 10808 and 10809, browsers and other applications must use the same values.

4. Save and restart

   Save the settings, return to the main window, and watch the log to confirm that the old process exits and the new Core successfully listens on the local ports.

5. Verify a real request

   Open an application that needs network access, confirm that the log shows a new connection, and then decide whether the settings have taken effect.

The complete workflow from launch to verification

Once the interface is familiar, daily operation can follow one consistent sequence: update the subscription, choose a server from the target group, confirm the active status and system proxy, then use the log to verify a real request. This avoids common confusion such as selecting a server in the list while Core still uses an old configuration, or starting Core while the application bypasses the local proxy.

1. Check the group: Confirm that the current view shows the subscription source you intend to use; do not rely only on similar server remarks.
2. Update the subscription: Update the current group and wait for the list to refresh. If the update fails, check the message and log first.
3. Test candidates: Run real connectivity tests on multiple servers and use the results for initial screening.
4. Set the active server: Explicitly run the switch command and watch for the active marker and Core restart record.
5. Apply the system proxy: Let desktop applications that follow the system proxy use v2rayN; for separately configured applications, verify 127.0.0.1 and the port.
6. Check the log: Confirm that the local ports are listening successfully and that real access produces connection and routing records.

If the connection is still failing, do not reinstall the client, delete subscriptions, switch Core types, and change DNS all at once. Use the log to identify the layer involved: no configuration generated from the subscription, Core not started, local port not listening, application not entering the proxy, or remote connection timing out. Verify one layer at a time to find the cause faster.

The key relationships in the main window are: subscription groups define the configuration source, the server list provides the current candidates, the active server determines which configuration Core uses, the system proxy determines whether application traffic enters the client, and the log shows how far the entire chain has actually run. Once these five concepts are clear, you can quickly find the right function even when later versions move the buttons.