For users who have opened v2rayN but aren't sure whether the connection is working. This Windows walkthrough covers subscription checks, testing candidate servers, setting an active server, and verifying the connection in a browser. It distinguishes server reachability, local proxy forwarding, and whether an app actually uses the proxy—so one latency reading doesn't tell the whole story.
Before connecting: Check your subscription and local port
v2rayN provides the client interface; the selected core handles the actual connection. A subscription supplies server configurations, but importing one doesn't establish a proxy connection. After a successful import, the server list should show details such as addresses, ports, and protocols. If you see only a group name with no server entries, troubleshoot the subscription update first.
Menu locations may vary slightly between desktop interfaces and versions. Look for options such as “Subscription Groups,” “Settings,” and “System Proxy.” Close other apps that might change system proxy settings. For your first test, leave TUN disabled to avoid adding variables such as virtual adapters, routing, and permissions.
-
Check the subscription
Open “Subscription Groups” → “Subscription Group Settings” and make sure the group URL is saved in full. Then go to “Subscription Groups” and select “Update All Subscriptions (without proxy).” If direct updates fail but you already have a working proxy, try updating through the proxy.
-
Check the server list
Switch to the subscription group you just updated and check that it contains server entries. If the list is empty, look in the logs for download, parsing, or authorization errors, and confirm that the subscription is still active.
-
Note the port
Go to “Settings” → “Parameter Settings” and note the HTTP or mixed inbound port under the local listener settings. The commands below use
10808as an example; substitute your actual port if it's different. Don't use the remote server's port. -
Check the logs
Show the log panel in the main window and make sure the core doesn't keep exiting, fail to listen, or report that a port is already in use. Being able to use the interface doesn't mean the core is running properly.
Real-connection latency: Find working servers first
TCP latency mainly shows whether a TCP connection can be made to the server's specified port. A real-connection latency test typically sends a request to a test URL through the server configuration, exercising more of the proxy handshake and request process. So a TCP latency reading alongside a failed real-connection test isn't a contradiction: the port may be reachable while authentication, transport, the security layer, or the target request still fails.
Hold Ctrl and select a few candidate servers in the list, then right-click and choose “Test server real-connection latency.” Start with three to five; there's no need to test the entire subscription at once. Results depend on your local network, the test URL, and server load. Don't treat one test as a reliability ranking.
These figures are examples, not measurements from this site. If Server A returns 180 ms and 210 ms over two rounds, while Server B returns 95 ms and then times out, Server A is the better choice for an initial connection check. One low reading doesn't offset repeated failures or predict download speed.
| Test results | What they tell you | Next step |
|---|---|---|
| TCP and real-connection tests both pass | The port and proxy request are working under the current test conditions | Set it as the active server, then test in a browser |
| TCP succeeds, but the real-connection test times out | An open port alone doesn't mean the server is usable | Check the subscription and logs, then compare with another candidate |
| Real-connection tests fail for every server | A shared issue with your local setup or the test target may be responsible | Check the network, system clock, core, and test URL |
| Real-connection test passes, but the site doesn't load | The test only confirms that its own target is reachable | Check the target site, routing rules, and app proxy settings |
Choose a server: Set the active server and system proxy
Once a test passes, right-click the server and select “Set as active server,” then check the active indicator and logs. Don't rely on a row being highlighted: selecting a row and setting the active server are two different things. Wait for the core to reload its configuration before sending a new request.
Next, open “System Proxy” → “Automatically configure system proxy” from the bottom of the main window or the tray context menu. This directs apps that follow system proxy settings to the local listener; it doesn't route all device traffic. Routing mode controls how requests are handled once they reach the core, so check both settings separately.
Local proxy endpoint
- Listen address
127.0.0.1- Example port
10808- Port type
- HTTP or a mixed listener that supports HTTP
- App proxy setting
- System proxy or manually configured app proxy
Use the port shown in Parameter Settings. A SOCKS-only port won't work with the HTTP proxy commands in this guide.
Recommended settings for the first test
- Active server
- A candidate server that passed the real-connection test
- System proxy
- Automatically configure system proxy
- TUN status
- Temporarily off
- Routing check
- Confirm the test target uses the proxy exit
If you temporarily use global proxy routing to troubleshoot, restore your usual routing rules afterward.
In Windows, check the system proxy status under “Settings” → “Network & Internet” → “Proxy.” The manual proxy address should match your local listener, for example 127.0.0.1:10808. If the setting changes back immediately, check for other proxy apps, browser extensions, or organizational policies instead of repeatedly switching servers.
Verify the proxy: Cross-check with commands, your browser, and logs
Verification takes two steps: first confirm that the local endpoint accepts requests, then check that your browser uses it. Explicitly specifying the proxy in a command-line request avoids uncertainty about whether an app reads system proxy settings. However, that alone doesn't prove the browser uses the system proxy or that the core routes the request through the remote server.
Step 1: Send a request through the local proxy
Run the command below in Windows Terminal. It uses curl.exe to avoid PowerShell environments that interpret curl as a different command. The test uses a public example domain; being able to reach it doesn't mean every site will work.
curl.exe --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com--proxypoints to the local HTTP proxy endpoint. The port must match the client settings.--noproxylimits proxy bypasses to local addresses, preventing broad bypass settings in your environment from skipping this remote test.--connect-timeout 10limits the connection phase to 10 seconds;--max-time 20limits the entire request to 20 seconds.-Irequests response headers. If the target doesn't support HEAD requests, remove it to send a regular request, then check the logs.
Seeing only 200 Connection established doesn't mean the target page loaded successfully; it may only indicate that the local proxy accepted the HTTPS tunnel request. Check the final response from the target or any subsequent errors. If the command can't connect to 127.0.0.1, check the core and local port before blaming the remote connection.
Step 2: Verify the browser's proxy path and exit
- Use a browser that follows system proxy settings and temporarily disable extensions that override them. Open a fresh test page rather than relying on a tab that was already loaded.
- Note the request time and look for the matching domain or connection in the v2rayN logs. If you need to inspect request records, temporarily enable access logging in the log settings supported by your version.
- Check that the log entry points to the expected proxy outbound, not a direct connection. A domain appearing in the log alone doesn't prove the request went through a remote server.
- Use the same trusted public IP lookup page to compare your exit address with and without the proxy. The lookup request must also match a proxy routing rule. A different address is supporting evidence, not a substitute for checking routing.
Common first-connection issues
Latency shows a number, but why won't the page load?
First check whether you're seeing TCP latency or real-connection latency. Then check the active server and “System Proxy” → “Automatically configure system proxy.” Compare with the explicit proxy command above: if it works but the browser doesn't, check the browser's proxy settings, extensions, and existing connections first.
Every server times out. Should I import the subscription again?
First check that the core starts properly and that the system date and time are correct. Then check whether the subscription has expired. If multiple servers fail to reach the same test URL, check the test URL settings available in your version under “Settings” → “Parameter Settings.” Retry with an HTTPS address you know is working; don't bypass the error by disabling certificate verification.
The exit address doesn't change after switching servers. What now?
Send a fresh request and check the active-server indicator. Multiple servers may share an exit address, and your browser may reuse an existing connection. Close the test tab and reopen the page; restart the browser if needed, then check the outbound logs. Don't rely on the exit address alone.
The logs say the port is already in use. What should I change?
Go to “Settings” → “Parameter Settings,” change the local listener to a port you've confirmed is free, save, and restart the core. For example, if you switch to 10818, update the system proxy and change the port in any manually configured apps and test commands. Don't terminate unfamiliar system processes.
Is it normal for downloads to be slow when real-connection latency is low?
Real-connection latency measures the response to one short request; it isn't a bandwidth test. Compare two verified working servers using the same target file, network, and time window. Download speeds also depend on server load, network congestion, and limits imposed by the target site. Millisecond readings can't be converted directly into download speeds.
After testing: Keep the connection state easy to reproduce
After your first successful connection, record only the details that will help you troubleshoot later: subscription group name, active server label, local port, system proxy status, routing mode, and test time. Never store subscription tokens, passwords, or full server credentials in public documents.
- Working server: Passes at least two rounds of real-connection tests and reaches the sites you need.
- Local endpoint: An explicit proxy request succeeds, and the listening port matches the app settings.
- Browser traffic: The browser uses the system proxy, and the logs show the expected outbound connection.
- Restore settings: Restore your usual routing rules and turn off temporary verbose logging. When you're done using the proxy, select “System Proxy” → “Clear System Proxy.”
Now “subscription imported,” “server test passed,” and “proxy working for this app” each have their own evidence. If a problem comes up later, start with the layer that failed. This makes it easier to preserve useful clues than repeatedly updating the subscription or changing several settings at once.