valnesfjord/tg-ws-proxy-rs v2.5.5

tg-ws-proxy-rs v2.5.5

on GitHub

A pinned fallback ladder (--pinned-upstream, --pinned-media-upstream) now honours the cooldown of a
--dc-ip address that has already timed out, the way the default ladder does.

Why (#148)

--pinned-upstream replaces the default ladder, and both rules about a cooled address lived in that
default ladder, so a pin switched them off:

• the client path dialled the address on every connection whose pool entry was cold, paying
  --ws-connect-timeout once per kws record before the pin's next rung got a turn;
• nothing else kept asking, so nothing but a pool pre-connect could clear the cooldown again.

--pinned-upstream ws,cfproxy,tcp is what nfqws-menu writes for two of its four variants, and the delay
lands in Telegram's own check of the proxy ("the proxy server uses incorrect settings"): the check wants
resPQ back inside a few seconds.

Measured on a Keenetic MT7621 (MIPS, kernel 4.9, v2.5.4) with a DPI-blocked --dc-ip that flaps:

The --check-listener rows are that box with the --dc-ip address pointed at an RFC 5737 blackhole,
three runs each.

Fixed

• The Ws rung of a pinned ladder steps over a cooled address while a later pinned rung can still
  connect, logging the same IP in cooldown → skipping direct WS to <ip> line as the default ladder, so
  log greps keep working on both.
• If every other pinned rung fails, the ladder comes back for the cooled address
  (every pinned fallback failed → re-probing <ip>) instead of dropping the connection. A pin dials
  exactly what it lists — the raw-TCP rung the default ladder would land on is not in that list — so
  without this second rule a skip would leave the client nowhere for the rest of the hour, and asking the
  address is the only thing that can clear its cooldown.
• A ws-only pin is unchanged: with no later rung, the doomed attempt is still the only path there is.

What it costs

One cooldown lookup per pinned connection. The cooled address is dialled again only once the rest of the
pin has failed, which is what happened before too — the difference is that the client no longer waits for
it on the way in.

Workaround for older builds

EXTRA_ARGS="--ws-connect-timeout 1" bounds the same window without the fix.