This guide is for desktop users opening v2rayN 7.14.3 for the first time. It covers the top menu, subscription groups, server list, log panel, and status controls in order, with precise steps for choosing an active server, updating subscriptions, checking local ports, and switching Core types. Button locations may vary between minor releases, but the configuration objects and troubleshooting sequence remain the same.
Start with the main window layout
Map the interface before taking action
The v2rayN main window is more than a simple node list. The top menu creates, imports, and edits configurations; subscription groups limit the data currently shown; the server list displays individual configurations; the log panel records Core startup, listeners, and connection results; and the status controls manage the system proxy, routing mode, and active server. Once these areas are clear, common tasks follow a consistent path.
The server list may be empty on first launch, which does not mean startup failed. Configurations appear only after importing a VMess or VLESS share link, or adding a subscription and running an update. If initialization logs are already visible at the bottom, the interface process is running. When the node count is still zero, check the import source before changing local ports.
Selecting a server and enabling a server are different actions. Clicking a row only moves the list focus. Double-click the row or use the context menu to make it the active server; the status area will then show its alias. Depending on your use case, you must also enable the system proxy. Browsers and desktop apps that follow the system proxy settings will send requests to the local listening port.
Workflow map: keep configuration management separate from traffic control
Complete in the main window
- Switch subscription groups and update nodes
- Choose an active server and test latency
- Review startup logs and connection errors
Complete in Settings
- Confirm the Xray or v2fly Core type
- Check the local listening port 10808
- Adjust routing mode and subscription update behavior
Load the configuration and establish the local listener first, then enable the system proxy. Checking these stages separately reduces interference between ports, nodes, and proxy status.
How to read the server list columns
Each row in the server list represents an outbound configuration that the Core can read. Column headers may vary slightly with window width, version, and display options. Common fields include alias, address, port, transport, TLS, subscription group, latency, and speed. The alias identifies the node for you; the address and port define the remote entry point; transport and security fields must match the server-side connection parameters.
To decide whether a node is worth troubleshooting, check configuration completeness before test results. Missing an address, port, user ID, transport, or security parameter usually makes latency tests meaningless. Latency is not download speed: a TCP or real latency test showing 86 ms only means that round trip was fast; it does not guarantee a fixed transfer rate for large files.
| List field | What it means | What to check |
|---|---|---|
| Alias | The local display name used to identify a node | When several nodes share a name, compare the address and group |
| Address | The remote server domain or IP address | Check for empty values, spaces, and truncated copies |
| Port | The port used to connect to the remote service | Must be between 1 and 65535 and match the server |
| Transport | Transport methods such as TCP, WebSocket, and gRPC | Paths, service names, Host values, and other fields must also match |
| TLS | Security layer and related server name settings | Check the server name, fingerprint, and Reality parameters |
| Group | The subscription or local category containing this configuration | Make sure the current filter is not hiding the target node |
| Latency | The millisecond value from the most recent test | For timeouts, check the logs instead of deleting a node based on one result |
Sorting the list only changes its display order; it does not switch the active server. After clicking the latency header, low-latency nodes may move to the top, while the connection still uses the item marked active in the status area. To switch, select the target row and choose “Set as active server,” then check the logs for a configuration reload.
The context menu is useful for individual or bulk configuration tasks, including editing or removing servers, testing latency or speed, and setting an active server. Before editing a subscription-generated node, check whether the upstream source will overwrite the change during the next update. When the address or transport parameters come from a subscription, correct them at the subscription source first.
How to switch and update subscription groups
A subscription group is a way to organize data, not a proxy protocol. One group can contain multiple VMess or VLESS configurations and can have its own update URL. Switching group tabs changes only the visible list; it does not automatically change the active server. Even after switching groups, the previous active item may continue running.
Before adding a subscription, make sure you have a subscription URL rather than a single-node share link. Content beginning with vmess:// or vless:// usually represents one configuration and can be imported from the clipboard. A URL that returns encoded content or a configuration list when opened in a browser belongs in a subscription group.
-
Open group management
From the main window, open the “Subscription Groups” management entry, click “+” to create a group, and give it a recognizable name.
-
Paste the URL
Enter the complete subscription URL in the address field. Check the protocol at the beginning, parameters at the end, and any spaces introduced while copying.
-
Save the group
Confirm and return to the main window. The new group may still be empty, so you need to run a subscription update manually.
-
Update subscriptions
Choose “Subscription Groups” → “Update all subscriptions,” wait for the completion status, and then check the server count.
-
Choose an active item
In the target group, select a configuration, test its latency, set it as the active server, and review the startup log at the bottom.
An update normally refreshes the group from the remote content. A manually deleted node may return during the next update, and edited aliases or parameters may also be replaced. Keep long-term custom configurations in a separate local group so they do not mix with automatically updated data.
Use multiple groups to organize sources or purposes, such as “Daily,” “Testing,” and “Backup.” Do not split groups only by protocol, because one subscription may contain both VMess and VLESS. During troubleshooting, record the group name, node alias, and update time; row numbers change after sorting or updating.
What the bottom log panel can tell you
The log panel is the first place to verify whether the Core actually started. After you set a server as active, v2rayN generates a runtime configuration and starts the selected Core. On success, you will usually see configuration loading, local listener creation, and runtime status messages. Missing fields, an occupied port, or parameters the Core cannot read will also appear here.
When reading logs, find the most recent error, failed, invalid, bind, or timeout entry first, then review the surrounding messages from that startup attempt. Do not let an older failure mislead you: switching nodes creates a new set of records, so use the time of your latest action as the boundary. The example text below illustrates the structure; exact wording depends on the Core type and version.
2026-08-28 10:18:42 loading configuration
2026-08-28 10:18:42 listening on 127.0.0.1:10808
2026-08-28 10:18:42 core started
2026-08-28 10:19:03 outbound connection timeout| Log clue | Check first | Action |
|---|---|---|
| address already in use | Local port 10808 is already in use by another process | Close the process using it, or choose an unused port in Settings |
| invalid config | The protocol, transport, or JSON configuration is invalid | Re-import the original share link and check for missing fields |
| timeout | The remote host is unreachable, subscription parameters are invalid, or the network path is blocked | Test another node and verify the address, port, and server name |
| connection refused | The target port is not listening or was actively refused by the remote host | Confirm that the remote port matches the subscription content |
| core started | The Core process has started | Continue by checking the system proxy status and actual request logs |
Seeing “core started” proves only that the local Core process is running; it does not prove that the remote node works. Visit a webpage and check for outbound connection records. If no new request appears, the system proxy may be disabled, or the target application may not follow system proxy settings.
A common local mixed listener is port 10808, but the actual value must come from Settings → Parameters. After changing the port, restart the Core and make sure the system proxy points to the same port. Changing the browser proxy without updating the application settings can leave it connecting to the old port.
The most useful settings to check
You do not need to review every advanced option when getting started. First check the Core type, local listening port, system proxy, and routing mode. The Core type determines which engine interprets the configuration; the port determines where local apps send traffic; the system proxy publishes the proxy address to apps that follow it; and routing determines whether requests use the proxy or a direct connection.
Go to Settings → Parameters → Core Type to confirm the current engine. Configurations using features implemented or extended on the Xray side, such as VLESS and Reality, generally use Xray; configurations intended for the v2fly Core should use the corresponding engine. The fact that imported fields are visible does not mean every Core can interpret all transport and security parameters. The startup log provides the final answer.
Core and listener
- Menu path
- Settings → Parameters
- Core type
- Xray or v2fly
- Common port
- 10808
- Listening address
- 127.0.0.1
After changing the Core or local port, reload the configuration and use the latest logs to confirm that the listener was created.
Proxy and routing
- System proxy
- Enable as needed
- Routing entry
- Settings → Routing Settings
- Matching criteria
- Domain, IP, port
- Common outcomes
- Proxy, direct, block
The system proxy determines whether requests enter v2rayN; routing rules determine which outbound handles them afterward.
- System proxy: Useful for browsers and desktop apps that follow system settings. After switching it, check that the status text changes accordingly.
- Routing settings: Rules are matched in order. When adding custom rules, handle local network addresses first, followed by specific domains or destination ports.
- Subscription updates: If an update fails, check whether the request needs to go through the enabled proxy under your current network conditions.
- Launch at startup: Before enabling it, complete one manual startup test to ensure the active server, Core, and local port all load correctly.
Routing mode and server nodes are separate dimensions. Switching the active server changes only the proxy exit; it does not rewrite routing rules. Switching routing rules does not change the node address. When some websites open but others fail, check both the matched routing direction and the actual outbound shown in the logs instead of repeatedly updating the subscription.
If the same subscription is also needed on Android, import it separately into v2rayNG or v2flyNG. v2rayNG uses the Xray Core, while v2flyNG uses the v2fly Core. Both can read compatible configurations from the same source, but system proxy settings, per-app proxy rules, and local listeners belong to each device and are not synchronized by the subscription.
Common first-use questions
These are the issues most likely to appear while working in the main window. Follow a fixed order: confirm that the list contains a complete configuration, confirm the active server, check the Core startup log, and finally inspect the system proxy and routing. Do not change the port, Core, and node at the same time, or it will be difficult to identify what changed.
Why can’t websites open after I double-click a node?
Check whether the status area shows that server as active, then confirm that the system proxy is enabled. Visit a webpage and watch the logs. If no new connection appears, check whether the application follows the system proxy and whether its proxy port matches 10808 in the parameters.
Why is the list still empty after a successful subscription update?
Switch to the corresponding subscription group and clear any list filters. If the group count is still zero, edit the subscription URL and verify that its response is actually a node list. Also check the update notice for parsing errors or the HTTP status.
Latency timed out. Should I delete the node?
Test two other configurations in the same group, then check whether the log points to DNS, a connection timeout, or an invalid parameter. A single test reflects current network conditions. If all three attempts fail and the remote address and port are unreachable, confirm the configuration status with the subscription provider.
Does switching groups automatically switch the current connection?
No. Group tabs mainly control which items are displayed, while the active server remains unchanged. Select the target node in the new group, choose “Set as active server,” and check the latest log to confirm that the Core reloaded.
What should I do if the log panel shows no access records?
Confirm that the Core reports a successful start, then check the system proxy status. If the target program has its own proxy settings, point them to 127.0.0.1 and the current local port. Restart the Core after changing the port so the program does not keep using the old value.
- Confirm that the address, port, protocol, and transport fields have loaded in the server list.
- Select a configuration and set it as the active server; do not confuse a “selected row” with an “enabled server.”
- Use the logs to confirm that the Core started and that a local listener was created on 127.0.0.1.
- Enable the system proxy, make an actual request, and watch for new inbound and outbound records.
- Adjust routing rules, automatic updates, and startup options only after the basic connection works.
After these five steps, the main window becomes a repeatable workflow: subscription groups provide configurations, the server list selects the active item, the Core turns the configuration into a running state, the local port receives application requests, and logs verify each step. When connection problems occur later, trace the same chain one stage at a time.