First V2Ray Connection: Test Nodes, Choose a Server, and Verify Your Proxy

1. Before connecting: check your subscription, time, and network

This guide focuses on v2rayNG on Android, which uses the Xray core. v2flyNG uses the v2fly core, so its menus and protocol support may differ. On desktop, you can also verify v2rayN in three stages: port reachability, the proxy connection, and the app's outgoing traffic. However, system proxy settings work differently from Android's VPN-based traffic routing.

First, make sure regular websites open directly on your current network. If hotel or public Wi-Fi requires a captive portal, sign in first. A successful subscription import only means the configuration was retrieved; it doesn't mean the account is still active or that every node is reachable. Menu names below refer to common Chinese-language interfaces and may vary slightly by release. Follow the function, not the exact wording.

1. Update subscription

   On the v2rayNG home screen, tap ⋮ in the upper-right corner and select “Update subscription.” If you haven't saved the subscription URL yet, add it under “Subscription group settings,” then update. Make sure the server list appears and that no expiration or request failure message is shown.

2. Set the correct time

   On Android, go to “Settings” → “System” → “Date & time” and turn on automatic time. On some devices, this option is under “Additional settings.” An incorrect system clock can interfere with TLS certificate validation and some protocol authentication.

3. Avoid conflicts

   Disconnect other apps using Android's VPN service, including filtering tools that run as a local VPN. With typical personal configurations, only one app at a time can take over the Android VPN connection for a user.

4. Keep conditions consistent

   For the first round, use your current Wi-Fi, pause large downloads, and don't switch to mobile data mid-test. Note the node label, test time, and network type so you can compare results under the same conditions later.

2. TCPing vs. real connection tests

TCPing typically tries to establish a TCP connection to the node's address and port. It's useful for a quick check that the endpoint is reachable. If the server uses port 443, a successful TCPing only confirms that the TCP handshake received a response; it doesn't verify TLS, VMess, or VLESS authentication settings. The port may be different—use the value in your subscription and don't change it to 443 just for testing.

A real connection test is closer to making an actual request through the selected configuration, but it still isn't a large-file download test. A node may complete the handshake quickly yet lack bandwidth for sustained transfers. Or a test URL may respond slowly once while commonly used sites work fine. Don't rank millisecond results from different test methods side by side.

• TCPing succeeds, but the real connection test fails: First check subscription validity, protocol and TLS settings, then see whether the test destination is reachable.
• TCPing fails, but the real connection test succeeds: Give actual proxy requests more weight, taking the transport type and test implementation into account. Don't discard a node based only on a failed TCPing test.
• Both tests fail: Try another node, then another network. This helps distinguish a single-node issue from a client problem.

3. Test nodes under consistent conditions

On the v2rayNG home screen, tap ⋮ and select “Test all configurations (TCPing),” then “Test all configurations (real connection).” Some versions put these options in a test submenu. If the list is long, select the subscription group you need first to reduce interference from simultaneous requests. Avoid switching nodes or updating the subscription while tests are running.

Keep a few candidates that pass the real connection test, then test them again. The numbers below are suggested testing steps, not measured results from this site or a guarantee of connection quality.

• Check the success rate first: A node that succeeds repeatedly is a better first choice than one with an occasional low latency but frequent timeouts.
• Then check consistency: Compare results on the same network using the same test URL. If results vary widely, pause other network activity and test again.
• Finally, check real-world use: Open your usual websites and check the initial load, images, and links. For sustained transfers, use a controlled file test instead of relying on latency alone.
• Keep a backup: Choose one verified working node as a backup. A location label doesn't confirm the actual exit location or predict how well a node will work.

4. Connect: VPN permission and app coverage

Select a candidate node to make it the active configuration, then tap the start button on the main screen. The first time you connect, Android asks for VPN permission. Approve it, then check the client's status and the system VPN indicator. The indicator confirms that the system VPN connection is active, not that the remote proxy is working. A real connection test may also run independently, so it doesn't replace this step.

If the connection stops right after starting, open “Logs” under ⋮ and check for errors during startup. A parsing error, unsupported configuration, and failed remote handshake are different issues; don't lump them together as “a slow node.” If the interface asks you to restart the service after changing routing or per-app settings, stop and restart it to apply the changes.

5. Browser and public IP: verify that the proxy is working

A page loading doesn't necessarily mean it's using the proxy; the site may allow direct connections. Conversely, a site failing to load doesn't necessarily mean the node is down. The destination may block data center IPs, show an access check, or be temporarily unavailable. A reliable check combines actual browsing, the public IP address, and your current routing rules.

1. Check your direct connection's public IP

   Stop v2rayNG first. In your browser, search for “IP address lookup” and open a page that displays your public IP. Note whether it shows an IPv4 or IPv6 address and the carrier information. Don't mistake a local network address for your public IP.

2. Connect to a candidate node

   Return to v2rayNG and check the selected node and connection status. Use the simplified verification setup from the previous section so requests from your test browser and IP lookup page go through the proxy.

3. Look up your public IP again

   Open the same lookup service in a new tab, then cross-check with a second service. Compare results for the same address type; don't compare a direct IPv6 address with a proxy IPv4 address to decide whether they match.

4. Check actual browsing

   Open a site you want to access through the proxy and check its text, images, and internal links. If your public IP has changed but only one site fails, investigate restrictions on that site instead of immediately reinstalling the client.

5. Restore your usual routing

   After restoring your usual routing rules, test the destination again. Your IP lookup site may now use a direct connection and show your local public IP; that's expected if your rules send it direct. If needed, use the connection details in the logs to see which route the destination domain takes.

6. Common issues: choose the next step based on what you see

When troubleshooting for the first time, don't change the port, DNS, transport settings, and routing all at once. VMess, VLESS, TLS, REALITY, and WebSocket settings in your subscription must match the server. Changing one at random can create a new problem. Update the original subscription first, then follow the steps for the symptom—this is usually more effective than repeatedly deleting configurations.