v2rayN First Connection Guide: Choose a Server, Run a Real Latency Test, and Verify the Proxy

Complete Subscription and Core Checks First

After the first launch, do not simply double-click any server in the list. v2rayN’s server list is only a collection of configurations. Seeing a server name, protocol, and address does not mean the configuration can connect. Before starting, make sure the system clock is accurate, the subscription has updated successfully, and the core type used by the current configuration is correct. VMess, VLESS, Trojan, and similar configurations are usually handled by the Xray core. If a subscription provides other protocols, a mismatch between the core and protocol capabilities may cause the client to log a configuration error immediately after startup.

The v2rayN 7.x layout may change between minor releases, but the main controls remain grouped around subscription groups, servers, settings, and the system proxy area at the bottom. For your first setup, keep just one subscription group, get a single server working, and only then add routing rules or other groups. This makes log errors easier to trace to a specific configuration and avoids confusion from multiple servers with the same name.

1. Sync the System Clock

   Enable automatic synchronization in your operating system’s date and time settings. If the local clock differs from standard time by several minutes, connections that depend on time validation may fail during the handshake.

2. Add a Subscription

   Open “Subscription Groups” → “Subscription Group Settings” → “Add,” enter a group name, and paste the complete subscription URL. Save it and return to the main window.

3. Update the Servers

   Choose “Subscription Groups” → “Update All Subscriptions (Without Proxy).” Once the list shows protocols, aliases, and addresses, check the log at the bottom for subscription parsing errors.

4. Confirm the Core

   Go to “Settings” → “Parameter Settings” → “Core Type.” For a first connection, select Xray according to the subscription protocol. Save the setting, then reload the core configuration once.

5. Keep the Default Routing

   During the initial verification, use the client’s existing basic routing settings and do not import several sets of custom rules at once. Configure direct, proxy, and blocking rules only after the basic connection works.

Choose Testable Servers from the Subscription

Subscription lists are often named by region, route, or traffic multiplier, but a name alone cannot show whether a server is currently usable. First check that the protocol fields and address are complete, then choose servers that are geographically closer and whose names do not indicate maintenance or expiration. Distance usually affects round-trip latency, but peak-hour load, ingress routing, and server congestion also change real-world results. Do not judge a server by its region alone.

If dozens of servers are imported at once, filter by alias or group to select 5 to 10 candidates before running real connection latency tests. There is no need to test every server repeatedly: batch testing creates many connections in a short period and results can be distorted by local network jitter. The goal of the first pass is not to find the theoretically fastest configuration, but to identify one to three servers that can complete the handshake reliably.

If the same server measures 82 ms the first time and 96 ms the second time, that is normal variation. If it measures 90 ms first and then exceeds 900 ms or times out, move it down the list for now. Judge the results across consecutive tests instead of locking onto a server because it produced the lowest single reading.

Use Real Connection Latency Instead of Ping

Ping mainly measures the round-trip time of ICMP packets. A proxy connection also involves DNS resolution, TCP or another transport-layer connection, the TLS handshake, protocol authentication, and outbound traffic from the server. Some servers restrict ICMP, so Ping may respond even when the proxy port is unavailable. For a first server selection, use v2rayN’s real connection latency test rather than relying on Ping alone.

Select the candidate servers in the server list. Use “Test Server Real Connection Latency” from the “Servers” menu, or choose the same option from the right-click menu. For batch testing, select a limited number of servers with Shift or Ctrl. When testing finishes, results appear in the latency column. Investigate timeouts, blank results, or negative values together with the logs.

The figures above illustrate the filtering method; they are not universal thresholds that every network must meet. Home broadband, mobile hotspots, and corporate networks have different baseline latency, and evening congestion can increase variation. A more reliable standard is that a candidate returns results repeatedly, the difference between two tests does not grow excessively, and actual pages or requests do not keep timing out.

• A latency value appears: The test request completed at least one real connection, but you still need to verify the system proxy and application traffic.
• Everything times out: Check the local network, system clock, subscription validity, and core logs before blaming the server’s region.
• Only a few servers succeed: Use a successful server to complete the first connection, then inspect the protocol parameters or service status of the others separately.
• Results fluctuate sharply: Wait 30 seconds and test again with fewer servers selected to rule out temporary congestion.

Start the Server and Verify the Proxy in Three Steps

After choosing a server, double-click its row or use the right-click menu to set it as the active server. Then check the status area at the bottom to confirm that the core is running. v2rayN commonly listens on SOCKS 10808 and HTTP 10809, but different versions or existing configurations may use a mixed port. Always follow the local ports shown under “Settings” → “Parameter Settings.”

A running core only means that a local proxy entry point has been created. Whether the browser uses it depends on the system proxy state. For desktop applications that follow the operating system proxy, select “Automatically Configure System Proxy” from v2rayN’s system proxy menu at the bottom. If “Clear System Proxy” remains selected, ordinary browser requests may continue to connect directly even when a server is active.

1. Confirm the Core Is Running

   Check the bottom status bar and runtime logs. Confirm that the active server name is correct and that the logs contain no port-conflict, configuration-parsing, or authentication-failure messages.

2. Enable the System Proxy

   Select “Automatically Configure System Proxy” from the system proxy menu at the bottom, then fully close and reopen the browser used for testing to avoid reusing old connections.

3. Send an Actual Request

   Open a regular webpage you have not visited before and refresh it twice. Once the page loads consistently, check the access logs for the matching domain and a proxy outbound record.

4. Compare with a Direct Connection

   Temporarily select “Clear System Proxy” and request the same page again, then restore automatic configuration. The access paths in both states should match your expectations. Keep the mode you need after testing.

The third step is especially important because a page loading by itself does not prove that the request went through the proxy. The destination may have been directly reachable, or the browser may be reusing a connection created before the switch. A more reliable method is to check v2rayN’s access logs at the same time: a new domain record should appear when the page is refreshed, and it should match a proxy outbound. Only then can you confirm that the chain from the application to the local port, core, and remote server is connected.

curl -I --proxy http://127.0.0.1:10809 https://example.com

Command-line tools usually do not inherit the desktop system proxy automatically. The example above explicitly specifies the local HTTP proxy port and is suitable for checking whether 10809 is available. If Parameter Settings shows another port, replace it accordingly. Receiving HTTP response headers means that command completed a proxied request, but you should still check the core logs to confirm the actual outbound route.

Troubleshoot Terminals and Routing After the Browser Works

For the first connection, complete the full verification loop with a browser that follows system settings before moving on to terminals, development tools, and other applications. Programs handle proxy settings differently: some follow the system proxy, some read only their own settings, and some require an explicit HTTP or SOCKS address. If the browser works but the command line does not, the server is not necessarily at fault. Check the application’s own proxy entry point first.

The routing mode determines which outbound a request uses after entering the core. Basic rules generally send some destinations direct, route others through the proxy, and may block advertising domains or specific addresses. During initial verification, avoid piling on complex rules. Get the default rules working first, then use the logs to confirm which outbound matches each target domain. When rules conflict, an earlier matching rule may determine the result.

On Windows, macOS, and Linux, verify individually whether each desktop application follows the system proxy. On Android, after v2rayNG or v2flyNG establishes a connection, check that per-app proxy rules have not excluded the application under test. If one device connects while another does not, compare the subscription update time, selected server, and system clock first, then compare core capabilities. Do not copy local routing settings blindly between platforms.

Common First-Connection Failures

If none of the candidate servers can complete a real connection test, start with local conditions shared by all of them. When multiple servers fail at once, the cause is more likely an outdated subscription, an inaccurate system clock, a core that did not start, a DNS resolution problem, or a local port conflict than a single server failure. Retrying each server individually will only repeat the same error.

Runtime logs are the main evidence for identifying the failure stage. A refused connection usually means the destination address or port is not accepting connections. A timeout means network interaction did not complete within the allowed time. Authentication or user-information errors require checking the subscription parameters, including the UUID, password, transport method, and TLS-related settings. Do not change every parameter based on one status message. First determine whether the error occurred at the local listener, the remote handshake, or the routing outbound.

If one server fails while others work, the local proxy chain is probably usable, so narrow the investigation to that server. Update the subscription again and compare its address, port, transport method, TLS, and server name fields. Do not guess missing parameters manually. The configuration supplied by the subscription should keep its fields consistent; changing one item arbitrarily may create a new handshake error.

Configuration Order After Basic Verification

Once the basic connection works, change only one variable at a time. The recommended order is to lock in one stable server, confirm DNS resolution, configure routing, and handle application-level proxy settings last. Repeat an actual request and compare the logs after every change so you can identify which setting changed the result.

• Phase 1: Keep one active server that passed the real connection test and record its normal latency range.
• Phase 2: Check that DNS resolution is stable. Avoid changing multiple DNS solutions and routing rules at the same time.
• Phase 3: Add direct, proxy, and blocking rules as needed, then use the logs to confirm the matching order.
• Phase 4: Configure an explicit HTTP, SOCKS, or per-app proxy entry point for terminals or specific applications.
• Phase 5: Complete an independent connection test on Windows, macOS, Android, and Linux. Do not substitute the status from one platform for another.

The key to a first connection is not seeing an “Connected” indicator, but establishing a repeatable verification chain: a valid configuration exists in the subscription, the real connection test completes the remote handshake, the local core listens normally, application traffic reaches the proxy port, and routing rules send the request to the correct outbound. When speeds change or a page becomes inaccessible later, follow this chain layer by layer instead of repeatedly reinstalling the client or switching servers at random.