First, distinguish between selecting a row, setting the active server, and enabling the system proxy. Then work through subscription groups, the server list, logs, and settings. This guide is for users who have imported a subscription but are still getting familiar with the main window. By the end, you’ll know how to update a group, test a node, check proxy status, and use the first relevant log entry to guide troubleshooting.
Understanding the main window: configurations, selections, and runtime status
Think of the v2rayN interface as a place to manage configurations—not proof that a connection is working. The server list stores node settings, subscription groups organize where nodes come from, and the log panel shows what the core is doing. The status area at the bottom displays current selections such as the system proxy and routing mode. A node appearing in the list only means that its configuration is present in the client.
This guide uses the Chinese-language Windows desktop interface. Menus may be arranged differently across versions and desktop layouts. For example, the system proxy option may appear both at the bottom of the window and in the tray menu. Look for menu names rather than relying on button positions. Before you start, note the version under Help → About. When troubleshooting, record the operating system and core version as well.
| Section | What it’s for | What it doesn’t tell you |
|---|---|---|
| Server list | View protocols, addresses, ports, and test results; set the active server | A listed node isn’t necessarily working |
| Subscription groups | Filter nodes by source, save subscription URLs, and update subscriptions | Changing groups doesn’t change the active server |
| Log panel | View core startup, connection requests, and errors | One request in the log doesn’t mean every app is using the proxy |
| Status area | Check the system proxy, routing, and local listening details | Enabling the system proxy doesn’t mean it handles all traffic |
| Settings | Change local listeners, interface behavior, and other runtime options | Changing a local port doesn’t change the remote server port |
Working with the server list: set the active server before testing
Clicking a row usually just selects it for editing or context-menu actions. Don’t mistake the selection highlight for an active-server indicator. Right-click the node and choose “Set as active server,” then check the active marker and the resulting log entries. After the change, the core may reload its configuration; startup messages during this brief process are expected and worth checking.
The “Port” column usually shows the remote node’s service port. The local listening port in Settings is where apps on your device connect to v2rayN. These serve different purposes and don’t need to match. Treat the protocol, transport, TLS, and authentication settings as a set. Don’t copy just a port or domain from another working node and expect it to work.
- Edit a node: Find the edit option for the relevant protocol in the context menu, then check the address, port, and transport settings. For subscription nodes, check the source first so you don’t mistake a temporary change for a permanent configuration.
- Test real connection latency: Select the nodes you want to test, then run the real connection latency test from the context menu. If you select multiple nodes, test only the intended ones to avoid sending test requests for the entire list at once.
- Sort results: Click the relevant column heading and check whether the sort is ascending or descending. Blank values, failures, and numbers may sort differently, so the top result isn’t necessarily the best one.
- Delete a node: First check which subscription group it belongs to. If you manually delete a subscription node, it may return the next time the subscription updates. That doesn’t mean the deletion failed.
Managing subscription groups: filtering isn’t updating
Subscription groups store subscription sources and organize nodes from the same source. Switching groups only changes which nodes are shown; it doesn’t download updated subscription content or indicate that the active server has changed. If the list suddenly looks empty, clear the search filter and switch to All groups before checking whether nodes were actually deleted.
-
Open subscription group settings
Go to “Subscription groups” → “Subscription group settings.” Select an existing group or add a new one. Use a recognizable note such as “Daily” or “Backup” to identify the source, but don’t put the full subscription URL in the note.
-
Save the subscription URL
Enter the full subscription URL in the group settings and save it. Query parameters are often part of the credentials, so don’t keep only the domain and path. Hide the entire URL before taking a screenshot.
-
Update subscriptions
Go to “Subscription groups” → “Update all subscriptions (without proxy)” to start an update. If your current network can’t reach the subscription URL and you already have a working proxy connection, try “Update all subscriptions (through proxy)” instead.
-
Check the update result
Review the update message, then return to the target group and check the node names, addresses, and protocols. After a successful update, set the active server and run a real connection latency test. A successful subscription download doesn’t mean a node connection succeeded.
Updating a subscription may replace nodes from its source, so changes made directly to a subscription node may not stick. To try a parameter temporarily, first copy the node as a standalone entry and make sure the subscription won’t overwrite it. Then change one setting at a time for comparison. Automatic updates only refresh the list; they don’t test whether nodes work. If the subscription provider limits request frequency, repeatedly clicking Update won’t help.
Reading logs and status: trace a single request
Show the log panel, set the active server, then visit a known-reachable HTTPS address. Follow the sequence: did the core start, did it receive a local request, which outbound route matched the request, and did an error follow? Don’t look only at the last line. The first startup error often helps pinpoint the problem more than later, repeated connection failures.
Destination domains, IP addresses, ports, and routing tags in the logs can help identify the traffic path, but the level of detail depends on the log level and core. Not seeing every request doesn’t necessarily mean there was no traffic. If needed, temporarily increase log verbosity, reproduce the issue once, then restore the original setting to avoid collecting unnecessary connection records over time.
| Log message | Check first | Next step |
|---|---|---|
address already in use | Local listening port is in use | Close duplicate instances, or identify the process using the port and choose another local port |
connection refused | Whether a service is listening at the address and port being contacted | First determine whether the target is a local entry point or a remote node, then check the relevant service |
i/o timeout | Network path, remote service, and request destination | Keep the test address the same and compare it with a known-working node |
x509 | System time, certificate validity, and server name | Sync the system clock and check the subscription’s TLS settings; don’t disable certificate verification |
A speed reading at the bottom can’t, by itself, prove that a particular browser is using the proxy; other programs may be generating traffic. To verify, stop unrelated activity, check the system proxy status, then inspect the log for the request and check the exit IP. Routing rules can send some destinations directly, so “proxy enabled” doesn’t mean every website uses a different exit IP.
Checking settings: local ports vs. remote ports
Open “Settings” → “Parameter settings.” First check the local listening ports and related options such as “Allow connections from the LAN.” Options may be on different tabs in different versions. Note the original values before making changes, and change one setting at a time. After saving a listening-related change, check the startup log to confirm which address and port are actually in use.
The examples below are two sets of teaching values to explain how the fields relate. They aren’t default settings for every version or importable nodes. For example, if the local machine provides a mixed proxy entry point and the remote node uses a TLS service port, you could record them separately like this:
Local listener example
- Listen address
- 127.0.0.1
- Listen port
- 10808
- Entry type
- Mixed proxy entry
- LAN access
- Off
Only route apps through this port using the relevant protocol if the configuration is actually a mixed entry. Confirm the active settings in the startup log.
Remote node example
- Server address
- node.example.invalid
- Server port
- 443
- Protocol
- VLESS
- Transport security
- TLS
This is a non-connectable example address. Use the subscription source for actual node settings; these four fields alone aren’t enough to build a complete configuration.
To make troubleshooting notes easier to check, record the three relevant numbers separately. The values below are examples or explain protocol ranges; they aren’t measured results:
- Local listener: Determines which entry point on your device apps connect to. If you change the port, update any apps where the proxy is configured manually.
- LAN access: Enable this only when other devices need to use the entry point, and restrict access with your firewall. Don’t expose a local proxy port directly to the public internet.
- Core selection: The core must support the node’s protocol and transport. If it can’t recognize a protocol or field, first check which core is running and its version. Don’t force it to start by removing security settings.
- Startup and interface behavior: Options such as launch at startup and minimize affect how the app runs; they won’t fix an unreachable server or failed authentication.
Choosing the system proxy or TUN: match the method to your apps
Open “System proxy” → “Automatically configure system proxy” from the bottom of the main window or the tray menu. This lets apps that follow system proxy settings use the local entry point. Before exiting, you can choose “Clear system proxy” to prevent the system from pointing to a local port that is no longer listening. Browser extensions or an app’s own proxy settings may override the system settings, so check them separately.
When to use the system proxy or TUN
Use the system proxy
- Best for browsers and desktop apps that follow system proxy settings.
- Make sure the local port is listening before enabling automatic configuration.
- If an app has its own proxy settings, check that it isn’t still using an old port.
Use TUN mode
- Best for programs that need network-level traffic capture but don’t follow system proxy settings.
- May require elevated permissions; check the virtual network adapter, DNS, and routes.
- Disable conflicting traffic-capture tools before testing the target app.
Both methods are affected by routing rules. Get one working first, then add the other to avoid changing multiple variables at once.
Routing determines whether traffic goes through a proxy outbound or directly. When troubleshooting a website, note the current routing rules, then check the request log and exit result. Restore the original settings after temporarily changing a rule. Don’t leave an unverified proxy-all configuration enabled just to confirm that the proxy works; consider whether LAN addresses and local services need to remain accessible. See the system proxy guide and TUN mode guide for details.
Common interface questions
I selected another node. Why hasn’t my exit IP changed?
Right-click the node and choose “Set as active server”—don’t just click to select it. Then check whether the destination request is routed directly. Close existing test connections or restart the test app before retrying, so you don’t mistake an old connection’s result for the new node’s.
The list is empty after updating a subscription. Are all my nodes gone?
Clear the search box and switch to All groups, then check the update message. If the response isn’t a recognizable subscription or the URL credentials have expired, verify the full subscription URL and service status. Don’t repeatedly delete and recreate every group.
The real connection latency test returned a value, but my browser won’t load anything. Why?
Check whether “System proxy” is configured automatically, then see if the browser has its own proxy settings. The real connection latency test only verifies its own test route; it can’t confirm the browser’s proxy entry point, DNS, or route to the destination website.
The log says a port is in use after I changed a setting. What should I do?
First close any duplicate v2rayN instances, then restart the app. If the port is still in use, use a system tool to identify the process. If you need to change the port, go to “Settings” → “Parameter settings” and update any apps that use a manually configured proxy port.
What interface details should I include when asking for help?
Include the client version, operating system, core version, selected proxy method, and error logs from before and after reproducing the issue. Hide subscription URLs, credentials, and unnecessary destination details. Keep the error keywords, event order, and port relationships so others can identify which layer is failing.
For a complete check, follow this order: update subscriptions → set the active server → test real connection latency → check the system proxy → inspect the request log. Note the result at each step and troubleshoot at the first one that fails. This helps distinguish subscription download problems, core startup failures, and apps that aren’t using the proxy—without changing unrelated settings.