For desktop users who have installed v2rayN and are ready to import a subscription or troubleshoot a connection. Follow the sections on the server list, subscription groups, traffic entry points, logs, and settings to tell the difference between a selected server, a running core, and app traffic actually routed through the proxy—and troubleshoot by changing one thing at a time.
Main window overview: configurations, entry points, and status
v2rayN is a desktop GUI client for managing server configurations, running a proxy core, and providing entry points such as the system proxy. Seeing a VMess or VLESS entry in the server list only means the configuration is saved. It doesn’t mean the core connected successfully—or that your browser is using it. Check the list, status bar, and logs together.
Button locations may vary by platform and interface version, and menu labels may differ slightly. This guide uses common labels from the Chinese desktop interface. Use the values shown in your own client and its startup logs; no particular port or core is a fixed default across all packages.
| Interface area | What it does | What to check |
|---|---|---|
| Server list | View, edit, and select servers | Active indicator, protocol, address, port, and group |
| Subscription groups | Save subscription sources and update the list | Update scope, method, and error messages |
| System proxy and routing | Control how traffic enters and leaves the core | System proxy status and current routing configuration |
| Log panel | Review startup messages, requests, and errors | Error time, destination address, and error type |
| Settings | Configure local listeners, logging, and runtime behavior | Ports, listening interfaces, and the core in use |
Server list: a selected row isn’t necessarily the active server
Clicking a row usually just selects it for editing, copying, or testing. To switch the server in use, right-click the row and choose “Set as active server,” then check the active indicator and startup logs. Don’t rely on the row’s background color to identify the connection, or mistake a latency value for the current connection status.
Use the context menu’s edit option to check the server address, server port, user ID, transport, TLS, and other fields. These values must match the server configuration; in particular, don’t enter a local listening port as the server port. Manual edits to subscription-generated entries may be overwritten during an update. Before making lasting changes, check how the subscription source is managed.
- Set the active server: After switching, check that the core starts normally, then test by visiting a webpage. Existing long-lived connections may need to be re-established by the app.
- Edit a server: During troubleshooting, compare each field with the server details. VMess and VLESS require different fields; changing only the protocol name isn’t enough.
- Copy or export: A share link may contain full authentication details. Don’t include it in public screenshots, group chats, or support requests.
- Bulk actions: Before deleting or testing multiple entries, confirm which ones are selected. Keep a recoverable subscription source before deleting entries in a group.
- Latency and speed tests: A TCP connection test isn’t the same as a proxy request test, and a speed test doesn’t necessarily reflect everyday app performance. Don’t mix different test results when sorting or comparing servers.
A test timeout doesn’t necessarily mean the server is down. An unreachable test target, DNS resolution problems, or an unsuitable test method can all affect the result. Start with a clearly configured entry, make a real request, and check the logs before deciding whether to delete it.
Subscription groups: import, update a specific group, or update through the proxy
Subscription groups store configuration sources and related management details—not network routes. Switching group tabs usually just filters the visible entries; it doesn’t mean the active server has changed. Create a group for each source to avoid mixing entries from different accounts or providers under one name.
-
Create a group
Open “Subscription groups” → “Subscription group settings,” add a group, and enter a recognizable note and the full subscription URL provided by your service. If the interface has a “+” button, you can use it to open the add-group dialog.
-
Choose the update scope
Return to the main window and select the group you want to update. From the “Subscription groups” menu, choose the option to update the current subscription. When troubleshooting for the first time, update one group and check the results and logs before updating all subscriptions.
-
Choose an update method
If the source is directly reachable, update without using a proxy. If a direct update fails and a working server is available, set it as active first, then update through the proxy. If the menu offers separate options, choose the one that matches your intended method.
-
Check the imported entries
Check that entries appear in the list, then review their protocols, notes, and group. Set the active server afterward. If the list is empty after an update, check the update logs and group filters before trying the import repeatedly.
Updating through the proxy requires a working local proxy entry and connection path; it can’t revive an expired subscription. If no server is available, first restore direct access to the source or use a valid configuration provided separately by the service. Subscription URLs often contain account tokens, so share only a redacted domain and error message when asking for help.
System proxy and TUN: choose the traffic entry point first
“Set system proxy” and routing mode solve different problems. The system proxy sends requests from apps that honor the system setting to a local port. Routing determines which outbound route handles requests after they reach the core. Choosing a proxy route has no effect if an app never sends traffic to the client.
Choose an entry point: start with the system proxy, then test TUN if needed
System proxy
- In the main window or tray menu, open “System proxy” and select “Set system proxy.”
- A good first step for testing browser requests that follow the system proxy setting.
- Some apps use their own proxy settings; check those separately.
- On Linux desktops, also check whether the app reads the desktop proxy settings.
TUN
- Uses a virtual network interface to capture traffic covered by the configuration. The routing and exclusion rules determine what gets captured.
- Before enabling it, confirm that your platform, permissions, and client components support TUN.
- For the first test, pause other tools that capture network traffic to reduce routing conflicts.
- If something goes wrong, turn off TUN and return to the verified system proxy setup.
Test one entry point at a time. Once it works, adjust routing. This helps distinguish “the request never reached the client” from “the request reached the client but took the wrong route.”
Direct, proxy, and block rules in the routing configuration determine the outbound route; they’re not the same as subscription groups in the interface. After changing a rule, send the same test request again and check the route label in the access logs. One website loading—or failing to load—doesn’t prove that every routing rule is working.
Settings: check the listening port and interface first
Open “Settings” → “Parameter settings” and start with the local listener options. Their location may vary across versions. The two cards below are configuration examples, not fixed defaults or remote server settings to copy as-is. When mixed listening is enabled, one port can accept both HTTP and SOCKS requests; check whether the current interface supports it.
Local access example
- Listening address
- 127.0.0.1
- Example port
- 10808
- Listener type
- Mixed listener; confirm it’s enabled
- Allow LAN access
- Off
Use the actual listening port in apps on this computer. If the port is already in use, choose a free one and update the app settings to match.
Log troubleshooting example
- Everyday log level
- warning
- Temporary troubleshooting level
- info
- Test requests
- One request to a specific target
- After troubleshooting
- Restore the previous log level
Access and error logs may be controlled separately. If only warnings are shown, it’s normal not to see every successful request.
“Allow connections from the LAN” changes which network interfaces accept connections. Leave it off if you only use the client on this computer. If you need to share access, also check your firewall, access controls, and whether the network is trusted. Listening on all interfaces exposes more than listening on 127.0.0.1; don’t open it just to troubleshoot a browser on one computer.
- Port conflict: First close any duplicate client instances, then change the local port. If your browser uses a manual proxy, update its port setting too.
- Core selection: If settings include “Core type” or other core options, make sure the selected core supports your configuration. v2rayN is the management interface; V2Ray and Xray are different cores, so the client’s name alone doesn’t tell you which protocols it supports.
- Start at login: Starting the client at login, automatically selecting a server, and setting the system proxy are separate actions. After enabling a startup option, sign out and back in to verify what actually happens.
- Apply changes: After saving, restart the core or client as prompted, then check the new startup logs. Logs from before the change don’t show whether the new configuration works.
Reading the log panel: check startup, entry point, then outbound route
When troubleshooting, note the time you reproduce the issue. Clear the panel, then perform just one action, such as switching the active server once or opening one webpage. The log panel may combine subscription updates, client activity, and core output. Identify which layer produced each message before deciding where the failure occurred.
| Log clue | What it usually means | What to check next |
|---|---|---|
address already in use | Local listening address or port is already in use | Close duplicate instances and check the actual listening port |
connection refused | The destination port actively refused the connection | Identify whether the destination is the local entry point or a remote server, then check the address and port |
timeout | A step didn’t finish within the time limit | Use the destination and context to distinguish a DNS, connection, TLS, or read timeout |
no such host | Domain name lookup failed | Check the server hostname for typos, then check the current network and DNS settings |
Errors related to certificate | Certificate validation or TLS settings may not match | Check the system clock, server certificate, and server name required by the configuration |
The command below tests a local HTTP proxy entry point in a Windows terminal. Run it only if the listening address, port, and entry type match the example; otherwise, replace them with your local values first. This is a test command, not a measured result or a guarantee of any server’s performance.
curl.exe --proxy http://127.0.0.1:10808 --head --max-time 15 https://example.com/If the command can’t connect to 127.0.0.1, check the core and local listener first—not the remote DNS. If the local entry point accepts the request but a remote connection or TLS error follows, check the active server configuration and network path. If you temporarily increase log verbosity, remove subscription tokens, user IDs, and other authentication details before sharing logs.
FAQ: The list looks fine, but the connection doesn’t behave as expected
I selected a server. Why is my browser still connecting directly?
First, right-click the target row and choose “Set as active server,” then check the status of “System proxy” → “Set system proxy.” If the browser uses its own proxy settings or an extension to control the proxy, check the browser’s entry point too. Selecting a row doesn’t perform these steps.
The subscription update succeeded. Why is the list still empty?
Switch to the all-groups view and clear any search filters, then confirm you’re viewing the group you just updated. If entries are still missing, check the update logs for parsing errors. A successful download doesn’t mean the server configurations were imported if the source returned a webpage or unsupported content.
The latency test shows a number. Why won’t webpages load?
Check what kind of test was run. A successful TCP connection only confirms that the connection was reachable at that stage; it doesn’t verify authentication, the transport path, or TLS settings. Set the server as active, make a real request, and check the core errors from the same time.
Why can’t my browser connect after I quit the client?
Reopen the client, choose “System proxy” → “Clear system proxy,” then exit and check your system’s network proxy settings. If you also set a manual proxy, remove any app settings that point to the local port. Once the local core exits, that port no longer provides a service.
A complete check should answer four questions: Which server is active? Which local port receives the app’s requests? Which outbound route did the core choose? At what stage did the log report a failure? Record these details before changing settings. It’s easier to find the cause than when you update subscriptions, switch cores, and enable TUN all at once.