Latency, Node Selection and Real-World Speed: Getting More From Your Setup

Almost every routing client has a button that measures your nodes and prints a number next to each one. Green for low, orange for middling, red for bad. It is the most-clicked control in the whole interface, and it is also the most misread.

The number is not “speed”. It is one narrow measurement, taken once, from where you happen to be sitting, against whatever endpoint the client was configured to poke. Treating it as a throughput ranking is how people end up on a node that shows 38 ms and downloads at a crawl.

What follows is a practical look at what that test actually does, why the lowest figure is often not the best choice, and the handful of settings underneath — health checks, DNS, MTU, congestion control, multiplexing — that shape real-world performance far more than node order ever will.

What the Latency Test Measures

When you press the test button, the client opens a connection through each node to a test URL and times the round trip. Depending on the implementation and the configured target, that timing covers some combination of:

• The TCP handshake between you and the node.
• The node’s own connection out to the test URL.
• A minimal HTTP request — typically a HEAD or a request to an endpoint that returns an empty 204 — and its response.

So the figure is closer to “time to first useful byte through this path” than to a raw ICMP ping. That is genuinely more informative than a ping, because it includes the node’s ability to open outbound connections rather than just its ability to answer you.

What it does not include is anything about sustained transfer. Bandwidth, packet loss under load, per-user throttling, how many other people are on the node at 9pm — none of that appears. A path can complete a handshake in 40 ms and then deliver 900 KB/s because it is saturated.

Latency and throughput are different properties

Latency is how long a single round trip takes. Throughput is how much data fits through the pipe per second. They are related — high latency limits how fast a TCP window can grow — but they are not the same measurement, and a node can be excellent at one and poor at the other.

The practical consequence is that different workloads want different winners. Interactive work — SSH, a remote desktop, a video call, gaming — genuinely cares about the low number. Bulk transfer cares about sustained bandwidth and loss, and will often be happier on the node that tested 20 ms slower.

Choosing a Test URL That Tells the Truth

The default test target in most configurations is a lightweight endpoint that returns a 204 with no body. That is the right shape for the job: no DNS complexity on the far side, no redirects, no large payload, nothing cached.

Three things make a test URL misleading:

• It is heavily CDN-distributed. Every node hits a different nearby edge, so you are partly measuring CDN topology rather than the node.
• It returns a real page. Body transfer adds variance that has nothing to do with connection setup.
• It is unrelated to what you actually use. If your traffic is mostly one API, testing against something else tells you about a path you never take.

A reasonable compromise is a plain, small, geographically stable endpoint for routine health checks, and an occasional manual test against the service you care about most when you are choosing between two nodes that look equal.

proxy-groups:
  - name: Auto
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - Node-A
      - Node-B
      - Node-C

Health Checks: Interval and Tolerance

Two numbers in that snippet do most of the work, and both are commonly set badly.

Interval is how often the group re-tests. Short intervals react quickly to a node going bad, but they also generate constant background connections and make the group twitchy. Something in the range of a few minutes is usually right; testing every thirty seconds mostly buys you noise.

Tolerance is the margin, in milliseconds, by which a challenger must beat the incumbent before the group switches. Without it, two nodes within normal jitter of each other will trade places on every test, and every switch resets your connections. A tolerance of 50 ms or so means the group only moves when the difference is real.

If you have ever had a video call drop for no visible reason, an over-eager url-test group with zero tolerance is a strong suspect.

When fallback beats url-test

A url-test group chases the fastest node. A fallback group stays on the first node in its list until that node fails, then moves down. For long-lived connections — a call, a sustained upload, a remote session — stability is worth more than a few milliseconds, and fallback is often the better choice.

Geography Usually Wins, Except When It Does Not

Physics sets a floor. Light in fibre covers roughly 200 km per millisecond, and real paths are not straight, so a node on another continent cannot beat a nearby one on raw round-trip time. Closer is the right default assumption.

But routing is not geography, and there are real exceptions:

• Peering matters more than distance. A nearby node on a poorly peered network can lose to a distant one sitting on a major backbone.
• Congestion is local and temporal. The closest node is also the one everyone else nearby picked. At peak hours it may be the slowest.
• The destination has a location too. If the service you are reaching lives in one region, exiting near it can beat exiting near you.
• Some paths take strange routes. Traffic between two nearby points occasionally traverses a distant exchange for reasons no dashboard will explain.

This is why measurement beats reasoning. Test, do not assume — and test more than once.

The Layers Underneath the Node List

Once your node selection is sane, the remaining gains are in the transport itself. These settings rarely get attention because they are not visible on the proxies page, but they account for a surprising share of “it feels slow”.

MTU on the TUN interface

When traffic is pulled in through a virtual network adapter, packets carry extra encapsulation overhead. If the resulting packet exceeds the path MTU it gets fragmented — or, when Don’t Fragment is set and the ICMP messages that would report the problem are being dropped somewhere, silently discarded.

The symptom is distinctive and easy to misdiagnose: small requests work perfectly, large uploads or page loads with big headers stall. That is a classic MTU black hole, not a slow node.

tun:
  enable: true
  stack: system
  mtu: 1500
  auto-route: true
  auto-detect-interface: true

If you see that pattern, step the MTU down — 1400 is a common safe value — and see whether the stalls disappear. It is a two-minute experiment that resolves a class of problem people otherwise chase for days.

TCP congestion control

Congestion control decides how aggressively a connection grows its send rate and how it reacts to loss. Loss-based algorithms treat any dropped packet as congestion and back off hard, which is the wrong assumption on a long path with mild, random loss — throughput collapses even though the pipe is fine.

Newer model-based algorithms estimate available bandwidth instead of retreating at the first lost packet, and generally hold up better on high-latency links. This is an operating-system setting on whichever machine terminates the connection, not something a client toggles, but it explains why two nodes with identical latency can deliver very different sustained speeds.

Multiplexing

Multiplexing carries several logical streams inside one established connection, so a new request skips the handshake and starts immediately. On a high-latency path that saving is real and repeated — page loads with dozens of small requests feel noticeably quicker.

The trade-off is head-of-line blocking: one stalled stream can hold up the others sharing the connection, and a single dropped connection takes every stream with it. Multiplexing helps many small requests and hurts a small number of large sustained transfers. Turn it on for browsing, consider turning it off for bulk work.

DNS: The Latency Nobody Measures

Before a single byte of your request travels anywhere, a name has to become an address. That resolution is pure added delay, it happens on every new domain, and it never shows up in a node latency test.

Two failure modes account for most of the pain:

• Slow resolvers. An encrypted DNS endpoint that takes 300 ms adds 300 ms to the first request to every new domain you touch.
• Resolution on the wrong side. Resolving a CDN hostname locally while exiting through a distant node gives you an edge server near your house and an exit on another continent — the worst of both.

A workable arrangement keeps local names on the local resolver and sends everything else somewhere fast and consistent, with fake-IP deferring resolution until the routing decision is made:

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fallback:
    - https://dns.google/dns-query

If you are still choosing a client, this is worth weighing before you commit to a particular clash download — DNS handling, health-check configuration and TUN stack options vary between implementations, and they matter more for day-to-day speed than the node list does.

Testing Methodology That Produces Usable Answers

One test tells you almost nothing. Network conditions vary by the minute, and a single sample is as likely to capture a transient hiccup as a real property of the path.

1. Repeat. Run the test five times and look at the spread, not the best result. A node that returns 60, 62, 61, 240, 63 has an intermittent problem that its average hides.
2. Test at different hours. Sample once during your working day and once at local peak. Congestion patterns can reverse the ranking entirely.
3. Separate latency from throughput. After the latency test, pull a large file through your top two or three candidates and watch the sustained rate. The winners are frequently different nodes.
4. Change one thing at a time. Adjust the MTU, or the DNS, or the multiplex setting — never all three — and re-measure between changes.
5. Write it down. A three-line note per node beats memory, especially when you revisit the question in a month.

Client documentation such as the guides on clash-vergerev.co is worth checking for the exact meaning of the health-check fields in your build, since interval and tolerance semantics differ slightly between cores and versions.

Reading the Connections Log

When something is slow, the connections view answers the question that guesswork cannot: which path did this actually take? Each active connection typically shows the destination host, the rule that matched, the policy group and node in use, and the bytes moved in each direction.

Four patterns are worth learning to recognise:

• The unexpected rule. A connection matched something further up the list than you intended and is exiting via the wrong node. Reorder the rules; do not blame the node.
• The connection that never grows. Established, byte counters barely moving. That is a stall — MTU, a dead node, or a blocked path — not slowness.
• Chatter you did not ask for. Dozens of connections to one telemetry domain, all being routed. A REJECT rule removes them from the picture entirely.
• Split loads. Two thirds of a page’s requests going one way and a third the other, because one hostname matched a different rule. Usually a rule-set boundary you did not know was there.

Fifteen minutes reading that log while reproducing the problem is worth more than an afternoon of switching nodes at random.

Frequently Asked

My fastest node by ping is slow for downloads. Why?

Latency measures a round trip; downloads depend on sustained bandwidth and loss. A node can answer quickly and still be bandwidth-limited or crowded. Test the two properties separately and pick per workload — the low-latency node for interactive use, the high-throughput one for transfers.

How often should health checks run?

A few minutes is a sensible default. Much shorter and you generate constant background traffic and encourage the group to flap; much longer and a failed node keeps receiving traffic for a while. Pair the interval with a non-zero tolerance so normal jitter does not trigger switches.

Everything is slow, but only sometimes. Where do I start?

Check DNS first — intermittent slowness on the first request to a new domain is almost always resolution, not routing. If large transfers stall while small requests are fine, look at MTU. If it correlates with time of day, it is congestion on the node.

Does adding more nodes to a group make it faster?

No, and past a point it makes things worse. Every node in a url-test group is tested on every interval, so a group of forty generates a lot of background connections for little benefit. Keep five or six nodes you have actually verified.

Closing Notes

Performance tuning here is mostly a matter of measuring the right thing. The latency button answers one narrow question well, and people extend its answer far past what it supports.

Get the health-check interval and tolerance sane so the group stops flapping. Put DNS where it belongs and stop paying for resolution twice. Check the MTU if large transfers stall. Then use the connections log to find out what is genuinely slow, rather than cycling through nodes hoping one feels better. The gains from those four things comfortably exceed anything you will get from reordering a node list.