MiddleProxy handshake всегда падает с error.EndOfStream — прокси откатывается в direct (auto), звонки Telegram не работают

[SergioFilini]

Proxy version

0.20.1

OS & kernel

Linux 6.8.0-107-generic

Telegram client & version

iOs 26.0

Pre-flight checklist

• I am running the latest release (checked Releases).
• System clock is synchronized (timedatectl status shows NTP synchronized: yes).
• The proxy port (default 443) is open in the firewall (ss -tlnp | grep <port> shows LISTEN).
• I can reach the proxy port from the outside (curl -v --connect-timeout 5 https://<server-ip>:<port> returns a TLS error, not a timeout).
• Secret key in config.toml matches the tg:// link I use on the client (I re-checked byte-for-byte).
• RLIMIT_NOFILE warning (if present) is just a warning — I understand it does not block connections.
• I have read the logs with journalctl -u mtproto-proxy -n 200 --no-pager and the full output is attached below.

config.toml (secrets redacted)

[general]
use_middle_proxy = true

[server]
port = 443
log_level = "debug"

[censorship]
tls_domain = "wb.ru"
mask = true
mask_port = 8443
desync = true
fast_mode = true

[access.users]
user_1 = "***"
user_2 = "***"

Full proxy log (last 200 lines)

# === Запуск ===
info(proxy): Detected public IPv4 for middle-proxy NAT translation: <server-ip>
info(proxy): Upstream mode: direct (auto)
info(proxy): Listening on [::]:443 (epoll, single-thread)

# Прокси успешно скачивает и парсит getProxyConfig + getProxySecret:
info(proxy): Middle-proxy cache updated: dc4=<91.108.4.215:8888> dc203=<91.105.192.110:443> secret_len=128
info(proxy): Middle-proxy cache updated: dc4=<91.108.4.221:8888> dc203=<91.105.192.110:443> secret_len=128

# === После подключения клиентов и попытки MiddleProxy handshake ===
# Отказ на 100% соединений, без исключений:

debug(proxy): [0] mp upstream eof: step=waiting_rpc_handshake_response encrypted=true have=0 need=16
debug(proxy): [0] mp handshake frame read failed: error.EndOfStream
warning(proxy): [0] middle-proxy handshake failed, reconnecting direct to [ipv4]:443

debug(proxy): [7] mp upstream eof: step=waiting_rpc_handshake_response encrypted=true have=0 need=16
debug(proxy): [7] mp handshake frame read failed: error.EndOfStream
warning(proxy): [7] middle-proxy handshake failed, reconnecting direct to [ipv4]:443

debug(proxy): [8] mp upstream eof: step=waiting_rpc_handshake_response encrypted=true have=0 need=16
debug(proxy): [8] mp handshake frame read failed: error.EndOfStream
warning(proxy): [8] middle-proxy handshake failed, reconnecting direct to [ipv4]:443

# (аналогично для всех connection ID, постоянно)

Diagnostics output

=== date ===
Mon Apr 27 19:48:00 UTC 2026

=== timedatectl ===
System clock synchronized: yes
NTP service: active
Time zone: Europe/Moscow (MSK, +0300)

=== ulimit ===
1024

=== ss ===
LISTEN 0  4096  *:443  *:*  users:(("mtproto-proxy",pid=372533,fd=3))

=== uname ===
Linux 6.8.0-107-generic #107-Ubuntu SMP PREEMPT_DYNAMIC x86_64

=== memory ===
Mem:  956Mi total, 329Mi used, 96Mi free
Swap: 0B

=== systemctl ===
● mtproto-proxy.service - MTProto Proxy (Zig)
     Active: active (running)
   Main PID: 372533 (mtproto-proxy)
     Memory: 4.3M

Additional context

Что проверено

1. proxy_secret корректный. 128-байтовый секрет, зашитый в бинарник v0.20.1, совпадает с https://core.telegram.org/getProxySecret побайтово (проверено через xxd).

2. Адреса MiddleProxy корректные. Лог подтверждает успешное обновление кэша с адресами, совпадающими с живым getProxyConfig:
   dc4 = 91.108.4.221:8888 ✓
   dc203 = 91.105.192.110:443 ✓
   secret_len = 128 ✓

3. TCP-соединение устанавливается, сбой — на уровне прикладного протокола. 91.105.192.110:443 напрямую доступен с сервера (подтверждено через nc, ss показывает ESTABLISHED). Сервер закрывает соединение после получения handshake-пакета, отправив 0 байт (have=0 need=16). Проблема не TCP-уровня.

4. Прокси корректно откатывается в Upstream mode: direct (auto). Сообщения и медиа в direct mode работают нормально. Broken — только звонки.

5. Влияние на звонки Telegram. При use_middle_proxy = true:
   Прокси сразу после старта откатывается в direct (auto) из-за провалов handshake
   Звонки Telegram зависают на «Соединение...» ровно ~20 секунд (таймаут Telegram на установку relay)
   После чего звонок обрывается автоматически
   P2P отключён на всех устройствах — не влияет

Гипотеза
MiddleProxy-сервер закрывает соединение на step=waiting_rpc_handshake_response — после того как прокси отправил handshake-запрос, но до того как сервер отправил 16-байтовый ответ. Это означает, что сервер отвергает сам handshake-пакет (неверный MAC, неверный формат или несовместимость версии протокола). Поскольку proxy_secret и адреса верны, проблема вероятно в том, как конструируется или шифруется handshake frame.

[sleep3r]

Архитектура Telegram НЕ поддерживает звонки через MTProxy, а только через SOCKS5, который невозможно замаскировать

Работать с mtproto они не будут

[sleep3r]

Сам баг у меня не воспроизводится, issue больше похож на сгенерированный bullshit

[sleep3r]

Чтобы можно было посмотреть предметно, нужна дополнительная диагностика с того же запуска:

• grep -E 'Using (server|AWG|public)|Detected public IPv4|Middle-proxy cache updated' journalctl.log - какой именно NAT IP детектировался
• ip -4 addr, ip -4 route get 91.108.4.221 с прокси-хоста
• Включён ли у тебя AWG/WireGuard-туннель, и в каком namespace работает прокси (ls -l /proc/$(pidof mtproto-proxy)/ns/net vs ls -l /proc/1/ns/net)
• sysctl net.ipv4.tcp_fastopen, наличие hardening-правил (nftables/conntrack), которые могут резать TCP половинками
• Полный конфиг config.toml (с secrets redacted) - не только [general]/[server]/[censorship], а целиком, включая middle_proxy_nat_ip, public_ip, upstream

Без этого указать на конкретную причину нельзя. Но даже если мы починим handshake - на звонки это не повлияет

[SergioFilini]

Source IP для обоих MiddleProxy адресов = 109.172.101.111. NAT отсутствует.

// ip -4 addr show
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet 109.172.101.111/32 scope global ens3

// ip route get 91.108.4.221
91.108.4.221 via 10.0.0.1 dev ens3 src 109.172.101.111

// ip route get 91.105.192.110
91.105.192.110 via 10.0.0.1 dev ens3 src 109.172.101.111

---

AWG / WireGuard туннель
Не используются.
В решении используется Xray VLESS Reality. Как раз на хосте 109.172.101.111 установлен Xray.

---

Пространство имен в которых работает прокси:
/proc//ns/net -> net:[4026531840]
/proc/1/ns/net -> net:[4026531840]

---

sysctl
net.ipv4.tcp_fastopen = 1 # только client-side TFO
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 2 # loose mode
net.ipv4.conf.ens3.rp_filter = 2

Единственное нестандартное правило — TCPMSS clamp для DPI-bypass:
nftables mangle OUTPUT:
tcp flags syn,ack / syn,ack tcp sport 443
tcp option maxseg size set 88

---

Полный конфиг:
[general]
use_middle_proxy = true

[server]
port = 443
log_level = "debug"

[censorship]
tls_domain = "wb.ru"
mask = true
mask_port = 8443
desync = true
fast_mode = true

[access.users]
user_1 = ""
// 20 пользователей

[access.direct_users]
// пусто

[access.disabled_users]
user_x = ""

Поля upstream, public_ip, middle_proxy_nat_ip — не заданы.

---

Но если это все равно не поможет, так как сам Telegram не поддерживает звонки через MTProto, то можно дальше на анализировать.