v2rayN First Connection Guide: Choose a Server, Test Connectivity, and Verify Your Proxy

Before You Connect: Check Your Subscription, Core, and Local Listener

v2rayN provides the client interface; the selected core handles the actual connection. A successful subscription update only means the client received and parsed the server details. It doesn't confirm that a server is online or that your account has traffic available. For your first connection, keep the imported settings as they are. Don't change DNS, transport, routing, and certificate settings all at once.

Menu names below refer to a common Chinese-language interface; groups and punctuation may vary between desktop builds. This guide assumes no specific version or default port. Use the current client settings and startup logs to confirm the listening address and port.

1. Update the Subscription

   Open “Subscription Group” → “Subscription Group Settings” and check the address for the group you want. Then use the corresponding update command under “Subscription Group.” If this is your first connection, try updating without a proxy first. If it fails, check the update log instead of adding the same group again.

2. Check the Server Details

   Double-click a candidate in the server list to review its address, port, protocol, and transport settings. Make sure the address isn't blank and the remote port matches the subscription. A region label in the server name is a useful filter, not proof of the actual exit location.

3. Check the Core

   Go to “Settings” → “Parameter Settings” and review the core-related options. Configurations such as VLESS and REALITY require a core that supports their fields. For the first connection, keep the client's compatibility settings for the imported server, then check the logs for unsupported fields.

4. Note the Local Proxy Port

   In “Settings” → “Parameter Settings,” note the local listening port and check the listening address in the logs. The examples below use an HTTP or mixed proxy at 127.0.0.1:10808. If your port differs, replace it in the commands.

Choosing a Server: Start with Region, Then Check the Protocol

For the first round, keep two or three candidates: one relatively close to your network and one in a different region. If your subscription offers different transport options, add a candidate that uses a different protocol or transport. A closer region isn't always faster—peering, server load, and the outbound route all affect performance.

A protocol name isn't a performance ranking. VMess and VLESS use different authentication methods; WebSocket is a transport, while TLS and REALITY involve connection security. These settings must match the server as a set. The combinations below show which fields to check—they aren't ready-made configurations for arbitrary servers.

Real Connection Tests: Distinguish an Open Port from a Working Proxy

A TCP latency test mainly checks the connection to the server port; it doesn't prove that authentication succeeded. A real connection test attempts an actual request to a test address through the server, giving you a better sense of whether the proxy route can complete a request. The test address, timing, and success criteria depend on the client and its implementation, so confirm the result with a real visit as well.

1. Choose Candidates

   Select two or three servers in the list. To select multiple servers, hold Ctrl while clicking. Start with a small batch; too many concurrent requests can overload your network or trigger server-side limits, skewing the results.

2. Run a Real Connection Test

   Right-click to open the server menu, then choose “Test Server Real Connection Latency” or the equivalent real connection test option. Don't confuse it with the TCP results from “Test Server Latency.”

3. Repeat the Test

   Wait for the current round to finish before testing again. Run three rounds against the same test address. Note successes, large latency swings, and repeated timeouts instead of keeping only the lowest result.

4. Set the Active Server

   Right-click the server you want and choose “Set as Active Server.” Confirm that the active marker changes, then check the logs to make sure the new configuration loaded and the core started successfully. Selecting a server to test doesn't automatically make it active.

Real connection latency isn't download speed and can't predict whether video will play smoothly. If several servers fail against the same test address, first check that the address is available, whether the destination is restricting requests, and which route the request uses. Then decide whether the servers themselves are all down. Recording the date, network, and test address is more useful for troubleshooting than a screenshot of a single latency number.

System Proxy and Routing: Verify Each Path Separately

On Windows, open “System Proxy” from the v2rayN tray menu and select “Set system proxy automatically.” This lets apps that follow system proxy settings connect to the local listener. It doesn't capture every application or enable TUN. Browser-specific proxy settings, extensions, and organizational policies can override system settings.

For initial troubleshooting, use the system proxy path without adding TUN. This avoids introducing virtual adapter, permission, and system routing issues at the same time. After testing global proxy routing, restore your usual routing rules and test the destination again. “Global” here describes how the selected route handles traffic that reaches the core; it doesn't mean every app is routed through the core.

Verify the Browser and Public IP: Keep a Record You Can Check Later

First, send a request through the explicitly specified local proxy to confirm the entry point. Then check the system proxy in your browser. This helps distinguish a server problem from a browser that isn't using the proxy. Run these commands in a Windows terminal. curl.exe explicitly invokes curl; this example assumes an HTTP proxy is listening locally on 10808.

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

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://api.ipify.org

curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

The first command checks whether an HTTPS request can pass through the local proxy. If the response includes an HTTP status, determine whether it came from the destination or an intermediary error page; text appearing in the terminal alone doesn't prove success. The second command reports the public IP seen after the request follows the current route. The third provides a comparison without curl's explicit application-level proxy. If TUN or another network tunnel is still active, the third command doesn't represent an exit that completely bypasses tunnels.

• Proxy command works, but the browser doesn't: Check the system proxy port, browser-specific settings, and extensions first. Reinstalling the core isn't the first step.
• Proxy and direct connections show different exit IPs: The two requests used different observed exits. Check whether the browser sees the same result when visiting the same IP-check service.
• Both connections show the same exit IP: First check whether the IP-check domain matches a direct-connection rule and whether you changed the active server. The same IP alone doesn't prove that the proxy isn't running.
• The exit region doesn't match: Geolocation databases can disagree. Compare another IP-check service and the destination's own assessment instead of relying on the server label.

To verify the browser, open the same IP-check address used in the command, refresh, and record the exit IP. Then visit the site you actually want to use. Keep a record of these five details: active server, routing mode, test destination, exit IP, and time. An IP shows the exit used for one request; it doesn't prove that every app, domain, or DNS request follows the same route.

Common Connection Failures: Narrow Them Down by Log Stage

When a connection fails, start with the layer where the error occurred. Repeatedly refreshing the browser won't help if the core failed to start; if the local listener responds, changing its port may not fix remote authentication. Logs may contain subscription URLs, UUIDs, or other credentials—redact them before sharing a screenshot.

A successful first connection means more than seeing a latency number in the server list. The active server must load, a request explicitly sent through the proxy must succeed, the browser must use the expected entry point, and traffic to the destination must take the expected outbound route. Once all four checks pass, set up automatic updates, everyday routing, or other advanced options. Change one setting at a time so you can roll back easily if something breaks.