V2Ray First Connection Guide: Choose a Server, Test Real Connection Latency, and Check Your Exit IP

Check the subscription group and server source

First, distinguish the client, core, and subscription. v2rayN manages subscription groups, servers, and proxy settings; the core handles the actual connection. A subscription URL provides server configuration, not a client download. A successful subscription update only means the configuration was retrieved and parsed—it doesn't mean every server in it is reachable from your current network.

This guide follows the commonly used Chinese-language v2rayN interface. Menus and shortcuts can vary by version, so follow the full menu names shown in your client. For initial troubleshooting, turn off TUN to avoid having it and the system proxy handle traffic at the same time, which can make it unclear which route a request is taking.

1. Check the group

   Open Subscription Group → Subscription Group Settings from the top menu and verify the URL for the group you want to use. If you create a group with Add, give it a note that identifies its source. Don't enter a web address for a sign-in portal in the subscription URL field.

2. Update the subscription

   Return to the Subscription Group menu. If no proxy is available yet, start with Update All Subscriptions (without proxy). If the subscription server is only reachable through a proxy, first establish a working connection, then choose the corresponding update option that uses the proxy.

3. Narrow down candidates

   Switch to the group you just updated and pick two or three servers that the provider recommends for your connection or clearly identifies for your intended use. A region label is only a note: it doesn't confirm the actual exit location or guarantee speed.

4. Run the test

   Select the candidate rows, right-click, and choose Test server real connection latency. Wait for the tests to finish before comparing results. Don't update the subscription, run bulk latency tests, and switch the active server all at once.

5. Activate a server

   Right-click a candidate that passed the test and choose Set as active server. Confirm the active marker has changed, then check the logs for core startup errors. Selecting a row with the mouse alone may not change which server the current connection uses.

TCPing vs. real connection latency

TCPing checks whether a TCP connection can be established to the server's target port. It doesn't verify the subscription's user ID, TLS settings, or proxy protocol handshake, nor does it check whether a website can be opened through the proxy. TCPing can still show a result even if the port is reachable but protocol authentication fails.

A real connection latency test sends an actual test request through the server, so it's closer to real application traffic than TCPing. Results still depend on the test URL, DNS, timeout, server exit, and client implementation. A successful test means that request completed; it doesn't guarantee access to every site or tell you the available download bandwidth.

Open Settings → Parameter Settings and check the real connection test URL and timeout options available in your version. Don't keep changing the test target just to get a better-looking number. If every server fails, first check whether your device can resolve the relevant domains, whether its clock is correct, and whether the test URL is temporarily unavailable. Don't assume the entire subscription is invalid.

• A result is shown: This means the test returned a result. Verify with a browser and compare multiple runs using the same network and test target.
• Times out or fails: Check the logs to tell a connection timeout from a certificate or authentication error. Don't guess based on a single negative value.
• Results vary widely: Test again later and pause bandwidth-heavy tasks. Don't draw a conclusion based only on the lowest result from a single run.

Enable the system proxy and check the local port

After setting an active server, applications still need to send their requests to the client. On Windows, right-click the v2rayN tray icon and choose System Proxy → Automatically configure system proxy. Use a browser that follows the system proxy for your initial check. Some command-line tools, games, and apps with their own proxy settings won't use it automatically.

Check the local listening settings under Settings → Parameter Settings, then compare them with the manual proxy address under Windows Settings → Network & Internet → Proxy. The numbers below are examples for instruction, not defaults for every version. Use the values shown in your client.

Don't copy a server's remote port as the local proxy port. If the logs show address already in use or a bind error, another process may be using that listener. Close any duplicate client instances, then check the port. After changing it, reapply the system proxy so Windows doesn't keep pointing to the old port.

Check your exit IP and routing rules

Choose an IP lookup page and first check which routing rules are active. To verify proxy egress, temporarily switch the routing setting to global proxy for a comparison, then restore your usual rules. Global proxy here refers to routing behavior; it doesn't mean every application on your system will automatically use the proxy.

1. Record a direct-connection baseline. Keep TUN off, choose System Proxy → Clear system proxy, then refresh the lookup page and note your current public IP. If your browser has separate proxy settings, turn them off first to keep the test conditions consistent.
2. Test the proxy route. Restore Automatically configure system proxy, confirm the active server is the one that passed the test, then refresh the same lookup page and note the exit IP.
3. Check the request route. Use the active routing rules and available logs to determine whether the lookup domain went direct or through the proxy. Test again after switching servers. If the page cached its previous result, open a new session or cross-check with another lookup page.
4. Restore your usual rules. Undo the temporary global proxy setting, then visit the sites you actually need to use. Passing an IP lookup test doesn't mean your routing rules behave as expected for every destination.

IP geolocation databases can be out of date, and the same exit IP may show different cities on different services. A server note, the server's connection address, and the exit IP are three different things; they can differ when traffic passes through a relay or exit gateway. Judge the route by where requests actually go, not by the region in a server note.

To avoid differences in how browsers handle the system proxy, you can explicitly send a request through the local HTTP proxy. The command below works with curl.exe on Windows, provided you've confirmed that 10808 is an HTTP or mixed inbound port and that the current routing rules send the request through the proxy.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

This command only checks whether a request to the example site through the local proxy returns HTTP response headers; it doesn't show your exit IP. Using http:// for the proxy connection doesn't turn HTTPS traffic to the destination into plaintext. HTTPS requests typically establish a tunnel with HTTP CONNECT. Check your exit IP separately after receiving a response; if the request times out, use the logs to find where it failed.

Troubleshoot by where the first connection fails

Keep track of the current server, test time, and exact error message, and change one thing at a time. Don't switch servers, change DNS and the local port, and enable TUN all at once. Even if access returns, you won't know which change helped. Before sharing screenshots or logs, remove subscription URLs, user IDs, and other credentials.

Save your first-connection test results

After your first connection, a reproducible record of what you checked is more useful than remembering one low latency result. Networks, subscription contents, and server exits can change. Using the same steps next time makes it easier to tell whether the issue is with the subscription update, core connection, application routing, or proxy rules.

• Check the configuration: Record the client version, subscription group name, active server note, and test time. Don't save subscription credentials in a public document.
• Check the route: Run at least one real connection latency test and open an HTTPS site. TCPing alone isn't a complete connection check.
• Check the exit: Record the lookup target, active routing rules, and exit IP so you don't compare results from different routing setups later.
• Restore your settings: Restore your usual routing rules and make sure the system proxy is in the expected state after closing the client. Remove any setting that points to an inactive port.

To review subscription imports and proxy settings, see subscription group setup, real connection latency tests, and system proxy settings. If you need to route traffic from apps that don't follow the system proxy, read the TUN setup guide. Don't use a more complex routing mode to mask an unresolved basic connection problem.