v2rayN First Connection Guide: Choose a Server, Test Latency, and Verify Your Proxy

1. After importing a subscription, check your servers and core status

A populated server list only means the subscription was parsed. It doesn’t mean the core is running or that your browser is using the proxy. The subscription provides server addresses, ports, protocols, and authentication parameters. v2rayN manages these settings and starts the core that handles connections. Keep these roles separate to make troubleshooting easier.

For your first test, leave TUN off and don’t run another proxy or tunneling tool at the same time. Keep the route simple: local proxy → system proxy → browser. Menus may vary across desktop builds; this guide uses common Chinese menu labels. If you see an equivalent option such as “Test server real connection latency,” choose it based on its function.

1. Check the subscription group

   Switch to the newly imported subscription group in the main window. To refresh it, choose “Update current subscription (without proxy)” from “Subscription groups.” If you already have a working proxy and a direct update fails, use the corresponding option to update through the proxy. Don’t add the same group repeatedly.

2. Check the configuration

   Right-click a server and select “Edit server” to check that its address, port, protocol, and transport settings are complete. Authentication fields for protocols such as VMess and VLESS aren’t interchangeable. Leave subscription-provided TLS, SNI, transport paths, and REALITY parameters as they are; don’t fill them in based on guesswork.

3. Check that the core starts

   Check the main window log for repeated startup failures, configuration parsing errors, or port conflicts. Fix any errors first. Don’t keep switching the system proxy to mask a core that isn’t running.

4. Record a baseline

   Note the current server name, routing mode, and local listening port. Turn TUN off for now and keep the same network conditions. Change only one setting per test so you can tell what made a difference.

2. What TCPing and real connection tests can tell you

A TCPing result doesn’t prove a server can proxy web traffic. It mainly checks whether a TCP connection can be made to the server address and port. It doesn’t fully verify proxy authentication or access to the destination site. A port may accept connections even when credentials have expired, TLS settings don’t match, or the remote exit is unavailable.

Select a candidate in the server list, right-click it, and choose “Test server real connection latency.” The client usually creates a temporary test connection; you don’t need to enable the browser’s system proxy first. The test also doesn’t make the selected server your active server. Set that separately when the test is done.

Real connection test results depend on the test URL. Look under “Settings” → “Parameter settings” for an option related to the real connection test or latency test URL, and note the current URL. The setting may be in a different place in other builds. If the test endpoint is unavailable, multiple healthy servers may time out at once. Don’t switch to a URL that only returns locally cached content just to get a result.

3. Choosing a server: start with availability, then check stability

Test a small number of candidate servers from the same subscription rather than testing the entire list concurrently, which can strain both your network and the server side. Repeat the real connection test for servers that pass and check whether they remain reliable, then visit the sites you need. Latency is useful for comparing response times on your current network, but it isn’t download speed.

Once you’ve chosen a candidate, right-click it and select “Set as active server.” Check that the active marker or status bar changes. A single click may only select a row without switching the server in use. After switching, check the log for reload errors before continuing.

4. Make sure the system proxy points to the right local port

In v2rayN on Windows, select “System proxy” → “Automatically configure system proxy” from the main window or the tray icon’s right-click menu. Then open Windows “Settings” → “Network & Internet” → “Proxy” and check the local address and port. For the first test, select “Global” or the corresponding global proxy rule in the “Routing” selector. Once verified, restore your usual routing rules.

The system proxy and routing are separate settings. The system proxy determines whether apps that follow Windows proxy settings send requests to the local proxy. Routing determines which outbound connection the core uses for those requests. Choosing global routing doesn’t automatically send every app through the proxy, and it won’t override an app’s own direct connection rules.

10808 is the example port used below, not a guaranteed default for every version. Check the local listener settings under “Settings” → “Parameter settings” and compare them with the startup log. Some configurations use a mixed listener for both HTTP and SOCKS; others use separate listeners. Windows system proxy settings must point to an HTTP-capable listener, not a SOCKS-only port.

5. Verify the browser, logs, and outbound connection together

Start with a browser window that has no separate proxy extension, then reload a page that needs to fetch content from the internet. Incognito mode can reduce interference from some cached data and extensions, but it doesn’t bypass all caching. For a stricter test, open the developer tools Network panel, enable “Disable cache,” and reload. Seeing a page title alone doesn’t prove that all its requests succeeded.

1. Check page requests: See whether the main document, scripts, and images finish loading. If only some resources fail, different domains may be matching different rules; don’t immediately assume the entire server is down.
2. Check the access log: In v2rayN, review the core access log for the same time and check the destination domain or IP and the outbound connection used. If the current log level doesn’t show access records, enable the relevant logging temporarily and turn it off again after testing to avoid keeping unnecessary data.
3. Confirm the outbound connection: A request in the log only shows that traffic reached the core. Check whether it matched a proxy outbound or a direct outbound. Outbound tags can be customized, so compare them with your current routing configuration.
4. Restore routing rules and test again: After confirming the global proxy works, switch back to your usual routing rules and check the destination domain again. If global routing works but your usual rules don’t, check rule order and DNS before importing the same subscription again.

You can also specify an HTTP proxy explicitly in Windows Terminal to test the local listener on its own. The command below requests the headers from this site; replace the example port with your actual HTTP or mixed-proxy port. Use curl.exe to call the executable directly and avoid ambiguity with commands of the same name in some terminal environments.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://v2ray-club.com/

Receiving response headers means the command completed a request using its actual network and proxy settings; it doesn’t verify the browser’s system proxy. If the NO_PROXY environment variable includes the destination domain, rule out that bypass first. Even when the command succeeds, check the core log to make sure the request didn’t use a direct outbound. An HTTP error status doesn’t necessarily mean the tunnel failed: distinguish a proxy connection error from a status returned by the destination site.

6. Troubleshoot common first-connection problems by where they occur

You can define clear first-connection checks: confirm the active server, get consistent results from repeated real connection tests, match the local listening port to the system proxy, and verify that new browser requests reach the core and use a proxy outbound when required. Keep this baseline so you can tell whether later DNS, routing, or TUN changes caused a problem.

• When sharing an error, keep the timestamp, error type, and port. Remove subscription URLs, user IDs, and other authentication details first.
• To continue configuring, start with the subscription and connection guide; for routing rules and outbound connections, see the configuration reference.
• If you still can’t connect, follow the connection troubleshooting guide and check each layer in turn. Don’t change the server, DNS, routing, and proxy listener all at once.