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

Understand the four main work areas

The v2rayN main window can be divided into four areas: the menu and toolbar, subscription groups, the server list, and runtime logs. Everyday connections do not require opening every setting. First narrow down the node source through a subscription group, select an active server from the list, then check the logs to confirm that the core started successfully.

Button positions and column names may change between 7.x releases, but the overall flow remains the same. A subscription turns remote configuration into local server entries; the server list displays and selects those entries; the Xray or v2fly core handles the connection; and the system proxy sends traffic from browsers and other proxy-aware apps to a local listening port.

How to read the server list columns

Each row in the server list represents an available configuration, possibly using VMess, VLESS, Trojan, or another protocol. Names are usually supplied by the subscription provider and mainly identify the region, route, or traffic multiplier; they do not indicate measured quality. The address and port identify the remote endpoint. Columns such as transport, security, TLS, and Reality describe connection parameters and normally should not be edited after import.

Pay attention to how latency is measured. TCPing mainly checks whether a TCP connection to the target port can be established; a low value does not prove that the full proxy path works. A real-connection test sends an actual proxy request through the core and is more useful for choosing a node. If one result is 68 ms and the next is 210 ms, the route is unstable—run two or three consecutive tests instead of relying on the lowest number.

• Alias or note: Prioritize the region, route type, and traffic multiplier, such as “Tokyo IEPL 1.0x”.
• Address and port: Use these to confirm that the subscription produced a complete configuration. Port 443 does not necessarily mean the same protocol is being used.
• Transport: Common values include TCP, WebSocket, and gRPC. They must exactly match the server-side configuration.
• Security: VLESS nodes may use TLS or Reality; VMess configurations may show encryption settings such as auto.
• Latency: Below 100 ms usually feels more responsive, while 100–250 ms is still suitable for most webpages. Switch nodes if timeouts persist.
• Speed: Results depend on the test target, time of day, and local network, so use them to compare nodes tested in the same round.

How to organize nodes from multiple subscription sources

Subscription groups are not protocol categories; they store subscription sources and their update rules. If you use two subscriptions, keeping them in separate groups prevents all servers from being mixed into one list and lets you update only the source that changed. Name groups after the service or purpose so they are easy to recognize, rather than using generic names such as “Subscription 1” and “Subscription 2”.

Updating a subscription rereads its remote content, so node names, addresses, ports, and authentication details may change. Manually edited subscription nodes can be overwritten during an update. For personal labeling, use group filters or the client’s supported note feature instead of changing critical connection fields directly.

1. Create a group

   Open “Subscription Groups” in the main window, click “+” or the add entry, enter a group name and subscription URL, then save.

2. Update contents

   In “Subscription Groups”, select the relevant source and update the current subscription. For the first import, you can update all subscriptions.

3. Check the count

   Return to the server list and verify the number and names of entries in the group. If the list is empty, first confirm that the group is enabled.

4. Batch testing

   Select the current group first, then run a real-connection latency test to avoid sending requests to hundreds of unrelated servers at once.

5. Set as active

   Select a server with stable latency and set it as the active server. Check that the status area shows the new name as well.

Practical keyword filtering

When you have many nodes, filter by a region or route marker in the name. For example, entering “Tokyo” keeps only entries whose names contain Tokyo; excluding “3x” reduces interference from high-multiplier routes. Filtering depends on node names, does not replace checking protocol parameters, and does not change remote subscription content.

If old nodes remain after an update, first confirm which group you are viewing, then check whether an option to retain expired servers is enabled. Do not repeatedly add the same subscription URL, or the list may contain duplicate entries with identical names but different group ownership.

Core type and local ports in Settings

Settings centralize the core, listening ports, startup behavior, and proxy options. When getting started, confirm that the selected Core type is available and note the local listening port. A common setup uses 127.0.0.1 as the local address and port 10808, but the effective values are shown in the current settings and status bar.

If you configure a proxy manually in your browser, the protocol and port must match. A mixed port can accept common HTTP and SOCKS inbound connections; older configurations may use 10808 and 10809 separately. When a port conflict occurs, do not keep restarting blindly. Check the logs for the occupied port, then switch to an unused value such as 10818.

1. Open Settings

   From the main window, go to “Settings” → “Parameter Settings” → “Core Type” to see which core is selected for the current configuration.

2. Confirm the core

   For everyday VLESS, Reality, or newer Xray configurations, choose Xray. Existing VMess configurations should retain the compatible core specified by the subscription.

3. Verify the port

   In Parameter Settings, confirm the local listening port, such as 10808, and check that it listens only on the local address 127.0.0.1.

4. Save and restart

   Save the settings and restart the core. Then check the logs to confirm that the new core and port have loaded, rather than continuing to use an old process.

How to read startup and connection errors in the logs

Start log troubleshooting with the most recent entry. First check whether the core loaded the configuration and is listening on the local port, then see whether an outbound entry appears when you open a webpage. If the logs stop during startup, the issue is usually with the core, configuration file, or port. If connection entries appear but the remote side times out, the node, network, or remote service is more likely at fault.

During a normal startup, the logs usually show the core version, configuration loading, and listening address. Wording varies between cores, so do not look for an exact phrase. The important points are that errors such as failed, invalid, or address already in use do not appear immediately afterward and that the status bar remains in the running state.

Example troubleshooting order
1. Core: Xray
2. Local listen: 127.0.0.1:10808
3. Configuration loaded
4. After opening a webpage, an outbound connection appears
5. No timeout or connection refused appears

Before copying logs for troubleshooting, remove the subscription URL, node authentication details, and complete configuration contents. Usually, the 10–20 lines around the error, the v2rayN version, Core type, node protocol, and steps to reproduce are enough to determine whether the issue involves a local port, configuration parsing, or a remote connection.

How the status bar, system proxy, and routing work together

Selecting a server does not mean traffic is already using the proxy. The complete path is: an active server is set, the core is running, the local port is listening, and application traffic is directed to that port. For desktop apps that follow the system proxy, enable the system proxy in v2rayN. Apps that ignore system proxy settings need their own proxy configuration or, where appropriate, TUN mode.

Routing determines where traffic goes after entering the core. Rule mode can keep LAN traffic and common direct destinations direct while sending proxy-required requests through the active server; global mode sends more traffic through the proxy. After changing routing rules, test both a direct destination and a proxied destination so you do not validate only one webpage.

1. Set a server with normal real-connection latency as the active server in the server list.
2. Confirm that the logs show the core loaded and listening on the local port configured in Settings.
3. Enable the system proxy and visit two different websites in a browser.
4. Check that the exit IP matches the selected node region and that direct-routing rules behave as expected.
5. Disable the system proxy and visit the sites again to confirm that changing the proxy state changes the traffic path.

Common main-window problems and troubleshooting order

Most main-window issues do not require an immediate reinstall. Confirm the group and active server first, then check the core and port, and finally inspect the system proxy and routing mode. This separates subscription, node, and local proxy problems. Change only one variable at a time and retest after each change for clearer results.

Once the main window is familiar, daily use can follow a short routine: update the relevant subscription group, run a real-connection latency test, set the active server, enable the system proxy, read the logs, and verify the exit IP. When something fails, check these steps in reverse order to quickly determine whether app traffic never reached the local port or the core could not connect to the remote node.