Флуд к 194.221.61.2 от Telegram

1

В логах xray увидел подозрительную активность: 5 запросов в секунду к tcp:194.221.61.2:443 со SNI www.google.com. Эта активность начинается и прекращается по определенному триггеру. Опытным путем установил, что триггером является открытие и закрытие андроид-клиента Телеграм. Не этап “Connecting…“, а именно foreground/background state, то есть если Телеграм активен, то и запросы не прекращаются. Используя NetGuard подтвердил, что Телеграм обращается к www.google.com/443 в момент когда в логах появляется 194.221.61.2. Анализ активности в Wireshark: множество коротких соединений с одинаковыми характеристиками (20 пакетов, 9 КБ, 12 секунд). Если в xray заблокировать 194.221.61.2, то Телеграм некоторое время будет усиленно флудить с рейтом 50-100 RPS и в итоге перестанет обращаться к этому адресу, но продолжит работать корректно. Если разблокировать, то через некоторое время Телеграм вновь начинает к нему обращаться. На десктопном клиенте обращений к этом адресу я не увидел.

Я потестил это на двух разных устройствах: телефоне и планшете. Оба подключены к одной сети.

Сам айпи не бьется как гугловский. Если обратиться к нему вот так curl --resolve www.google.com:443:194.221.61.2 https://www.google.com , то сервер даже SYN-ACK не отвечает.

Вопрос к знатокам: что это? Это так Телеграм получает служебную информацию для приложения? Или это выглядит как баг и стоит написать в их саппорт? А возможно я заблуждаюсь и это вообще не относится к Телеграм.

2

на xray сервере и клиенте включен routeOnly? (только если сниффинг вкл). если нет, то включи и флуд должен прекратиться после успешного подключения (сниффинг ломает подключение с чужим sni и тг постоянно переподключается)

3

спасибо! включение на клиенте помогло. как я понял, так телеграм пытается обходить ркн? потому что sni = www.google.com, ja4 = хромовский. а раз routeOnly был выключен, то сервер резолвил реальный www.google.com и возвращал его данные, а телеграм уже отказывался и ретраил.

4

выглядит как баг, потому что десктоп клиент на пк обращается тоже к google .com но по корректным адресам. (принадлежащим гуглу и устанавливающим сессию)
и потом еще doh google использует, игнорируя настройки сети на пк. возможно все обращения необходимы для dns (сначала получает настройки для doh, потом его включает)
и все это при запуске клиента, непонятно только зачем ему вообще dns
p.s моб. клиент не проверял

5

На macos приложении тоже флудит, но на адрес 5.28.195.2, принадлежащий Vodafone, и тоже со SNI google.cоm

У же несколько лет это висит в багрепортах https://bugs.telegram.org/c/36949/8

6

Днс там нужен чтобы получать новые ип адреса проксей/серверов

GET /dns-query?name=apv3.stel.com&type=16&random_padding=EmUQ3oZIWcvJJ9RLxaxeKqSqhSE9UA396LugW4Z4u2X7e17s8hoT1V8pRXUYC3FkyZ1gQVsl5RfChBKYfqsjg HTTP/2
host: mozilla.cloudflare-dns.com
user-agent: Telegram/32738 CFNetwork/3826.600.41 Darwin/24.6.0
accept: application/dns-json
accept-language: ru
accept-encoding: gzip, deflate, br

7

This is the internal MTProxy in Telegram’s infrastructure, distributed through DNS TXT record of apv3.stel.com.

The MTProxy is in FakeTLS mode, the fronting domain is www.google.com.

I once wrote a Python script to extract the current proxy config
tg_txt_decrypt.py (12.9 KB)

The current production config is,

  Domain  : apv3.stel.com
  Date    : 2026-04-27 14:02:54 UTC
  Expires : 2027-04-27 14:02:54 UTC [valid]

  DC 4  phone_prefix=(all)
    address : 194.221.61.2:443
    secret  : FakeTLS  host=www.google.com  key=f7f7da556b4bd989fd44c9bc7b7b2a75
    tg link : tg://proxy?server=194.221.61.2&port=443&secret=eef7f7da556b4bd989fd44c9bc7b7b2a757777772e676f6f676c652e636f6d

Distribution and decryption code is at,

  1. tdesktop/Telegram/SourceFiles/mtproto/special_config_request.cpp at 2cfdf1b32ee4160da4d0816f6b9ff26bdf41cd81 · telegramdesktop/tdesktop · GitHub
  2. tdesktop/Telegram/SourceFiles/mtproto/mtproto_config.cpp at 2cfdf1b32ee4160da4d0816f6b9ff26bdf41cd81 · telegramdesktop/tdesktop · GitHub

BTW the config is quite useless in China because the fake domain www.google.com would trigger TCP RST censorship. They can do it better, like distributing fake domain as www.bing.com for China’s +86 phone prefix.