Testing node speed properly: latency, bandwidth and pitfalls

What the latency test actually measures

The client sends one HTTP request through the node to a test address and records how long the response takes. mihomo defaults to an endpoint that returns an empty 204, such as http://www.gstatic.com/generate_204.

That figure covers connection setup, the TLS handshake and one round trip. It tells you how responsive a node is, not how many megabytes per second it can move. A Hong Kong relay might show 60 ms with a hard bandwidth cap, while a 200 ms direct route saturates your line.

Three things that distort the number

• Concurrent testing. Most clients test dozens of nodes at once, so all that traffic contends for your single uplink and every result comes out high. To compare a handful of candidates seriously, test them one at a time.
• The test endpoint itself. If the URL resolves to a nearby CDN edge or lands somewhere unexpected, different nodes are not measuring the same target. When choosing your own endpoint, prefer a service that behaves consistently worldwide.
• Connection reuse. A node you just tested may still have a live connection, so the second measurement comes out noticeably lower. Leave a gap between runs if you are comparing.

How to measure real throughput

1. Pin your variables first: select exactly one node and switch off auto-select and load-balancing groups, or the client may swap nodes halfway through the test.
2. Run an ordinary speed-test site in the browser and note the download and upload figures. This measures your network plus the node plus the test server as one chain — which is also exactly what you experience day to day.
3. Switch to direct and run it again as a baseline. If your line only does 20 Mbps unproxied, no node can beat that.
4. Test the same node at different times of day. The gap between peak evening hours and early morning is often larger than the gap between two different nodes.

The speed-test site goes through the proxy too. Watch which server it picks: measuring against a server far from your exit point drags the result down for reasons that have nothing to do with the node.

Choosing by what you actually do

• Streaming and downloads: bandwidth first. One or two hundred milliseconds of latency is essentially invisible here.
• Calls, gaming, SSH: latency and stability first, and jitter matters more than the average. Test the same node five times in a row — numbers bouncing around are worse than a steady 150 ms.
• General browsing: latency dominates, because a single page fires dozens of requests and each one pays a round trip.