For desktop users who have imported a subscription but aren’t sure how to connect. Start with a few candidate nodes, use real connection latency tests to rule out unusable routes, then check the local proxy port, system proxy, and the destination request’s public IP. This walkthrough uses v2rayN on Windows and focuses on repeatable checks—not just a number in the node list.
1. After importing: Check nodes, core, and local ports
A successful subscription update only means the client retrieved the node configuration. It does not confirm that your account is valid, the server is reachable, or your browser is using the proxy. First, make sure the list contains actual server entries, not just a subscription group name. Then select a node so the client loads its configuration. The server address, credentials, transport, and TLS settings all affect the connection; the node label alone tells you nothing definitive.
The steps below use common menu names from the Windows desktop interface. Labels may vary slightly between versions—for example, “Test server real connection latency” may appear as “Test real connection latency.” Use the equivalent feature, and don’t change existing settings just to match a menu label.
-
Check the subscription
Under “Subscription Group” → “Subscription Group Settings,” make sure the group is enabled. Then choose “Update all subscriptions (without proxy)” from the “Subscription Group” menu. Check the update log and node list. If your current network can’t reach the subscription URL, troubleshoot subscription retrieval first.
-
Check the settings
Select a node, right-click it, and choose “Edit server.” Check that the address, port, protocol, and transport settings all come from the same configuration. For VLESS with REALITY, the public key, server name, shortId, and other settings must also match the server. Don’t guess or fill in missing values yourself.
-
Check the port
Open “Settings” → “Parameter Settings” and find the local listening port and related inbound settings. Note the actual port for the HTTP or mixed proxy. The commands in this guide use
127.0.0.1:10808as an example that supports HTTP proxying; replace it with the value shown in your settings before running them. -
Set as active
Right-click a node and choose “Set as active server.” Confirm that the active marker moves to the intended node, then check the log for configuration load failures, core exits, or port conflicts. Selecting a row does not necessarily make that node active.
2. Choosing a node: Region, protocol, and reliability
Start with two or three candidate nodes in the same region to avoid confounding the results by changing regions and service routes at once. Geographic distance can help narrow the list, but it can’t replace testing: peering, peak-hour congestion, server load, and intermediate routing all affect performance. The region in a node’s label may not match its actual exit location.
Candidate nodes in the same region
RecommendedAmong nodes that meet the target website’s regional requirements, pick two or three and run repeated real connection tests. Favor routes that succeed consistently with little variation over ones that occasionally show the lowest latency.
Best for: first-time connections, everyday browsing, and establishing a baseline
Nodes in a specific region
When a service requires a particular region, rely on the actual exit location and how the website identifies it. Higher latency doesn’t necessarily mean the configuration is wrong; it may be normal for a cross-region route.
Best for: services with specific regional access requirements
Alternative protocols
If the primary route fails, compare it with another fully configured node supported by your core. A protocol name alone doesn’t guarantee lower latency: results depend on the address, route, and transport combination.
Best for: distinguishing a route issue from a local environment issue
If your subscription includes VLESS + REALITY nodes, make sure the core you’re using supports that configuration. In v2rayN, look under “Settings” → “Parameter Settings” for options related to the core type, and check the startup log to see which core actually loaded. Don’t treat core names as a ranking of route quality, and don’t change security settings required by the server.
- Web browsing: First check that real connection tests succeed consistently, then observe how quickly pages open and how images and scripts load.
- Long downloads: Test sustained transfers separately. Low latency doesn’t mean high throughput; keep an eye on subscription data usage and test traffic.
- Region-specific services: Check the actual exit location and how the target website identifies it. Node labels are only a guide.
3. TCPing vs. real connection tests: What each one tells you
TCPing typically measures how long it takes to establish a TCP connection to a node’s address and port. It does not fully test proxy authentication, the transport handshake, or access to a destination website. A reachable port doesn’t prove that the proxy service behind it works; another service on the server or an upstream access layer may accept the connection.
A real connection latency test attempts to reach a configured test URL through the node, checking more of the proxy route. It’s a better indicator of whether a node can establish a connection for a request, but the result still depends on the test URL, DNS, timeout settings, and route conditions. It doesn’t guarantee access to every website.
| Test type | What it checks | What it can’t tell you |
|---|---|---|
| TCPing | Whether the node’s TCP port is reachable and how long connection setup takes | Whether authentication works or a proxy request completes |
| Real connection latency | Whether a request to the test URL succeeds through the node and how long it takes | Whether all websites work or what sustained download speeds will be |
| Download speed test | Transfer performance for a specific resource during the test period | Long-term reliability or performance for other destinations |
Recommended test sequence
- Select a few candidate nodes, then choose “Test server real connection latency” from the right-click menu or the same-named option in the “Server” menu.
- Use the same test URL and repeat the test three times, noting whether each run succeeds and how much latency varies. Don’t run download tests on a large number of nodes at once.
- If all tests fail, open “Settings” → “Parameter Settings,” check the real connection test URL, and make sure the test destination is reachable. Then review the log.
- Set a consistently successful node as the active server, then verify it with an actual application request. The test feature itself may not require the system proxy to be enabled.
If the list shows a negative value, timeout, or blank result, check the result description and logs for your version first. A negative value does not mean “extremely low latency.” If TCPing succeeds but the real connection test fails, check authentication, TLS, transport settings, and the test destination. If both fail, investigate the node address and port, local network, and firewall.
4. Verify the system proxy: Route requests to the local port
After setting an active node, you still need to direct application requests to v2rayN. Windows system proxy settings provide an entry point for apps that respect them; they don’t automatically route traffic from every program. Terminal tools, some browser extensions, and standalone apps may use their own proxy settings.
-
Enable the system proxy
Open “System Proxy” → “Automatically configure system proxy” from the v2rayN status bar or tray menu. Make sure the current mode isn’t “Clear system proxy.” For initial troubleshooting, avoid running other programs that modify system proxy settings at the same time.
-
Check Windows settings
Open Windows “Settings” → “Network & Internet” → “Proxy” and check whether the manual proxy points to the local address and correct port. If you use a setup script, check “Use setup script” as well; don’t look only at the manual proxy toggle.
-
Test the port directly
Run the command below in PowerShell with the proxy explicitly specified. This avoids differences in whether a terminal reads system proxy settings. If it can’t connect to the local port, check the listening port and core status first.
-
Check the browser
Set the browser to use the system proxy, temporarily disable extensions that manage proxy settings, and open a new page to the target website. If the command succeeds but the browser doesn’t, check the browser’s own proxy rules before changing your subscription.
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 15 --head https://example.com/This guide uses curl.exe to avoid PowerShell resolving curl to a different command. --noproxy "" clears the proxy bypass list for this command. The example requires a port that supports HTTP proxying. If you have a SOCKS-only inbound, use --proxy socks5h://127.0.0.1:10808 instead; socks5h sends the destination hostname to the proxy for resolution.
5. Verify the public IP: System proxy vs. routing rules
System proxy settings determine whether a request reaches the client; routing rules determine which outbound handles it. Even with the system proxy enabled, websites in mainland China may be routed directly by rule. So don’t use a website configured for direct access to decide that the proxy has failed, and don’t assume the exit has changed just because a page loads.
The commands below compare a direct request with a proxied request to the same HTTPS URL. The endpoint returns the public IP address seen for the request; it’s only a test destination, so availability still depends on your network and the service itself. If it’s unavailable, use a trusted IP lookup service, keeping the destination the same for both requests.
# Send a direct request without using a proxy
curl.exe --noproxy "*" --connect-timeout 10 --max-time 15 https://api.ipify.org
Write-Output ""
# Send an explicit request through the local HTTP or mixed proxy port
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 15 https://api.ipify.org
Write-Output ""- Different direct and proxy IPs: The two requests used different public exit IPs. Check the client log as well to confirm the proxy request used the intended outbound.
- Same IP for both requests: Check whether the domain is routed directly, whether another network proxy is in use, and whether the active node switched successfully. This alone doesn’t mean the node is broken.
- Direct request fails, proxy request succeeds: This confirms that the proxy route is reachable, but there’s no direct-exit baseline to compare. Check the log and the target website’s response for more context.
- Command succeeds, browser shows a different IP: Check browser extensions, independent proxy settings, and whether the browser is querying the same IP lookup domain.
To isolate the effect of routing, note the current routing mode first. In v2rayN, temporarily select a global rule under “Routing” that sends ordinary destination requests through the proxy outbound, then run the lookup again. Names may vary across versions and custom rules; check the rule contents and outbound tag in the log. Restore your original routing rules when you’re done.
6. Common first-connection issues and how to troubleshoot them
TCPing shows a result, but why does the real connection test keep timing out?
First check the node’s authentication details, transport type, TLS server name, and core support. Then make sure the test URL is reachable. A port accepting a TCP connection only completes the first part of the check; a failed proxy handshake can still cause the real connection test to time out.
The real connection test succeeded. Why won’t the website load?
First run a command with the proxy specified explicitly. Then check “System Proxy” → “Automatically configure system proxy” and the browser settings. If only one website fails, check its routing, DNS, and response instead of assuming all nodes are unusable.
What should I do if the log says the local port is already in use?
Run netstat -ano | findstr :10808 to find the process using the port, then check the corresponding PID in Task Manager. Make sure you haven’t started the client more than once. If you need to change the port, update it under “Settings” → “Parameter Settings,” then update the system proxy and test commands too.
Latency is low, but downloads are slow. Is the speed test inaccurate?
Latency measures how long a single request takes. Throughput depends on route bandwidth, congestion, the server, and the download destination. Compare two nodes at the same time using the same destination, avoid running multiple speed tests at once, and watch your subscription data usage.
I changed nodes, but the public IP is still the same. Did the switch fail?
Different entry nodes may share the same exit. Check the active server marker and logs for a new request, then run a fresh test. Existing browser connections may not switch immediately. If a rule sends the request directly, changing nodes won’t change its exit anyway.
Keep a record you can reuse
After your first successful connection, record the node label, protocol and transport combination, local listening port, test destination, routing mode, and test time. If problems come up later, repeat the same checks to help distinguish node changes from local configuration changes or a problem with the target website.
- Check locally first: Is the core running? Is the port listening? Is the correct server active?
- Then check the route: Did the real connection test succeed? Does an explicit proxy request get a response?
- Finally, check the app: Do the system proxy, browser settings, routing rule, and actual exit match your expectations?
- Before sharing logs: Redact subscription URLs, credentials, and other sensitive settings. Include only the error details needed to diagnose the issue.