Блокировка хендшейков Telegram

Похоже, началось.

Использую последний telemt (3.3.35, свежачок, обновил вчера). 01.04.2026 примерно с обеда по Мск в логи массово посыпались сообщения

WARN telemt::maestro::listeners: Connection closed with error peer=XX.XX.XX.XX:XXXXX error=Telegram handshake timeout

Я так понимаю, DPI решили банить по хендшейкам. Это не новость. Вопрос - как они раскрывают обфускацию (естественно, она настроена)?

Конфиг сервера? Ip в лс

Аналогичная ситуация, на трёх разных серверах.
на самих серверах nginx, свои домены, под которые маскировка. В логах аналогично - Telegram handshake timeout.

[general]
prefer_ipv6 = false
fast_mode = true
use_middle_proxy = false

[general.modes]
classic = false
secure = false
tls = true

[general.links]
public_host = "XXXXXXX"

[server]
port = 443
listen_addr_ipv4 = "0.0.0.0"
metrics_port = 9090
metrics_whitelist = ["127.0.0.1/32"]
max_connections = 1000  

[censorship]
unknown_sni_action = "mask"
tls_domain = "XXXXXXXX"
mask = true #
mask_port = 443
fake_cert_len = 2048

[access.users]
###### MASKED #######

[[upstreams]]
type = "direct"
enabled = true
weight = 10

аналогично, после полудня перестал конектиться телеграм через свой mtg с faketls

Apr 01 13:39:15 hostname mtg[651241]: {“level”:“info”,“client-ip”:“x.x.x.x”,“stream-id”:“YYY”,“logger”:“proxy”,“error”:“cannot process client handshake: cannot read frame: EOF”,“timestamp”:1775043555294,“message”:“obfuscated handshake is failed”}

Да, тоже наблюдаю периодический отвал mtproto в режиме fake-tls. Ответил тут тоже.

Наблюдаю проблему со вчерашнего дня.

видимо, со вчера начали раскатывать…. Сук, но как TLS преодолевается-то. Разве что косвенно, режутся характерные последовательности пакетов

Пока это выглядит так, что на время блокируются все TLS-подключения на 443 порту (не только mtproto). Размер пакета Client Hello нестандартный и много подключений на один адрес (а-ля “сибирская блокировка”).

у меня - нет, 443 норм проходит, fake сайт норм открывается (тестирую с другой VPS в РФ), потерь нет

Впрочем да, нельзя отрицать, что блок НЕ стоит на стороне клиентов. Никто точно не знает, сколько ТСПУ проходит трафик на своем пути и где это прикрутили

А разве mtproto proxy создаёт множество соединений?

могут на стороне клиентов давить

Это и так понятно что на стороне клиентов, не на сервере же стоит ТСПУ. Я посмотрел MTProto proxy, он действительно создаёт множество соединений.

Насколько я понимаю клиент телеги не косит под броузер и легко палится по фингеру TLS

как минимум cipher suites там такие же как у хрома.

у меня 5 мин назад блок пропал как будто, у вас как?

У меня и не было блока.

Вот что умник налепил

Этот отпечаток (JA3:

f07cc269d9323c428b7297219bed6754) подтверждает, что ваш Telegram-клиент использует стандартную библиотеку сетевого стека Telegram, а не имитирует браузер.

Вот что говорят эти данные:

  1. Анализ JA3 (f07cc269...)

Этот хеш характерен для Telegram Desktop (на базе библиотеки Qt/OpenSSL).

  • Шифры (Ciphers): Список 4865-4866-4867... включает в себя TLS 1.3 наборы (1301, 1302, 1303 в hex), что хорошо, но их порядок и набор специфичны для Telegram.
  • Расширения (Extensions): В списке присутствуют расширения padding (21), supported_versions (43) и key_share (51), но отсутствуют многие специфические расширения, которые всегда есть у современных Chrome или Firefox (например, Application-Layer Protocol Negotiation с поддержкой h2 может быть настроен иначе).
  1. Анализ JA4 (t13d1516h2...)

JA4 — это более современный и “читаемый” формат отпечатка.

  • t13: TLS 1.3.
  • d1516: Указывает на количество шифров и расширений.
  • h2: Означает поддержку HTTP/2 (через ALPN).
    Это выглядит как “законопослушный” TLS-клиент, но системы DPI (Deep Packet Inspection) знают, что браузеры выдают другие комбинации символов в хеш-суммах (вторая и третья части JA4).

Почему это важно для Fake TLS?

Когда вы используете Fake TLS прокси с SNI google.com, происходит следующее:

  1. DPI видит: Запрос идет на google.com.
  2. DPI сверяет: Клиент имеет отпечаток f07cc269....
  3. DPI знает: Настоящий браузер Chrome, обращаясь к Google, имеет совершенно другой JA3.
  4. Вердикт: Это не браузер, а средство обхода блокировок.

Вывод

Ваш клиент выдает себя за Telegram. Если ваша цель — полная маскировка «под браузер», то стандартный Telegram-клиент этого сделать не сможет, так как его TLS-стек жестко зашит в код приложения. Для обхода сверхчувствительных систем блокировок (как в Китае или Иране) обычно используют связку VLESS + Reality, где происходит более качественная имитация.

у меня все также. Появились error=IO error: Operation timed out (os error 110), что говорит в пользу “сибирского варианта”

блджад.

Это разве что ВПНом обходить. Или свой клиент ваять, но тут Паша будет против.

Как раз Паша мог бы задуматься и прикрутить что-то типа utls

там набор идентичен хрому

всмысле отсутствует? есть

и точно такой же как у браузеров h2,http1.1

я его клоду и чатгпт скормил и они говорят это хром а не openssl

https к серверу с тем же сни что и для тг работает без проблем. пока хз что это

Значит он напридумывал.
После анализа вручную нашел единственное отличие - у хрома ECH есть, у телеги нет.
Отсюда и отличия в JA3/JA4.
Но это можно списать на старую версию хрома.
Тогда что остается ? Статистика ?