V2Ray First Connection Guide: Choose a Node, Run a Real Connection Test, and Verify Proxy Traffic

At a glance

For users who have imported a subscription but aren't sure whether the proxy is working. Choose a node in v2rayN and run a real connection test, then check the local listening port and verify the connection with both the terminal and a browser. Use the logs to distinguish node failures from system proxy issues and direct routing. Android users can follow the same checks in v2rayNG.

1. Understand Subscriptions, Nodes, and Active Connections

A successful subscription update only means the client fetched and parsed the configuration; it doesn't mean every node can connect. Names, regions, and protocols in the node list come from the configuration. A node name doesn't confirm its actual exit location, and seeing VMess or VLESS doesn't prove the server is working.

v2rayN is a desktop client for managing subscriptions, starting the core, and configuring traffic entry points. The selected core handles the remote connection. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. When troubleshooting, note both the client and core details; “V2Ray won't connect” isn't specific enough.

Check that the list is up to date: In v2rayN, choose the appropriate update option from the “Subscription Group” menu, then check the logs to confirm parsing completed. Don't rely only on seeing the subscription URL saved.
Check that a node is selected: Select a valid node, right-click and choose “Set as active server,” then confirm the active-server indicator in the main window. Clicking a row alone may not switch the active node.
Check that the core is running: Look in the logs for configuration parse errors, core exits, or listener failures. If the core hasn't started, enabling the system proxy won't establish a connection.
Check that the system clock is correct: On Linux, run timedatectl status to check the time and sync status. A significantly incorrect clock can cause TLS certificate validation failures and may also affect protocol authentication.

2. Find a Working Node with a Real Connection Test

v2rayN's TCP latency test checks the TCP connection to the remote address and port. A real connection test typically sends a request to a specified test URL through the node, covering more of the protocol and transport path. Neither test measures bandwidth. A successful test only shows that the test target was reachable at that moment; it doesn't replace testing the sites you actually use.

Choose candidates

In the node list, hold Ctrl and select three candidate nodes. Start with nodes on different routes, and avoid testing the entire subscription at once, which can create a large number of simultaneous connections.
Run the real connection test

Right-click to open the test menu and choose “Test server real connection latency” or the option containing “real connection” in your version. Menu wording may vary slightly. Don't confuse this with a TCP latency or download speed test.
Check the test target

If every test fails, open “Settings” → “Parameter Settings” and look for the real connection test URL and timeout settings. Note the URL being used. If the target itself is unreachable, try another known-working HTTPS test URL for comparison.
Repeat and compare

Test each candidate two more times using the same network and test URL. Prefer nodes that succeed consistently, then compare latency. Don't choose a node based only on the lowest result from a single test.
Set the active node

Set a consistently successful node as the active server. Wait for the core to switch, then open a site you actually need to use. Running a test doesn't necessarily make that node the one currently in use.

Latency in milliseconds depends on the test target, handshake, and network conditions at the time. Don't compare results directly across clients or test URLs. For initial troubleshooting, focus on whether tests succeed consistently and what the logs show when they fail—not on hitting a fixed latency threshold.

Real connection test

Recommended

Sends a request to the test target through the node, making it the best first check when choosing a node. After a successful test, still verify the browser and the sites you need to access.

Best for: Choosing a node for your first connection

TCP latency test

Checks whether the remote TCP port is reachable. A successful TCP connection doesn't confirm that the UUID, TLS, transport path, or other protocol settings are correct.

Best for: Quickly checking whether the server port is reachable

Real-world website access

Also depends on app proxy settings, DNS, routing rules, and the destination service. This is the final check of the user experience, but one failed attempt isn't enough to conclude that a node is down.

Best for: Checking your everyday use case

3. Check the Local Port and Traffic Entry Point

Next, check “the node works” separately from “the app is using the node.” In v2rayN, open “Settings” → “Parameter Settings” and look for the local listening port and address. If your version puts these options on a separate inbound settings page, use the settings shown there. The 10808 below is an example for the commands, not a universal port number.

Example local entry point

Listening address: 127.0.0.1
Example port: 10808
Entry protocol: SOCKS5; a mixed inbound also accepts HTTP
Where to check: Parameter Settings and core startup logs

Use the commands below only if the client is listening on that port. For a separate HTTP inbound, use its own port.

Initial verification scope

What to verify: Browser and curl on this device
System proxy: Affects apps that follow system settings
TUN mode: Can be turned off for the initial test
LAN sharing: Not needed for local testing

Test one entry point at a time. Combining the system proxy, TUN, and browser extensions makes it harder to trace where traffic is going.

On Linux, run the command below to check the example port. If there's no output, first confirm the actual port and core status. If another program is using it, close the conflicting program or choose a different local port, then update the app settings too. Don't open every firewall port just because the proxy isn't working.

ss -ltnp 'sport = :10808'

Listening on 127.0.0.1 accepts connections only from this device, which is suitable for this guide. 0.0.0.0 listens on all IPv4 interfaces and may allow other devices to connect. You don't need to enable “Allow connections from the LAN” for a first local connection.

4. Verify the Proxy Route with curl

Explicitly specifying a proxy in the terminal avoids uncertainty about whether the terminal uses system proxy settings. The commands below use the local SOCKS5 port 10808 as an example and query an HTTPS service that reports your public IP. If that service is down, the test may fail too; try another reachable target before concluding that the node is unavailable.

# Direct connection baseline: ignore proxy environment variables; failures are still useful for troubleshooting
curl --noproxy '*' --connect-timeout 10 --max-time 20 https://api.ipify.org
printf '\n'

# Explicitly use the local SOCKS5 proxy and resolve the destination hostname through the proxy
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://api.ipify.org
printf '\n'

In socks5h, the h means the proxy resolves the destination hostname, reducing interference from local DNS during this check. It doesn't mean DNS on the entire device is routed through the proxy. --noproxy "" clears the bypass list for this request, preventing the NO_PROXY environment variable from sending the test directly.

Direct and proxied requests show different exit IPs: This means the requests used different public exit IPs. Check the core's access logs too, to confirm that routing rules didn't send the proxied request through a direct outbound.
Both requests show the same exit IP: This doesn't necessarily mean the proxy is broken. The node may share a public exit IP with your device, or a client routing rule may be sending that hostname directly. Check which outbound was selected.
Connection to the local port is refused: First check whether the core is running and whether the port is correct. Repeatedly switching remote nodes won't fix a local listener issue.
The local connection succeeds, but the request times out: Check the logs for DNS, TLS, remote connection, or authentication errors. Try a second target to distinguish a problem with the target from a problem with the node.

To test an HTTP entry point, run the command below only if that port actually accepts HTTP proxy connections. A mixed inbound usually accepts both SOCKS and HTTP; a standalone SOCKS inbound can't be used as an HTTP port. Don't hide TLS errors by disabling certificate verification.

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

5. Check That the Browser and Routing Work

Once curl succeeds with an explicit proxy, configure the browser. In v2rayN, choose “System Proxy” → “Set system proxy.” If this doesn't take effect on your Linux desktop, open GNOME “Settings” → “Network” → “Network Proxy” → “Manual” and enter the local HTTP or SOCKS host and the corresponding port. Settings vary by desktop environment, so follow the options available on your system.

Browsers may have their own proxy settings. In Firefox, go to “Settings” → “General” → “Network Settings” → “Settings,” then choose “Use system proxy settings,” or manually enter the SOCKS host 127.0.0.1 and the actual port. Temporarily disable extensions that change proxy settings so they don't override the system configuration.

Open a new browser window, visit the same IP lookup URL used in the terminal test, and note the result.
Check the v2rayN access logs at the same time to confirm the request for that hostname and the selected outbound. If access logging is disabled, turn it on temporarily and restore the previous setting when you're done.
If the request matches a direct-routing rule, note the current routing mode. If needed, temporarily switch to the global proxy mode available in your version for comparison, then restore your original routing rules after testing.
Finally, visit a site you actually need to use. The first connection check is complete only when the entry point, routing, and access to the destination all work as expected.

On Android, select a node in v2rayNG, tap the connect button on the main screen, and approve the system VPN permission before testing the connection. A VPN status icon only confirms that a local tunnel was created; you still need to check that the destination is reachable. If per-app proxying is enabled, make sure the browser is included. In v2flyNG, check the connection status and app scope separately as well.

6. Common First-Connection Questions

The real connection test succeeds, but why won't the browser load pages?

First run the explicit SOCKS5 curl command. If it succeeds, focus on the browser's own proxy settings, the system proxy, and routing rules. If there are no corresponding requests in the browser access logs, the request probably hasn't reached the core. Don't start by changing protocol settings in the subscription.

TCP latency shows a result, but the real connection test keeps timing out. Why?

This means the remote TCP port is reachable, but a later part of the connection isn't completing. Check that the test target is available, then verify the system clock and look in the logs for TLS, authentication, or transport errors. If only one node fails, update the subscription and compare it with another node. Don't change VLESS to VMess yourself.

The command says it can't connect to 127.0.0.1:10808. What should I check?

Go back to “Settings” → “Parameter Settings” and confirm the actual port, then run the port check command. If the core log says the address is already in use, resolve the conflict and restart the core. Even a consistently working remote node can't fix a local port that isn't listening.

If a website loads, does that prove the proxy is working?

Not necessarily; the site may have been reachable directly. Consider the IP lookup result, the destination request in the core logs, and the selected proxy outbound together. A proxy icon, node name, or single test result can't prove the browser's actual traffic route on its own.

If the connection still doesn't work, include your operating system, client version, core name and version, entry type and port, test target, time of failure, and relevant error lines when requesting help. Find version details under the client's “Help” → “About” menu or in the core startup logs; avoid saying only “latest version.” These details help pinpoint the failed step and distinguish local settings from server configuration issues.