Start by distinguishing a selected row from the active server, then check subscription groups, proxy status, and logs. This guide is for desktop users who have opened v2rayN but aren’t sure what to do next. You’ll learn how to update a subscription, switch servers, check the connection, and avoid changing settings unnecessarily.
Get to know the four main areas
Start with the Server, Subscription Group, and Settings menus at the top, then check the list, logs, and status area at the bottom. This guide refers to the Chinese-language Windows desktop interface. Button locations, column names, and log display options may vary by version. If you can’t find a button in the same place, look for it by menu name rather than guessing from an old screenshot.
- Top menu: Use it to add servers, manage subscriptions, and open settings. These are action menus, not proof of the current connection status.
- Server list: Shows node configurations saved locally. Each row is usually a selectable server configuration, not necessarily an active connection.
- Log panel: Shows client actions and core runtime details. For a subscription update or connection failure, check the new logs from the time it happened.
- Bottom status area: View or change system proxy and routing settings here. Some versions also show local listening details, traffic, or a summary of the active configuration.
Server list: understand the columns, then choose an active server
Click a row, then right-click to see available actions. A click usually just selects the row for editing, testing, or batch operations. To switch servers, choose Set as active server from the context menu. Don’t assume a server is active just because its row is highlighted—check the active indicator, status summary, or logs from the switch.
| Common column | What it shows | How to use it |
|---|---|---|
| Alias or remark | The display name used to identify a node | Use it to identify a node by purpose. The provider defines any region or multiplier in the name; it isn’t a result detected by the client. |
| Type | Proxy protocol, such as VMess or VLESS | Use this to check that the import is correct; protocol type doesn’t indicate speed. |
| Address and port | The remote server’s connection endpoint | For example, remote port 443. This is not the proxy port you enter in a local app. |
| Transport and TLS | Settings related to the transport method and connection security | Match these to the server configuration; don’t change them on their own just to try to improve speed. |
| Subscription group | The subscription source a node belongs to | Use this to see which group is affected when updating, replacing, or removing nodes. |
| Latency and speed | Results from the most recent corresponding test | Check which type of test was run before comparing results. A blank value usually means no test result is available yet. |
When choosing a node, first check whether it can complete a real request, then compare latency. A TCP connection test mainly checks whether the server address and port accept a connection. A real-connection latency test accesses a test target through the proxy, so it’s closer to actual use, but results still depend on the test site, network load, and server policy. Speed tests use data, so there’s no need to run them on every node whenever you open the client.
For example, a result of 120 ms only reflects that particular test; it doesn’t tell you how fast videos will download. A value in the list also doesn’t mean your browser is using the proxy. If you just want to open a webpage, a node that completes a real request is more useful than repeatedly sorting by latency.
Subscription groups: distinguish filtering, saving, and updating
Open Subscription Group → Subscription Group Settings and confirm that the group name and subscription URL are saved. Groups organize subscription sources and often filter the list in the main window. Seeing only one group’s nodes after selecting it is normal. If nodes seem to be missing, switch back to All groups before deciding they were deleted.
-
Check the group
Go to Subscription Group → Subscription Group Settings and check the target group’s remark and URL. The name helps identify the group; the URL determines where updates come from. Subscription URLs may contain access credentials, so don’t share screenshots that expose them.
-
Save your settings
Save the changes in the group editor, then return to the main window. Pasting a URL into a field without saving and closing the editor doesn’t complete the subscription setup.
-
Update the current group
Select the target group, then choose Update current subscription (without proxy) or Update current subscription (through proxy) from the Subscription Group menu. If the subscription URL requires a proxy, first make sure a working proxy connection is available.
-
Check the update results
Review the logs from this update, then check the list. A URL may be reachable even if its contents use an unsupported format, in which case no nodes can be imported. Don’t assume that a successful download means the import succeeded.
Update current subscription processes the selected group; Update all subscriptions processes multiple sources. When troubleshooting, start with the current group so it’s easier to match the logs to the action. An update doesn’t simply append a few rows to the list—it may replace nodes in that group. Back up important manual changes rather than assuming they’ll survive the next update.
Bottom status area: what system proxy and routing do
At the bottom of the window, choose System Proxy → Set system proxy to let apps that follow Windows proxy settings use the client. Clear system proxy removes those system proxy settings. Neither action adds or removes nodes, and neither guarantees that every app uses the same network route.
System proxy controls
- Where to check
- System Proxy at the bottom of the main window
- How to enable
- Set system proxy
- How to undo
- Clear system proxy
- What it affects
- Apps that follow system proxy settings
Check whether the app uses the system proxy before deciding if the setting worked.
Routing rules
- Where to check
- Routing selector at the bottom, or Settings → Routing Settings
- What it handles
- Connections that have already reached the core
- Common outcomes
- Proxy, direct, or blocked
- What to check
- The active rules and outbound details in the connection logs
Rule names are only hints. Actual behavior depends on the enabled rules and their matching order.
The system proxy controls how an app sends requests to the client; routing determines where those requests go next. If the browser isn’t using the system proxy, changing routing usually won’t fix the connection. If a request has reached the core but a rule sends it direct, check the routing rules instead of repeatedly importing the subscription.
TUN is another way to route traffic into the client. It covers different traffic from the system proxy and may involve permissions, a virtual network adapter, and routing configuration. When testing the main window for the first time, use just one traffic entry method so you can tell which setting is taking effect. If TUN is already configured, note the current settings before changing anything.
Log panel: start with the latest action
Note when the action happens, repeat it once, then read only the new log entries. To view core runtime details, look for Show real-time log under Settings → Settings; some versions require a core restart for changes to take effect. Higher log verbosity usually produces more output, so restore your usual setting when you’re done troubleshooting.
- Just updated a subscription: Look for download failures, timeouts, parse errors, and import results. Start by checking the subscription URL and update method.
- Just switched servers: Check configuration loading, core startup, and listener status. If the core failed to start, browser symptoms are usually just a downstream effect.
- Just opened a webpage: If the relevant log output is enabled, look for the target connection, a timeout, or a handshake error. Not seeing the target in the logs doesn’t by itself prove there was no traffic.
- Just changed a local port: Look for binding or listening errors. If the logs show
address already in use, check whether another process is using the port before switching to a different remote server.
A handshake error doesn’t necessarily mean the protocol is unsupported; it may also be caused by server settings, system time, or network interference. A timeout doesn’t immediately mean the subscription is invalid: the subscription is just a source of configuration, and the timeout may occur while connecting to a remote server or accessing a destination site. Diagnose it in the context of the action you just took.
Settings: check ports before changing the core
Go to Settings → Settings and first check the local listening ports and related connection options. Use the values shown in your current interface; tutorial examples aren’t universal defaults. For example, an app can use 127.0.0.1:10809 only if the local HTTP proxy is actually listening there. If the interface shows a different port, enter that value instead.
Check in this order, depending on the app
Browsers that follow system proxy settings
- Set a server as active and confirm the core starts normally.
- Choose System Proxy → Set system proxy.
- Check that browser extensions or separate proxy settings aren’t overriding it.
- Open the target webpage, then use the logs to check where routing sent the request.
Apps with their own proxy settings
- First check whether the app supports HTTP or SOCKS proxies.
- Enter the local listening address and the actual port for the selected protocol.
- Before using port 10809, for example, confirm that it supports the protocol you need.
- Retry the request. Command-line apps may require proxy environment variables to be configured separately.
First direct the app to the right local proxy endpoint, then check the remote connection. Don’t enter the remote server’s port 443 as the local proxy port.
Check core-related options such as Core type under Settings → Settings only when a protocol or feature specifically requires it; the location may vary by version. VMess and VLESS are protocols, while Xray and V2Fly are core projects—they’re different layers. Switching cores won’t automatically fix an incorrect server address, user ID, or transport setting.
Change one setting at a time, note its original value, then repeat the same request. If you change the port, DNS, routing, and core all at once, it’s hard to tell what fixed the problem even if the connection works again. For a first-time setup, keeping the protocol and transport settings imported from the subscription usually makes issues easier to isolate than changing advanced options one by one.
Common main window questions and checks
Why am I still using the old exit IP after selecting a node?
Right-click the target row and choose Set as active server, then check the active indicator or the switch logs. Test with a new request; existing long-lived connections may not reconnect immediately. If a routing rule sends the destination direct, changing the active server won’t change the route for that request.
The subscription update succeeded, so why is the list still empty?
Switch to All groups, clear any search filters, then check the import results in the update logs. If the download succeeded but no recognizable nodes were imported, check the subscription content format. Don’t keep adding the same URL, which can create duplicate groups that are hard to tell apart.
Does a traffic counter in the status bar mean my webpage is using the proxy?
The traffic counter alone can’t tell you how a particular webpage was routed. The traffic may come from another connection or a background request. First confirm how the browser connects, then check the target connection and outbound details around the time you visited the page. Retry a single request if needed to reduce interference from other apps.
Why is the app still in the system tray after I close the window?
Closing the main window may just minimize the client to the system tray rather than exit it. To quit completely, right-click the tray icon and select Exit. If you enabled the system proxy, choose Clear system proxy first, then check Windows proxy settings after quitting to avoid leaving a proxy entry that points to a port with no active listener.
Follow this checklist in order: check the group and server list, set an active server, confirm the core started, choose a traffic entry method, check routing, make one request, and review the new logs. With this sequence, every main window control has a clear purpose, and it’s easier to distinguish a server configuration issue from an app that isn’t using the proxy.