v2rayN Main Window Guide: Server List, Subscription Groups, Logs, and Settings

Start with the five areas of the main window

The v2rayN main window is more than a single “connect” button. Think of it as a configuration manager: the top menu handles actions, the left sidebar filters configurations by subscription group, the center lists nodes, the status bar shows what is running, and the log panel records core startup and connection details.

Button placement may shift slightly between 7.x releases, and the window width determines whether the sidebar and log area are fully expanded. This guide follows the common layout and Chinese interface labels in v2rayN 7.15.x. If an entry is missing, widen the window first, then check the relevant menu.

Build a top-to-bottom workflow

• Menu bar: Add servers, manage subscriptions, adjust settings, and run batch tests.
• Subscription group sidebar: Switch between subscriptions or custom groups to show only the servers in the selected group.
• Server list: Review aliases, addresses, ports, protocols, transports, and test results, then set the active server.
• Status bar: Check the active server, system proxy state, routing mode, and local listening port.
• Log panel: Review core startup, configuration loading, DNS queries, connection failures, and port-conflict details.

Use the menu bar for servers, subscriptions, and global settings

The menu bar is the entry point for administration. “Server” is typically used to add VMess, VLESS, Trojan, or Shadowsocks configurations manually, or to import shared links from the clipboard in bulk. When editing a server manually, the address, port, user ID, transport, TLS settings, and server name must match the server-side configuration.

“Subscription Group” lets you add subscription URLs, rename groups, update the current subscription, or update all subscriptions. Once an update finishes, the new configurations are written to the corresponding group. Updating does not automatically determine which route best suits your network; run a latency test in the server list and choose the active server yourself.

“Settings” includes parameter, routing, DNS, and core-management options. On first use, check the core type, local listening port, startup behavior, and system proxy settings. Avoid changing the port, DNS, and routing rules all at once: if an error appears in the logs, it will be difficult to identify the cause.

1. Open parameters

   Go to “Settings” → “Parameter Settings” and review the basic settings page before changing anything.

2. Confirm the core

   Then open “Settings” → “Parameter Settings” → “Core Type”. Common VLESS and VMess configurations can use Xray Core.

3. Check the port

   Check the local listening port. A common mixed port is 10808; if you changed it, browsers and other applications must use the same port.

4. Save the settings

   Click Confirm and watch the status bar. If the core restarts automatically, wait for the active server name and port to reappear.

5. Check the logs

   Watch the log panel for about 30 seconds and make sure there are no port-conflict messages such as “address already in use”.

Similar menu names, different jobs

The subscription group sidebar controls what appears in the list

Treat subscription groups as filters for the server list. Select a group and the center panel shows only its configurations. If dozens of nodes suddenly become a handful, check whether the sidebar switched to a manual, test, or filtered group before importing the subscription again.

A single subscription may contain regions and protocols from multiple locations. Name groups after their source or purpose, such as “Daily,” “Backup,” or “Manual.” Avoid naming a group after one specific node; when node names change after an update, it becomes hard to tell where the configurations came from.

If the list is empty after an update, check these three things first

1. Make sure the selected group is the subscription you just updated—not “Default” or a manual configuration group.
2. Clear any keyword filter above the server list, especially a region abbreviation or protocol name.
3. Open the logs and check the update result. Distinguish a network timeout from an empty subscription and a parsing failure.

How to read the server-list columns

The server list is the most information-dense part of the main window. Each row represents one local configuration record. Common columns include alias, address, port, protocol, transport, TLS, latency, and speed. Column names vary with the version, window width, and display settings, but the interpretation order is largely the same.

The “Alias” is a label for identification and does not affect the connection. The remote endpoint is defined by “Address” and “Port”. “Type” shows VMess, VLESS, Trojan, or Shadowsocks. “Transport” may show TCP, WebSocket, gRPC, and other values; it must match the remote configuration, so do not switch it casually to chase lower latency.

Pay attention to how latency is tested. TCP Ping mainly checks whether a TCP connection can reach the target port; a low value does not mean the proxy path works. Real-connection latency sends an actual request through the current proxy configuration and is more useful for judging whether a node works. If TCP testing returns a value but the real-connection test fails, check the protocol parameters, TLS, server name, and system time first.

Do not choose a node by the smallest number alone

• Run real-connection latency tests in bulk first, filtering out configurations that time out or fail during the handshake.
• From the successful results, choose a node with stable latency instead of mechanically picking the lowest momentary value.
• Test candidate nodes two or three times. A node jumping between 120 ms, 480 ms, and 160 ms is usually less stable than one staying around 180 ms.
• After setting the active server, open the webpage or application you actually use to verify it. A list test is a screening tool, not a complete verdict on network quality.

What the status bar and system proxy mean

The bottom status bar confirms the configuration that is actually running. It usually shows the active server name, local port, system proxy state, and routing mode. After highlighting a row in the server list, check that the name in the status bar changes too. If it does not, you have only selected the row, not set it as active.

When the system proxy is enabled, applications that read the operating system’s proxy settings send requests to v2rayN’s local port. A common mixed-port example is 10808, which can accept common HTTP and SOCKS inbound requests. If Parameter Settings uses another port, applications with manually configured proxies must be updated as well.

Routing mode determines whether requests use the proxy, connect directly, or are blocked. Rules are usually matched in order, with domains, IPs, processes, or ports serving as conditions. On first use, keep the client’s existing basic rules and avoid importing multiple overlapping rule sets from unknown sources.

How to troubleshoot connections with the log panel

Logs are not only for crashes. Watch them after switching the active server, changing the core type, updating routing, or changing the local port. A normal startup usually records configuration loading, inbound listening, and core runtime activity; repeated error lines indicate an ongoing configuration or network problem.

“address already in use” usually means another process has claimed the local port, or another v2rayN instance is still running in the background. Check the taskbar notification area and Task Manager first; do not keep launching more instances. Once duplicate processes are ruled out, open “Settings” → “Parameter Settings” and verify the local port.

When the logs show a connection timeout, identify whether it occurred during subscription updating, connection to the remote server, or a DNS query. A subscription-update timeout does not prove that every existing node is unusable; a remote connection timeout does not mean the local port is wrong. Use the action time and nearby log lines to determine the cause.

Recommended troubleshooting order

1. Record the active server name, core type, local port, and system proxy state.
2. Clear the current log or mark its current position, then perform one explicit action such as a real-connection latency test.
3. Handle only newly appearing errors; do not mistake subscription-update records from minutes ago for the current connection error.
4. Change one setting at a time, save it, retest, and compare the log changes.
5. Once a working configuration is restored, organize groups, routing, and DNS. Avoid expanding the troubleshooting scope prematurely.

A complete first-use workflow

Once you understand the layout, the daily workflow fits into six steps: import a subscription, update the group, test servers, set the active server, enable the system proxy, and watch the logs. Each step maps to a specific area of the main window, so you do not need to jump repeatedly between settings pages.

For the first setup, keep the default routing and DNS and confirm only the core and port. After a node works, adjust traffic-splitting rules to suit your needs. If something later breaks, you can quickly tell whether the cause is the node itself or a new routing or DNS setting.

1. Add a subscription

   Open “Subscription Group”, create a group, enter the complete subscription URL, save it, and update the current subscription.

2. Filter the nodes

   Select the group you just updated on the left, clear any keyword filter, and confirm that configurations appear in the server list.

3. Test the connection

   Run real-connection latency tests on several servers, remove timed-out entries, and test the candidates two or three more times.

4. Set as active

   Double-click the target row or use the context menu to set the active server, then verify its name in the bottom status bar.

5. Enable the proxy

   Enable the system proxy for your current use case and confirm that the local port in the status bar matches “Settings” → “Parameter Settings”.

6. Check the logs

   Open a webpage you actually use and watch the logs for about 30 seconds. If it fails, troubleshoot in this order: port, DNS, handshake, then remote timeout.