v2rayN First Connection: Choose a Node, Test the Proxy, and Verify It Works

At a Glance

When connecting for the first time, verify three things separately: the node can handle a proxy request, it is selected as the active server, and your browser is sending requests to the local proxy. This guide is for desktop users who have imported nodes but aren't sure they're working. Follow the steps in order: choose a node → run a real connection test → configure the system proxy → check the browser and logs. Don't treat a single latency reading as the final verdict.

Choose an Active Node Before Checking the Connection

A node appearing in the server list only confirms that its configuration was imported. Selecting a row, testing it, and setting it as the active server are three separate actions. For your first connection, choose a node from a trusted source with complete settings, test it, and then make it active. Avoid changing nodes, routing, and DNS at the same time; otherwise, it will be hard to tell what caused a failure.

The steps below use labels commonly found in the classic Windows WPF interface. Button locations, translations, and shortcuts may differ in cross-platform desktop versions. Check the context menu and status bar in your current interface. v2rayN manages configuration and proxies; the core handles the actual connection. Opening the window doesn't mean the core has started successfully.

Check the Node's Source

Check the server list in the main window and confirm that the subscription group contains nodes. If the list is empty, import nodes first. If it already contains nodes, don't re-add the same subscription just to test it. A subscription URL is a credential; don't include it in public screenshots.
Select a Node to Test

Select a row in the server list, then right-click and choose “Test server real connection latency.” In the classic interface, Ctrl+R is commonly used; check the shortcut shown in the menu before using it. Test a few nodes at first to avoid skewing the results with too many concurrent tests.
Set It as the Active Server

Right-click a node that passed the test and choose “Set as active server.” In the classic interface, Enter is commonly used for this action. Then check the active indicator and the server name in the status bar—don't rely on the highlighted row alone.
Check the Core Logs

Check the log area in the main window for errors such as startup failures, configuration parsing failures, or address conflicts. Fix local startup issues before testing in a browser.

What TCPing and Real Connection Tests Tell You

TCPing mainly checks whether a TCP connection can be established to the server address and port. An open port doesn't mean proxy authentication, the transport path, and TLS negotiation are all working. The node's transport also affects how useful this metric is. TCPing is useful for an initial reachability check, but it can't prove on its own that a node works.

A real connection latency test sends a request to a test target through the node, so it more closely reflects actual proxy access than TCPing. It still only tells you whether that node could reach that particular test target; it doesn't mean every site is accessible or that your browser is using the proxy. These tests can usually run independently of the system proxy, so they may return a result even when the system proxy is off.

Check	What It Confirms	What It Doesn't Prove
TCPing	Whether a TCP connection to the server port could be established on the network at the time of the test	Successful proxy authentication or that the browser is using the proxy
Real connection latency	Whether a proxy request from the tested node to a specific test target completed	That all destinations are reachable or download throughput is high
Browser access	Whether the current browser can retrieve content from the current destination	That other apps also use the proxy or that this request definitely wasn't direct
Request-specific logs	The destination and selected outbound route, if the logs include those fields	That every connection on the device is being routed through the proxy

When comparing nodes, keep the test target, network, and method consistent. Run the same test three times on one node and look for repeated timeouts instead of focusing on the lowest result. There is no universal “good latency” threshold: distance, destination, and network route all matter. A consistently successful request is more useful than an occasional low reading.

TCPing succeeds, but the real connection test times out: First check the node settings, protocol handshake, and reachability of the test target.
The real connection test succeeds, but the browser can't load pages: First check the active node, system proxy, and the browser's own proxy settings.
Pages load, but large downloads are slow: Latency isn't throughput. Next, check for network congestion, node load, and limits imposed by the destination service.

Enable the System Proxy and Check the Local Listening Port

After the real connection test passes, open v2rayN's “System proxy” menu and choose “Automatically configure system proxy.” In the classic Windows interface, this option is usually available from the status bar or tray menu. “Automatically configure” means the client writes the system proxy settings; don't assume the name refers to a browser PAC script mode.

System proxy and routing mode are separate settings. The system proxy determines whether apps that honor it send requests to the local proxy; routing determines which outbound route the core uses for requests it receives. For your first test, turn off Tun mode and temporarily exit other programs that modify the system proxy. Keep a single proxy entry to avoid interference.

10808

The example below uses a local mixed port; check your actual configuration

443

A common HTTPS destination port, not a local proxy port

The local listening address is usually 127.0.0.1, which refers to the local machine. Ports may vary by version or existing configuration; older setups may use separate HTTP and SOCKS listeners. Don't overwrite your settings just because a guide uses 10808. In the client, check the local listening fields under “Settings” → “Parameter settings,” then compare them with the system proxy address.

Check in the Client

Active server: The selected node appears in the status bar
Listening address: Local loopback address: 127.0.0.1
Listening port: Example: 10808; check your current configuration
Core status: Running, with no port conflict errors

A mixed port accepts both HTTP and SOCKS requests. If the listeners are separate, use the port for the corresponding protocol.

Check in the System and Browser

Windows path: Settings → Network & Internet → Proxy
Proxy address: Must match the client's local listening address
Proxy port: Must match a port that accepts HTTP proxy requests
Browser settings: Use the system proxy and temporarily disable proxy extensions

The system page confirms that proxy settings were written, but you still need to make an actual request to verify that the core and node are working.

On macOS, check the relevant settings under “System Settings” → “Network” → the current network service's “Details” → “Proxies.” The exact menu path varies by system version. If your browser has its own proxy settings, use those. A system proxy doesn't route all device traffic; apps that don't honor it need to be configured separately.

Verify the Proxy with a Browser Request and Logs

The goal isn't simply to see whether a page loads. You need to confirm that this new request went through the local proxy and used the expected outbound route. A site in mainland China may load quickly because a routing rule sent it direct; a page that still shows old content may be cached. Check the browser, logs, and exit IP together for a complete picture.

Make a new request: Open a new browser window and visit a trusted HTTPS page, using a hard refresh if needed. A private window can reduce the impact of some caches and extensions, but it doesn't enable the proxy automatically.
Check the timestamp: Note when you send the request and look for the corresponding destination in the v2rayN logs. Log detail depends on the core and log level. If you don't see a request, first check whether the relevant logging is enabled; its absence doesn't prove the request bypassed the client.
Check the outbound route: If the logs show routing results, confirm the destination used a proxy outbound rather than direct. Some destinations going direct is expected in rule-based routing. A connection record in the client alone isn't enough.
Compare exit IPs: Use a trusted IP lookup page and note the result, then compare it with a direct connection under controlled conditions. The server's connection address isn't necessarily the exit IP; they can differ.
Restore your settings: If you temporarily changed the routing mode or log level to diagnose the issue, restore the original settings when you're done. There's no need to keep verbose logging enabled after the first test.

To separate browser settings from node problems, you can run a command that explicitly specifies the proxy. The Windows terminal example below assumes the local 10808 port accepts HTTP proxy requests; if your configuration differs, use the actual port. It requests a public documentation domain, not a dedicated speed-test service.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output NUL --write-out "HTTP %{http_code}\n" https://example.com/

This command explicitly sends the request to the local proxy, but the core's routing rules still determine the final outbound route. An HTTP response means this explicit proxy request received a response; it doesn't guarantee the destination service itself is working properly. If the local address can't be reached, check the listening port. If you see a certificate error, check the system time and error details—don't disable certificate verification.

Common First-Connection Missteps and What to Check

During troubleshooting, keep one test target and one active node, and change only one thing at a time. First fix the local listener, then check the node request, and finally check the browser and routing rules. This avoids repeatedly importing subscriptions, changing cores, or reinstalling the client without ever testing the actual point of failure.

Why Won't Pages Load Even Though There's a Latency Reading?

First check that the reading came from a real connection test, not TCPing, then confirm the node is set as the active server. Next, check “System proxy” → “Automatically configure system proxy” and the browser's proxy settings. A successful test on one row doesn't make the browser use that node automatically.

Every Real Connection Test Times Out. Are All My Nodes Down?

Not necessarily. First check the logs for core startup errors, verify the system time, and check your current network. Then look at the speed-test settings under “Settings” → “Parameter settings.” Menu group names may vary. Before changing the test address, note the original value and compare it with a target you've confirmed is reachable and suitable for testing.

Why Can't I Browse After Closing the Client?

Check whether the system is still pointing to the local proxy. Reopen the client, choose “System proxy” → “Clear system proxy,” then exit normally. If the client won't start, turn off the proxy entry you configured in the system proxy settings. On managed devices, check with your administrator first.

Why Does the Browser Work but Other Apps Don't?

Check whether the app honors the system proxy or has its own HTTP or SOCKS proxy settings. If configuring it manually, use the actual local listening port. Only investigate Tun mode if you've confirmed the app can't use either of those options. Don't combine multiple traffic-capture methods during your first test.

Why Are Downloads Still Slow When Latency Is Low?

The round-trip time for a small request doesn't measure sustained transfer speed. Keep the node the same, compare different destinations and times of day, and check whether only one site is slow. Don't enable Mux or change the transport just to lower the latency reading; those settings must match the protocol and server configuration.

After your first verification, note the active node, listening port, system proxy mode, and routing mode. These details make problems easier to reproduce than a latency screenshot alone. If connection issues come up later, check the same items in order. For more basic steps, see the Getting Started guide; for help by issue type, see the Troubleshooting guide.