Everyday v2rayN use comes down to four tasks: organize sources into subscription groups, choose an active server, decide how traffic reaches the client with the system proxy or TUN, and check the logs to confirm core and routing behavior. This guide is for users who have opened the client but aren’t sure whether a selected server is actually active. By the end, you’ll know how to check the basics, from updating a subscription to tracking down a connection issue.
First, know the four areas: server list, groups, logs, and runtime status
The key point: seeing servers in the list doesn’t mean the core is running properly, and a running core doesn’t mean your browser is using the proxy. The main window shows different kinds of status. To tell whether a connection is working, consider them together rather than relying on the latency shown for one server.
This guide uses the labels commonly found in the Chinese desktop interface. Menu locations may vary by release, operating system, or window size, and the log pane may be collapsed. If menu wording differs, look for the feature by name rather than relying on a button’s exact screen position.
| Area | What it’s for | What to verify |
|---|---|---|
| Server list | View servers, test connections, and switch the active server | The active server, not just the selected row |
| Subscription groups | Manage, update, and filter servers by subscription source | Whether the selected group or search term is hiding other servers |
| Log window | Check startup, listeners, connections, and errors | The time of your action and the first related error |
| Status area and settings menu | Configure the system proxy, routing, TUN, and runtime options | How traffic enters the client and which routing rules are in use |
Server list: what selection, activation, and the context menu do
Clicking a row usually just selects it so you can edit, copy, test, or delete the server. To use a different server, right-click it and choose “Set as active server,” then check the active indicator and the log at the bottom. Some versions let you switch servers by double-clicking, but the context menu makes the action clearer when you’re getting started.
The remark helps identify a server; its address and port point to the server endpoint. Protocols such as VMess and VLESS describe how the connection works, but don’t tell you how fast it will be. Transport and security settings must also match the server. Changing a remark usually won’t affect the connection, while changing the address, port, or TLS settings may cause the handshake to fail.
- Edit: Select a single server, then open the editor from its context menu. Keep a copy of the original configuration so you can revert if you need to check the protocol, server port, or transport settings.
- Test: Check whether the menu offers a connection latency test or a real connection latency test before reading the result. These tests use different methods and targets, so don’t compare their results as if they were the same metric.
- Copy share link: Use this to move a single server to another client. It usually doesn’t include the client’s full routing and DNS settings. Share links may contain authentication details, so don’t post them publicly.
- Delete: Check which servers are selected before deleting. A manually deleted subscription server may reappear the next time the subscription updates. To stop using a source long-term, manage it in subscription groups instead.
Subscription groups: updating a source and filtering the list are different tasks
Subscription groups manage sources and filter what’s shown, but these are separate functions. Switching groups changes which servers you see; it doesn’t automatically switch the active server. Updating a subscription fetches its latest contents, which may add, remove, or overwrite server configurations.
-
Open group settings
In the main window, go to “Subscription groups” → “Subscription group settings” and check the group’s remark and URL. Subscription URLs often contain access tokens, so save only complete links from trusted sources.
-
Update subscription contents
Return to the “Subscription groups” menu and choose “Update current subscription (without proxy)” to update the selected group. If the source specifically requires a proxy, first make sure you have a working connection, then choose the corresponding “via proxy” update option.
-
Clear list filters
Switch to a view that shows all servers and clear the search box. If the update log reports success but the list is empty, check whether the group and search filters are hiding results before trying to import again.
-
Confirm the active server again
Select a server in the updated list, right-click it, and choose “Set as active server.” Then check the configuration load result in the logs to make sure you aren’t still using a different server from before the update.
Name groups by source rather than giving them similar region-based names. One source may include servers in several regions, and servers in the same region may come from different sources. Clear source remarks make it easier to tell which subscription you’re updating. Before manually editing a subscription server, consider whether the next update will overwrite your changes; back up any changes you need to keep.
System proxy, routing, and TUN: three controls for different parts of the flow
The system proxy directs requests from apps that follow system settings. TUN uses a virtual network interface to capture traffic that matches its configuration. Routing rules determine whether requests entering the core use the proxy, connect directly, or get blocked. These aren’t interchangeable controls, and turning them all on won’t necessarily make the connection more reliable.
Start with the system proxy
RecommendedIn the Windows main window, open the system proxy menu and select “Set system proxy automatically.” Then test with a browser that follows the system proxy. It’s easier to confirm which traffic is covered, making this a good starting point for troubleshooting.
Best for: first-time setup, browser access, and basic connection checks.
Enable TUN when needed
Consider TUN if an app doesn’t follow the system proxy. Before enabling it, check your platform’s permission requirements and watch the logs for virtual adapter, DNS, and route setup. The traffic covered depends on the actual configuration.
Best for: apps that ignore the system proxy and situations where you need a unified way to route traffic.
Configure a proxy manually
Enter the local address, port, and proxy type in an app that supports proxy settings. This is useful for testing an individual app, but its own settings may override the system proxy. Make a note of how to revert the change.
Best for: command-line tools, standalone apps, and isolating an issue in one app.
After changing the routing profile, confirm that the new one has loaded. If a direct-connection rule matches, the request bypassing the proxy is expected; don’t assume the server is down. For more on rule order and outbound tags, see the setup guide. For complex traffic interception issues, work through the full troubleshooting guide.
Log window: read entries by time, level, and connection stage
The most useful approach is to perform one clear action, then read the entries that follow. Note the current time, switch the active server, and make a single request to the site you’re testing. This helps distinguish startup failures from access problems without searching through old logs for a word that might be relevant.
The interface log may show subscription updates, while core output focuses on configuration loading, listeners, and connections. Not every version displays request details by default. At a higher log level, a request may be absent from the logs even if it happened. Temporarily increase the detail level and reproduce the issue once; there’s no need to keep verbose debug output on.
| Log pattern | Typical stage | What to check next |
|---|---|---|
address already in use | Local listener started | Check whether another process is using the local port and whether the client is running more than once |
failed to load config | Configuration read | Look for the next specific error and check custom configuration and field compatibility |
timeout | Connection or request waiting | Use the destination address to determine whether the timeout is at the server connection, DNS, or destination access stage |
certificate | TLS verification | Check the system clock, server certificate, and TLS server name setting |
Settings: start with the listener ports and core selection
Open “Settings” → “Parameter settings,” note the current values, then change one thing at a time. Local listeners, core selection, DNS, and startup behavior are more likely to affect everyday connections than the interface theme. Depending on the version, core options may appear under “Core type” or on a separate core settings page. Choose a core based on the server protocol and what the core supports.
These values illustrate local proxy addresses; they aren’t server configuration. You might enter 127.0.0.1:10808 as the local proxy in an app, but first confirm that the listener supports the app’s selected HTTP or SOCKS proxy type. Port layouts can differ between versions, so don’t assume an additional port is available just because an older guide mentions it.
- Listener port: Check the local listener value in the basic settings. After changing it, update any apps where you configured a manual proxy and check whether the system proxy has refreshed.
- LAN access: Enable this only if other devices need to connect. They can’t use
127.0.0.1to reach this computer; use its LAN address instead, and check the firewall and access scope. - Core type: VLESS and VMess are protocols; Xray and V2Ray are cores; v2rayN is a client. Switching cores doesn’t switch servers or guarantee compatibility with a server configuration that doesn’t match.
- DNS: First confirm whether you’re using the system proxy or TUN, then check the domain resolution path. Don’t change DNS, servers, and routing all at once before you’ve identified the source of the problem.
- Startup behavior: Start with Windows, minimize on startup, and automatically set the system proxy are separate options. Enabling one doesn’t mean the others are enabled too.
After saving your settings, check the logs to confirm they reloaded successfully, then return to the main window and verify the active server and proxy status. If something breaks, revert the setting you just changed; that’s easier to diagnose than reimporting every subscription.
Common v2rayN interface questions: troubleshoot with the shortest steps
I clicked a server. Why is my traffic still using the old exit?
Right-click the row and choose “Set as active server.” Confirm that the active indicator changes, then check the logs for a successful load. If the active server has changed, check whether a direct-connection rule matches the destination and whether the browser is using its own proxy settings. Simply selecting a row may not change the connection.
The subscription update succeeded, but the servers are missing. Why?
Clear the search box and switch to a view that shows all servers. If the list is still empty, open “Subscription groups” → “Subscription group settings” and confirm that the updated source matches the current group. Check the logs to see whether any servers were actually parsed, rather than just the URL request completing.
The logs keep scrolling. Which section should I copy?
Stop repeating the test and note the time. Perform a single server switch or access attempt. Copy the entries around that time, from the action through the first related error. For a startup failure, include the listener or configuration-loading entries; there’s no need to send the entire access history.
Why did my browser lose internet access after I closed the client?
Check whether the system is still pointing to a local proxy that’s no longer listening. If you can reopen v2rayN, choose “Clear system proxy” from the system proxy menu before exiting. Also check whether the browser or another app has a separate manual proxy configured.
Follow the same check order each time: confirm the group and active server, check the local listener, verify how the app connects, then read the routing and error logs for that request. This separates “server unavailable,” “app bypassing the proxy,” and “rule sent traffic direct” into distinct issues, reducing guesswork and unnecessary changes.