How to Choose a Node: Latency, Rate Multiplier, Region and Protocol Type in Order of Priority

Set the order first: region → protocol type → rate multiplier → latency

A node list carries plenty of fields, but only four kinds really shape the experience: the node's region, its protocol and transport combination, the traffic rate multiplier, and the latency produced by the first two together with your local route. Comparing all four at the same level at once only leads to endless second-guessing.

Excluding first and ranking second works better. Region sets the physical floor for round-trip time, the protocol combination decides how easily a route is disturbed under congestion, the rate multiplier decides what those bytes cost you, and latency is simply the result of the first three in your current network.

The reference figures you can use directly across the four dimensions are below; each one is expanded later in the article.

Region: sets the latency floor and the route quality

Physical distance cannot be argued with. For a packet travelling from your local egress to the remote data center and back, the round-trip time of light in fiber already sets the floor; protocol-level tuning can only add on top of that.

The table below collects rule-of-thumb ranges by common data center location. Real numbers move with your local broadband egress, your ISP's international routes and evening-peak congestion — and between two routes in the same region the gap can be wider than between regions.

Region's job is to narrow the field, not to make the final call. Split candidates into near, mid and far groups by physical distance first, then compare specific routes inside each group — the comparison goes much faster.

Protocol type: look at the transport layer first, then the security layer

Node names in a client list usually carry three pieces of information: protocol, transport and security layer — for example VLESS + TCP + Reality, or VMess + WebSocket + TLS. The protocol decides authentication and encryption; the transport decides what the packets look like on the wire.

Ordinary users don't need the implementation details of every combination. Three questions are enough: does the route need your own domain, does it depend on a TLS certificate, and will it load properly in the client you actually use?

Under normal network conditions the speed difference between the three combinations is usually under 10%; what really separates them is how stable the route is at peak hours or across networks. Protocol type is good for ruling out clearly unsuitable combinations, not for fine-grained picking.

The fastest way to tell which combination a node uses is to read the share link parameters in the subscription:

• security: the security layer, with values none / tls / reality; it determines the handshake method.
• type: the transport, with values tcp / ws / grpc / http.
• flow: flow control; xtls-rprx-vision is only valid with VLESS + TCP + Reality or VLESS + TCP + TLS.
• sni: the target domain used in the handshake; both Reality and TLS rely on it.
• path and host: used only by WebSocket and HTTP transports; when missing, the connection succeeds but no traffic is forwarded.

Rate multiplier: work out the traffic cost before ranking

The rate multiplier is the billing coefficient the server applies to traffic. 1.0× means 1 GB actually transferred costs 1 GB from your plan; 2.0× means the same 1 GB costs 2 GB. The multiplier has no necessary link to speed — a high-multiplier route is not automatically faster.

Multiplying the multiplier into your monthly usage makes the picture much clearer. Say 60 GB up and down combined per month:

• 1.0× route: 60 GB of plan traffic used.
• 1.5× route: 90 GB of plan traffic used.
• 2.0× route: 120 GB of plan traffic used.
• 3.0× route: 180 GB of plan traffic used.

The conclusion: keep nodes at 2.0× or above as emergency backups, and keep daily drivers between 1.0× and 1.5×. For high-traffic tasks such as streaming video or downloading large files, prefer the low multipliers; for light tasks such as browsing and messaging, the difference between multipliers is negligible.

Latency: what to test, how many times, and how much fluctuation counts as abnormal

Clients can measure two kinds of latency. One is TCP handshake latency, which only checks whether the port on the node server is reachable; the other is real-connection latency, which actually issues a request through the node and returns the result. The first number is smaller, the second is closer to real experience — use the second when choosing nodes.

In v2rayN, select a node, right-click and choose Test real connection latency; the main window re-sorts by the result. In v2rayNG, tap ⋮ in the top right and choose Test all configurations latency, and the values fill in down the right side of the list. The default timeout on cross-border routes can be too short — raise it under Settings → Parameter settings → Basic settings and test again.

Don't trust a single result. Test the same node three times in a row, take the median, then compare it with neighbouring nodes. The four rules below cover the judgement.

1. All three results within 80 ms: promote it to daily main node.
2. Results vary by more than 30%, or one of the three times out: the route is jittery — demote it to backup.
3. Real-connection latency clearly higher than TCP latency, for example more than double: the node server is heavily loaded or the return path detours — switch to another node in the same region.
4. All nodes slow down at once: the problem is usually not the nodes. Turn the proxy off first and check whether your local network is fine, then test again.

One more case is worth recording separately: a node that is stable during the day but always jitters at peak hours. That is route congestion rather than node failure — keeping it in the backup group is more valuable than deleting it.

Putting it to work: one selection result shared by both ends

When the desktop and Android clients use the same subscription link, the node list, groups and ordering stay in sync, so you only need to do the selection once. The two ends differ mainly in where you run the tests and how you use them day to day.

Turn this order into a habit: after importing a new subscription, split groups by region, drop nodes at 2.0× or above, test real-connection latency three times for each of the rest, sort by the median, and keep the top three as your regular nodes. After that, just re-test once whenever the subscription updates.

One caveat: node quality changes over time, so a single selection is not a long-term verdict. The same data center can behave completely differently at different hours, which makes periodic re-testing more useful than one careful pick.