It starts with the node list after a subscription update, explains the difference between plain latency and real connection latency, picks usable nodes with a batch real connection test, and finishes by verifying the proxy at three levels: app status, exit IP, and a target site. Best for users who have just installed v2rayNG and imported a subscription but still can't open web pages.
Reading the node list after a subscription import
Once the subscription update finishes, each row in the main list is one node configuration. The left side shows the remark name, the right side is the test result slot, empty by default or showing the last test value. Remark names come from the server; the usual format is region plus a number. It's just a name and says nothing about line quality — duplicates and garbled text are normal.
Tap the menu on the right of a node entry to see Edit, Share, and Test real connection latency; the top menu also has a batch test for a whole group. On a first connection, don't open nodes one by one and hope for the best — run a batch test first and narrow things down to the few that actually work.
- Name: used to tell lines apart; when names repeat or look garbled, go by the remark
- Protocol: the four common types — VMess, VLESS, Trojan, and SS
- Transport: TCP, WebSocket, gRPC and so on; determines whether traffic is relayed through a CDN
- Test result: latency in milliseconds, or the words "timeout" and "failed"
If the list is empty, or the number of entries doesn't change after updating the subscription, go back to Subscription group and confirm the subscription URL works and the update finished without errors before testing anything. When the subscription itself is dead, every speed test will just return timeouts.
Real connection latency test: filtering out dead nodes
v2rayNG offers two kinds of tests. A plain latency test only does one TCP round trip to the server address and port — a good number doesn't mean the handshake will succeed. A real connection latency test completes the protocol handshake and then sends one request to the probe address, writing the combined handshake and time-to-first-byte figure back to the list. For a first connection, go by the real connection result.
The batch option is Test all configs' real connection in the top menu; for a single node, pick Test real connection latency from its entry menu. Keep your network stable during the test and don't switch nodes at the same time, or the entry being tested will be interrupted and the result will be invalid.
Read the results with the table below — timeouts and failures need different handling, so don't just retest everything.
| What the list shows | Meaning | What to do |
|---|---|---|
| Two- to three-digit milliseconds | Handshake completed, probe request answered | Use it directly |
| Timeout | No response to the handshake or probe request | Switch to another node in the same group and rule out local network problems |
| Failed | Rejected during the handshake | Update the subscription again so the parameters match what the server sends |
| Value clearly higher than usual | Congested line or local network jitter | Retest after a few minutes before deciding |
After one round, pick out the nodes with low latency that didn't time out and enable one of them. Keep the other working nodes in the list as backups — no need to enable them all, since the client only uses one configuration at a time.
Verifying the proxy works: status, exit IP, target site
Once you've chosen a node, walk through the five steps below. Each one has a clear observation point, so you don't have to judge by feel.
Enable the node
Tap the node that passed the test in the list; once the connection status appears in the notification bar, the core has started.
Check the core log
In Settings → Parameter settings, set the log level to Info, then reconnect and check the startup lines.
Compare exit IPs
Turn the proxy off first and note the direct IP on an exit IP lookup page, then turn the proxy on and refresh the same page.
Open the target site
Use a site that normally needs a proxy to confirm the link actually works.
Record the working combination
Write down the node name, routing mode, and per-app proxy status so you can reuse them when you switch networks.
When these two lines appear in the log, the core has started and the local port is ready. If they're missing, the core probably didn't start or the port is already in use — change the local port in Settings → Parameter settings and reconnect.
[Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
[Info] transport/internet/tcp: listening TCP on 127.0.0.1:10809When comparing exit IPs, pay attention to the routing mode. With Bypass LAN and mainland China selected, sites in mainland China don't go through the proxy anyway, so an unchanged exit IP is expected; test with a site outside China or an overseas IP lookup page. Routing mode is switched in Settings → Routing mode.
Leave the target site check for last. If the exit IP changed but the target site won't open, it's usually a DNS resolution or routing issue: first check whether Settings → Per-app proxy excludes your browser, then check whether the domain resolution strategy conflicts with your current network.
Checking node parameters: protocol and transport fields
Node parameters from a subscription are delivered by the server, so you normally don't need to edit them by hand. When troubleshooting a failed node, open the node edit page and compare the fields with what was delivered to see whether the subscription was parsed incorrectly.
VLESS + Reality
- Transport
- TCP
- Flow
- xtls-rprx-vision
- Fingerprint
- chrome
- Public key and short ID
- Delivered by the subscription
Filled in automatically on subscription import; editing any field by hand will break the handshake.
VMess + WebSocket + TLS
- Transport
- WebSocket
- Path
- /ws
- Encryption
- auto
- Host and SNI
- Matches the certificate domain
When traffic is relayed through a CDN, Host and SNI must match the certificate domain.
If the fields don't match the subscription — for example, you edited the path or SNI by hand — the real connection test will fail outright. The fix is to delete the node and update the subscription again so the parameters match what the server sends, instead of guessing field by field.
There's only one case where you need to enter parameters by hand: when the server provides a share link but no subscription. In that case, use Import from clipboard, paste the whole share link, and let the client parse the fields.
Common first connection issues
These come up most often during a first connection, and the approach is always the same: work out which layer is broken first, then change settings.
What if every real connection test times out?
First confirm your device can open web pages normally, then check whether the subscription is still valid. If only one group times out, test another group, and if necessary switch to a different network and update the subscription again.
Low latency but pages won't open?
A passing real connection test only means the handshake and probe request succeeded. Check whether Settings → Per-app proxy excludes your browser, then check whether the routing mode is sending the target domain through a direct connection.
Exit IP doesn't change after connecting?
First check the connection status in the notification bar. With the routing mode set to Bypass LAN and mainland China, sites in mainland China not going through the proxy is expected — try a site outside China or an overseas IP lookup page.
Do I need to retest every time I switch nodes?
Node entries reset after a subscription update, so run a batch test again; for everyday switching, just tap an entry you've already tested — no need to retest.
Is it normal for plain latency and real connection latency to differ a lot?
Yes. For nodes relayed through a CDN, the plain latency test only reaches the edge node, while a real connection has to go all the way to the origin link, so a gap of tens of milliseconds is common.