For users who have opened v2rayN but aren't sure why selecting a server doesn't mean the proxy is working. This guide explains the menus, groups, server list, logs, and status bar, then walks through a first setup you can verify. Focus on the active server, local listener, system proxy, and routing mode—there's no need to change advanced protocol settings first.
Identify the main sections, then check your version
v2rayN is a desktop client that stores server configurations, generates core configuration, and provides a user interface. The selected core handles the actual connection. Seeing the window doesn't mean the core started successfully, and seeing entries in the server list doesn't mean your browser is using the proxy. Check each of these states separately.
This guide covers the common layout of the Chinese-language Windows interface. The classic 6.x interface and the 7.x and later cross-platform interfaces may differ in menu locations, column names, and status bar layout. Check your installed version under Help or About, then look for features by name. Proxy handling on other desktop operating systems may also differ from Windows.
- Top menu: Add servers, manage subscriptions, open settings, and view help.
- Subscription groups: Filter the list by configuration source; this does not switch the system proxy.
- Server list: Review server settings, select the active server, and run tests.
- Logs or information panel: Check subscription updates, core startup, and connection errors.
- Status bar: Check the local listener, system proxy, routing, and traffic. In some versions, related controls are in the toolbar or tray menu.
Top menu: Find the right settings
Use Servers to manage one or more server configurations, Subscription Groups to manage subscription URLs and updates, and Settings to adjust client behavior and core options. These controls serve different purposes: changing the local listening port won't change the server's port, and a successful subscription update doesn't prove a server works.
| Menu item | Common use | Check before proceeding |
|---|---|---|
| Servers → Import bulk URLs from clipboard | Import copied server share links | Check whether the clipboard contains server links or a subscription URL; these use different import options |
| Subscription Groups → Subscription Group Settings | Add a group, enter a subscription URL, or edit the group description | Make sure the URL is complete and from a trusted source |
| Subscription Groups → Update All Subscriptions | Fetch the server configurations in your subscriptions again | Distinguish between the menu options to update through or without a proxy |
| Settings → Parameter Settings | Check options such as local listeners and configuration tests | Note the original values; the tab containing an option may vary by version |
| Settings → Routing Settings | View and edit routing rule sets | Editing rules and selecting the active routing configuration are separate actions |
VMess and VLESS are protocol names in server configurations, not system proxy modes. After importing a configuration, you usually don't need to change its protocol, transport, or TLS settings just to make the menus look consistent. These values must match the server; changing the transport won't fix a failed subscription update.
Subscription groups: Manage sources and filter the list
Group tabs primarily filter the server list. Select a subscription group to show its servers, then switch back to All to check entries from other sources. Changing tabs doesn't change the active server, which may belong to a different group.
-
Open group settings
Go to Subscription Groups → Subscription Group Settings, then use the Add option to create a group. Name each group by its source so you can tell them apart.
-
Enter the subscription URL
Enter the full URL in the subscription URL field, save, and return to the main window. Subscription URLs may contain access credentials, so don't include them in public screenshots or support posts.
-
Update the subscription
Open Subscription Groups and choose to update the current subscription or all subscriptions. If you don't have a working proxy yet, try the option to update without a proxy first. If you already have a working connection but a direct update fails, try updating through the proxy.
-
Check the filtered results
Select the relevant group tab and confirm that its servers appear. If the list is empty, switch back to All and check the update log to tell a filtering issue from a download failure.
An update may recreate entries based on the remote subscription. Changes you make to a subscribed server's address, name, or transport settings may be overwritten next time. If you need to keep custom changes, back up your configuration first and keep manually maintained entries separate from subscription-managed ones.
Server list: Understand each column
Each row represents a server configuration, not an established connection. Clicking a row usually just selects it for copying, testing, or editing. Activating a server tells the client to use that configuration to generate runtime settings. Don't judge connection status by row highlighting alone; check the context menu, active indicator, and status bar.
| Column or indicator | What it means | Common misconception |
|---|---|---|
| Name | The display name of the server | A location or route in the name isn't a result verified by the client |
| Address, port | The remote server's connection address | The remote port isn't the local proxy port on your computer |
| Type or protocol | For example, VMess or VLESS | This alone doesn't tell you the latency, speed, or availability |
| Transport, TLS | The transport method and security settings for the connection | These must match the server; don't combine options arbitrarily |
| Subscription group | The source the configuration belongs to | Servers with the same name may come from different groups |
| Latency, speed | The result of the most recent corresponding test | A blank value usually means the server hasn't been tested; a previous result doesn't reflect its current status |
Right-click the server and select Set as Active Server; some interfaces also let you double-click to activate it. Then run Test Server Real Connection Latency on a few candidates. This test typically uses the server to reach a test URL, making it a better indicator of application connectivity than a simple remote port check. Results still depend on the test URL and your network.
- Latency is measured in ms: It is the time taken by a test, not download bandwidth.
- Speed tests use traffic: Don't repeatedly test every server if you don't know your plan's limits.
- Check the scope of a timeout: One failing server and all servers failing call for different troubleshooting steps. If all fail, also check your local network and the test URL.
Local listening ports and status bar: Keep them separate
The local listener is the entry point for apps sending traffic through the proxy. The remote address is where the core connects. Both may show port numbers, but they serve different purposes and are configured in different places. Check the actual local listening values under Settings → Parameter Settings, then compare them with the main window's status bar. Don't assume an old guide's port number applies to your setup.
Local proxy endpoint
- Common address
127.0.0.1, the loopback address for this computer- Example port
10808; use the value in your current settings- Endpoint type
- SOCKS, HTTP, or a mixed listener, depending on the version and configuration
- Where to check
- Settings → Parameter Settings and the startup log
Older versions commonly use SOCKS on 10808 and HTTP on 10809. With a mixed listener, both types of requests can use the same port; don't assume there's a separate 10809 port.
Remote server configuration
- Address source
- Server address imported from a subscription or entered manually
- Example port
443, shown here only as an example field value- Protocol field
- VMess, VLESS, and other protocols; must match the server
- Where to check
- The server list and the edit window for the selected entry
A remote port of 443 doesn't mean your local listener should use port 443. The port number alone also doesn't confirm that TLS is enabled.
Traffic rates in the status area reflect activity within the displayed statistics. A zero rate could mean there are no requests right now, or that the app isn't using the proxy. Traffic appearing doesn't prove that every app is routed through it. To confirm the proxy is working, check the active server, proxy endpoint, and actual browsing results.
System proxy and routing: Different layers
In the Windows interface, the System Proxy menu commonly offers Set system proxy automatically, Clear system proxy, and Do not change system proxy. Automatic configuration sets the system proxy endpoint; clearing removes the related settings; leaving it unchanged preserves the current state—it does not disable an existing proxy. The tray menu usually has the same options.
What to check for each connection method
Use the system proxy
- Select Set system proxy automatically in v2rayN.
- The app must be configured to use the system proxy.
- Check the local address and port under Windows Settings → Network & Internet → Proxy.
- This setting alone doesn't confirm traffic routing for apps that ignore the system proxy.
Configure the app manually
- Select the appropriate HTTP or SOCKS type in the app's proxy settings.
- Enter the loopback address and the port the client is actually listening on.
- This method doesn't rely on the system proxy, but the core still needs to be running.
- Check any direct-connection exceptions configured in the app, too.
The system proxy determines how some apps send traffic to the proxy. Routing rules determine how requests that reach the core are handled. These are separate controls.
Use Settings → Routing Settings to manage rules; use the routing selector in the status bar or toolbar to switch the active configuration. Even if a request reaches the local proxy, a rule may route it directly. TUN is a separate way to capture traffic that involves permissions, a virtual network adapter, and routing. While learning the main window, test one connection method at a time rather than changing both the system proxy and TUN.
Logs panel: Read events in order
Don't wait for an error to check the logs. When updating subscriptions, switching the active server, or reloading a configuration, note the time and look at what appears immediately afterward. If your version separates Information and Logs into different tabs, check both the client's operation messages and the core's runtime output.
- Subscription stage: Check whether the request succeeded and whether any servers were parsed. A subscription update timeout doesn't necessarily mean the active server is down.
- Startup stage: Check whether the core exited and whether the local listener started.
address already in useusually points to a conflict with the listening address or port. - Connection stage: Check whether the failure occurred during DNS resolution, the remote connection, or the handshake.
timeoutonly means that one step timed out; the word alone doesn't identify the cause. - Before sharing logs: Redact subscription URLs, UUIDs, passwords, and other credentials. Keep the error text, timestamp, and relevant details about what you were doing.
Why isn't my browser using the proxy when the server list has entries?
Right-click a server and choose Set as Active Server, then check the logs for core startup errors. Make sure System Proxy is set to Set system proxy automatically. If your browser has its own proxy settings, check whether they override the system settings and whether the address and port match the local listener.
The update succeeded, so why is the group still empty?
Switch to All, clear any search filters, then select the target group again. If it is still empty, check the logs to see whether only the download succeeded or whether servers were parsed, too. A successful network request may still return a web page or an error message instead of importable configuration.
If a port is already in use, should I change the server's port?
Don't change the remote port first. Close any duplicate client instances, then check the local listening port under Settings → Parameter Settings. If you do need to change it, update any proxy port entered manually in your apps and reapply the system proxy settings.
Why can't I open a website even though the real connection test succeeded?
The real connection test only checks its own test destination. Confirm that your browser is using the proxy, then check the active routing configuration and DNS-related logs. If only one site fails, consider the site's own status, access restrictions, or required connection method before reinstalling the client.
Before closing the main window
After your first setup, connect the four key details: the server list provides the destination, core logs show whether it started, the local listener provides an entry point, and the system proxy or app settings send requests to it. Check them in that order to keep useful clues and avoid repeatedly switching servers.
- Confirm the right group is selected and the active server is the one you intend to use.
- Run a real connection latency test and check its timestamp and result; don't treat an old result as current.
- Check the startup log for local port conflicts and configuration loading errors.
- Verify the address and port in the system proxy or app proxy settings, then try accessing a site.
- When you're done, reset the system proxy before closing the client. Do not rely on Do not change system proxy to clear old settings.
To explore routing and DNS, visit Advanced Setup. For terms related to protocols, cores, and subscriptions, see the glossary. Keep a verified working configuration before adding features one at a time.