This guide is for users who have imported a subscription into v2rayN but have not completed their first connection. Check the node details and core type first, run a real connection latency test, enable the system proxy, then verify the result through core logs, the browser’s exit address, and an explicit proxy command.
Check the Node and Local Settings First
Key point
A successful subscription update only means the client received the server configuration; it does not mean a node is connected. The address, port, protocol, transport, and TLS settings in a node entry must be used together. Protocol names such as VLESS and VMess are only part of the configuration. Do not combine one node’s address with another node’s port, or casually change the UUID, flow control, SNI, or transport path before the first connection.
Key point
This guide uses the v2rayN 7.12.5 desktop interface as its menu reference. Labels may differ slightly between minor versions, but the workflow is the same: select the subscription group, update the subscription, then confirm the Core type and local listening port. For VLESS and Reality configurations, Xray is usually the right choice; Xray can also read existing VMess and WebSocket nodes.
Update Subscription
Open “Subscription Group” in the main interface, select the current group, and choose “Update Current Subscription.” Confirm that nodes appear in the server list and that the update time is not an old record.
Select the Core
Go to “Settings” → “Parameters Settings” → “Core Type” and choose Xray for standard VLESS and VMess nodes. Save, return to the main interface, and make sure the configuration is not still being handled by an incompatible core.
Check the Port
In “Settings” → “Parameters Settings,” check the local SOCKS listening port. The commands in this guide use 10808; if your interface shows a different value, replace it in all subsequent commands.
Sync the Clock
Enable automatic synchronization for the system date, time, and time zone. A large clock offset can make the TLS handshake fail because certificate validity is evaluated incorrectly.
Clear Old Proxies
Quit any old client still listening on the same port, then start v2rayN. A port cannot be occupied by two processes at once. This is especially important when the logs show “address already in use.”
Choose the First Node by Real Connection Latency
Key point
A node’s region and advertised multiplier do not prove that it is usable. For a first connection, real connection latency is the most useful metric: the client sends an actual request through the local proxy core, including protocol authentication, transport establishment, and the TLS handshake. It is therefore closer to the experience of opening a web page than basic network latency.
Key point
Select candidate nodes from the same subscription in the server list, right-click, open “Test Server,” and run “Real Connection Latency.” For the first round, test 3 to 8 nodes rather than hundreds at once. If the results are 186 ms, 242 ms, 611 ms, and timeout, try the first two first. Nodes above 500 ms may still connect, but their initial response is usually slower.
Basic Latency
Mainly measures the basic round-trip time between your device and the destination address. It is faster, but may not complete the proxy protocol and encryption handshake.
Best for: Quickly ruling out clearly unreachable addresses
Real Connection Latency
RecommendedCompletes an actual connection through the proxy core. Because the request path is closer to browser traffic, this is the most useful metric for choosing a first node.
Best for: First-node selection and everyday node switching
Download Speed Test
Transfers data continuously to measure throughput. Results are affected by the test endpoint, network congestion, local bandwidth, and node speed limits.
Best for: Comparing large-file speeds among usable nodes
| Real Connection Result | First-Connection Decision | Next Step |
|---|---|---|
| 80～300 ms | Usually suitable as a first-round candidate | Set as Active Server and Start the Proxy |
| 300～500 ms | May connect but respond slowly | Compare with other nodes in the same region |
| Over 500 ms | High latency or network congestion | Keep as a backup; try another node first |
| Timeout or -1 | The test request did not complete | Check the logs; do not delete it based on one result |
Key point
A single timeout does not prove that the configuration is invalid. The test endpoint may be temporarily unreachable, DNS resolution may have failed, the node may restrict the test address, or the core may have just started. Retry after ten seconds and check whether the log reports a timeout, connection refused, TLS error, or DNS error. The specific error type is more useful for diagnosis than one red number in the list.
Start the Node and System Proxy
Key point
After the real connection latency test finishes, double-click a candidate node or use the context menu to set it as the active server. The main interface usually marks the current node as selected. Then open the v2rayN menu in the system tray and choose a system proxy mode. For the first verification, use a mode that covers the request being tested. Otherwise, routing rules may classify the test site as a direct connection and create the false impression that the node is running but the exit address has not changed.
Key point
Core startup and the system proxy are two separate states. Once the core starts, a local port such as 127.0.0.1:10808 accepts proxy requests. Once the system proxy is enabled, browsers and apps that follow the system settings send traffic to that port automatically. If only the first step is complete, a command with an explicitly specified proxy may work while the browser still connects directly.
Set as Active
Double-click the node with the lower real connection latency and confirm that it becomes the active server. Do not stop at the highlighted row; the active server must actually change.
Start the Core
Watch the status and log panels at the bottom of the main window. A normal startup should report that the local port is listening and should not continuously output startup failures or port-conflict errors.
Enable the Proxy
Open the tray menu and choose a system proxy mode. During the first verification, disable any separately configured proxy in the browser so requests are not forwarded to another port.
Refresh the Connection
Fully close and reopen the browser, or open a new private window. Some long-running applications reuse old connections, so a normal page refresh may not switch to the new proxy immediately.
Verify That the Proxy Is Working in Three Steps
Key point
A status bar showing “Running” only proves that the core process started; it does not prove that the target traffic passed through the node. Reliable verification must cover the local entry point, proxy exit, and the application’s actual request. The following three checks use logs, the browser, and the command line to distinguish between a core that did not start, a system proxy that did not take over, and routing rules that sent the request directly.
Check the Core Logs
Open the v2rayN log panel and visit a new web page. You should see a new connection record showing that the request entered a proxy outbound, rather than repeated timeout, failed to dial, or TLS handshake error messages.
Compare the Browser Exit Address
With the system proxy disabled, record the public exit address once. Then enable the proxy and query it again in a new window. If the test domain follows the proxy rule, the exit address and provider should change.
Run an Explicit Proxy Request
Specify 127.0.0.1:10808 directly from the command line to bypass the system proxy settings. If the command succeeds but the browser result does not change, focus on system proxy takeover and the browser’s own network settings.
Key point
On Windows, use curl.exe in PowerShell or Command Prompt to avoid parameter-parsing issues caused by command aliases in older PowerShell environments. On macOS and Linux, the terminal usually uses curl directly. The following command sends DNS lookups through the SOCKS proxy as well; the final h in socks5h means the proxy resolves the target domain.
curl.exe --proxy socks5h://127.0.0.1:10808 https://api.ipify.org
curl --proxy socks5h://127.0.0.1:10808 https://api.ipify.orgKey point
The command returns a public address, showing that the local SOCKS entry received the request and obtained a response. Then run the same request without --proxy for comparison. Different results usually indicate that the explicit proxy path is working; identical results must be assessed alongside the node exit, routing rules, and logs rather than by comparing the address strings alone.
curl.exe https://api.ipify.org
curl https://api.ipify.orgKey point
With split-routing rules, the public-address test domain may be classified as a direct connection. In that case, the outbound tag in the logs is more reliable: the request should hit a proxy outbound, not direct or freedom. You can also choose a test domain explicitly configured for proxying, run the request again, and verify the domain, destination port 443, and outbound tag in the logs.
Quick Checks for a Failed First Connection
Key point
Do not change the node, core, port, routing, and DNS settings at the same time. Change one variable at a time, restart the core after each change, and test again. The shortest path is to confirm that the local port is listening, then confirm that the node completes the remote handshake, and only afterward troubleshoot the system proxy and split-routing rules.
What if every real connection latency test times out?
First confirm the subscription update time and system time, then go to “Settings” → “Parameters Settings” → “Core Type” and verify the core. Restart the core, test only one node, and use the logs to distinguish DNS failure, connection refusal, and handshake timeout.
What if the logs say the port is already in use?
Quit other proxy clients and old v2rayN processes, then check whether 10808 is still occupied. You can also switch to an unused port such as 10818 in the parameter settings; save and restart, then update the command-line parameter as well.
The command works, but the browser exit address does not change?
A successful explicit proxy request shows that the node and local SOCKS entry are basically working. Next, check the system proxy mode in the tray, disable the browser’s custom proxy, restart the browser, and confirm that the test domain was not classified as a direct connection by the routing rules.
Only one node fails while the others work?
The local environment is usually not at fault overall. Update the current subscription again and check that the failed node has a complete address, port, transport, TLS, SNI, and flow-control configuration. Do not copy individual fields from a working node over it.
The connection drops after a few minutes?
Keep the log panel open and record the error and time of the disconnection. If multiple nodes fail at once, check local network changes, sleep and wake events, and DNS. If only the current node fails, switch to a backup node in the same subscription with normal real connection latency and compare.
| Symptom | Layer to Check First | Key Evidence |
|---|---|---|
| Core fails to start | Local process and port | Listening failure or configuration parsing error in the logs |
| Explicit proxy also times out | Node and remote handshake | DNS, connection, TLS, or protocol error |
| Explicit proxy succeeds, browser fails | System proxy and application settings | Browser request does not appear in core logs |
| Some websites connect directly | Split routing | direct or freedom outbound in the logs |
Wrap Up After a Successful First Connection
Key point
After completing all three checks, you can restore your everyday routing mode and run one more comparison test. Direct connections for domains in mainland China and proxying for other requests are common split-routing goals, but the result depends on rule order and outbound tags. Rules are usually matched from top to bottom, so specific ad-blocking, private-address, and domain rules should come before broad rules.
Key point
Keep at least two nodes that have passed a real connection test: one primary and one backup. After switching nodes, test the exit address and logs again. Do not assume every node in the same subscription uses identical transport parameters. Subscription updates overwrite the node content delivered by the server, so confirm that a local manual edit is truly necessary before changing a subscription node.
- Record the current local listening port, such as SOCKS port 10808, so you can run explicit proxy tests later.
- Keep one backup node that stays within 300 ms and succeeds in three consecutive real connection tests.
- Run the real connection latency test again after updating the subscription; do not rely on speed-test results from several days ago.
- After changing geosite, geoip, or custom domain rules, verify the actual outbound tag in the logs.
- When troubleshooting, first record the error time, node name, and log type, then work through each layer.