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

At a glance

For users who have imported a subscription but aren't sure how to connect for the first time. Follow these steps: choose candidate servers → test real connectivity → set an active server → configure the system proxy → verify an actual request. This guide uses v2rayN on Windows to distinguish server availability, a running core, and apps using the proxy. Replace example ports with the values shown in your local settings.

1. Server list: Pick a few candidates

Main window → current subscription group. First, make sure the list contains server details such as addresses, ports, and protocols. A subscription distributes connection settings; it doesn't indicate connection status. Seeing server names means only that the client read the entries—not that the servers are reachable or that your browser is using the proxy.

For your first test, pick two or three candidates rather than repeatedly testing the entire subscription. Regions, multipliers, and route descriptions in server names are supplied by the provider and are only clues for filtering. Actual performance also depends on your network, server load, and destination. Two similarly named servers may use different exit routes.

Candidate with complete settings

Recommended

Prioritize entries with complete settings after updating the subscription that pass a real connectivity test. Verify access once before deciding which route to use long term. Avoid changing the protocol, routing, and DNS settings all at once.

Best for: first-time connections and establishing a repeatable test baseline

TCP port test only

A reachable TCP port indicates that the initial connection may be working, but authentication, the transport path, TLS, or a later HTTP request can still fail. Keep it as a candidate; don't assume it's usable.

Best for: distinguishing network reachability from protocol connection issues

Timed out or missing settings

First check that the subscription updated successfully, the service hasn't expired, and your system clock is accurate. Don't guess at changes to the UUID, SNI, transport path, or Reality settings; these must match the server.

Best for: pausing use and confirming settings with the provider

VMess and VLESS are protocols; WebSocket and similar options are transport methods; TLS and Reality involve connection security settings. For a first connection, don't assume newer protocols are faster. Keep the combination supplied by the subscription and make sure the selected core supports it. Changing the system proxy won't fix a failed protocol handshake caused by incorrect subscription settings.

2. Test real connectivity: Make sure the server can complete a request

Server list → select a candidate → right-click and choose “Test server real connection latency.” Some versions shorten this to “Test real connection latency”; use the label shown in your menu. This measures the time taken to reach a test address through the candidate server. It's not a simple ping or a download speed test.

Check the test address

Open Settings → Parameter Settings and look for the real connection test address options. Keep the client's existing address initially and make sure it's reachable from your network. Results before and after changing the address aren't directly comparable.
Select candidates

Return to the server list and Ctrl-click two or three entries. Pause any large downloads first so local bandwidth use doesn't mask differences between servers.
Run the real connection test

Right-click → “Test server real connection latency” and wait for the results. Start the next round once a clear result appears. Don't keep clicking and queue up multiple tests.
Retest and keep the reliable ones

Run another test using the same address and network. Prioritize servers that succeed in both rounds. Keep occasional timeouts on the list for access testing rather than treating a single result as a long-term verdict.

A real connection test typically creates a temporary connection through each candidate server; it doesn't require the browser to be configured to use the system proxy. It can help check the protocol connection and a request to the test destination, but it can't prove that every website is accessible. The exact timing method depends on the client, so compare results from the same test setup.

3. Active server and local port: Connect both ends

Server list → right-click a candidate → “Set as active server,” then check the main window status and logs. Don't rely on the highlighted row alone: it may simply be selected. Confirm that the active server indicator or status has changed and that the core hasn't immediately exited. Menu locations vary slightly between versions; the context menu is usually easier to verify than a keyboard shortcut.

Next, open Settings → Parameter Settings and check the local listening address and port. The cards below separate remote server details from your local proxy endpoint, so you don't accidentally enter the server's port 443 as the browser proxy port. These examples explain the fields; they aren't defaults for your computer or usable server settings.

Example: local proxy endpoint

Where to check: Settings → Parameter Settings
Listen address: 127.0.0.1
Example port: 10808
Requirements: The port supports HTTP or mixed proxy connections

Local apps connect here; command-line examples must also use the actual listening port.

Remote server settings

Where to check: Server list → Edit server
Server address: Use the value imported from the subscription
Example port: 443
Authentication and transport: Keep all settings supplied by the provider

The core connects here; the remote port cannot be used as the local proxy listening port.

Older configurations may use separate SOCKS and HTTP ports, such as 10808 and 10809. Newer configurations may use a single mixed port. You can't identify the protocol from the port number alone. If the logs show address already in use or a bind error, close any duplicate client processes and check which process is using the port. Don't troubleshoot websites until the core is listening.

10808

Example local port; replace it with the value shown in your settings

443

Example remote port; don't enter it as the system proxy

2 rounds

Retest under the same conditions and check whether the result is consistent

4. System proxy: Route browser traffic through the local endpoint

From the v2rayN main window or the tray context menu, choose System Proxy → Set system proxy automatically. Turn it on after the core is running, then check the proxy address and port in Windows Settings → Network & Internet → Proxy. “Set system proxy automatically” is the client's menu option; it doesn't mean you need to enter an automatic configuration script URL manually.

The system proxy tells apps that read it where to find the local endpoint; it doesn't force all traffic on your computer through the proxy. A browser may use the system settings, or override them with its own settings, extensions, or organizational policies. For your first test, disable extensions that might change proxy settings and open a new window to avoid interference from existing connections.

What to check	Where to check	What it means
System proxy entry	v2rayN “System Proxy” menu	After automatic setup, apps must still read the system proxy settings to use it.
Local address and port	Windows Settings → Network & Internet → Proxy	These should match the actual HTTP or mixed listening endpoint in the client.
Routing mode	Routing selection in the v2rayN main window	Controls whether requests handled by the core go direct, through the proxy, or are blocked; this is separate from the system proxy toggle.
Browser settings	Browser settings and extension management	Custom proxy rules can override system settings, so check them separately.

Use the current routing mode for your first verification; there's no need to enable Tun right away. If an app doesn't use the system proxy, check its own proxy settings or look into Tun permissions and traffic coverage if needed. Enabling multiple traffic interception methods at once makes it harder to tell where requests are going.

5. Verify it works: Match requests to the logs

In your browser, open a new HTTPS page you haven't visited before while watching the v2rayN logs. A page loading successfully isn't enough: it may come from the cache or be routed directly by a rule. Match the request time and destination domain with the outbound details in the logs to tell whether that request used the proxy server.

Check that the core is running: The logs shouldn't show repeated startup failures, port binding errors, or process exits.
Check that the app is connected: After you make a new request, look for the corresponding destination in the logs. If access logging is off, first check the logging options under Settings → Parameter Settings. Don't assume the app isn't connected just because no entry appears.
Check the routing outcome: Distinguish proxy, direct, and blocked traffic. Outbound labels vary by configuration, so identify them using your current routing rules; a domain appearing in the logs alone doesn't tell you which route it took.
Check the destination response: The page should return a valid response. Authentication failures, TLS errors, and connection timeouts need further investigation; a successful connection to the local port doesn't prove the request succeeded.

To rule out browser settings, use curl.exe in Windows Terminal and specify the proxy explicitly. This command assumes the HTTP or mixed port is 10808; change it first if your port differs. It sends a regular GET request, discards the response body, and displays connection details. It isn't a download speed test.

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

The command confirms that the request was sent to the specified local endpoint, but it can't show on its own whether the core ultimately used a proxy outbound route; a direct routing rule may still match the destination. Match the command's run time to the logs. If needed, briefly select a routing mode that explicitly sends the destination through the proxy, then retry. Restore your usual split-routing mode afterward. If environment variables define a proxy bypass list, check whether it affects the test.

6. First connection troubleshooting and cleanup

The real connection test passed, so why does the browser still time out?

First check that System Proxy → Set system proxy automatically has been applied, then confirm the Windows proxy port matches the current listening endpoint. Use the explicit proxy command above to rule out browser issues. If that fails too, check whether the active server is the same one you tested.

Every server times out. Has the subscription expired?

Don't assume so. First make sure your basic connection works without the proxy, check your system time and time zone, and verify the test address. Then check whether the core is running and the subscription is still valid. If only one test destination fails, retry with another address you know is reachable.

One website won't open. Should I switch servers?

Try a second destination first and check the logs for the failed request. A single website may be affected by DNS, routing, account region, or restrictions on the website itself. Keep your current working server and change one thing at a time to avoid mistaking a destination-specific issue for a problem with the entire route.

Why can't I browse after closing the client?

First, use the tray menu to choose System Proxy → Clear system proxy, then exit the client. If the program exited unexpectedly, check Windows Settings → Network & Internet → Proxy for a leftover manual proxy pointing to your computer. Contact your administrator about settings managed by your organization.

After verifying the connection, note three details: the active server, local listening port, and current routing mode. If something breaks later, check these values first instead of reinstalling the client or changing subscription settings in bulk. For further help, see Troubleshooting to narrow the issue down to the listener, protocol connection, routing, or app settings.

Before sharing logs, remove sensitive details such as subscription links, authentication information, and server addresses. Error types, timestamps, and steps you've already tried are usually more helpful than simply saying “it won't connect.” A successful first connection isn't just a latency number; you should be able to tell which local port received a new request from the app and which outbound route handled it.