For desktop users who have imported a subscription but aren't sure which servers work. Follow this sequence—check server settings → run a real connection test → set an active server → enable the system proxy → compare logs and your public IP—to pinpoint server, proxy, and routing issues separately. This guide uses v2rayN on Windows; you don't need to enable TUN to get started.
Before connecting: check your subscription and local proxy
A successful subscription update only means the client received server entries; it doesn't mean every server can connect. Check that each entry has an address, port, and protocol, then make sure the subscription is still active. VMess and VLESS also rely on correct identity parameters and transport settings. Don't change the provider's TLS, SNI, or transport path just to lower latency.
The menu names in this guide reflect common labels in the v2rayN 7.x Windows interface; button locations and wording may vary slightly between minor versions. Open “Settings” → “Parameter Settings” to check the local listening port, then return to the main window and check “System Proxy” and the routing mode at the bottom. Commands below assume a local mixed inbound that supports HTTP proxying at 127.0.0.1:10808. Check Parameter Settings and the startup log for the actual value.
Choose a server: real connection latency is a better guide to actual use than TCP latency
A TCP latency test checks whether a TCP connection can be established to a host and port. It doesn't confirm that the identity parameters are correct or that TLS, the transport layer, and the remote exit are working. A real connection test sends a request through the server to a test address, making it more useful for an initial shortlist. However, it only reflects access to that test address at that moment.
Real connection latency
RecommendedSelect a candidate server in the main window, right-click it, and choose “Test server real connection latency.” This sends a request to the configured test address through the proxy and can catch connection problems that a port check alone won't reveal.
Best for: initial screening and checking connectivity after switching servers
TCP latency
Choose “Test server latency Tcping” from the right-click menu to quickly check whether the TCP port is reachable. A latency reading doesn't mean the proxy is ready to use; nodes that rely on other transport methods can't be judged by this result alone.
Best for: distinguishing an unreachable port from a later handshake failure
Download speed test
Speed tests generate real traffic, so use them to compare throughput after confirming connectivity. A high speed doesn't guarantee that websites will load quickly, and you shouldn't run bulk tests across your entire subscription too often.
Best for: choosing a server for large downloads from a small group of working nodes
Start with 3–5 candidate servers and test each one 3 times to see whether it succeeds consistently. These are illustrative results, not tests run by this site: Server A returns 180, 195, and 188 ms; Server B returns 95 ms, times out, then returns 110 ms. For a first connection, favor a consistent option like A over B's single best result.
- Everything times out: First check that your local network can access the internet, then check whether the test address is available, your subscription is active, and the logs show a shared handshake error.
- Only some tests time out: Switch to a server that succeeds consistently before changing any global settings.
- Latency looks fine, but the target site fails: Test the target site separately. Reaching the test site doesn't mean every site will be reachable.
First connection: set an active server, then enable the system proxy
The highlighted row in the list isn't necessarily the server in use. Tests can also run against the selected entry, so a successful test and routing current traffic through that server are two different things. After testing, explicitly set the server as active and wait for the core to reload successfully.
-
Select a candidate
In the server list, click a node that passed the real connection test consistently. Check which entry you're acting on before using the right-click menu; don't rely on its previous row position after switching subscription groups.
-
Set as active
Right-click and choose “Set as active server,” then check the active indicator in the list and the reload result in the logs. A highlighted selection alone doesn't mean the switch succeeded.
-
Set up the proxy
From the “System Proxy” menu at the bottom of the main window, choose “Automatically configure system proxy.” You can also use the “System Proxy” submenu from the tray icon. Don't choose “Clear system proxy” for this test.
-
Check the routing mode
Note the current routing mode. To rule out split-routing effects, temporarily select the client's “Global” routing preset. Restore your usual split-routing preset when you're done.
-
Send a new request
Open a new browser window and visit the target page while watching the log at the bottom. If the browser reuses an old connection, quit it completely, reopen it, and repeat the test.
Verify the connection: compare your browser, public IP, and logs
A page loading by itself isn't enough to prove the proxy is working: the site may be reachable directly, or a routing rule may send it direct. For a more reliable check, compare the same destination with no proxy, with an explicitly specified proxy, and in a browser using the system proxy.
| Check | What to do | What the result tells you |
|---|---|---|
| Direct connection baseline | Send a request to an IP lookup service without a proxy and note the returned address | Shows the public IP your current network uses to reach that service directly |
| Explicit proxy | Use the local mixed port to request the same IP lookup service | Checks the local proxy entry, selected server, and remote exit route |
| Browser test | With the system proxy enabled, open the same lookup service in your browser | Compare with the explicit proxy result to check whether the browser uses the expected proxy entry |
| Check the logs | At the time of the request, look for the target domain, exit label, or any errors | Helps determine whether the request entered the core and was proxied, sent direct, or rejected |
In Windows PowerShell, use curl.exe to compare results. Specifying the executable avoids confusion with aliases that may exist in some environments. The commands below use a public IP lookup service, which will receive your current exit IP; choose a service that fits your privacy needs. If your port isn't 10808, replace it with your actual local HTTP or mixed-proxy listening port.
# Direct connection baseline: explicitly bypass the proxy
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org
# Explicitly use the local HTTP / mixed proxy entry
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://api.ipify.orgThese commands are still affected by the core's routing rules, so use the temporary Global routing preset you noted earlier when comparing results. If the second command returns a different public IP from the direct request, open https://api.ipify.org in your browser and compare its result with the second command. IP geolocation databases can be inaccurate, so don't judge whether the server changed based only on the country or city shown.
- Explicit proxy works, but the browser still shows the direct IP: First check the system proxy, browser proxy extensions, and the browser's own proxy settings.
- The two IPs match: First check that the lookup service isn't covered by a direct-connection rule, then verify the active server. Matching addresses alone don't prove that the proxy failed.
- IP lookup works, but a site you need doesn't: Check that site's routing, DNS, and server-side restrictions. There's no need to reinstall the client right away.
Check the logs at the time you sent the request. If the current log level records only warnings or errors, the absence of a request entry doesn't prove that the request bypassed the core. If needed, temporarily change the log level in “Settings” → “Parameter Settings” and send the request again. Logs may contain domains and addresses; restore the original setting when finished and redact sensitive details before sharing them.
Common issues: narrow down the cause based on where the connection fails
Real connection test passes, but the browser still can't open pages?
First run the explicit proxy command above. If it works, check whether “System Proxy” → “Automatically configure system proxy” is enabled and pause browser proxy extensions. If the command also fails, check the active server, routing mode, and logs from the time of the request. The real connection test and your browser use different destinations, so one can't replace the other.
Can't connect to 127.0.0.1:10808?
The local proxy entry isn't reachable; this isn't a high-latency issue with the remote server. Check the listening port in “Settings” → “Parameter Settings,” then confirm that the core started successfully. If the log says the address is already in use, run Get-NetTCPConnection -LocalPort 10808 -State Listen in PowerShell to check what's using it. Verify which process it is before taking action; don't terminate an unknown system process.
All pages fail after enabling the system proxy?
First select “Clear system proxy” from the “System Proxy” menu and check whether direct access works again. If it does, retest the server and check the local port. If direct access still fails, check your local network first. Clear the system proxy before closing the client too, so apps don't keep trying to connect to a local port that is no longer listening.
The logs show a certificate error. Can I disable certificate verification?
First sync your system clock in Windows “Settings” → “Time & language” → “Date & time,” then check that the server name for the node's TLS matches the SNI provided by your service provider. Keep certificate verification enabled; don't make bypassing verification a routine fix. If the settings are unclear, update your subscription and confirm the details with your provider.
A successful first connection isn't about a toggle changing color. Look for a set of repeatable checks: the server passes real connection tests consistently, the active server is clear, explicit proxy requests succeed, the browser behaves as expected, and the logs show no connection errors for the request. Restore your usual split-routing preset afterward and test the sites you use every day, so temporary troubleshooting settings don't stick around.
- Keep a working backup server and switch to it for another test if your primary server has problems.
- Note the port, routing preset, and time of failure. Don't save or share your full subscription URL.
- After restoring split routing, a direct IP on sites in mainland China may be the expected result. Check each site's routing rule; not every site should show the same exit IP.