v2rayN Main Window Guide: Server Lists, Subscriptions, Logs, and Settings

Understand the four main areas first

The v2rayN main window handles configuration and status monitoring; the selected core handles the actual connection. The layout may vary slightly across 7.x releases, display scaling, and enabled panels, but the information structure remains much the same: menus and shortcuts at the top, the server list in the center, subscription filters in a sidebar or group pane, and status information plus runtime logs at the bottom.

The most common confusion is the difference between a selected row and the active server. Clicking a row usually changes only the current selection for testing, editing, or deletion. The server becomes the current outbound only after you double-click it or choose “Set as active server.” After switching, check the list marker, the status at the bottom of the window, and the current server name in the tray menu instead of relying on the highlighted row alone.

• Menus and tools: Subscription updates, server tests, routing, settings, and help are grouped here.
• Subscription groups: Filter servers by subscription source and keep work, everyday, and testing configurations separate.
• Server list: Shows aliases, addresses, ports, protocols, transports, groups, and test results.
• Status and logs: Confirm that the core has started, the listening ports are available, and which stage caused a connection to fail.

How to sort, test, and switch servers

The server list is more than a simple node list. It also handles filtering, batch testing, result sorting, and switching the active outbound. Click the “Real connection latency” column header to sort by the latest results; clicking again usually toggles ascending and descending order. Empty cells mean the corresponding test has not been run, not that the server has failed.

Different tests answer different questions. TCP latency checks only whether a basic connection can be established to the target address and port, so it is usually lower. Real connection latency includes the protocol handshake and proxy request, making it closer to the wait time for opening a web page. Speed tests also depend on the test target, route load, and local bandwidth, so repeated tests can fluctuate noticeably.

1. Filter by group

   Select a source in the subscription group pane and test only that group to avoid opening connections to hundreds of servers at once.

2. Test real latency

   In the server list, press Ctrl+A to select the current results, open the context menu, and choose “Test server real connection latency.”

3. Sort the results

   Click the Real connection latency column header to move available servers with lower values to the top while excluding entries marked as timed out.

4. Set as active

   Double-click the target server, or choose “Set as active server” from the context menu, then confirm that the alias in the status bar has changed.

5. Verify the exit route

   Enable the system proxy, open the site you actually need to reach, and check the logs for the matching target and a successfully established connection.

For example, if a server on the same network shows 38 ms TCP latency but 126 ms real connection latency, the difference is not unusual because the latter includes protocol negotiation and the target request. If TCP latency is 42 ms while real connection latency consistently times out, the issue is more likely to involve protocol parameters, server status, or target reachability than simple distance.

Subscription groups are more than an update button

Subscription groups store subscription URLs, update behavior, and server ownership. Every imported server is associated with a group, so check for manually edited servers before deleting a group, cleaning up old configurations, or changing filters. A direct subscription update normally refreshes the group with remote content, so review any manually changed aliases and parameters afterward.

The add option is usually under the “Subscriptions” menu. After creating a group, enter a note and subscription URL, then choose “Update current subscription” or “Update all subscriptions.” If the list does not change after an update, clear the search term and protocol filter first, then verify that the displayed group is the one just updated.

A complete subscription update check

1. Open “Subscriptions” and confirm that the note, URL, and enabled status are correct.
2. Choose “Update current subscription” and wait for the window or log to report completion.
3. Check whether the server count changed and whether expected protocols such as VMess, VLESS, or Trojan appear.
4. Run a real connection latency test on new entries instead of switching based on their names alone.
5. Set an available server as active, then verify the system proxy and an actual connection.

Automatic updates work well for subscriptions that remain valid over time, but the interval should not be too short. For once-a-day updates, 1,440 minutes is a useful reference. Frequent updates do not improve an existing connection and may repeatedly overwrite the list when the network is unstable. If a subscription must be accessed through an existing proxy, keep one working route available first, then enable updating through the proxy in the group update options.

What to look for in the log panel

Logs help identify which layer failed. When starting the core, first check whether the configuration loaded and the local listening port was created. When opening a website, check domain resolution, route matching, outbound selection, and the connection result. The final line alone is rarely enough; keep at least 10–20 lines before and after the error.

Common local v2rayN ports include SOCKS port 10808 and HTTP port 10809, but use the values shown under “Settings” → “Parameter settings” as the source of truth. If the log says the address is already in use, another program or core process is listening on the same port. Exit the duplicate process or change the local ports to unused values, such as 10818 and 10819, then restart the core.

2026/08/21 10:14:03 loading configuration
2026/08/21 10:14:03 listening TCP on 127.0.0.1:10808
2026/08/21 10:14:11 accepted tcp connection
2026/08/21 10:14:11 routing to selected outbound
2026/08/21 10:14:12 connection established

The example above shows that configuration loading, local listening, inbound acceptance, route selection, and outbound establishment have all completed. If the log stops at loading configuration and immediately reports an error, check the configuration fields and core type first. If it reaches accepted connection but later times out, inspect the active server, remote port, DNS, and routing rules.

• Configuration parsing error: Usually reported while the core starts; check manually edited transport parameters, ports, and security settings.
• Port already in use: The common keyword is address already in use; free the local listening port or choose another one.
• Resolution failure: No address was returned for the domain; temporarily switch the DNS configuration and test again.
• Connection timeout: Try another server in the same group, then compare TCP latency with real connection latency.
• Routing block: If the log shows the target entering the block outbound, check the current routing mode and custom rules.

Tray menu and system proxy status

After the main window closes, v2rayN usually remains in the system tray. Whether the core keeps running depends on the program state, not on whether the main window is visible. If the window is missing, check the tray icon first: double-click it to restore the main interface, or right-click it to quickly switch the system proxy, active server, and routing mode.

The system proxy determines whether applications that follow the operating system proxy settings connect to v2rayN’s local port. Common options include “Clear system proxy,” “Automatically configure system proxy,” and “Do not change system proxy.” Automatic configuration suits browsers and standard desktop applications that should use the proxy immediately; leaving it unchanged suits tools or applications that specify 127.0.0.1:10808 themselves.

Where to change the core type

To check the core, go to “Settings” → “Parameter settings” → “Core type.” Save the settings and restart the core, then review its startup messages in the log. The core type must match the configuration features; if a subscription includes specific transport or security parameters, changing only the interface option will not fix incorrect remote parameters.

System proxy vs. TUN

The system proxy mainly covers applications that follow system proxy settings. It is simple to configure and works well for browsers and standard desktop software. TUN mode takes over a broader range of traffic at the network layer, requires the relevant system permissions, and may conflict with security software, virtual adapters, or other networking tools. For first-time setup, verify that system proxy mode works before testing TUN separately.

Common interface issues and troubleshooting order

Interface problems are often not caused by a single button. A useful order is to verify the subscription content, then the active server, followed by the core, ports, system proxy, and logs. Change one variable at a time and record the result; this is easier to diagnose than switching the server, DNS, routing, and core simultaneously.

A daily checklist worth keeping

1. After startup, confirm the subscription group and active server name.
2. Run one real connection latency test on a candidate server.
3. Confirm that the core log reports successful local listening.
4. Choose automatic configuration or leave the system proxy unchanged according to the use case.
5. Visit the target service and verify the routing outbound in the log.
6. Clear the system proxy before exiting if needed, so no stale port configuration remains.

With this sequence, the v2rayN main window can be understood as five layers of state: subscriptions provide configuration, groups organize sources, the active server determines the current outbound, the core executes the connection, and the system proxy determines which applications send traffic to the local port. When something fails, checking these five layers in order usually reveals whether the issue is in the list, configuration, core, or access method.