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

tg-ws-proxy-rs v2.5.0

on GitHub

--check now reads a reply from a plain MTProto upstream proxy instead of only sending it the
handshake, so an upstream that accepts the handshake and cannot reach Telegram fails the check.

Why

The upstream probe sent the 64-byte obfuscation handshake and returned OK without reading anything.
An accepted handshake says the socket is open, not that anything behind it works: a proxy answers one
before its own route to a data centre exists, and Telegram stays silent behind it. That is the same
trap #93 was about for the Worker tier, and the listener probe already had the cure.

Changed

• require_res_pq is the exchange the listener probe performs — send a real req_pq_multi,
  decrypt the reply, require resPQ, and report a transport error as one — extracted so both probes
  share it instead of keeping two copies that can drift.
• probe_mtproto_proxy calls it on the plain path. A plain upstream that answers the handshake and
  then nothing now fails with the upstream proxy closed without answering — no tier reached the DC,
  or with the transport error the DC sent.
• probe_listener uses the same helper. Its behaviour is unchanged; the failure wording only gains
  the article, so a transport error now reads the listener reported a transport error: -404.

Notes

• The FakeTLS path is unchanged: it verifies the server's fake-TLS handshake end-to-end, and carrying a
  resPQ through that record layer needs the record framing on the probe's side. That is a further
  step, not something this release guesses at.
• Upstreams that could not reach a DC used to pass --check. If your config lists an upstream proxy
  that is no longer alive, this release will start reporting it.