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

1. Main window layout: configurations, core, and system proxy

v2rayN is a desktop client interface; cores such as Xray handle proxy connections. Seeing a server in the list only confirms that its configuration is saved. Selecting a server doesn’t prove that your browser is using the proxy, either. To confirm connectivity, check that the configuration works, the core is running, and the app’s traffic is reaching the local listening port.

When you first open v2rayN, maximize the main window and locate the top menu, subscription groups, server list, log panel, and status bar. Some versions hide the log panel, and window size can affect which buttons are visible. Here, “system proxy” refers to the Windows proxy settings—not a switch that connects to a remote server.

2. Server list: import, select, and set an active server

The server list typically includes columns for type, alias, address, port, transport, and test results. VMess and VLESS are protocol names; TCP and WebSocket are transport settings; TLS and REALITY are connection security settings. Don’t infer a node’s protocol from its alias, or assume two nodes are configured the same just because both use port 443.

Start by testing one configuration from a trusted source before organizing multiple entries. When copying a share link, keep it intact: don’t truncate the encoded content after vmess:// or remove query parameters from a vless:// link. Add subscription URLs through subscription group management rather than importing them as individual nodes.

1. Import a configuration

   Copy the complete share link, then in the main window choose “Server” → “Import batch URLs from clipboard.” If your version uses a different label, choose the option that includes “Import from clipboard.”

2. Check the node

   Find the new row, then use the right-click menu’s “Edit server” option to check the address, port, and transport settings. The remote port, such as 443, is set by the server. Don’t change it to the local listening port, 10808.

3. Set it as active

   Right-click the target row and choose “Set as active server.” Confirm that the active marker changes, then check the logs to see whether the core loaded the new configuration successfully. A selected row highlight alone doesn’t mean the server was switched.

4. Test the connection

   Run “Test server real connection latency” for the row, then open the website you actually need. A successful test only confirms that the specific test request worked; still check the system proxy and any proxy settings in the app itself.

Interpret test results according to the test type. For example, a TCPing result of 42 ms and a real connection latency of 310 ms aren’t contradictory: the former mainly measures the TCP handshake, while the latter also includes the proxy handshake and test request. These are example readings, not measurements from a particular node, and they don’t predict download speed.

3. Subscription groups: filtering the list doesn’t switch connections

A subscription group holds a subscription URL and the servers it generates. It manages where configurations come from and how they’re updated; it doesn’t choose the best node for your network. When you switch groups in the main window, the list shows only that group’s servers, but the active server may still belong to another group.

To add a subscription, go to “Subscription groups” → “Subscription group settings,” create a group, enter a note and subscription URL, and save. Then return to the “Subscription groups” menu and update it. Common versions offer “Update all subscriptions” and options to update “through proxy.” Choose the update method based on whether you can access the subscription URL directly.

• First import: If you don’t have a working node yet, try updating without a proxy first. If the subscription URL is only accessible through a proxy, import a working individual node first.
• Update through proxy: First confirm that the active server can access websites. Enabling this option won’t fix a failed node.
• List is empty after updating: Check whether another group is selected or a search term is still applied. Then check the update results for the node count and any errors.
• Similar names: Distinguish groups by source and purpose, such as “Primary subscription” and “Backup subscription.” Notes help identify groups but don’t change connection settings.

Subscription URLs often contain access tokens; treat them like account credentials. When troubleshooting, you can share the update time, error type, and node count, but don’t post the full subscription URL in a public screenshot. A successful update only means the client fetched and parsed the content—it doesn’t confirm that each node can connect.

4. System proxy and routing: what each setting controls

In the Windows version, open “System proxy” in the status bar or right-click the app icon in the taskbar notification area, then choose “Set system proxy” or “Clear system proxy.” The first points the system proxy to the client’s local listening address; the second removes that system proxy setting. Clearing it doesn’t necessarily stop the core, and apps with manually configured proxies may still use it.

Routing is a separate layer. After traffic reaches the core, routing rules decide whether it goes through the proxy, connects directly, or gets blocked. So setting the system proxy doesn’t mean all traffic will go through the remote server. Likewise, global proxy routing won’t capture apps whose traffic never reaches the core.

For example, if a browser works but a command-line app doesn’t, first check whether that app reads the Windows system proxy instead of switching nodes right away. Conversely, if all apps that honor the system proxy fail, check the local listener, active server, and core logs first.

5. Settings: check local listening and remote server parameters

Go to “Settings” → “Parameter settings” and check the local listening ports, whether LAN connections are allowed, the log level, and core-related options. Depending on the version, these may be under tabs named “Basic settings,” “Core,” or something similar. Don’t assume the default ports from an old guide still apply. After saving, check that the core reloads successfully.

The cards below illustrate how the parameters relate; they aren’t fixed values to copy. The first assumes the mixed listening port is set to 10808. The second lists the details to check with your provider when editing a remote node. The client’s local port and the server’s remote port belong to separate connections.

If an older configuration uses separate ports for the HTTP proxy and SOCKS5 proxy, such as 10809 and 10808, don’t move every app to 10808 just because that’s the mixed-port example above. First check how the client is actually listening. For local use, keep the loopback address and disable LAN access. If you need to share the proxy, configure the listening scope, firewall, and access controls separately.

6. Log panel: troubleshoot startup, listening, and requests

First expand the log panel in the main window. If it’s hidden, look in the menus for “Logs” or “Show logs.” Then switch the active server once and check the new startup entries, followed by a single website request. A controlled test at a specific time is easier to diagnose than searching through a large backlog for red text.

More errors in the log don’t necessarily mean a more serious problem, and no errors doesn’t prove that traffic reached the core. The log level controls how much detail is recorded. For a short troubleshooting session, adjust the relevant logging options under “Settings” → “Parameter settings,” then restore the original settings to avoid generating excessive logs.

To check which process is listening on a port, run this read-only command in PowerShell. Replace 10808 with the port shown in your settings. OwningProcess is the process ID; look it up under the “Details” tab in Task Manager. No output, or a message that no object was found, means there’s no matching TCP listener on that port.

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Before sharing logs, redact sensitive information such as subscription tokens, user IDs, server addresses, and visited domains. The error time, core name, relevant error message, and action you just took are usually more useful for reproducing the issue than a complete configuration.

7. Common questions about the main window

Follow the same checks each time: confirm the active server, check whether the core started, verify the system proxy or TUN connection, then check routing and the target request. Checking each layer separately helps pinpoint whether the issue is the configuration source, local access, or remote connection.