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

At a glance

Seeing servers in your subscription list doesn’t mean your proxy is working. This guide walks desktop users through a first-time check after importing a subscription: test a server’s connectivity, set it as active, enable the system proxy, then check your exit IP and logs. The steps focus on v2rayN for Windows and distinguish three separate requirements: a reachable server, an app using the proxy, and a route that sends traffic through it.

1. Check Local Ports and Testing Scope

v2rayN provides the client interface; the running proxy core handles the connection. A subscription supplies server addresses, protocols, and authentication settings. The system proxy tells some apps to send requests to a local listener, while routing rules determine whether requests connect directly or go through a remote server. A problem at any layer can leave you with a selected server but no working web access.

For initial troubleshooting, turn off TUN mode and quit other apps that change the system proxy. This lets you test the system-proxy path on its own, without a virtual network adapter taking over traffic and masking port or browser configuration issues. The values below are explicit test parameters—not test results or defaults for every installation.

127.0.0.1

Loopback address

10808

Example local proxy port

15 seconds

Maximum timeout for a single command-line request

Go to Settings → Parameters and check the local listening ports under inbound settings. Compare them with the HTTP, SOCKS, or mixed listener shown at the bottom of the main window. Setting group names may vary by version, so use the listener type shown in your build. If HTTP and SOCKS use different ports, enter the correct port in each command below rather than copying one number everywhere.

2. Test Server Connectivity and Set an Active Server

A real-connectivity latency test typically sends a request to a test URL through the selected server, making it a better indicator of actual use than a basic TCP port check. It still only confirms that the route from that server to that test URL works—it doesn’t guarantee that every site or protocol will work, or that downloads will remain stable. Avoid changing DNS, routing, and transport settings at the same time, or you won’t know which change made a difference.

Check the server list

Open the subscription group you just imported in the main window and check that each server has a name, address, and protocol. Don’t treat entries that only show traffic details or an expiration notice as connectable servers.
Run a batch test

Select a few candidate servers, right-click to open the test menu, and choose “Test server real connection latency.” Some versions label the menu item as supporting multiple selections. Choose the option that explicitly tests a real connection, not just TCP latency.
Retest candidates

Review the real-connection latency results and keep servers that return a successful response. Test promising candidates twice more to check for repeated timeouts; don’t judge long-term reliability by a single low result.
Set as active

Right-click a server and select “Set as active server,” then confirm the current server shown in the main window. Testing a server doesn’t automatically make it the one in use.
Check that the core is running

Check the log at the bottom of the window to make sure the core hasn’t exited. If you see a port-in-use error, a configuration parsing failure, or an unsupported protocol field, fix the startup issue before testing in a browser.

3. Configure the System Proxy and Global Routing Separately

In v2rayN for Windows, open System Proxy from the bottom of the main window or the tray context menu, then select “Automatically configure system proxy.” In Windows, go to Settings → Network & Internet → Proxy and check that the manual proxy address and port point to v2rayN’s local HTTP listener. Don’t enter the remote server address here: the system proxy connects to a listener on your own computer.

The system proxy and routing are separate settings. The system proxy determines whether an app sends requests to the local proxy; routing determines how the core forwards requests it receives. For a first-time check, temporarily use the Global routing preset to rule out direct-connection rules. Switch back to your usual routing rules once testing is complete.

System proxy + temporary global routing

Recommended

Enable automatic configuration under System Proxy, then choose the global proxy preset under Routing. Setting both makes it easier to confirm whether browser requests are going through the active server.

Best for: first-connection checks and ruling out routing-rule interference.

System proxy + split routing

Apps still connect to the local listener, but the core uses domain, address, and other rules to decide whether to connect directly or use the proxy. Routing rules may also send IP-check sites directly.

Best for: everyday use after verifying the connection.

Active server only

The core has a working remote exit, but apps that aren’t configured to use the proxy will usually keep using their existing network path. A server name in the status bar alone doesn’t prove that your browser is using it.

Best for: apps with manually configured proxies or standalone command-line tests.

“Global” refers to the core’s routing scope; it doesn’t mean all computer traffic automatically goes through the proxy. Apps that ignore the system proxy, browser extensions with their own proxy settings, and some UDP requests need separate checks. The browser steps here focus on HTTP and HTTPS requests that follow the system proxy.

4. Verify in a Browser: Compare Exit IPs and Check the Logs

Choose a trusted IP-check service and use the same one for both checks. For example, enter https://api.ipify.org in your browser’s address bar to see the public IP used for that request. These services can see your exit IP; don’t send third parties screenshots that include subscription URLs or authentication details.

Record a direct-connection baseline: Temporarily clear the system proxy, keep TUN off, and make sure no other proxy is intercepting traffic. Refresh the page and note the IP address returned.
Record the proxy result: Restore “Automatically configure system proxy,” keep the same active server, temporarily switch to global routing, and reload the same URL.
Check where the request went: If your current log level includes access records, find the request for the target domain and confirm it used a proxy outbound rather than a direct connection. Outbound labels vary by core, so check them against your configuration.
Check for browser overrides: Review proxy-management extensions and the browser’s own proxy settings. A private window can reduce cache interference, but it doesn’t necessarily disable extensions or proxy settings.

Different exit IPs are strong evidence that the two requests used different exits. If the IPs match, check routing rules and whether the app is using the proxy before drawing conclusions; it doesn’t automatically mean the server is down. Also check whether one request used IPv4 and the other IPv6—results across address families aren’t directly comparable. The browser may also show a cached result, so force a refresh if needed.

5. Verify from the Command Line: Compare Explicit Proxy and Direct Requests

Command-line tools don’t necessarily use the Windows system proxy. Specify the proxy address explicitly to bypass the question of whether an app reads system settings and test the connection from the local listener to the remote exit directly. In Windows PowerShell, use curl.exe to avoid differences caused by the curl alias in older environments.

HTTP proxy listener

Proxy address: 127.0.0.1
Example port: 10808
Command option: --proxy http://127.0.0.1:10808
Requirement: The port must support HTTP proxy or a mixed inbound listener

HTTPS destinations use HTTP CONNECT to create a tunnel; using http for the local listener doesn’t disable TLS to the destination.

SOCKS proxy listener

Proxy address: 127.0.0.1
Example port: 10808
Command option: --proxy socks5h://127.0.0.1:10808
Requirement: The port must support SOCKS or a mixed inbound listener

socks5h sends the destination hostname to the proxy for resolution, rather than having curl resolve it on your computer first.

Once you’ve confirmed the ports, run each command below. The first explicitly bypasses proxies and ignores proxy environment variables; the next two test the HTTP and SOCKS listeners. If your local listener isn’t a mixed inbound, replace the port in the relevant command with the actual one. These commands don’t include real test results; use the IP address and elapsed time shown by your own output.

# Direct-connection baseline: run with TUN and other transparent proxies disabled
curl.exe -4 --noproxy "*" --connect-timeout 5 --max-time 15 https://api.ipify.org

# HTTP proxy: clear the NO_PROXY bypass list and force use of the specified listener
curl.exe -4 --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://api.ipify.org

# SOCKS proxy: send the destination hostname to the proxy for resolution
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://api.ipify.org

The first two commands use -4 to reduce address-family differences between the direct connection and the local connection. With remote DNS resolution over SOCKS, the destination address family still depends on resolution and routing at the proxy. If the results show different address families, check the logs rather than comparing the IP strings alone.

Result	Check first	Next step
Connection to the local port is refused	The core isn’t running, or the port is incorrect	Check the listener shown in the status bar and look for a listener startup error in the logs.
Local listener connects, but the request times out	Remote connection, destination reachability, or DNS	Try another server that passed the real-connection test, keeping all other settings unchanged.
Command succeeds, browser fails	System proxy or browser override settings	Reapply automatic system proxy configuration and temporarily disable proxy-management extensions.
Proxy and direct requests show the same exit IP	The core routed the request directly	Temporarily switch to global proxy routing and check the outbound records.

6. Common First-Connection Questions

The real-connection test succeeds. Why can’t I open websites?

The test uses a specific URL. Your browser may not be using the local proxy, or the destination site may have a separate connectivity issue. First confirm that the server is set as active, then check System Proxy → Automatically configure system proxy. Finally, use an explicit-proxy command to request the same destination and narrow down the issue one layer at a time.

Is the server with the lowest latency always the fastest?

No. Real-connection latency measures how long the test request takes, not download bandwidth. Choose a server that passes repeated tests, then try the sites you actually need at the same time of day. Batch download tests consume subscription traffic and aren’t necessary every time you start the client.

How do I fix “address already in use” in the logs?

Usually, another process is using the local listening port. First check whether the client is running more than once. If you need to change the port, go to Settings → Parameters and edit the inbound port. Save, restart the relevant service, reconfigure the system proxy, and update the port in your command-line tests.

After switching to a VLESS server, do I need to re-enter protocol settings?

A complete subscription usually already includes the fields required by the server. Don’t change transport, TLS, REALITY, or flow parameters without a reason. If you see an unsupported-field error, first check whether the current core supports that combination, then confirm the settings with your subscription provider. Changing fields won’t fix a mismatch on the server side.

How do I restore web access after closing the client?

Restart v2rayN and select “Clear system proxy” from the System Proxy menu. If you can’t start the client, go to Windows Settings → Network & Internet → Proxy, turn off any leftover manual proxy, then check whether another proxy app is still intercepting network traffic.

7. Restore Your Usual Routing After Testing

A successful first-connection check means more than seeing a server name in the status bar. The local listener must accept connections, an explicit-proxy request must succeed, the browser must be configured to use the proxy, and the destination request must use the expected outbound. Keeping track of these checks makes future troubleshooting more useful than repeatedly running latency tests.

Keep a retested active server and note which subscription group it belongs to, so you don’t accidentally select an informational entry after an update.
Switch from temporary global routing back to your usual split-routing rules, then check your regular sites. Some sites returning to a direct connection is expected under those rules.
Keep a record of the actual HTTP and SOCKS ports, and don’t confuse remote server ports with local listening ports.
When asking for help, include the client version, core type, time of the issue, and a redacted error message. Hide subscription URLs, authentication IDs, and connection credentials.