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

tg-ws-proxy-rs v2.4.0

on GitHub

--fronting-domain now fronts unconditionally.

Why

Fronting used to be reactive: the proxy sent the real telegram.org SNI on
the first ClientHello and only retried with the fronted SNI after the
handshake timed out. On networks that RST the real SNI on sight — the TCP RST
blocking common in China, for example — that first attempt never survives long
enough for the retry to help: the leak happens before fronting can do its job
(#111).

Changed

• While --fronting-domain is set, every direct-WebSocket attempt presents
  the fronted SNI from the very first ClientHello — including background pool
  pre-connects, which previously dialed with the real SNI and would have
  leaked it anyway.
• A failed fronted connect is now just a normal direct-WS failure: it enters
  the regular --ws-fail-cooldown and the fallback ladder moves on.
• The sticky-window ("stay fronted for N seconds after a success") and
  fail-cooldown machinery is gone with the trigger. --fronting-cooldown and
  --fronting-fail-cooldown still parse — hidden from the docs, values
  ignored — so already-deployed LuCI UCI options and systemd units with
  TG_FRONTING_COOLDOWN / TG_FRONTING_FAIL_COOLDOWN keep starting.

Everything else about fronting is unchanged: it still applies only to direct
WebSocket connections to a --dc-ip target, never to the Cloudflare proxy,
Cloudflare Worker, or upstream MTProto proxy paths, and certificate
verification is still unconditionally skipped on fronted connections (a real
Telegram certificate can never match a fronted SNI).

Cost

On a network where fronting was already known to work, nothing changes except
that the first attempt carries the fronted SNI immediately — one fewer timeout
before the working path. On a network where the DC IP itself is blocked
(fronting cannot help there), a fronted attempt now costs the same single
timeout the direct attempt did, instead of the two sequential attempts the
reactive path made.