When you first use v2rayN, it helps to understand four things: the server list is where you choose a node, subscription groups organize sources, the log window shows what the core is doing, and settings control local listeners and traffic rules. This guide walks through each area, then ties them together in a practical check. It’s for anyone who has opened the client but isn’t sure why selecting a node is different from actually routing traffic through it.
The main window: nodes, sources, logs, and traffic settings
The key point: seeing nodes in the list doesn’t mean the core started successfully. Setting a node as active doesn’t mean your browser is using the proxy, either. v2rayN is a desktop configuration and management interface; the core handles connections, and app traffic must reach it through the system proxy, an app’s own proxy settings, or TUN.
The layout can vary across releases and desktop environments. Subscription groups may appear as tabs, a dropdown, or a separate panel; system proxy and routing options may be in the status bar or tray menu. The labels below refer to common menu names. If you can’t find an exact match, look for an equivalent in your current interface rather than relying on the position in an old screenshot.
- Top menu and toolbar: Look for “Servers,” “Subscription groups,” and “Settings.” These are mainly used to import, update, and configure.
- Server list: Check each node’s protocol, address, port, and test results, then set the one you want as the active server.
- Logs or information panel: Follow startup activity, connection records, and errors. In some layouts, you’ll need to expand the panel at the bottom.
- Status bar and tray: Check the system proxy, routing mode, and runtime status. Don’t rely on the highlighted row in the server list alone.
Server list columns: addresses, ports, and latency
Names such as VMess and VLESS in the node list refer to connection protocols, not client names. A remark is a label for identifying a node; it may come from a subscription or be edited by the user, and it doesn’t determine the destination. When troubleshooting, check the address, server port, transport, and security settings rather than judging availability by a location in the remark.
| Common column | What it means | What to check |
|---|---|---|
| Type / protocol | The protocol used by the node, such as VMess or VLESS. | Check it against the core’s capabilities and the full node configuration. The protocol name alone doesn’t tell you how fast it will be. |
| Alias / remark | The node’s display name. | Two nodes with the same name aren’t necessarily the same node. Editing a remark doesn’t change the server address. |
| Address | The remote server’s domain name or IP address. | If name resolution fails, start by checking the DNS error in the logs. |
| Port | The port the remote service listens on, such as 443. | This is the server port, not the local proxy listening port on your computer. |
| Transport / TLS | The transport method and related security settings. | The list often shows only a summary. Open the edit window to review the full configuration. |
| Latency / speed | The result of the most recent test of that type. | Check the test type, units, and time before comparing results. |
TCP connection tests, real connection latency tests, and download speed tests in the context menu measure different things. A successful TCP test only shows that a connection could be established at that time. Real connection tests depend on the test address and proxy route; download speed also depends on the test source, node load, and local bandwidth. A blank column usually means the test hasn’t been run. If a test times out, check the logs before concluding that all apps are unable to connect.
- Sorting changes the display order; it doesn’t automatically switch to the first node in the sorted list.
- Before running a batch test, check which nodes are selected so you don’t mistake one group for the full list.
- Before sharing a screenshot, hide server addresses, user identifiers, and subscription URLs. Don’t share a complete configuration publicly.
Subscription groups: switching views vs. updating nodes
Subscription groups organize node sources. Selecting a group mainly changes which nodes are displayed; it doesn’t switch the active server or start a subscription update. If a new group is empty, you may have saved the URL but not updated it yet. If nodes seem to disappear after switching groups, you may simply be viewing a different subset.
-
Open subscription group settings
In the main window, go to “Subscription groups” → “Subscription group settings” and add an entry. Some layouts have an Add button in the group panel that does the same thing.
-
Save the subscription URL
Enter a recognizable group name, paste the full subscription URL into the address field, and save. A subscription URL serves a different purpose from a share link for a single node; don’t paste a single-node link into the subscription URL field.
-
Update the subscription
Go back to “Subscription groups” and choose the menu item for updating the current subscription or all subscriptions. If the interface offers both a direct update and an update through the proxy, choose the option that matches your current network access.
-
Check the update result
Review the update notification and logs, then return to the group and check the node count. If the update fails, keep the original error text instead of repeatedly deleting and recreating the group.
-
Activate the node you want
In the group, right-click the node you want and choose “Set as active server” or an equivalent activation command. Then check the active indicator and the core’s startup result. This is where switching groups connects to choosing the server used for the connection.
Subscription updates may recreate nodes from the source, so edits to subscribed nodes may not survive the next update. Keep manual configurations in a separate group if you need them to persist. Before deleting a group, check whether its server entries will also be removed. Subscription links often contain access credentials; when troubleshooting, share only a redacted URL structure and the error message.
The bottom log window: finding connection problems in startup output
Logs help you identify which step failed; they don’t provide a one-click fix for every problem. First choose an active node, observe a core startup, then open a test webpage. Following this sequence is more useful than picking a red line from a long history at random. Client messages and core output may share the same panel, so distinguish a failed subscription update from a failed proxy connection.
| Log term | What it usually means | What to check next |
|---|---|---|
address already in use | The local address or port to bind is already in use. | Check whether the client is running twice and whether another program is using the local listening port. |
failed to parse | A configuration value couldn’t be parsed. | Read the rest of the line and check the imported content, field values, and whether the selected core supports them. |
no such host | The relevant domain name didn’t resolve to a valid result. | Identify whether the domain in the error belongs to the subscription URL, a node address, or the destination you’re visiting, then check the corresponding DNS path. |
connection refused | The connection to the destination address was refused. | Check the address and port in the error. Determine whether the local proxy isn’t listening or the remote service refused the connection. |
timeout | A step didn’t finish within the allowed time. | Use the surrounding log lines to determine whether DNS resolution, connection setup, the handshake, or a test request timed out. |
These are search terms, not exact error messages. A startup sequence may show a warning before the error that actually caused it to exit. Keep several lines before and after the failure. A destination domain in the connection log only shows that the request reached the core’s processing path; it doesn’t prove the page loaded successfully.
General and routing settings: separate local entry points from outbound rules
“Settings” → “Parameter settings” usually controls client behavior, local listeners, and related basics. “Settings” → “Routing settings” manages traffic-matching rules. The tabs and fields can move between versions, but the two sections serve different purposes: the former determines which local entry point apps use to hand off traffic; the latter determines which outbound route the core selects.
Check the local listener
- Where to find it
- “Settings” → “Parameter settings”
- Fields to check
- Local listening address, port, and proxy protocol
- Example address
127.0.0.1- Example port
10808; use the value shown in your current interface
The proxy type and port entered in an app must match the listener that’s actually configured.
Check routing rules
- Where to find it
- “Settings” → “Routing settings”
- Fields to check
- Rule conditions, order, and outbound destination
- Match criteria
- Domain names, IP addresses, and other conditions
- Verify the result
- Use access logs to confirm the actual outbound route
After saving a rule, make sure the expected routing configuration is enabled in the main window.
Don’t change the listening port, DNS, routing, and core all at once just to fix one webpage. First determine whether traffic isn’t reaching the client or is taking the wrong route after it gets there, then change the relevant setting. Don’t switch cores based on their names alone: the selected core must support the node’s protocol and any extended parameters. Starting successfully and completing a handshake are two separate checks.
These three numbers distinguish the roles of addresses and ports; they aren’t values you should change everything to. If an app is set to 127.0.0.1:10808, make sure that port actually provides the proxy protocol the app is configured to use. A remote node on port 443 doesn’t mean local apps should also use port 443.
System proxy and TUN: validate one route at a time
The system proxy makes proxy settings available to apps that follow them; it doesn’t guarantee that every program will use the proxy. TUN captures traffic covered by its configuration through a virtual network interface and involves permissions, routing, and DNS. When getting started, validate one route at a time so you know where requests are entering if both modes are enabled.
Choose a test based on how the app handles traffic
Test the system proxy first
- In the main window’s status bar or tray, open “System proxy” and choose an option such as “Automatically configure system proxy.”
- Open a test page in a browser that follows system proxy settings and check the logs at the same time.
- If the app has its own proxy settings, check its address, port, and proxy type separately.
Test TUN if needed
- Note the current system proxy state, then follow the client’s prompts to grant the required permissions and enable TUN.
- Check the virtual interface and related startup logs; don’t rely only on whether the toggle is on.
- If something goes wrong, undo the changes from this test first, then check DNS and routing. Avoid piling on more changes.
Verify using the target app’s actual connection result and the corresponding logs, not the color of a toggle.
The routing mode in the main window and the system proxy toggle are also separate settings. The former controls traffic routing inside the core; the latter affects whether apps send requests to the local proxy. After changing a setting, make a new request and check again. Existing long-lived connections may not immediately reflect the new route.
Common interface questions and a first-check sequence
I clicked a node. Why doesn’t my traffic seem to use it?
First check whether you only selected the row. Use “Set as active server” or an equivalent activation command, confirm the active indicator and startup logs, then make a new request. Next, check whether the app uses the system proxy, its own proxy settings, or TUN. A highlighted row alone doesn’t tell you which route your traffic is using.
The subscription updated successfully. Why is the list still empty?
Return to the group you just updated, clear any search terms, and check whether another filter is active. Then review the number of valid nodes in the update result. A successful request doesn’t guarantee that the response could be parsed into nodes. Don’t start by deleting all your existing configurations.
The latency test shows a result, but my browser still can’t open webpages. Why?
First check which test the result came from, then check the proxy route used by your browser. In “Settings” → “Parameter settings,” verify the local listener values. Revisit the page and check the logs. If there’s no corresponding entry, first check whether the request is reaching the local proxy instead of changing remote node settings right away.
The log window is empty. Does that mean the core is broken?
First make sure the log panel is expanded and not filtered. Then activate a valid node and check the startup output. If only access logs are missing, check the current log level as well. Use startup errors to determine whether the core failed to start; an empty window by itself doesn’t prove that it did.
For a first check, follow the same sequence each time: confirm the subscription group has valid entries, activate a node, check the core startup logs, choose one way to send traffic through it, and test with the same app. Change one setting at a time and record the result so you can return to a known-good state if something goes wrong. For more troubleshooting steps, see the Troubleshooting guide; for the basic workflow, see the user guide.
Download the v2rayN client
Choose the client for your operating system and processor architecture, then follow the guide to import a configuration, activate a node, and set up a proxy. If you already have a working configuration, back it up before changing your current setup.
View download options Read the guide