When a --dc-ip address does not answer, the direct WebSocket tier now gives up after one
--ws-connect-timeout instead of two.
Why (#148)
The direct tier tries two hostnames per DC, kws{N} and kws{N}-1, but it dials both at the same
--dc-ip address: the hostname only goes into the TLS SNI and the HTTP Host header, after the TCP
connect. So when the address timed out for the first hostname, the second attempt waited the same
timeout on the same address. With the default --ws-connect-timeout 10, a client whose pool entry
was cold sat through about 20 seconds of silence before the Cloudflare or upstream-proxy tier was
tried. Telegram's own proxy check gives up after a few seconds and switches the proxy off with "the
proxy server uses incorrect settings".
Fixed
- A TCP connect that times out ends the hostname walk for that attempt. The cold direct tier now
costs one--ws-connect-timeout, not two. - Anything that fails after the TCP connect still moves on to the second hostname: a redirect, a
refusal, or a TLS or WebSocket handshake that stalls. These depend on the hostname, so the other
record can still succeed.
What it costs
Nothing for a working address. The second hostname is skipped only when the first one never got a
TCP connection at all.
This does not change the default timeout. A single cold attempt still waits up to 10 seconds, which
is longer than Telegram's check allows. A cooled address is stepped over for an hour (v2.5.5 extended
that to pinned ladders), so this wait only happens on the first failure and when the cooldown runs
out. --ws-connect-timeout shortens it further for setups that need it.