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

At a glance

This guide is for anyone who has opened v2rayN but isn't sure what each part of the window does. Find the menus, groups, server list and logs, then import a configuration, set an active server and enable the system proxy. Learn the difference between selecting a row, activating a server and routing an app through the proxy—and use the logs to pinpoint where a problem occurs.

Main window layout: find the controls, then check the status

v2rayN manages server configurations, subscriptions and local proxy access; the selected core handles the connection itself. Seeing a configuration in the server list only confirms that it was imported. It does not mean the core is running or that your browser is using it. Check each of these separately when troubleshooting.

This guide uses the commonly seen Chinese-language interface on Windows. Layouts may differ between desktop and WPF editions, and menu labels can vary by version. Subscription groups may appear in a sidebar or as tabs, while logs may be shown in a panel at the bottom. Look for features by what they do; you don't need to switch versions just to match the screenshots.

Window area	What it contains	When to use it
Top menu bar	Commands such as Server, Subscription Groups and Settings	Import configurations, update subscriptions and adjust options
Subscription groups	Group names and filtering controls	Check which set of servers you're viewing
Server list	Remarks, address, port, protocol and test results	Select a server, review its settings and run tests
Log panel	Client messages, core startup details and connection errors	Check the results after activating a server
Status bar	System proxy, routing and runtime details; available items vary by version	Check the current traffic entry point and routing mode

Use the top menu to perform actions and the status bar to verify the current state. Don't assume the proxy is working just because the window is open; the main client window may stay visible even if the core fails to start.

Menus and subscription groups: keep configuration sources organized

A single-server share link and a subscription URL are different kinds of input. The former describes one server and can be imported via Server → Import batch URLs from clipboard. The latter retrieves a set of configurations and should be added under Subscription Groups → Subscription Group Settings. Pasting a subscription URL as if it were a single-server link usually won't produce the server list you expect.

Open group settings

Choose Subscription Groups → Subscription Group Settings to find the add option. If your version has a plus button in the sidebar, make sure it opens the subscription group editor, not the single-server editor.
Save the subscription source

Enter a helpful name, paste the subscription URL into the URL field, then save. Subscription URLs may contain access tokens, so don't post an uncropped screenshot of the window in a public forum.
Update the server list

From the Subscription Groups menu, choose Update all subscriptions (without proxy). If the subscription source requires a proxy, first activate a working server, then choose Update all subscriptions (through proxy). The exact wording and parentheses may vary by version.
Check the selected group

After updating, select the target group and check whether its servers appear. If they don't, switch to All groups and clear the search field, then check the update result in the logs. Don't immediately import the subscription again.

Groups primarily organize configuration sources and filter the server list. Switching groups doesn't change the active server or automatically create routing rules based on the group name. Updating a subscription may also replace its server entries. Back up any manual changes you want to keep, or save them as a separate configuration, so they aren't overwritten by the next update.

Server list context menu: selection, activation and testing do different jobs

Clicking a row usually just selects it so you can use the context menu. To change the server actually in use, right-click and choose Set as active server, then check the active indicator and core logs. Double-clicking may open an editor in some versions, so don't treat it as a universal way to connect.

Two kinds of list actions: manage configurations and test connections

Configuration management

Edit server lets you review the protocol, address, port and transport settings.
Set as active server switches the current outbound configuration.
Sharing and exporting may expose authentication details; check who will receive them first.
Before deleting multiple entries, check the number of selected rows and the current group.

Connection tests

TCPing checks whether a TCP connection can be made to the target port.
Real connection latency sends a test request through the proxy route.
Speed tests use data; avoid running them repeatedly on every selected server.
Sorting only changes the list order. It doesn't mean the active server has changed.

Activate the target server first, then verify it using the logs and an actual request. A low latency figure in the list isn't a substitute.

When reviewing the list, check the remarks, protocol and server port before looking at latency. Remarks are just display names; they don't prove a server's location or availability. VMess, VLESS and other protocols have different authentication and transport requirements. Changing the protocol in a dropdown alone doesn't convert a configuration; use the original details from your configuration provider if you're unsure.

A blank test result may mean the server hasn't been tested yet. A timeout can also be caused by the test target, DNS or your current network. A successful TCPing only confirms that a TCP port is reachable; it doesn't verify TLS, authentication or subsequent proxy requests. Don't delete an entire group based on a single column of numbers.

Settings and status bar: separate local proxy access from outbound routing

Common options are under Settings → Parameter Settings. Note the original values before making changes, and change one setting at a time. The system proxy controls how apps that use system proxy settings connect to a local port. Routing rules determine which outbound the core uses for traffic. These are separate settings, not one universal on/off switch.

Local proxy entry point

Where to check: Settings → Parameter Settings
Listen address: 127.0.0.1 is the loopback address for this device
Listen port: Check the current interface and startup logs
How apps connect: System proxy or manual proxy settings in the app

The local listening port is not the remote port shown in the server list; the two don't need to match.

Core routing outbound

Where to check: The routing selector at the bottom, or Settings → Routing Settings
Matching conditions: Domains, IPs and other supported rule conditions
Common outbounds: Proxy, direct, block
Applies to: Traffic that has entered the core for processing

Changing a routing preset doesn't automatically route every app through the proxy.

Choose Set system proxy automatically in the System Proxy menu at the bottom to point the system proxy to the client's local listening port. Here, “automatically” means the client writes the system setting for you; it doesn't decide which websites should use a proxy. Routing rules still control that. Before exiting, use Clear system proxy to restore the setting, then check that the system settings are as expected.

127.0.0.1

Loopback address on this device, not a remote server

10808

Example port; check it against the actual listening port

2 layers

Check app access and core routing separately

For example, enter this address and port in an app's SOCKS5 settings only after the logs confirm that the local SOCKS listener is running at 127.0.0.1:10808. If that port is actually a mixed-protocol listener, use a protocol supported by the current core. TUN is a separate way to route traffic and may involve permissions, a virtual network adapter and routing changes. When first checking the main window, stick to one entry point to make problems easier to isolate.

Log panel: find the first relevant error by time

After switching servers, check the latest core startup log, then make a request. Startup success, an accepted connection and a failed connection each indicate a different stage. A message such as accepted usually means only that the local request was received; by itself, it doesn't prove the destination page finished loading.

Port binding failed: If you see address already in use, check whether multiple instances are running or another program is using the same local port. Identify the process holding the port before closing it, or change the listening port and update the app settings to match.
Connection refused: connection refused means the connection was explicitly rejected. First determine whether the address in the log is the local entry point or the remote server, then check the relevant process, address and port.
Name resolution failed: If you see an error involving lookup, check the domain in the error, your current network and the DNS path. Don't assume every server is unavailable.
TLS error: First check the system clock and the server name, transport and security settings in the configuration. Don't routinely disable certificate verification as a workaround.
Request timed out: timeout only tells you that one stage timed out. Use the preceding destination address and surrounding error context to narrow it down; don't diagnose it from the final word alone.

Common main window issues: check each part of the interface

Import succeeded, but why is the list still empty?

Clear the list search field and switch to All groups. If you added a subscription URL, save the group and then run an update from the Subscription Groups menu. Check the logs to see whether the configurations were retrieved; saving a group doesn't mean its servers have been downloaded.

I selected a server. Why didn't anything change in my browser?

Right-click and choose Set as active server, then confirm the core has started. Next, check that System Proxy at the bottom is set to Set system proxy automatically. If your browser has its own proxy settings, check those too. The row's background color alone doesn't indicate connection status.

Why don't the logs show anything new after I open a website?

Make sure you're viewing runtime logs, not subscription update messages, then check whether the app is using the local proxy. Log levels and panel filters can also affect what's shown. Check the relevant options under Settings → Parameter Settings as needed, but don't leave verbose debugging enabled indefinitely.

I clicked Close. Where did the main window go?

Check the Windows notification area, including hidden icons. Depending on your settings, the Close button may minimize v2rayN to the tray rather than exit it. Open the main window from the tray menu and check the system proxy and core status. To stop the app, use the tray's Exit command and make sure the system proxy has been restored.

Use a simple routine: choose a group, activate a server, check the system proxy and routing, make a request, then review the logs. Changing settings only at the relevant step helps keep subscription update failures, port conflicts and website access problems separate. For more setup help, see the user guide. For routing rules and DNS, see advanced configuration.