When v2rayN opens for the first time, the main window presents buttons, server rows, group tabs, and scrolling logs all at once. There is plenty of information, but the workflow is straightforward. Think of the main window as five layers: the top command area starts actions, the subscription and group area narrows the scope, the server list selects a configuration, the log pane reports results, and the bottom status area confirms the current proxy state.
Button layouts may vary across versions, desktop platforms, and window widths, and some labels may differ slightly. The core relationship remains the same: subscriptions provide server configurations; those configurations are passed to the Xray core; the core creates local inbound ports and forwards traffic according to routing rules; the system proxy or TUN mode then determines which application traffic enters those ports. Once this chain is clear, most controls in the interface have an obvious place.
Build a map of the main window from top to bottom
The top of the main window usually combines a menu bar with shortcut commands. The menu bar contains the full feature set, while shortcuts keep frequent actions close at hand, such as adding a server, updating subscriptions, testing servers, setting the active server, and opening settings. When the window is narrow, some buttons may move into a More menu. If an icon seems missing, expand the relevant menu before assuming the feature was removed.
The middle section is the heart of server management. It usually includes subscription-group controls, search or filtering tools, and the server table, which takes up most of the available space. Each row represents an outbound configuration that the core can use. Configurations may come from manual entry, imported share links, bulk clipboard imports, or subscription updates. VMess, VLESS, and other protocols can appear in the same list, but every row retains its own address, port, transport, and security parameters.
A log pane usually sits below the server list. Logs are not decorative; they are the first evidence of whether an action succeeded. Results from updating subscriptions, starting the core, switching servers, enabling the system proxy, or establishing connections appear there. The status area at the bottom provides a quick view of the active configuration, local ports, proxy mode, and core status.
For everyday use, follow a consistent viewing order: check the current group, then the active server, then the proxy mode, and finally the logs for recurring errors. This is faster than repeatedly opening the settings page and helps prevent confusing “a node exists in the list” with “traffic is actually being forwarded through that node.”
What the top menus and shortcuts do
Server commands: manage individual configurations
Server menus handle one or more configuration rows. Common actions include manual entry, clipboard import, editing, copying, deletion, latency testing, and setting the active server. The edit dialog is useful for checking protocol parameters, but subscription-generated configurations should not be modified permanently: the next subscription update may overwrite the row with the server-provided values.
When editing a VLESS configuration manually, the address, port, user ID, transport, security layer, SNI, fingerprint, and flow fields must match the server configuration. VMess likewise requires matching user ID, alterId or compatible parameters, transport, and TLS settings. Even a server name that looks correct will not establish a usable connection if a critical field differs.
Subscription commands: generate and refresh configurations in bulk
Subscription controls manage a set of server records maintained remotely. The usual workflow is to add a subscription URL and then run an update. After v2rayN retrieves and parses the content, recognizable records are placed in the relevant subscription group. A successful update does not mean every node works; it only confirms that the subscription was retrieved and converted. Connectivity still needs to be tested separately.
If many servers with identical names suddenly appear, do not delete them row by row immediately. First check whether the same subscription was added more than once or placed in multiple groups. Manage the source in subscription settings so duplicate records do not return during the next update.
Testing commands: distinguish connectivity, latency, and real-world speed
The testing menu may offer several types of results, and they are not interchangeable. Port reachability only means that a basic connection can be made to the destination address and port. Actual latency usually measures a proxied request to a specified test target. Download speed is also affected by the test resource, route congestion, and your local network. A row with lower latency is not necessarily faster for large transfers, nor does it guarantee the same path to every website.
| Action | What it answers | What it cannot prove |
|---|---|---|
| Port test | Whether the target host and port are reachable | Whether all protocol parameters are correct |
| Real latency | The approximate round-trip time for a proxied request | Whether sustained download speed is stable |
| Speed test | Throughput under the current test conditions | Performance at other times and with other targets |
How to read each server-list column
The server list is the core of the main window, but you do not need to watch every column at once. New users should start with the alias, address, port, protocol, transport, security layer, subscription group, and test result. The remaining columns are useful for deeper diagnosis and can wait until they are needed.
Alias and active marker
The alias is a local display name used to identify a region, route, or purpose. It is not part of the network handshake. The active marker indicates the currently selected outbound configuration; the two should not be confused. Renaming an alias does not change connection parameters, although a subscription update may change the name again.
Address and port
The address is the server domain or network address, while the port is the service entry point being listened on by the server. Together they determine where the client connects first. If the logs repeatedly show connection timeouts or refusals, check the local network, DNS resolution, address, and port before changing routing rules. Routing decides which outbound path receives traffic; it cannot repair an unreachable server endpoint.
Protocol, transport, and security
The protocol column commonly shows VMess or VLESS. The transport column may show TCP, WebSocket, gRPC, or other methods; security-related columns may show TLS, REALITY, or version-specific settings. These fields work together to define the connection and cannot be judged by protocol name alone. Two VLESS configurations still cannot share parameters if their transport, security layer, or flow differs.
To keep the table compact, the list often shows only a summary. Open the edit dialog to confirm SNI, Host, path, service name, fingerprint, and other complete details. Use the server-provided information as the source of truth rather than guessing from the node name.
Subscription groups and test results
The subscription-group column shows which source manages the row. It helps locate duplicate nodes and bulk-update issues. The test-result column may show a latency value, an error, or nothing. A blank usually means that the relevant test has not been run; it does not directly mean the node is dead. Interpret failures alongside the logs to determine whether the test target was unreachable, the server timed out, or the protocol handshake failed.
How to organize and update subscription groups
One list is enough when you have only a few servers. As subscription sources grow, groups determine whether the main window stays manageable. Organize groups by source or purpose instead of repeatedly renaming them around temporary latency results. Source-based groups clarify update ownership, while stable aliases can describe intended use.
- In subscription settings, give each URL a clear name instead of keeping a long, hard-to-recognize address.
- Update one new subscription first, verify the parsed result and server count, and then run the full update.
- Switch to the relevant group in the main window and check that the protocol, address, and aliases are as expected.
- Run real-latency tests on a small selection of servers; there is no need to speed-test every record each time.
- Set a confirmed working configuration as the active server, then watch the status area and logs.
If the server count drops to zero after a subscription update, common causes include an unreachable subscription URL, an empty response, an unrecognized format, or changed subscription permissions. Start with the subscription-update logs. If they clearly show a network request failure, the problem occurred during retrieval. If the request succeeded but produced no configurations, inspect the returned content and parsing result.
Subscription nodes are best maintained by the subscription itself. If you need to preserve custom parameters for the long term, create a separate manual configuration and give it a clear, distinct alias. Otherwise, the next update may restore the original subscription values and remove your changes to the path, SNI, or port.
Group filtering only changes which rows are visible; it does not change the core’s routing rules. In traffic routing, “groups” usually means rule sets, outbound tags, or domain categories, which is a different layer from subscription groups in the main window. The former determines how a connection travels; the latter mainly organizes server configurations.
How to read the log pane in the right order
Start reading the logs at the time the action was triggered rather than looking only at the final line. A normal startup typically includes configuration generation, core startup, and local inbound-port listening. When application traffic enters the proxy, logs may then show the destination, routing decision, or reason for failure. Output formats vary by version, but the “action—target—result” method applies broadly.
First, determine whether the core started
If switching the active server immediately produces a configuration error, the core may not have reached the listening stage. Even if the system proxy is enabled, traffic cannot be forwarded through a local port. Open the relevant server configuration and check required fields, port formatting, transport parameters, and security parameters.
Next, determine whether the local port is listening
After startup, the core creates local SOCKS, HTTP, or mixed inbound ports. The exact ports are defined in settings. If the logs report that a port is already in use, another v2rayN process, a different local networking program, or a leftover process from an abnormal exit may have claimed it. Check for duplicate processes first, then consider changing the local port.
Finally, determine whether the remote connection and routing work
A connection timeout usually means that the target server is unreachable, the network path is blocked, or address resolution failed. A connection refusal means the host is reachable but the relevant port is not accepting connections. Handshake or authentication errors more often point to mismatched protocol, security-layer, time, or server parameters. If only certain websites fail while other requests work, continue by checking DNS and routing rules rather than declaring the entire server unusable.
| Log symptom | Check first | Next action |
|---|---|---|
| Configuration parsing failed | Server fields and core configuration | Open the current row and verify the protocol and transport parameters |
| Local port already in use | Duplicate processes and inbound ports | Stop the duplicate process or change the local listening port |
| Connection timed out | Server address, port, and local network | Test the port and switch to a confirmed working server |
| Handshake failed | TLS, REALITY, SNI, flow, and related parameters | Check each field against the server-provided information |
| Only some domains fail | DNS and routing matches | Check domain-rule order and the resolution strategy |
Before sharing logs for troubleshooting, remove server addresses, user IDs, subscription URLs, and other account information. Do not leave the log level at its most verbose setting indefinitely. Detailed output is useful when reproducing a problem; normal logging is easier to use for finding important errors during everyday operation.
Four core areas in Settings
The settings page contains many options, but beginners only need to understand four areas: local ports, system proxy, core and routing, and TUN. Avoid changing many parameters immediately after the first launch. Change one item at a time and record its previous value so the log results remain comparable.
Local ports
Local ports are the entry points between applications and the Xray core. If a browser or another program uses a manual proxy, enter the listening address and port shown here. When system proxy mode is enabled, v2rayN writes the relevant information to the desktop system’s proxy settings. After changing a port, applications still using the old port will lose connectivity immediately, so update manual proxy settings as well.
System proxy mode
The system proxy determines whether applications that follow the desktop proxy settings send requests through v2rayN. Common states include set system proxy, clear system proxy, and leave system proxy unchanged; exact labels vary by version. “Leave unchanged” does not enable the proxy—it only means that v2rayN will not modify the current system value.
Some applications do not read system proxy settings, and some network traffic is neither HTTP nor SOCKS. In those cases, it is not contradictory for the system proxy to be enabled while the target program connects directly. First confirm the program’s proxy support, then choose between an in-app manual proxy and TUN mode.
Core and routing
Core settings control the runtime component, log level, DNS, and other foundational behavior. Routing settings assign different destinations to proxy, direct, or blocked outbounds. Default rules cover ordinary use, so beginners should avoid stacking many custom rules at once. Rules are evaluated according to their matching logic; overly broad domain or network rules can intercept traffic before later entries are reached.
After changing routing, test destinations intended for both direct and proxied access, and confirm the actual outbound path in the logs. Whether a webpage opens does not show whether split routing worked as intended: both direct and proxied access may succeed, but through different paths.
TUN mode
TUN mode uses a virtual network interface to take over a broader range of system traffic, making it suitable for applications that do not read system proxy settings. It involves routing tables, DNS, and permissions, so troubleshooting is more complex than with a standard system proxy. Before enabling it, confirm that the server works in ordinary proxy mode; otherwise, node problems and traffic-capture problems become entangled.
How one complete operation moves through these areas
Linking the interface areas together gives you a reliable first-use workflow. First, add a source in subscription settings and run an update. Second, return to the matching group in the main window and confirm that server rows were created. Third, select one row for a real-latency test and interpret the result with the logs. Fourth, set a confirmed working server as active. Fifth, choose the appropriate system proxy state. Sixth, visit a test destination while watching the logs for request and routing entries.
If there is no traffic after step five, check the bottom status area and system proxy first instead of re-adding the subscription. If the logs show traffic but the remote connection fails, return to the server row to verify its parameters or switch to another node. If only specific destinations fail, check DNS and routing. Each symptom belongs to a layer of the interface; troubleshooting by layer is more effective than toggling settings at random.
Before exiting v2rayN, confirm how the system proxy will be handled. If you plan to stop using it completely, use the program’s proxy command to clear the system proxy before exiting normally. If you are only minimizing it to the background, confirm that the tray status and active server remain normal. Depending on the settings, closing the window may hide the app in the background or terminate the program, so the core status cannot be inferred from whether the main window is visible.
Ten-minute checklist
- Subscription-group names clearly identify their sources, and the list contains no obvious duplicate subscription records.
- The active-server marker is clear; do not mistake clicking a row for switching servers.
- The address, port, protocol, transport, and security layer match the server configuration.
- Understand latency, port tests, and speed tests separately instead of judging everything by one number.
- The logs show that the core started and the local port began listening.
- The system proxy state matches the current use case, and manually configured proxy applications use the correct local port.
- After ordinary proxy verification is complete, consider custom routing or TUN capture.
- When something fails, read the logs from the time of the current action and troubleshoot in this order: configuration, local port, remote connection, then routing.
Once these areas are clear, the v2rayN main window is no longer just a collection of unrelated buttons. Subscription groups answer “where did the configuration come from?”, the server list answers “which configuration should be used?”, the active marker answers “which outbound server is current?”, system proxy and TUN answer “which traffic enters the core?”, and logs answer “at which stage did the request succeed or fail?”. This map remains useful as you move on to routing, DNS, and advanced transport parameters.