This guide is for anyone opening v2rayN for the first time or looking for features after an upgrade. Using the v2rayN 7.15.4 interface as a reference, it explains the menu bar, subscription groups, server list, runtime logs, and settings in order. By the end, you’ll know which group a node belongs to, which node is active, where to look when a connection fails, and how to verify the Core type and local ports.
Start with the main-window map
Interface note
The v2rayN window is easiest to understand as five areas arranged by workflow: the top menu issues commands, subscription groups organize configuration sources, the server list displays and selects nodes, the log area reports runtime activity, and the bottom status area shows the current proxy mode, active server, and local listening ports. When troubleshooting, follow this chain instead of jumping repeatedly between unrelated menus.
Interface note
Icons or menu labels may shift between 7.x releases, but the data relationships are mostly unchanged. A subscription group is not a node, and a node is not necessarily the outbound currently running. A configuration participates in connections only after it is set as the active server and the corresponding core is started. Whether the system proxy is enabled is a separate switch that determines whether browsers and other applications hand traffic to v2rayN.
Two ways to read the main window
Everyday connection flow
- Choose the right subscription group
- Run a real connection latency test
- Set it as the active server
- Confirm the system proxy mode
Troubleshooting flow
- Check the active server name
- Inspect core startup logs
- Verify ports 10808 and 10809
- Check routing and DNS records
Everyday use moves from the group to the status bar; troubleshooting works in reverse, tracing from the status bar back to the server configuration and core logs.
Interface note
The “Server” menu handles individual configurations, including adding, editing, deleting, importing, and setting an active server. “Subscription Groups” manages subscription URLs and update actions. “Settings” contains system proxy, routing, general parameters, and core-related options. For a first setup, remembering these three entry points is enough; use the other menus when you need to export, back up, or check version information.
What each server-list column means
Interface note
The server list is a configuration inventory, with each row representing an outbound configuration the core can read. The address, port, protocol, and transport come from a subscription or manual entry; latency and speed are results from tests run on your machine. Test results are not permanent measures of node quality—network paths, server load, and test timing can all change the numbers.
Interface note
“Alias” is usually the node name supplied by the subscription provider, identifying a region, route, or purpose. “Address” is the remote hostname or IP address, while “Port” is the port listened to by the remote service—do not confuse it with the local port 10808. “Network” may show transports such as tcp, ws, or grpc; “Security” may show tls, reality, or none. Protocol fields such as VMess and VLESS must be read together with the transport fields; no single column describes the complete connection requirements.
| List field | What it shows | How it helps with troubleshooting |
|---|---|---|
| Alias | Node name and route label | Confirm that the selected row belongs to the intended region or group |
| Address / Port | Remote server endpoint | Identify resolution failures, unreachable ports, or malformed subscription data |
| Protocol | Outbound protocols such as VMess and VLESS | Determine which core and protocol parameters should handle it |
| Transport / Security | Combinations such as TCP, WebSocket, gRPC, TLS, and Reality | Verify fields such as the path, SNI, fingerprint, and Flow |
| Real connection latency | Response time measured after the proxy handshake | Closer to the actual cost of establishing a proxy connection than a standard ping |
| Speed | Throughput measured during a download test | Distinguish low-latency nodes from high-bandwidth nodes |
Interface note
For example, two configurations in the same group may show real connection latencies of 186 ms and 312 ms; the first is usually better for web browsing. If download tests report 4.8 MB/s and 12.4 MB/s, the second may be better for transferring large files. Latency and bandwidth measure different things, so do not sort by one column and permanently lock in a node.
Interface note
Select a row and choose “Set as active server.” The interface usually marks the current configuration with a highlight, color, or status-bar label. Simply clicking a row normally selects it; it does not prove that the core has switched. After switching, check the active server name at the bottom, then look for a new outbound-configuration load entry in the logs.
How subscription groups organize nodes
Interface note
Subscription groups store subscription URLs, update rules, and the server list generated from each source. A group can contain multiple node configurations and can have its own update behavior. Keeping work, testing, and backup routes in separate groups makes problems easier to isolate than putting every node in one long list, and reduces accidental deletion or switching.
Interface note
When updating a subscription, v2rayN requests the content and parses the supported configurations. A successful update only means the client retrieved and processed the subscription data; it does not mean every node can connect. After an update, check whether the list count and aliases changed, then run a real connection test on the target group. If the list is empty after switching groups, check the filter first instead of immediately adding the subscription again.
-
Confirm the current group
Interface note
Select the target group in the subscription-group area of the main window and record the node count before updating—for example, 18 entries—so another source’s list is not mistaken for the update result.
-
Check subscription settings
Interface note
Open “Subscription Groups” → “Subscription Group Settings” and verify the enabled state, notes, and matching subscription URL. Use notes to distinguish groups with the same name.
-
Update the group
Interface note
Choose “Subscription Groups” → “Update Current Subscription” and wait for the completion status. To refresh every source, choose “Update All Subscriptions” instead.
-
Test a working configuration
Interface note
Select the target row in the server list and run a real connection latency test. A concrete result such as 186 ms indicates that the full proxy handshake succeeded; a blank result or timeout means you should inspect the logs.
-
Verify the core type
Interface note
Go to “Settings” → “Parameters” → “Core Type” to open the core-selection area. Confirm that the target protocol is assigned to Xray or v2fly, save the change, and restart the core.
Interface note
A smaller node list after an update does not necessarily indicate a parsing error; the subscription source may have changed its routes. Compare the node count, aliases, and protocol column, and check the update log for unsupported configuration types. Manual edits to subscription-generated nodes may be overwritten by the next update, so long-term custom configurations are better kept in a separate group.
What to look for in the log panel
Interface note
Logs are most useful for locating where the connection chain stops, not for reading line by line. During startup, check whether the configuration loaded, the core process is running, and the local ports are listening. During access, check DNS, route matching, and the remote connection result. If startup has already failed, changing browser proxy or routing rules usually will not help.
Interface note
A typical successful sequence is: v2rayN generates the runtime configuration, starts the Xray or v2fly core, establishes a local listening address, and then receives application traffic through 127.0.0.1. Older versions commonly use SOCKS port 10808 and HTTP port 10809; some 7.x configurations use a mixed listener, so always follow the local ports shown under “Settings” → “Parameters”.
Startup check example
Core: Xray
SOCKS: 127.0.0.1:10808
HTTP: 127.0.0.1:10809
Active server: HK-02 VLESS Reality
Routing: domainStrategy = AsIs
Test result: true connection latency 186 ms- Port already in use: When the log shows bind, address already in use, or a listening failure, close the old process using 10808 or 10809, or choose an unused port in the parameter settings.
- DNS resolution: When entries such as resolve or DNS timeout appear, check the DNS configuration and whether the current network can perform basic resolution before changing the query method.
- Remote timeout: When you see connection timeout or context deadline exceeded, retest other nodes in the same group to distinguish a single-node failure from a local network problem.
- Authentication failure: If the log points to a user ID, key, Reality public key, or shortId, update the subscription and verify the configuration fields. Repeating speed tests will not fix incorrect parameters.
- Routing rejection: If the connection is handled by a block outbound, check the rule order and the relationship between inboundTag, domain, ip, and outboundTag.
Interface note
A warning in the log does not necessarily interrupt the connection. For example, the core may continue listening after ignoring a compatibility option. Prioritize errors that terminate the process, prevent configuration parsing, or stop the listener. Start with the first critical error near startup, then review the follow-up errors it triggered.
Interface note
When reproducing a problem, clear the old log or note the current time, then perform only one target action. For example, switch nodes at 14:32:10 and open a test page at 14:32:15, then focus on that interval. This prevents timeouts from hours earlier being mistaken for the current issue and makes it easier to compare the active server and routing results before and after the switch.
Core settings and four key parameter groups
Interface note
Not every commonly used v2rayN switch is in the server editor. The individual server editor handles remote protocol parameters; local listening ports, Core type, log level, and some DNS behavior are under “Settings” → “Parameters”. System proxy and routing modes sit one layer higher as traffic-entry and split-routing controls, so be clear which layer you are changing.
Interface note
Core type determines which core processes the configuration. On desktop, v2rayN commonly uses Xray for VLESS, Reality, and similar configurations, but v2fly can be selected according to the protocol mapping. After changing the Core type, save the settings and restart the core, then verify the actual core name in the logs. Changing the dropdown without restarting may leave the current process on the old setting.
Local proxy endpoint
- SOCKS address
- 127.0.0.1
- SOCKS port
- 10808
- HTTP port
- 10809
- Purpose
- Receive traffic from local applications
Use the actual value shown in the parameter settings; manual browser proxy settings must use the same port.
Core type
- Menu path
- Settings → Parameters
- Common cores
- Xray
- Available cores
- v2fly
- How to apply
- Save and restart the core
The selection should match the server protocol and transport parameters, then be verified against the startup log.
System proxy mode
- Off
- Leave the system proxy unchanged
- Auto-configure
- Submit traffic according to the rules
- Global
- Send system traffic to the local proxy
- Where to check
- Main-window status area
If the core is running but web pages still connect directly, first confirm that the system proxy mode matches your expectations.
Logs and routing
- Log level
- warning / info
- Troubleshooting level
- info
- Domain strategy
- AsIs
- Key rule settings
- outboundTag
After troubleshooting, restore your usual log level. After changing routing, verify it with the actual target domain.
Interface note
System proxy mode, Core type, and routing mode form a chain: the application first submits the request to a local proxy port, the core then reads the server configuration, and routing rules finally choose a direct, proxied, or blocked outbound. When a page will not open, troubleshoot in that order. Changing the Core type alone may only change the symptom while leaving the actual port, node, or rule error untouched.
Common main-window questions and quick checks
Interface note
Once the interface is familiar, most issues fit into four categories: the group did not update, the node was not set as the active server, the core is not listening properly, or system traffic is not reaching the local proxy. Identify the category first; this is more reproducible than repeatedly switching nodes or importing the subscription again.
Why does double-clicking a node still use the old route?
Interface note
Check the active server name in the bottom status area first. If it has not changed, right-click the target row and choose “Set as active server,” then restart the core and confirm in the log that the new configuration loaded.
The subscription says the update succeeded. Why is the list unchanged?
Interface note
Make sure you are viewing the group that was just updated, and clear any list filters. Record the counts before and after—for example, 18 entries in both cases. If neither the count nor the aliases changed, the subscription content itself may simply be unchanged.
The real connection latency is blank. Where should I look?
Interface note
Check whether the core started, then inspect DNS, connection timeouts, and authentication entries during the test period. If port 10808 failed to listen, resolve the port conflict first; the latency test needs a working local entry point.
The core is running, but the browser still connects directly. Why?
Interface note
Check the system proxy mode and the browser’s own proxy settings. For manual setup, point SOCKS to 127.0.0.1:10808 and enter the HTTP port shown in the parameter settings. Do not substitute the remote server port.
How can I confirm that a routing-mode change took effect?
Interface note
After restarting the core, visit one target expected to connect directly and another expected to use the proxy. In info-level logs, check the matched outboundTag. If every request reaches the same outbound, inspect the rule order and fallback-rule position.
Interface note
Finish the main-window check with this fixed sequence: confirm the group, select a node, run a real connection test, set it as the active server, verify the system proxy, open the target page, and read the logs for that time window. Each step produces a clear result in the interface, so an anomaly can be handled at the current layer without changing the subscription, ports, core, and routing all at once.