For Windows users who have imported a subscription but aren't sure how to connect. Use Tcping to find reachable servers, then run a real-connection test to verify the proxy route. Set the active server, enable the system proxy, and confirm the result using browser requests, your public IP, and client logs. This guide checks the system proxy first and leaves TUN off to avoid mixing two traffic-routing methods.
1. After importing, check your servers and active server
Seeing entries in the server list only means the client has loaded server settings. It doesn't mean the subscription is still valid or that your browser is using the proxy. v2rayN provides the client interface, while the core handles connections. The server address, port, authentication details, and transport settings all affect whether a connection succeeds.
The steps below use the menus commonly found in the desktop version. Depending on the release, test menu items may include wording such as “multi-select.” Look for the functions “Tcping,” “Real connection latency,” and “Set as active server.” If an update moves a menu, check the version information under “Help” and note the full version number when troubleshooting.
-
Check the subscription
Open “Subscription Group” → “Subscription Group Settings” and make sure the group is enabled and its URL is complete. To fetch it again, choose “Update current subscription (without proxy)” from the “Subscription Group” menu. Try updating through a proxy only if you already have a working one.
-
Choose candidates
Select 3–5 servers from the list, preferably across different routes or regions. Don't rely on the region listed in a server's remarks: that label is supplied by the service provider and doesn't confirm the server's actual exit location.
-
Check reachability
Right-click the selected servers and choose “Test server latency (Tcping).” Keep candidates with a normal latency result. Set aside timed-out servers for now; don't immediately change their protocol settings.
-
Run a real-connection test
Right-click a candidate and choose “Test server real connection latency.” Pick a server that succeeds repeatedly, then right-click it and select “Set as active server.” Confirm that the active indicator changes in the list.
2. What Tcping and real-connection tests tell you
Tcping mainly checks whether the client can establish a TCP connection to the server's specified port. It's not an ICMP ping and doesn't fully test proxy authentication, TLS, the transport path, or access to the destination website. A reachable server port only confirms that the first step works.
A real-connection test uses the proxy core to send a request to the configured test address, so it more closely reflects actual proxy access. The result depends on the test address, DNS, the protocol handshake, and current network conditions. A timeout for one test address may simply mean that address isn't reachable over this route; one result alone doesn't prove the server is down.
| Results | What it means | Next step |
|---|---|---|
| Tcping: 48 ms; real connection: 260 ms | The port is reachable and the test request succeeded. The two tests cover different parts of the connection. | Set it as the active server, then use a browser to test the destination website. |
| Tcping: 35 ms; real connection: timed out | The port is reachable, but authentication, transport, name resolution, or the test destination may be failing. | Check the system clock and logs, then try another test destination. |
| Tcping: timed out; real connection: succeeded | There may have been a temporary network issue, or this connection method may not map directly to a TCP probe. | Test again, then rely on actual website access and the logs. |
| Both tests timed out | The current network path to the server, the server itself, or its configuration may have a problem. | Test another route to determine whether the issue is limited to one server or affects the wider network. |
The download-speed test in the menu measures something else: how much data can be transferred over time. A latency of 60 ms doesn't guarantee a high download speed, and a 300 ms real-connection result doesn't mean every web page will take that long to load. For your first connection, confirm that requests complete reliably before comparing throughput for your needs. Bulk testing uses data, so start with a small number of candidates.
3. Choose a server by consistent results, not just the lowest latency
Three consecutive tests of the same server tell you more than a single best result. For example, real-connection results of 220, 235, and 228 ms generally make a better first-connection candidate than 90 ms, a timeout, and 1,800 ms. These figures illustrate how to evaluate results; they aren't a promise of network quality. Evening congestion, changes in Wi-Fi signal, and server load can all affect performance.
Assigning roles to candidate servers: primary and backup
Primary server
- Succeeds in all three consecutive real-connection tests.
- Loads the content and static resources on commonly used websites.
- Shows little latency variation, with few interruptions to long-lived connections.
Backup server
- Preferably uses a different route from the primary server.
- Also passes the real-connection and browser tests.
- If the primary fails, set the backup as active and test it again.
Keep one reliable primary and one verified backup. There's no need to test every server in the subscription on your first connection.
VMess and VLESS are protocol names, not speed ratings. Don't change the subscribed port, TLS server name, transport path, or Flow just to lower latency; these settings must match the server. If only one server fails, test another for comparison first. That's usually more useful than guessing at configuration changes.
4. Enable the system proxy and check the local listening port
After setting the active server, choose “System Proxy” → “Set system proxy” from the main window or tray menu. Then open Windows “Settings” → “Network & internet” → “Proxy” and check the local proxy address set by the client. Check the result here; don't manually enter a second set of proxy values.
For the local port, check “Local mixed listening port” under “Settings” → “Parameter settings.” Recent configurations commonly use 10808. Older versions may provide separate SOCKS and HTTP ports; 10809 is a common HTTP port. Retained settings after an upgrade may differ, so don't overwrite existing values just to match a tutorial.
Check the client listener
- Settings path
- Settings → Parameter settings
- Address range
- Loopback address: 127.0.0.1
- Example mixed port
- 10808; use the value shown in the app
- Active server
- A candidate server that passed the real-connection test
A mixed listener accepts both HTTP and SOCKS requests. Check each port separately if they are configured individually.
Check the system proxy
- Client action
- System Proxy → Set system proxy
- Where to check in Windows
- Windows Settings → Network & internet → Proxy
- Server address
- 127.0.0.1
- Port requirement
- Must match the actual HTTP or mixed listening port
The system proxy doesn't route traffic for every device or app; it affects apps that follow this setting.
5. Test in a browser: compare the website, exit IP, and logs
Opening a website in mainland China doesn't prove the proxy is working; routing rules may connect to that domain directly. Choose a destination that you expect to go through the proxy, then check whether the request appears in the client and which outbound route the logs show.
- Start a fresh request. After confirming the active server, close any existing test tabs and open the destination website in a new browser window. If needed, fully quit and reopen the browser to reduce the impact of reused connections. A private window can reduce cache interference, but it won't change proxy settings.
- Check how the browser gets its proxy settings. For the first test, use a browser that follows the Windows system proxy. If a proxy extension is installed, pause it. If the browser has its own manual proxy settings, switch it to use the system proxy so they don't override the client's configuration.
- Check your exit IP. Use a trusted public IP lookup site to note your exit IP, then compare it with the result after clearing the system proxy. Also check the route used for the lookup domain. If that site connects directly, seeing your local exit IP doesn't mean the client as a whole has failed.
- Compare the logs. Check the log or information panel in the v2rayN main window, reload the destination website, and look for a domain, connection entry, and outbound route at the same time. Log fields vary by core. An entry showing proxy outbound traffic is stronger evidence than the active-server indicator alone.
- Run a comparison test. With TUN off and no other proxy tool taking over, choose “System Proxy” → “Clear system proxy.” Start a fresh request, then restore “Set system proxy” and test again. If the destination is always directly reachable, whether the page opens isn't enough to tell; also check the exit IP and logs.
A browser exit-IP check only shows the route for that request; it doesn't prove that every app uses the proxy. Some apps ignore the Windows system proxy and need an HTTP or SOCKS address entered in their own settings. Others maintain separate long-lived connections and need to be restarted after a change. Verify the browser first, then handle other apps one at a time. Don't conflate different connection methods.
6. Common first-connection issues and how to troubleshoot them
Change one setting at a time and record the results before and after. Recommended order: server real-connection test, active server, local port, system proxy, browser-specific settings, then routing and DNS. This avoids changing routing while fixing a port and makes it easier to identify what resolved the issue.
Tcping shows a result. Why won't the website load?
Run “Test server real connection latency” on the same server. If it fails, check the logs for authentication, TLS, or connection-timeout errors. Sync your system clock under Windows “Settings” → “Time & language” → “Date & time,” then test again. A reachable port doesn't mean the proxy handshake succeeded.
The real-connection test succeeds, but the browser says the proxy server refused the connection. Why?
First, check that the proxy port in Windows matches the local listening port under “Settings” → “Parameter settings.” For example, if the client listens on 10808 but Windows still uses 10809, the browser may be connecting to a port with no service. Run “Set system proxy” again, then check the logs for a port conflict or a core startup failure.
Why is the IP address unchanged after switching servers?
First, make sure the new server is set as the active server, then start a fresh browser connection. The lookup domain may be routed directly, and different servers may share an exit IP, so an unchanged address doesn't by itself mean the switch failed. Also check the active-server indicator, the outbound route for the lookup domain, and requests to other destinations.
The subscription updated successfully. Does that mean the servers work?
No. A successful subscription update only means the client retrieved the server details; the subscription URL and the server are usually different destinations. After updating, run a real-connection test and check your account's data allowance, validity period, and server status. If an update fails, don't delete your only working server as a first step.
A successful first connection isn't defined by a status message; the evidence should line up: the correct active server, repeated success in real-connection tests, the system proxy pointing to the actual listening port, and browser requests reaching their intended destinations through the proxy. Note the verified server and port so you can compare against a known-working setup when issues arise. For more help, see the setup guide. To troubleshoot by symptom, visit Troubleshooting.