Handshake timeout

[0WL007]

привет!
установил только сегодня, столкнулся с долгим подключением. в логах вижу:
WARN telemt::maestro::listeners: Connection closed with error peer=46.241.ХХХ.ХХХ:62767 error=Telegram handshake timeout
по несколько раз подряд. Иногда предупреждение возникает в процессе.
Такая же беда при подключении через МТС
WARN telemt::maestro::listeners: Connection closed with error peer=176.15.206.241:62275 error=Telegram handshake timeout
и через Билайн
WARN telemt::maestro::listeners: Connection closed with error peer=91.78.222.7:7158 error=Telegram handshake timeout
Так же очень долго приходится ждать ответа от бота - от 5 секунд и больше.

[FreezInside]

такая же проблема

[ariestop]

Ну сегодня блокировать начали MTProto протокол, ищите сервер с белым IP

[vaban-ru]

Ну сегодня блокировать начали MTProto протокол, ищите сервер с белым IP

Есть откуда то информация, что прям протокол? И типа никакой SNI не подойдёт?

[vaban-ru]

Насколько критично не 443 порт, а например 9443?

[0WL007]

пробовал на других портах - точно такое же поведение

[SamNet-dev]

This is not an MTProxyMax bug — it's active DPI blocking by Russian ISPs (TSPU). The Telegram handshake timeout means the TLS connection establishes, but the MTProxy handshake inside it gets detected and killed. Multiple ISPs (МТС, Билайн, dom.ru) all run the same TSPU equipment, which is why the behavior is identical across providers and ports.

What's happening:
The Russian TSPU has learned to fingerprint MTProxy-over-fakeTLS traffic. Even with masking enabled, the handshake pattern inside the TLS tunnel has detectable characteristics. Changing the port doesn't help because the DPI inspects the traffic content, not the port number.

What you can try:

1. Change the masking domain — try a popular Russian domain (vk.com, ok.ru, mail.ru, yandex.ru). Some domains get less scrutiny from TSPU because blocking their TLS pattern would cause collateral damage.

2. Use a "clean" IP — if your server IP is already flagged, even a perfect handshake may be blocked. Try a fresh VPS with a new IP from a different provider/region.

3. Proxy chaining — route through an intermediate server in a non-blocking country. MTProxyMax supports upstream proxy chaining (Security & Routing > Proxy Chaining). Put a cheap VPS in a neutral country between your users and the proxy.

4. Try a non-standard client_handshake timeout — in some cases, increasing it helps clients that are slow due to DPI-induced latency. But this only helps if the connection isn't being actively reset.

Unfortunately there's no software-side fix for protocol-level DPI blocking. The engine's fake-TLS masking is the best available obfuscation for MTProxy, but determined DPI can still detect the inner protocol characteristics.