v2rayN First Connection: Choose a Server, Test Real Latency, and Verify Your Proxy

At a glance

Importing nodes only adds configurations to the list. Before using v2rayN for the first time, check that the remote server is reachable, the proxy handshake succeeds, the local listener is working, and browser requests are routed through the proxy. This guide focuses on Windows desktop use and walks through testing candidate nodes, selecting an active server, enabling the system proxy, and verifying real requests—so you don't mistake a green latency reading for a working connection.

1. After importing: Check your nodes before testing

v2rayN is a desktop client for managing connection profiles, running a core, and providing a local proxy endpoint. Each row in the node list is usually a set of server connection parameters—not an established connection. A successful subscription update and correctly displayed node names don't prove that the server accepts those credentials.

Start with a small group of candidate nodes instead of testing hundreds of profiles at once. Large concurrent tests can burden your computer and network, and may trigger server-side connection limits. For a first check, test 3–5 nodes, prioritizing profiles from a known source with complete settings and an active service.

Check the subscription group: Select the subscription you just updated to avoid testing an older profile with the same name. An updated subscription doesn't mean every node in it is working.
Check the key settings: Open the node editor and verify the address, port, protocol, transport, and security settings. Credentials and TLS and transport parameters for protocols such as VLESS and VMess must match the server.
Check your system clock: Set the correct date, time, and time zone in Windows, then sync the clock. A significant time difference can affect certificate validation or authentication for some protocols.
Keep the settings unchanged: For your first connection, use the configuration provided by your service provider. Don't change the SNI or transport path, or disable certificate validation, just to run a test.

2. TCPing vs. real connection latency: What each test tells you

TCPing mainly checks whether a TCP connection can be established to a node's address and port. A real connection test uses the node configuration to make a proxy request to the test URL set in the client. The tests measure different paths, so their numbers aren't directly comparable—and a successful TCPing doesn't prove that a website will load through the proxy.

Real connection latency test

Recommended

Use this as the main test when selecting nodes for your first connection. It typically involves the local test core, node authentication, the transport handshake, and a request to the target site, making it closer to actual proxy use than a basic TCP port check. The timing method and success criteria depend on the current version.

Best for: Verifying a node configuration and choosing a reliable everyday server.

TCPing latency test

Quickly checks whether the remote TCP endpoint is reachable. A successful port connection doesn't mean protocol authentication passed or that the node can reach its destination. TCPing is even less useful for configurations that don't use TCP transport.

Best for: Catching an incorrect address, an unreachable port, or an obvious network outage.

For example, a node might show a TCPing result of 35 ms but time out in a real connection test because of incorrect credentials, TLS settings, the server's outbound connection, or the test target. Another node might show 80 ms for TCPing and 210 ms for a real connection, but succeed consistently—making it a better first-choice candidate. These figures are illustrative only; they aren't results measured by this site.

Rule of thumb: Check success rate before comparing latency

Keep nodes that pass repeated real connection tests, then compare their latency against the same test URL. A low TCPing result doesn't make a node a good primary server if proxy requests keep failing.

3. Run a real connection test: Try the same target three times

Select candidate rows in the node list, open the context menu, and look for “Test server real connection latency” or a similarly named option. To select multiple nodes, hold Ctrl as you click. The test only checks the selected profiles; it may not make one the active server, and it doesn't automatically enable proxying in your browser.

Check the test URL: Go to “Settings” → “Parameter settings” and find the option for latency or real connection tests. Note the current test URL. If the test target itself is unreachable, multiple nodes may fail at once.
Run the first round: Select 3–5 candidate profiles, run the real connection test, and note which succeed, time out, or return another error. Don't start downloads yet; they can use up your available bandwidth.
Run two more rounds: Wait a few seconds between tests, keeping the network, test URL, and candidate nodes the same. Prefer nodes that succeed all three times over those that occasionally show an unusually low figure.
Set the active server: Select a candidate node, choose “Set as active server” or the equivalent option from the context menu, and confirm that the active indicator has moved to it.
Check the startup result: Review the log at the bottom of the window. Make sure the core doesn't exit immediately and that there are no errors such as listener startup failures or invalid configuration.

Don't treat a latency test as a bandwidth test. Low real connection latency usually means a small request gets a quick response; it doesn't predict large-file download speeds. Server load, network congestion, and rate limits on the destination can all cause low latency and slow downloads at the same time.

3 rounds

Suggested number of test rounds, not measured performance data

10808

Example local HTTP-compatible proxy port used below

443

Common HTTPS destination port; this is not the node's port

4. Set up the system proxy so your browser uses the local endpoint

Selecting an active server determines which connection settings the client uses. The system proxy determines where applications send their requests. These are separate steps. In Windows, right-click the v2rayN tray icon, open “System proxy” → “Set system proxy”, then check the system proxy status shown in the client.

Use the local listening port shown in your current settings and startup log. The example below uses 127.0.0.1:10808, assuming that port provides an HTTP proxy or an HTTP-compatible mixed endpoint. If your configuration uses a different port, substitute it. A SOCKS-only endpoint can't be used directly with an HTTP proxy command.

Check Windows settings: Open Windows “Settings” → “Network & Internet” → “Proxy” and make sure the proxy address and port match the client. The layout may vary between Windows versions.
Check your browser: For an initial test, use a browser window configured to follow the system proxy by default. If you have a proxy-switching extension, check that it isn't overriding the system settings.
Check the routing rules: The system proxy determines whether a request enters the client. Once it does, routing rules may send it direct, through the proxy, or block it.
Distinguish other modes: The system proxy doesn't route every program's traffic, and it isn't the same as TUN mode. For your first check, test the system proxy on its own instead of changing multiple ways to route traffic at once.

5. Verify the proxy: Cross-check the browser, commands, and logs

Open an HTTPS page that normally works to make sure your basic network connection is up, then visit a destination that should use the proxy under your current routing rules. A page loading on its own doesn't prove the proxy is working: it might be cached, or routing rules might send it direct. Check the logs for the new request as well.

Make a new request: Open a new browser window and visit the destination, using a hard refresh if needed. Note the time so you can find the request in the logs.
Check where the connection went: Look for the destination domain or connection entry in the client logs. If the logs show an outbound tag, check your current configuration to determine whether it means proxy or direct.
Check the actual page components: The page, images, and login requests may use different domains. If the homepage loads but images fail, check the failing domains individually instead of immediately switching every node.

To separate browser settings from local proxy issues, explicitly specify the proxy in Windows PowerShell. The command below tests the request path from the local proxy endpoint to an example HTTPS site; it doesn't verify whether the browser follows the system proxy. First make sure the example port matches your settings.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com

The connection timeout is set to 10 seconds and the overall timeout to 30 seconds, so a failed request won't wait indefinitely. Receiving HTTP response headers means the destination or an intermediary has responded at least in part. Even with a 403 status, investigate whether the destination refused the request or the outbound connection is restricted instead of assuming the local port is unreachable. The command is still affected by core routing; to confirm that traffic used a remote node, also check the outbound connection logs.

Rule of thumb: If the explicit proxy works but the browser doesn't, check the app's proxy settings

First verify the system proxy port, browser extensions, and any proxy settings configured separately in the app. If the explicit proxy command also fails, check the local listener, core logs, and real connection test for the node. Don't start by reinstalling the client.

6. Common issues: Troubleshoot by where the error occurs

Change one variable at a time. Changing nodes, modifying DNS, switching routing rules, and enabling other traffic-capture modes all at once makes it hard to tell what fixed the issue. Note which steps succeed and fail; this is usually more useful than repeatedly clicking Connect.

TCPing returns a number, but the real connection test keeps timing out. Is the node broken?

Not necessarily. First check whether the test URL is reachable, then verify the node's authentication and transport settings. If nodes from different sources all fail against the same test target, try a trusted HTTPS target known to be reachable. Don't disable certificate validation just to get a successful test.

The real connection test passes, but the browser still won't load pages. What should I check first?

First make sure the node is set as the active server, then check whether “System proxy” → “Set system proxy” is working. Next, try the explicit proxy command above. If the command succeeds but the browser fails, check browser proxy extensions, separate proxy settings, and leftover port settings.

The log says the port is already in use. How do I check?

First close any duplicate client instances, then check which ports are listening. In Windows, run the command below to view connections involving port 10808 and their process IDs. Output alone doesn't necessarily indicate a conflict: check the LISTENING rows, then identify the process in Task Manager. Don't terminate an unknown system process.

The latency is negative or marked as failed. Does that mean the network is extremely slow?

These readings usually indicate a failed test, not a real latency value you can compare. Check the error details to tell a timeout from authentication failure, a certificate error, or a test core startup failure, then try again. Don't include failed results in an average.

Some websites load and others don't. Should I switch protocols?

First check the routing path for the failing domain and look for DNS errors. If only certain destinations fail while the same node reliably opens other HTTPS pages, check the destination's restrictions and your routing rules first. Changing protocol isn't a universal fix for access problems.

netstat -ano | findstr :10808

7. First-connection checklist and clean shutdown

A first connection is working when you have consistent evidence along the path from the app to the remote server—not just a green number in the interface. Keep one reliable primary node and one backup; there's no need to reconfigure everything every day over a few milliseconds.

Candidate nodes repeatedly pass the real connection test against the same target.
The active node is clear, and the core runs without repeated startup or listener errors.
The local proxy address, system proxy settings, and port used by the app all match.
The destination page generates a new request, and its route in the logs matches your expectations.
Before fully exiting the client, set “System proxy” to “Clear system proxy” so Windows doesn't keep pointing to a local port that is no longer listening.

If something breaks later, troubleshoot in reverse: check whether the app is using the proxy, then whether routing is correct, and finally whether the node and server are working. For help importing configurations and getting set up, read the user guide. For VMess, VLESS, and transport settings, see the protocol guide.