For users who have opened v2rayN but are still finding their way around. Follow the sections on the server list, subscription groups, status bar, logs, and settings to tell apart the selected row, the active server, and whether traffic is being proxied—then verify the connection in a way you can repeat.
The main window: five areas to know
v2rayN is a desktop client that manages configurations; the selected core handles the actual connection. Opening the window only confirms that the graphical interface has started. You still need to check the server configuration, core status, and how apps send traffic through the proxy. This guide follows common Windows desktop workflows. Menu locations may differ between desktop and classic WPF versions, so use the fields in your current interface as the reference.
| Area | What it does | Check first |
|---|---|---|
| Server list | View configurations, select the active server, and run tests | Active server and test results |
| Subscription groups | Filter servers by source and manage subscription URLs | Correct group selected and subscription updated successfully |
| Bottom status bar | Check system proxy, routing, and runtime status | Whether the proxy entry point and routing policy are as expected |
| Logs panel | Review startup, connection, and error details | First error and when it occurred |
| Settings | Change listener, core, and interface options | Whether changes were saved and reloaded |
Follow a consistent order: confirm the group, set the active server, check the system proxy, then visit a webpage and review the logs. Don’t change the port, DNS, and routing all at once; when several settings change together, it’s hard to tell which one affected the result.
Server list: selecting a row doesn’t make it active
Each row usually represents a server configuration, not an established connection. Clicking a row only selects it for editing or bulk actions. To switch the server in use, right-click and choose “Set as active server,” then check the active indicator. Depending on the version, this may appear as an icon, a color, or a status label.
- Alias: Identifies the server and usually comes from the subscription. Any region or multiplier in the name is provider-supplied information, not a route attribute independently verified by the client.
- Address and port: Point to the remote server. The remote port is not a local listening port; don’t confuse the two.
- Protocol and transport: VMess and VLESS are proxy protocols; TCP and WebSocket are transport methods. Security and transport settings must also match the server.
- Subscription group: Shows where the configuration came from. Servers with the same name may belong to different subscriptions, so don’t identify duplicates by alias alone.
- Latency and speed: Results from a particular test, not continuous monitoring. A blank value means there’s no result yet; it doesn’t necessarily mean the server is unavailable.
To change an address, user ID, or transport setting, double-click the configuration or use the right-click menu to edit it. Manual changes to subscription-generated servers may be overwritten at the next update. For changes you want to keep, use a separate manual configuration and keep it distinct from the subscription group.
Test first, then set the active server
RecommendedSelect a few candidate servers, then right-click and choose “Test server real connection latency.” Set a server with a valid result as active, then verify access in a browser.
Best for: First-time connections, large server lists, and checking basic availability.
Switch directly to a known server
Set a recently verified server as active, then check the logs. Past results can become outdated as routes and server status change, so still verify access this time.
Best for: Switching among a small set of familiar servers.
A real connection latency test accesses its target through the proxy chain; it’s different from checking whether a TCP port is reachable. A successful test only shows that the target was reachable at that moment. Verify download speed, access to specific websites, and long-connection stability separately. Sorting only changes the list order; it won’t make the top server active.
Subscription groups: manage sources and filter the list
A subscription URL retrieves a set of configurations; groups organize them. Switching groups usually only filters the list—it doesn’t automatically change the active server. If the list suddenly looks empty, first check the selected group, search filters, and subscription update results instead of deleting everything and importing it again.
-
Open group management
Go to “Subscription Groups” → “Subscription Group Settings” in the main menu. If your version has a management button in the group bar, open the settings window with the same name.
-
Enter a subscription URL
Add a group, enter a descriptive label and the full subscription URL, then save. Don’t paste an individual server share link into a field that expects a subscription URL.
-
Update subscription content
Return to the “Subscription Groups” menu and choose “Update all subscriptions (without proxy),” or the equivalent command in your version. Check the logs for retrieval or parsing errors.
-
Check for new servers
Select the group you just created and clear any search filters. Check that its servers appear, then test candidates, set an active server, and verify access in a browser.
“Without proxy” is for subscription URLs accessible over your local network. If the URL is only reachable through a proxy, first make sure an existing server works, then choose “Update all subscriptions (through proxy).” Without a working proxy, repeatedly choosing this option makes subscription retrieval depend on a connection that hasn’t been established yet.
Bottom status bar: check system proxy and routing separately
The system proxy determines which apps that follow system settings send requests to the local proxy entry point. Routing determines where requests that have reached the core go next. These are separate layers. Switching routing to “Global” doesn’t mean every app is using the proxy, especially apps that choose their own networking method.
Check both layers: entry point first, destination next
System proxy: app to local machine
- Check that the system proxy control in the bottom bar is set to “Automatically configure system proxy.”
- Make sure the local listening address and port match the system proxy settings.
- Browser extensions or an app’s own proxy settings may override system settings.
Routing rules: local machine to destination
- Check which rule set is selected in the routing control at the bottom.
- Check whether the destination domain is routed directly or through the proxy.
- Rule sets with the same name may have different contents if a user has edited them.
First confirm that requests reach the local listener, then check the matching route. Don’t infer how all apps are routed from a single webpage visit.
“Clear system proxy” removes the system-level proxy configuration. “Do not change system proxy” usually means the client won’t modify the current system settings; it doesn’t force a direct connection. If another tool set a proxy before you quit, check your system network settings. A zero live speed reading doesn’t prove the connection is down: no traffic during idle periods is normal, and the counter may not cover the whole device.
- Webpages won’t load and no new requests appear in the logs: check the app’s proxy entry point before changing the remote server.
- Requests appear in the logs but go direct: check route matching and rule order.
- If TUN is configured, check permissions, routing, and DNS interception separately. Don’t apply checks meant only for the system proxy.
Settings: listener ports and core options
A common route is “Settings” → “Parameter Settings.” Start with the local listener options under “Basic Settings.” Core options are usually under a tab or field related to “Core Type.” Tab names may vary between versions; check the settings in your current interface rather than copying an old screenshot and editing configuration files blindly.
Suppose the local entry point is 127.0.0.1:10808. This means a connection to port 10808 on your own machine, not the remote server address. Recent versions may use a mixed listener that accepts both HTTP and SOCKS requests; older configurations may use separate listeners. Check the current listener type to see which protocols it supports—don’t infer that from the port number alone.
- Change the port: Save the settings and reload or restart the core as prompted by the interface. Update any apps with manually configured proxy settings, and reapply automatic system proxy configuration if needed.
- Allow LAN connections: This changes who can access the listener; it isn’t a speed boost. Enable it only when sharing is necessary, and use firewall rules to restrict access.
- Core Type: Determines which core handles the corresponding configuration. Before switching, check support for the server’s protocol, transport, and security settings.
- Log level: Temporarily increase detail while troubleshooting, then restore an appropriate level after reproducing the issue. This keeps excessive output from making logs harder to read or taking up unnecessary storage.
VLESS and VMess are configuration protocols; Xray and V2Ray are core names. Changing the protocol is not the same as changing the core. The same subscription may also fail to start with a particular core if its settings aren’t supported. Check the specific error instead of assuming compatibility because a server name appears in the interface.
Logs panel: check startup errors before connection errors
Open the panel using “Show Logs” or the log area below the window. Some versions show runtime messages separately from core output. Note the time, reproduce the failed action once, then review entries around that time. An old error from a long-running session may have nothing to do with the current issue.
| Log term | What it usually means | Next step |
|---|---|---|
address already in use | Local address or listening port is already in use | Identify the process using it, or choose a port you’ve confirmed is free |
connection refused | Connection to the destination was refused | First determine whether the address is the local entry point or a remote service, then check accordingly |
timeout | A connection stage did not finish before the timeout | Use the destination and surrounding log entries to tell whether this involves subscription retrieval, server connection, or website access |
failed to load config | The core couldn’t load its configuration | Check the field identified in the error and whether the selected core supports that setting |
A timeout keyword alone isn’t enough to identify the cause. A timeout while downloading a subscription and one while browsing occur in different processes, even if the log text looks similar, so they don’t necessarily have the same fix. Before sharing logs, redact server addresses, user IDs, and subscription credentials, while keeping a little context around the error so the issue can be reproduced.
Common interface questions and a verification checklist
Why am I still using the old server after clicking a new one?
A click may only select the row. Right-click and choose “Set as active server,” then check the active indicator and logs. Existing long-lived connections may continue using the old server; open a new page or send a fresh request to verify.
The update succeeded, so why is the list still empty?
Select the relevant subscription group again and clear search filters, then check the parsing results in the update logs. Retrieving content doesn’t guarantee it contains usable servers; the subscription URL may also have returned an error page.
Why can’t my browser open websites if the real connection test passed?
Check that automatic system proxy configuration is enabled and the browser isn’t using an overriding proxy. Then see whether the browser’s requests appear in the logs. The test and the website may use different destinations and match different routing rules.
Why is v2rayN still running after I close the window?
The close button may be configured to hide the app in the system tray. Find v2rayN in the tray; to stop it, choose Exit from the tray menu, then check that the system proxy was restored as expected.
Once you know your way around the main window, use the same routine every time: check the group to confirm the source, the active indicator to confirm the server, the status bar to verify the entry point and routing, and the logs to confirm requests. Change a setting only when its layer isn’t behaving as expected; this is more effective than repeatedly changing everything.