For desktop users who have imported a subscription but haven't confirmed that their connection works. Start with a few candidate servers, distinguish port reachability checks from real connection tests, then verify the active server, local listener, system proxy, and routing logs. A successful latency test doesn't mean your browser is using the proxy; this guide checks each layer in turn.
1. Before your first connection
v2rayN is a client for configuring and managing connections; the selected core handles the actual proxy connection. Seeing servers in your subscription only means the client has configuration entries—it doesn't confirm that credentials are valid, a server is online, or your browser is sending requests through the local proxy. This guide uses the Windows desktop interface; menu labels may vary slightly by version.
For initial troubleshooting, use the system proxy and temporarily turn off TUN mode. Running both entry points at once makes it harder to pinpoint issues. Also close other apps that modify the system proxy or take over network traffic. Keep the current routing settings unchanged so you don't alter multiple variables at once.
- Check the subscription: The list should show each server's address, port, and protocol. Don't judge performance by the region or route in a server's label alone.
- Check the system clock: In Windows, open Settings → Time & language → Date & time and verify the date, time, and time zone. A significant clock error can cause certificate validation or protocol authentication to fail.
- Confirm the core is running: Check the client log for startup failures, configuration parsing errors, or a listener port that's already in use.
- Protect subscription details: Subscription and sharing links often contain access credentials. Blur links, user IDs, and authentication fields in troubleshooting screenshots.
2. Choose candidate servers and test in order
Testing a small number of candidate servers reduces the impact of running multiple tests at once. Server labels are for identification only; protocol names such as VLESS, VMess, Trojan, or Shadowsocks don't determine latency rankings. Distance, network routing, server load, and the test target's location all affect the results.
-
Choose candidates
Hold Ctrl and select three candidate servers in the server list. Start with entries that match your intended use and preferred region; don't repeatedly test the entire subscription right away.
-
Run Tcping
Right-click the selected entries and choose the latency test with “Tcping” in its name. First identify servers that consistently time out. For TCP-based connections, this is a preliminary check of whether the server address and port are reachable.
-
Test the real connection
Keep the same servers selected, then right-click and choose “Test server real connection latency.” Wait for the results to update. This runs a test; it doesn't automatically route your browser through each candidate server.
-
Compare repeat tests
Run three real connection tests for each candidate, keeping the test address and local network unchanged. Record how often each test succeeds and the range of results instead of keeping only the lowest reading.
-
Set the active server
Right-click the server you want and choose “Set as active server.” Confirm the active marker has moved, then check the logs for new startup or connection errors.
If two servers have similar latency, prefer the one that succeeds consistently and loads real pages reliably. You don't need to run a download speed test on your first connection; throughput tests use data and may interfere with latency tests running at the same time.
3. Tcping vs. real connection latency
Tcping mainly checks whether a TCP connection can be established to the server's port. It doesn't complete proxy protocol authentication or show whether the remote server can reach a website. A real connection latency test sends a request to a specified test address through the proxy, covering more of the connection path. The exact timing and success criteria depend on the client version and test implementation.
| Test type | What it checks | What it can't confirm |
|---|---|---|
| Tcping | Whether this device can reach the server address and TCP port | Valid proxy credentials, correct TLS settings, or website access |
| Real connection latency | Whether a request can reach a specified HTTP or HTTPS target through the proxy | Access to every website, whether the browser uses the system proxy, or sustained throughput |
| Browser access | How the current app accesses a site with the existing proxy and routing settings | Whether other apps use the same entry point and outbound route |
Real connection results also depend on DNS, the protocol handshake, TLS, the server's outbound connection, and the test target's response. A server with low Tcping latency can still time out on a real connection test. Conversely, an unavailable test address can make a connection look like a failure even if it can reach other sites. Note the test address and keep it the same when comparing servers.
4. Check the system proxy and local listener
After setting the active server, configure how apps send traffic to the proxy. In the System proxy menu at the bottom of the v2rayN main window, choose “Auto configure system proxy.” This writes the proxy address to system settings and mainly affects apps that read those settings; it doesn't route all network traffic.
In Windows, open Settings → Network & internet → Proxy and check the manual proxy settings. For the example in this guide, the proxy address should point to your local device, and the port should match the client's HTTP or mixed entry point. Don't enter the remote server's address and port here.
Client local entry point
- Listen address
127.0.0.1- Example port
10808- Entry type
- Mixed entry point for HTTP and SOCKS requests
- Where to check
- Listener information at the bottom of the main window and Parameter settings
This describes the local entry point. If you're using a separate HTTP port, enter that port instead.
Windows system proxy
- Enable the entry point
- “System proxy” → “Auto configure system proxy”
- Proxy address
127.0.0.1- Proxy port
- Must match the local HTTP or mixed port
- Applies to
- Requests from apps that read the system proxy settings and don't bypass the proxy
Matching the address and port is only a necessary condition; also make sure the corresponding entry point is listening.
You can check the local port in PowerShell with the command below. If your port isn't 10808, replace it with the actual value. TcpTestSucceeded : True only means the local TCP port is reachable. It doesn't prove that v2rayN is the process listening on it or that the remote proxy works.
Test-NetConnection -ComputerName 127.0.0.1 -Port 108085. Verify browser access and outbound routing
Open an HTTPS page you use regularly and can clearly tell has loaded successfully. Don't rely on content already shown in an old tab; refresh the page or open a new private window to reduce interference from caches and extensions. Enabling the system proxy shouldn't require changing certificates, and you should never disable certificate verification to work around a connection error.
- Check the entry point: The browser should use the system proxy or be explicitly configured to use the same local entry point. If a browser extension or policy sets a separate proxy, Windows settings may not apply.
- Check the request: Look in the client logs for the destination host and connection entry corresponding to the page you just opened. If needed, temporarily increase the log level, then restore it when you're done; detailed logs may include information about visited sites.
- Check the route: See which outbound connection handled the request. A routing rule may send it through a direct connection, so a page loading successfully doesn't by itself prove that traffic went through the remote server.
- Cross-check: Compare access to the same page with different active servers. If you use an IP lookup page, also make sure routing rules haven't sent that lookup request through a direct connection.
To check whether the browser settings are the issue or the local proxy is unavailable, explicitly specify the proxy when accessing this site from Windows Terminal. The command below retrieves only the response headers; update the parameter if you changed the local port.
curl.exe --head --proxy http://127.0.0.1:10808 https://7v2ray.com/6. Common first-connection issues
Troubleshoot in this order: “local listener → app entry point → routing → remote connection → destination response.” First identify the layer where the failure occurs, then change the relevant setting. Don't change the server, DNS, protocol settings, and test target all at once, or you won't know which change made a difference.
Tcping works, but the real connection test times out?
First make sure the test address hasn't changed, then check the logs from the time of failure. For authentication errors, check the subscription status. For TLS errors, verify the system clock and the server name required by the server. For connection timeouts, distinguish between a failure to connect to the server and a failure to reach the target. Don't arbitrarily change the VLESS Flow, Reality public key, or transport type.
The real connection test succeeds, but the browser still can't load pages?
Check “System proxy” → “Auto configure system proxy” again, then verify the address and port in Windows proxy settings. Cross-check with a curl command that explicitly specifies the proxy. If that command works but the browser doesn't, check browser proxy extensions, enterprise policies, and errors affecting individual sites first.
The log says address already in use?
Another process is using the listener port. First check whether the client is running more than once, then close any other app using that port. You can also change the local listener port under Settings → Parameter settings, then reapply the system proxy so its port matches the new listener port.
Low latency, but slow downloads?
A latency test measures the response to a small request, not sustained transfer speeds. Stop other speed tests first, then compare candidate servers using the same file or service. Check whether the slowdown affects only one destination; a single destination's bandwidth limits, throttling, or routing issues can't be explained by one latency reading.
Can't access the internet after closing the client?
Check whether Windows still has a manual proxy pointing to the local port. Restart v2rayN and choose “System proxy” → “Clear system proxy” to restore the settings. If the client won't start, disable the relevant manual proxy in Windows settings. Closing the window doesn't necessarily mean the process has exited.
A successful first connection isn't just “one row shows low latency.” The active server should be clear, the local entry point should be reachable, the browser should use the expected entry point, and the logs and routing should explain where requests went. Keep this checklist handy to troubleshoot future subscription updates or network changes in the same way.