V2Ray First Connection Guide: Choose a Server, Test Real-Connection Latency & Verify Your Proxy

Check your subscription and test setup first

A successful subscription update only means the client retrieved the configuration; it doesn't mean every server in it is reachable. Region, speed multiplier, and route labels are usually supplied by the subscription provider, not measured by the client. For your first connection, pick a few candidates from the same subscription group. Don't judge speed by server names alone.

The v2rayN menu names in this guide refer to the Chinese interface. Button locations may differ between versions, and menu names may include keyboard shortcuts. Before you begin, go to Help → About and note the version. If you're using a custom configuration, some GUI settings may not be included when the config is generated, so check the configuration that's actually loaded.

• Make sure the list isn't empty: Open the subscription group and check for server addresses, ports, and protocol details. If the list is empty, first check the group filter and subscription update status.
• Check the system clock: In Windows, go to Settings → Time & language → Date & time, turn on automatic time setting, and sync now. An incorrect clock can interfere with certificate checks and some protocol authentication.
• Keep your network consistent: Use the same network throughout a test run; don't switch hotspots midway. Pause large downloads to reduce interference from other traffic on your device.
• Avoid stacking proxies: Quit other proxy apps and temporarily disable browser proxy extensions. This guide checks the system proxy first and leaves TUN mode out of the initial troubleshooting.

Choose servers by checking availability first

Start with 3–5 candidates, prioritizing the exit region you actually need, then compare real-connection results. A shorter geographic distance can help reduce propagation latency, but routing detours, congestion, and server load can all affect results. A successful test only shows that the test target is reachable; it doesn't guarantee that every site or service will work.

Real-connection latency is not download speed. It measures how long a request takes to reach a test target through the proxy; the exact measurement depends on the client. Download speed also depends on bandwidth, concurrent connections, and limits imposed by the destination site. For a first connection, check availability first. Only run bandwidth-heavy download tests once you know the connection works.

Real-connection latency: test, compare, and connect

A TCP latency test typically checks only whether a TCP connection can be established with the server. It doesn't fully verify protocol authentication, transport settings, or access to the final destination. A real-connection test tries to request a test URL through the proxy, making it more useful for an initial check, though results still depend on the test URL itself.

1. Select candidates

   In the v2rayN main window, open the subscription group you want and hold Ctrl while selecting 3–5 rows. Selecting a row does not make that server active.

2. Run a real-connection test

   Right-click the server list and select Test server real connection latency. Some versions indicate multi-select support or a keyboard shortcut in the menu label. Don't choose Test server latency (TCPing) or the download speed test by mistake.

3. Compare repeated tests

   Wait for the current test run to finish, then test the same candidates twice more, for three runs total. Note how often each succeeds or fails, and watch for large latency swings. Treat timeouts and failed tests as failures, not as zero-latency results.

4. Set as active

   Right-click a consistently performing candidate and select Set as active server. Check that the active indicator and status information at the bottom of the window have updated, then check the logs for core startup errors.

5. Check startup

   If the logs show address already in use, resolve the local listening-port conflict first. For authentication, TLS, or handshake errors, check the configuration and system clock instead of assuming the network is slow.

System proxy: route browser traffic through the client

These steps use Windows as an example. Right-click the v2rayN icon in the taskbar notification area and select System proxy → Automatically configure system proxy. Then open Windows Settings → Network & Internet → Proxy and check the manual proxy address and port. A common local address is 127.0.0.1; the port should match the client's listening settings.

In v2rayN, go to Settings → Parameter settings and check the local listening port and the HTTP or mixed-proxy entry point. The settings layout varies between versions, so don't assume a port from an online guide is the one configured on your device. Older configurations may use a separate HTTP port, such as 10809; newer configurations may accept multiple proxy request types on a single mixed port.

The local port accepts requests from apps on your device; the server port belongs to the remote server. They serve different purposes. After changing the local port, reload the configuration in the client and update the system proxy and any apps with manually configured proxy settings.

• Browser entry point: Start with a browser that uses the system proxy. If the browser has its own proxy settings, check them too. Incognito mode does not necessarily disable proxy extensions.
• Routing exit: Enabling the system proxy only sends requests to the client; routing rules may still send them directly to the internet. Note the current routing preset first, then check which rule matches the destination domain.
• Other apps: Command-line tools, games, and some apps may not use the system proxy. A successful browser test doesn't mean every app is connected, and it doesn't prove that UDP traffic is going through the proxy.

Verify proxy traffic: cross-check requests and logs

Opening a known, accessible HTTPS page only proves that the page loaded. If the site is also reachable directly, check the routing logs to confirm the route. Open the client logs before refreshing the page. If needed, temporarily increase the log level to see access records, then restore the original setting when you're done troubleshooting.

To distinguish a system proxy configuration issue from a local proxy connection issue, run the following explicit proxy request in Windows Terminal. It uses curl.exe to avoid environments where curl is interpreted as a different command. Before running it, make sure 10808 is a local port that accepts HTTP proxy requests.

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

--noproxy "" clears the proxy bypass list for this request, while --proxy explicitly specifies the local entry point. The 10-second connection timeout and 20-second total limit prevent a long wait. This command runs a one-off test; it does not change your browser or system settings. The example uses a regular HTTPS site, not a dedicated server testing service.

Desktop and Android: different entry points

The Windows system proxy in v2rayN and Android VPN routing in v2rayNG work differently. Both clients can use a subscription from the same provider, but whether it can be imported and connected depends on protocol support and the configuration. A successful connection on one device does not remove the need to verify the other.

Common first-connection questions