A successful subscription import only means the configuration has been added to v2rayNG. A node appearing in the list does not mean the route is currently usable. Your first connection should be split into four actions: check the configuration, filter the nodes, start the proxy, and verify the exit route. Each step has its own evidence.
This guide uses the commonly seen Chinese interface of v2rayNG 1.10.x as an example. Menu labels may vary slightly between minor releases, but the core checks remain the same. The steps assume that VMess, VLESS, or other nodes have already been imported. If the list is still empty, add and update the subscription first.
This guide is for new users who can already see a node list but are unsure which node to choose. First use real connection tests to identify candidates, then start v2rayNG, and finally verify the proxy with the exit IP, web access, and a network-switch retest. This also helps rule out cases where the icon is on but traffic is not passing through the node.
Check the node and core before connecting
Whether a node works first depends on whether the client understands its protocol fields. A VMess node usually includes a server address, port, user ID, transport, and TLS settings. A VLESS node may also include flow, a Reality public key, shortId, serverName, and other parameters. Missing key fields or errors during subscription conversion can all appear as timeouts.
Open the target node’s edit page. Check the protocol type first, then verify the address and port. The address should be a complete domain name or a valid IP address; the port must be between 1 and 65535. Common service ports include 443, 8443, and 2053, but a familiar-looking port does not prove that the configuration is correct. Use the node details as the source of truth.
Xray core
RecommendedProvides broad support for VLESS, Reality, XTLS Vision, and common VMess configurations. Prefer this option when the subscription contains newer fields.
Best for: daily use, VLESS Reality, and mixed-protocol subscriptions
v2fly core
Suitable for older configurations built around VMess, WebSocket, TLS, and other conventional combinations. When Xray-specific fields are present, do not mistake core incompatibility for an offline server.
Best for: traditional VMess configurations and compatibility testing
When Xray is the primary core, go to “Settings” → “Parameter settings” → “Core type” and confirm that Xray is selected. Return to the main screen and restart the connection so the new core is actually loaded. Changing the option without reconnecting may leave the current session using the old state.
- VMess: Check the user ID, alterId, transport, and TLS toggle. In modern configurations, alterId is usually 0.
- VLESS: Check the user ID, flow, encryption setting, transport layer, and security layer. VLESS does not use VMess’s alterId.
- Reality: Check serverName, publicKey, shortId, and fingerprint. These fields must match the server configuration.
- WebSocket: Check path and Host. Whether the path starts with a slash is also part of the configuration.
Filter working nodes with real connection tests
Start by distinguishing how the latency was measured. A regular ping mainly reflects ICMP round-trip time. Some servers restrict or ignore ICMP while still accepting connections on the proxy port. The TCP test in the v2rayNG list only confirms whether the target port can accept a connection; it does not complete the proxy protocol or make a full request to the destination.
A real connection test loads the node configuration, completes the protocol handshake, and sends an actual request through the proxy chain, making it a closer approximation of whether a web page will open. For VLESS Reality, VMess TLS, and WebSocket nodes, the result is more useful than a simple ping.
-
Update subscription
Open the menu in the upper-right corner and select “Update subscription.” Wait for the node list to finish refreshing so you do not keep testing configurations that have been removed or had their parameters changed.
-
Check the core
Go to “Settings” → “Parameter settings” → “Core type” and choose a core compatible with the node fields. VLESS Reality usually requires Xray.
-
Run a real connection test
From the main-screen menu, select “Test all configurations with real connections.” If there are many nodes, long-press the target node first and test 3 to 5 candidates individually.
-
Keep the candidates
Prefer nodes that return results twice in a row with limited variation. For example, 168 ms and 191 ms is generally more stable than 120 ms followed by 860 ms.
-
Retest after connecting
Select a candidate and start the connection, then open two different sites. If the speed test passes but browsing fails, continue by checking routing, DNS, and the scope of application proxying.
Do not simply pick the lowest value in the entire list. A one-off 95 ms result may be luck; a node measuring 182 ms, 176 ms, and 189 ms across three tests is often better for daily use than one showing 95 ms, 640 ms, and a timeout. For an initial filter, keep nodes under 300 ms that succeed repeatedly. Put nodes above 800 ms or those that fail multiple times aside for now.
A real connection result of 0, -1, a timeout, or a blank value usually means the test did not receive a valid response. It does not automatically mean the server is permanently unavailable. A network change, failed DNS resolution, incorrect system time, subscription field errors, or temporary congestion can produce the same result. Retest once on Wi-Fi and once on mobile data before deleting the node.
Start the connection and understand the system status
After selecting a node, tap the circular connection button in the lower-right corner of the main screen. The first time you start it, the system displays a network connection authorization dialog. Confirm it; a key-shaped status indicator usually appears in the status bar, and the v2rayNG main screen also shows a connected state.
These two indicators only prove that the local tunnel has started. They do not independently prove that the remote node is usable. The client may have created a local network interface while the remote handshake is still timing out. Or application-level proxying and routing rules may prevent the current browser traffic from entering the proxy.
Recommended approach: verify Wi-Fi and mobile data separately
Wi-Fi
- Close other proxy tools before connecting
- Record the exit IP before and after connecting
- Open two different domains in succession
- Check whether the connection drops automatically within 3 minutes
Mobile data
- Turn off Wi-Fi and restart the connection
- Run another real connection test
- Check whether both websites and apps work
- Lock the screen for 1 minute, then visit a web page again
Only when both networks can consistently show the expected exit IP change and load web pages can you consider the node, client configuration, and current routing combination basically sound.
If you only need apps on the current device to use v2rayNG, you generally do not need to enter 10808 or 10809 manually. System authorization mode takes over traffic covered by the rules. The local SOCKS and HTTP ports are mainly for apps that explicitly specify a proxy or for debugging the local listener.
- Select a node with a stable real connection test result so that its name is highlighted.
- Tap the connection button and confirm system authorization. Do not switch back to the main screen while the authorization dialog is open.
- Wait 3 to 5 seconds, then check whether live traffic shows upload and download values.
- Open a browser and visit a regular web page, then compare the exit IP.
- If it disconnects immediately, open the log page and check the first error or failed entry.
Verify access with the exit IP and web browsing
The most direct verification is a before-and-after comparison. Before connecting v2rayNG, search the browser for “current IP” and record the IP address, country or region, and network provider. After starting the proxy, refresh the same lookup page. If the exit IP and provider information change, the browser traffic is passing through the remote node.
Country or region alone is not precise enough. The same network may be mapped to different cities in different databases even when the address itself has not changed. Compare the full IP first, then the ASN or provider. For example, seeing a residential broadband provider before connecting and a data-center network afterward, together with a completely different IP address, is meaningful evidence.
before_ip
Exit before connecting
Turn off v2rayNG, then look it up and record it. This confirms the original exit route of the local network; do not rely on memory.
after_ip
Exit after connecting
Reload the lookup page after starting the connection. The address should differ from the pre-connection address and broadly match the selected node’s location.
web_access
Web access
Test at least two different domains to avoid mistaking a single-site outage, cached page, or temporary throttling for a proxy problem.
reconnect
Reconnect and retest
Disconnect, wait 5 seconds, and connect again. Completing the test twice in a row is more reliable than one accidental success.
A web page opening does not mean every app is using the proxy. If application-level proxying is enabled, check that the browser is on the allowlist. If routing rules bypass LAN and local-region traffic, some sites connecting directly is expected. In that case, use another test page that clearly requires the node and compare the exit IP again.
The failure pattern also provides clues. If the page immediately reports that the domain cannot be resolved, check DNS first. If it spins for a long time before timing out, check the remote node and transport parameters. If only one app cannot connect, check application-level proxying and that app’s background network permission. If every page opens but the IP stays the same, check whether the routing mode classified the test traffic as direct.
| Observed result | What this confirms | Next step |
|---|---|---|
| IP changed; both pages open | Proxy is basically working | Continue monitoring stability and speed |
| Shows connected, but the IP is unchanged | Traffic may be going direct | Check routing mode and application scope |
| IP changed, but pages frequently time out | The node can complete the handshake but is unstable | Switch to a candidate with less variation |
| All domains fail to resolve immediately | The DNS path may be failing | Restore the default DNS and reconnect |
How to check routing rules and local ports
Routing rules decide whether a request uses the proxy, connects directly, or is blocked. During first-time verification, more complex rules mean more variables to troubleshoot. Start with v2rayNG’s standard preset, confirm that the node works, and only then enable custom domain, IP, or application rules.
Global proxying is useful for short diagnostic sessions: most proxyable traffic is sent through the selected node, making it easier to determine whether the node itself works. Split routing is better for daily use: LAN, local-region traffic, or specified apps can connect directly while other traffic follows the rules into the proxy. This is a routing-policy difference, not a measure of protocol strength.
- Only the browser fails: Check the application proxy list and confirm that the browser has not been excluded.
- LAN devices are unreachable: Check whether private address ranges such as 192.168.0.0/16 were mistakenly sent through the proxy.
- Local-region sites are slower: Check whether global proxying is enabled and restore standard split routing if necessary.
- An app requires manual proxy settings: Confirm the local listening port first. The common SOCKS entry is 10808; use the local-port value shown under “Settings” → “Parameter settings” as the authority.
- The log reports a port conflict: Close the app using the same port, or change the local port to an unused value such as 10818. Save and reconnect.
A port conflict occurs locally on the device and is not the same concept as the remote port of a subscription node. Remote port 443 is where the server accepts connections; local port 10808 is the entry point on the device for apps connecting to the proxy core. Changing the local port will not fix an incorrect remote 443 configuration or change the server’s listening state.
Handle common first-connection problems in order
When a connection fails, do not jump repeatedly between dozens of nodes. First confirm that the device time is set to automatic synchronization, then update the subscription and run a real connection test. A large clock offset can affect TLS and Reality handshakes, often appearing simply as a connection timeout.
Read the log downward from the first failure. Common keywords include timeout, connection refused, failed to find an available destination, and DNS resolution errors. The remote address, port, and transport shown in the log should match the node edit page. If fields changed after a subscription update, retest using the new configuration.
The real connection test returns a value. Why can’t web pages open after I connect?
First confirm that the selected node is the one that just passed the test, then switch routing back to the standard preset. Disable application-level proxying, reconnect, wait 5 seconds, and retest with two different domains. If the exit IP is still unchanged, check whether the test browser has been assigned a direct-connection rule.
What should I do if every node in the list times out?
Enable automatic date and time and the correct time zone, switch once between Wi-Fi and mobile data, and select “Update subscription.” Go to “Settings” → “Parameter settings” → “Core type” and confirm that Xray is in use, then test three nodes using different protocols. If all fail, verify the subscription status and node fields.
The latency is only 80 ms. Why are web pages still slow to open?
Low latency only means that one response was fast; it does not indicate sufficient bandwidth. Loading page resources continuously is also affected by packet loss, congestion, and server load. Test the same node three times and load a page containing images. If the result swings from 80 ms to 900 ms, switch to a slightly higher-latency node with better stability.
The connection button is on, but the lookup still shows my old IP. Why?
Check whether the current routing sends the lookup site directly, and confirm that the browser is included in the application proxy scope. Temporarily disable custom rules, reconnect, and run the lookup again. If another app’s exit IP has already changed, the issue is usually in the application scope or domain rules, not the node handshake.
Is it normal for the connection to drop when switching from Wi-Fi to mobile data?
A change in the underlying network can invalidate existing connections. After switching networks, wait 3 to 5 seconds. If the connection does not recover automatically, disconnect and reconnect manually, then look up the exit IP again. During frequent network changes, also allow v2rayNG to keep running in the background so the system does not suspend the core process.
A complete success check requires all four conditions: the real connection test returns valid results repeatedly, the client stays connected, the exit IP changes as expected, and at least two different sites remain reachable. Meeting only one of these conditions is not enough to end troubleshooting.
After the first verification, save two stable nodes as primary and backup. When performance suddenly drops in daily use, compare those two nodes first instead of retesting the entire subscription. This makes it easier to distinguish local network fluctuations, congestion on one node, and a subscription-wide problem.