With --cf-balance, the connection pool's spare Cloudflare-proxy connections are dialled at the
kws{N} record, not at the bare --cf-domain.
Fixed
--cf-balance sent every pool spare to the zone apex (#161)
After a Cloudflare-proxy connection succeeds, the pool opens a spare through one domain. Without
--cf-balance that is the record that just answered, kws{N}.your-domain. With --cf-balance the
pool takes the next domain in the rotation instead, so the spares follow the balancing. But the
rotation holds bare domains, and the pool dialled the pick as is: your-domain, with no kws{N}.
in front. The zone apex has no DNS record, so Cloudflare answered 530 and the spare was never opened.
Clients were not cut off: the connection that triggered the spare had already succeeded. But every
balanced spare failed, so the pool never helped, and every connection paid the full Cloudflare
handshake inline. In the reporter's Cloudflare analytics, exactly half of the /apiws requests
were failing 530s on the bare domain.
- The pool now dials the
kws{N}record of the domain it picks from the rotation, the same name the
inline path uses. - Cloudflare Worker spares are unchanged. A Worker is dialled at its own hostname, which is what the
rotation holds for it.
Thanks to @UjuiUjuMandan for tracking this down.
What it costs
Nothing. The spare now reaches a record that exists, and --cf-balance works for the pool as
intended.