For new users who have opened v2rayN but aren’t sure whether selecting a server also activates it. This walkthrough covers the server list, subscription groups, system proxy, logs, and settings so you can tell where configurations come from, which one is active, whether apps are using the proxy, and where to find errors—then run a basic connection check.
Main window layout: find your configuration, then check its status
The v2rayN main window is more than a connection status dashboard. The server list stores connection profiles, subscription groups organize them, and the bottom panel shows runtime information. System proxy and routing controls determine how traffic enters the client and where it goes next. A server appearing in the list doesn’t mean the core is running successfully; a running core doesn’t mean your browser is using it.
Control locations and menu labels can vary slightly between desktop builds and the Windows WPF version. This guide uses the names shown in the Chinese interface. System proxy steps are based on Windows; on other desktop systems, also check the corresponding network proxy settings instead of following Windows tray instructions.
| Window area | What it contains | What to check first |
|---|---|---|
| Server list | Remarks, protocol, address, port, test results, and more | Is the expected profile active? |
| Subscription groups | Group tabs, subscription URLs, and update controls | Is the list filtered to a single group? |
| Bottom log panel | Core startup, connection, and error messages | The first error after switching profiles |
| System proxy and routing | How apps connect and which routing rules are selected | Don’t confuse the traffic entry switch with routing rules |
| Settings | Local listeners, core options, logs, and more | Record the original value before changing one setting at a time |
Server list: selection, activation, and editing
Each row in the server list usually represents a remote connection profile. VMess and VLESS are protocol types; the address and port identify the remote endpoint, while the remark is just a label for easier identification. A region or purpose in the remark doesn’t mean the client has verified it. Check actual access and the logs to assess the connection.
- Select a row: This usually just selects it for context-menu actions or bulk operations. It doesn’t mean the connection has switched.
- Set as active server: Select the profile, choose the corresponding context-menu action, then check the active indicator and core logs. The indicator may look different across versions.
- Edit server: Use the context-menu edit option to review protocol settings. Don’t change the address, UUID, or transport settings just to switch servers.
- Test server: Check whether the menu option tests connection latency, a real connection, or speed. Each test uses a different method and measures something different, so results aren’t interchangeable.
- Delete server: This removes the local profile. Subscription-sourced entries may return after the next update. To disable an entire source, change its subscription group settings.
If columns are too narrow, scroll horizontally or resize them; don’t mistake a truncated address for a missing configuration. Before sharing a screenshot, hide server addresses, subscription URLs, and credentials. Troubleshooting usually requires only the protocol, a redacted error line, and the time of the operation.
Subscription groups: filter with tabs and find update controls
Subscription groups serve two purposes: they categorize servers and store subscription sources with their update options. Clicking a group tab usually filters the list; it doesn’t activate a server in that group. If a tab looks empty, don’t assume all servers have been deleted.
-
Open group settings
In the main window, go to “Subscription Groups” → “Subscription Group Settings.” If your version shows this as a button, use the button with the same name. Don’t mistake the group tabs above the list for an editing window.
-
Add a subscription source
Create a group, enter an easy-to-recognize name and the full subscription URL, then save. Subscription URLs often contain access tokens, so treat them as credentials and don’t paste them into public logs or screenshots.
-
Update subscriptions
Return to the “Subscription Groups” menu and choose “Update All Subscriptions (Without Proxy)” or “Update All Subscriptions (Through Proxy),” depending on your network. Some versions use similar labels, such as “Current Subscription.”
-
Check the active profile
When the update finishes, open the relevant group and confirm that entries appear. Select one and set it as the active server. A successful update means the subscription was fetched and parsed—not that every profile in it works.
“Update Through Proxy” requires an existing, working proxy connection. If you’re importing subscriptions for the first time and the list is empty, repeatedly choosing this option may leave the client without a route to the subscription server. If updating without a proxy also fails, check that the URL is complete and hasn’t expired, then look in the logs for a timeout, certificate issue, or parsing error.
Avoid editing key settings on subscription-generated profiles as a permanent fix; the next update may overwrite your changes. To keep a custom configuration, create a separate manual profile or group and clearly label its source.
System proxy and routing: traffic entry isn’t the same as routing rules
On Windows, common system proxy options include “Set system proxy automatically,” “Clear system proxy,” and “Do not change system proxy.” Automatic setup usually points the system proxy to the client’s local listener. Clear removes the related system proxy settings. Do not change keeps the current state; it doesn’t turn the proxy off.
System proxy controls
- Where to find them
- The “System Proxy” menu at the bottom of the main window or in the system tray
- Traffic entry option
- Set system proxy automatically
- Applies to
- Apps that follow the system proxy settings
If an app isn’t sending traffic through the proxy, changing routing rules usually won’t help.
Routing mode controls
- Where to find them
- The routing selector in the main window
- Applies to
- Connections that have already reached the core
- Typical routes
- direct、proxy、block
Rule names depend on the local configuration; the name alone doesn’t reveal everything a rule does.
For example, when a browser follows the system proxy, requests go to the local core first, then routing rules decide whether to connect directly or use the proxy. An app that connects directly and ignores system proxy settings may never send traffic to the core—even when proxy routing is selected. TUN is a separate way to route traffic; you don’t need to enable it while first learning the interface, as it adds another variable to troubleshoot.
- Websites behave the same after switching: check the system proxy address and port, as well as the browser’s own proxy settings.
- Only some domains take an unexpected route: check the selected routing mode, rule order, and outbound tags in the logs.
- Websites stop loading after you exit the client: check for system proxy settings that still point to a listener port that is no longer running.
Log panel: find the first failure by timestamp
The bottom panel may combine client activity with core output. Client messages describe actions such as updating subscriptions or switching profiles; core output covers listener startup, connection handling, and errors. Note when you perform an action, then look for the first error after that time so you don’t mistake an old error for a new one.
| Log message | What it usually means | Where to check |
|---|---|---|
address already in use | A listener port is already in use by another process | Local ports in Settings and other running instances |
failed to load config | The core couldn’t load the generated configuration | The specific error that follows and any recently changed settings |
connection refused | A connection was refused by the destination | The destination address and port shown in the error |
i/o timeout | A network operation timed out | Whether the timeout occurred during a remote connection, DNS lookup, or subscription fetch |
certificate | A TLS certificate check may be involved | The full error, system date and time, server name, and server-side settings |
These are common log fragments, not complete error messages. The same timeout wording can appear at different stages, so keep the surrounding lines for context. A “core started successfully” message only confirms startup; make an actual request to check whether connections are being handled correctly.
Settings: distinguish local listener ports from remote ports
Open “Settings” → “Parameters” and look for the local listener port options first. Depending on the version, the client may use separate HTTP and SOCKS ports or a mixed listener. Don’t assume the ports in an older guide are still the defaults. Check the settings page and startup logs for the actual values.
If the local listener is 127.0.0.1:10808, that’s where apps on your computer send requests to the client. The remote port in the server list is where the core connects to the server. Changing the local port won’t fix an incorrect remote port; it may instead leave your browser or other manually configured apps pointing to the old port.
- Local listener address: For local use, keep the loopback address. Before allowing LAN connections, make sure you understand the network scope and access controls.
- Local port: Save your change and confirm that the core reloads successfully. Then update the system proxy and any apps with manually configured proxy settings.
- Core options: Don’t switch settings just because several options are available. Cores differ in their support for protocol fields and configuration formats. After switching, verify startup and test a connection again.
- Log level: Increase the detail when troubleshooting, then restore an appropriate level when you’re done. Logs may contain destination and local network information, so avoid sharing them publicly in full.
The server editor handles the address, authentication, and transport settings for an individual connection. The settings window controls general client or core behavior. If you can’t find a UUID, TLS server name, or WebSocket path, open that server’s editor instead of searching through general settings.
Common interface issues and a basic verification workflow
I clicked a server. Why is it still using the previous connection?
A click may only select a row. Right-click the profile and set it as the active server, check the active indicator, then review the core logs after switching. Existing long-lived connections may not move immediately, so start a new request to verify the change.
The subscription update succeeded. Why is the list still empty?
Switch to all groups, clear any search terms, then check the target group. If it’s still empty, check the update logs to see whether any recognizable entries were imported. A successful request that returns a login page or error text won’t produce valid server profiles.
The core started. Why won’t my browser load anything?
In Windows, open the “System Proxy” menu and check whether it’s been configured automatically, then verify the local listener port. Make a request and check for a matching connection log. If the connection appears but fails, troubleshoot the remote settings based on the error stage.
I changed too many settings. What should I restore first?
Revert the last setting you changed and reload before resetting subscriptions, routing, and listener ports all at once. Check each step in order: active server, core startup, system proxy, and actual access. Keep a record of each change.
Once you’re familiar with the interface, use the same sequence each time: confirm subscription entries are present, set an active server, check the core startup logs, enable the required traffic entry method, then make an actual request. If it fails, resume troubleshooting from the last step you confirmed was working; there’s no need to import every configuration again.
- Note the current group, active server remark, and local listener port. Don’t record or share credentials.
- Switch only one active profile and check for new startup errors.
- Check the system proxy status and test with a new request—not a cached page.
- Use the request time to find the relevant logs. If only certain sites are affected, check routing and DNS before reinstalling the client.