sleep3r/mtproto.zig v1.4.2 on GitHub

🇷🇺 Что нового (RU)

Что чинит этот релиз

v1.4.2 — UX-фикс MiddleProxy / ad-tag для нестандартного egress (SOCKS5 / HTTP / туннель).

[!NOTE]
Для direct-egress ничего не меняется. Для socks5/http/tunnel рекламный tag и медиа не-премиум через ME теперь работают из коробки — ручной middle_proxy_nat_ip больше не нужен. Обновление безопасно и рекомендуется.

MiddleProxy + ad-tag «из коробки» на SOCKS/туннеле (#335)

Симптом: при egress через socks5/http/tunnel рекламный tag (и медиа не-Premium через ME) молча не работали — приходилось вручную вписывать [server].middle_proxy_nat_ip, а клиенты/операторы про это обычно не знали.

Причина: сам коннект к MiddleProxy и фетч getProxyConfig/getProxySecret шли через upstream, но автодетект middle_proxy_nat_ip зондировал публичный IP напрямую (ipify в обход upstream). При socks/tunnel Telegram-MiddleProxy видит exit-IP egress'а, а не IP хоста → IP в деривации AES-ключа не сходится → каждый RPC_HANDSHAKE падал → тихий фолбэк на direct-DC, который тег не несёт.

Фикс: NAT-IP теперь зондируется тем же egress'ом, что и MP-трафик:

upstream	как определяется NAT-IP
`socks5` / `http`	через прокси → реальный exit-IP SOCKS/HTTP
`tunnel`	через интерфейс туннеля → реальный exit (WG-endpoint остаётся только fallback'ом)
`direct` / `auto`	прямой зонд, как раньше

→ socks/туннель + ad-tag работают без ручного middle_proxy_nat_ip.

Хватит падать молча

На старте: warn, если MiddleProxy/tag включён, но egress-IP определить не удалось — с точным указанием, какой ключ задать.
В рантайме: периодический warn, когда MP-хендшейки уходят в direct-фолбэк (на этих соединениях тег/ME-медиа не доезжают) — с подсказкой проверить egress и middle_proxy_nat_ip.

Проверено

zig build test — 247/247 (новые юнит-тесты на egress-приоритет и tunnel-fallback) + кросс-сборки x86_64-linux/aarch64-linux + zig fmt — зелёные.

🇬🇧 Release notes (EN)

What this release fixes

v1.4.2 is a UX fix for MiddleProxy / ad-tag on non-default egress (SOCKS5 / HTTP / tunnel).

[!NOTE]
Nothing changes for direct egress. For socks5/http/tunnel the ad-tag and non-Premium media via ME now work out of the box — no hand-set middle_proxy_nat_ip needed. Upgrading is safe and recommended.

MiddleProxy + ad-tag out of the box on SOCKS/tunnel (#335)

Symptom: with socks5/http/tunnel egress the ad-tag (and non-Premium media via ME) silently didn't work — you had to manually set [server].middle_proxy_nat_ip, and operators/clients usually didn't know that.

Cause: the MiddleProxy connection and the getProxyConfig/getProxySecret fetch both went through the upstream, but middle_proxy_nat_ip auto-detection probed the public IP directly (ipify over the default route). Under socks/tunnel, Telegram's MiddleProxy observes the egress exit IP, not the host IP → the IP folded into the AES key derivation never matched → every RPC_HANDSHAKE failed → silent fallback to direct DC, which carries no ad-tag.

Fix: the NAT IP is now probed through the same egress MiddleProxy traffic uses:

upstream	how the NAT IP is found
`socks5` / `http`	via the proxy → the real SOCKS/HTTP exit IP
`tunnel`	via the tunnel interface → the real exit (WG endpoint IP is now only a fallback)
`direct` / `auto`	direct probe, as before

→ socks/tunnel + ad-tag work without a hand-set middle_proxy_nat_ip.

Stop failing silently

At startup: a warn if MiddleProxy/tag is enabled but the egress IP couldn't be detected — naming the exact knob to set.
At runtime: a periodic warn when MiddleProxy handshakes fall back to direct (those connections carry no ad-tag / ME media) — hinting to check egress and middle_proxy_nat_ip.

Verified

zig build test — 247/247 (new unit tests for the egress-first priority and the tunnel fallback) + x86_64-linux/aarch64-linux cross-builds + zig fmt — green.

Changelog

fix(middleproxy): detect NAT IP through the egress so socks/tunnel + ad-tag work out of the box (#335)

Full diff: v1.4.1...v1.4.2