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

1. After Importing a Subscription, Check Your Servers and Local Listener

A successful subscription update only means the client downloaded a configuration it could parse; it doesn't mean every server in it is reachable. v2rayN is the management interface, while the selected core establishes the connection. Once server names, addresses, and protocols appear in the list, you still need to test a server, set it as active, and start the core.

This guide uses v2rayN on Windows desktop. Menu locations may differ between Desktop and WPF interfaces, so use the menu labels below to find settings. If you can't find a matching item, check your interface and version rather than guessing from screenshots. For the initial test, leave TUN off and disable other proxy apps to reduce routing and port conflicts.

1. Check the Subscription Group

   Open “Subscription Group” in the main window, select the group you just imported, and make sure the server list isn't empty. Check the expiration date and data allowance. A region in a server name is only a label; it doesn't confirm the exit location or availability.

2. Check the Listening Port

   Go to “Settings” → “Parameter Settings” and find the local listening port options. Note the port and supported proxy types. The examples below use the mixed port 10808 configured on this machine. If your interface shows a different port, update the commands accordingly.

3. Choose a Few Servers

   Start with 3–5 servers from the same subscription, prioritizing nearby locations and routes the provider recommends for your network. Don't test hundreds of servers at once; concurrent requests can skew the results.

4. Open the Logs

   Expand the log panel in the main window and check the core startup messages. If you see address already in use, resolve the local port conflict first; switching remote servers usually won't help.

2. How to Test Real-World Latency and Choose a Server

Select the servers you want to test, right-click the server list, and choose “Test server real connection latency.” Wait for the results. Some interfaces add a multi-select or keyboard shortcut hint to the menu item. Don't keep switching cores, changing the test URL, or updating the subscription while a test is running; results from different runs won't be easy to compare.

A real-connection latency test accesses the configured test URL through a server, making it a better proxy-path check than simply probing the server's TCP port. Still, the result reflects only one test against one target, on one server, under current network conditions. It doesn't guarantee that every website will work or indicate download speed. If the test target is unavailable, several healthy routes may all appear to fail.

Choose based on repeated results, not just the lowest latency

Run three tests in a row on each candidate server, waiting a few seconds between runs. For example, if one server returns 120, 135, and 128 ms while another returns 80 ms, times out, then returns 900 ms, start with the first one. These figures illustrate how to interpret results; they aren't measurements from this site or a performance guarantee. Bandwidth, congestion, and rate limits on the destination can all make a low-latency server slow to download.

• Keep at least two servers that succeed across multiple tests so you can compare them later.
• If every test fails, check the system clock, subscription validity, and test target first. Don't rush to change protocol fields in bulk.
• If only one server fails, check its address, port, and provider status. Don't treat an isolated issue as a client-wide failure.

3. Set an Active Server and Enable the System Proxy

Select a server that passed the test, right-click it, and choose “Set as active server.” Wait for the core to reload. A highlighted selection isn't necessarily the active server, so confirm which item is marked active. Next, open “System Proxy” in the tray menu and choose “Automatically configure system proxy.” Then check the logs for startup errors.

For the initial check, temporarily select “Routing” → “Global” so ordinary requests are more likely to use the proxy, reducing interference from routing rules. “Global” describes how the core routes connections it receives; it doesn't make every app send its traffic to the core, nor does it necessarily remove special rules for loopback or local network traffic. Switch back to your preferred routing mode after verification.

4. Verify in a Browser: Check the Page, Exit IP, and Logs

With the system proxy enabled, open a new page in a browser that follows Windows system proxy settings. If the browser has a proxy extension, a separate proxy configured, or its own bypass rules, disable those overrides temporarily. A page loading is only the first clue: the site might have been reachable directly anyway.

1. Test a fresh request: Open a frequently used HTTPS site and refresh it; don't judge by a cached page. Note the time so you can find the corresponding log entries.
2. Check the exit IP: Use a trusted IP lookup page and compare the public IP with and without the proxy. Don't use a lookup service that asks for your subscription or account details.
3. Check the outbound route: Find the destination domain and outbound route in the core logs for the same time. If the outbound is shown as direct, the request may have reached the core but matched a direct-routing rule.
4. Test routing rules: After switching from Global back to your everyday rules, visit a site that should use the proxy and one that should connect directly. Confirm both behave as expected.

A changed exit IP is useful evidence, but geolocation databases can be outdated, and a single route may use multiple exit IPs. Don't rely solely on the country or city shown, and don't assume a mismatch between the exit region and server name means the connection failed. Check the IP, actual requests, and logs together. If logging is set to a low detail level, missing per-request entries alone don't prove that a request bypassed the core.

5. Verify from the Command Line with an Explicit Local Proxy

Command-line tools may not read Windows system proxy settings. To check the path from the local core to the remote server, specify a SOCKS proxy explicitly as shown below, without relying on the system proxy toggle. First confirm that 127.0.0.1:10808 provides a SOCKS or mixed listener on your machine. If your port differs, replace it before running the command.

Run the following command in PowerShell. Use curl.exe to avoid invoking a same-named alias in some environments. socks5h sends the destination hostname to the proxy for resolution, helping separate local DNS effects from proxy connectivity. If you've set the NO_PROXY environment variable, make sure it doesn't bypass the proxy for the test domain.

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

Receiving an HTTP response from the destination means the explicit proxy request completed a network exchange. For a response such as 403, distinguish the website's access policy from a connection failure. This alone doesn't prove your browser is using the proxy. To compare with a direct request, run the command below; even if both requests succeed, that doesn't prove they use the same exit IP.

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com

• Can't connect to 127.0.0.1: Check whether the core is running and the port is correct before changing your subscription.
• Local connection works, but the request times out: Check the remote server, test target, and core logs. Try another server that passed the tests for comparison.
• Explicit proxy works, but the browser doesn't: Check the system proxy settings, browser-specific settings, and extensions. The problem is more likely in how the app connects to the proxy.
• Browser works, but the command fails: Check the port and proxy protocol specified in the command. Don't assume the browser and command use the same local proxy endpoint.

If needed, check whether the port is listening

Check the local listener in PowerShell. OwningProcess in the output is the process ID. A listening port only proves that a process has bound to it. In Task Manager, open “Details” and check whether that ID belongs to the expected core. If there's no output, return to the logs and resolve the startup error first.

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

6. First-Connection FAQs and Final Checks

A successful first connection isn't just a green latency number. Look for repeatable results: the active server is clear, the core is listening normally, explicit proxy requests succeed, and the browser's exit IP and routing match your expectations. Note the working server, local port, and everyday routing mode. If something breaks later, you can repeat the same tests to identify what changed without altering several settings at once.