Два апреля, утро. Открываю Telegram на ноутбуке, а там бесконечное «Connecting». Беру телефон - то же самое. В рабочем чате десять человек пишут одно и то же: прокси отвалились, ни один не поднимается. Если вы читаете это, скорее всего у вас та же история.
За эти месяцы я перелопатил кучу логов, поговорил с людьми, которые держат собственные узлы, и посмотрел, как ведут себя разные клиенты на разных платформах. Причин сразу несколько, и они накладываются друг на друга. Ниже - по порядку, без мистики и без дежурного «всё сломалось, ждите».
Клиент сломали раньше, чем что-либо ещё
Часть поломки сидит внутри самого приложения. В сборках клиента для Android, которые вышли в начале апреля, разработчики допустили грубые ошибки при компиляции. Не в серверах, не в протоколе, а в коде клиента. Люди обновлялись до 6.7.5 на десктопе, обновляли прокси-демон до 1.6.0 и получали ровно то же самое: вечный коннектинг и ноль новых соединений в логах.
Маркер простой. Когда в логах нет вообще никаких попыток коннекта, проблема не в удалённом узле. Узел тут ни при чём, до него даже не доходит. Клиент не инициирует соединение. Меняйте прокси сколько угодно, результат будет один и тот же, пока не откатитесь на рабочую сборку или не дождётесь исправления.
Я поймал это на себе: полчаса перебирал узлы, тыкал в каждый, ругался. Потом включил подробное логирование, перезапустил демон и увидел пустоту. Ни одной строки о попытке соединения. Дальше стало понятно, что искать надо не там.
ECH и fingerprint: почему MTProxy стал видимым
Второй слой проблемы технически глубже. MTProxy маскирует трафик под обычный HTTPS: тот же TLS, тот же порт 443, снаружи выглядит как поход на какой-нибудь сайт. Вся идея держится на том, что фильтрующая система не отличает сессию мессенджера от сессии браузера на том же домене.
А теперь представьте ошибку в коде генерации параметра Encrypted Client Hello. ECH шифрует имя запрашиваемого сайта внутри TLS-хэндшейка, чтобы посредник не видел, куда именно вы идёте. Одна кривая строчка в реализации - и отпечаток перестаёт совпадать с браузерным. Системы анализа трафика на стороне провайдеров получили ровно то, что им нужно: стабильный признак, по которому MTProxy-сессия отличается от Chrome на том же сайте.
Дальше механика простая. Есть шаблон - есть фильтрация по шаблону. Ломать шифрование не нужно, расшифровывать содержимое тоже. Достаточно понять, что вот эта последовательность байт в хэндшейке не встречается у настоящих браузеров, и пометить соединение. Никакого взлома, чистая статистика.
Отсюда жалобы, которые я видел десятками: фото грузится, а видео умирает на третьей-пятой секунде. Картинки идут мелкими пакетами по одному каналу, видео требует стабильной полосы и держит сессию дольше. Сессия не доживает до конца буферизации - вот и весь фокус.
Почему «подожду, само наладится» не сработает
Публичные MTProxy живут по принципу «один узел на тысячу человек». Пока признак не сформирован, это работает. Как только признак появился, все тысяча отваливаются одновременно. Хозяин узла меняет конфиг, ставит новый секрет, и через день-два история повторяется: изменился не узел, а способ его распознавания.
Я наблюдал за одним таким узлом месяца три. Пики отказов шли волнами с шагом примерно в неделю. На Reddit владельцы публичных узлов описывают ту же картину: поднял инстанс, раздал людям, через несколько дней снова тишина. Не невезение, а структурная проблема: шаблон в трафике никуда не делся.
Вторая причина, по которой ожидание бесполезно, - нагрузка. Когда у соседа тоже отвалилось, он идёт туда же, куда и вы. Узлы, которые держали 200 Мбит без напряга, к середине месяца проседали до 15. Дело не в протоколе, дело в том, что на один порт село в пять раз больше людей.
Чем SOCKS5 отличается от MTProxy и почему это важно
Тут многие путают тёплое с мягким. MTProxy - собственный протокол Telegram со своим секретом и маскировкой под TLS. SOCKS5 - универсальный протокол: он просто передаёт TCP-соединения через узел, без всякой маскировки под HTTPS. В текущей ситуации это его главное преимущество.
У SOCKS5 нет задачи выглядеть как браузер. Он и не пытается. Зато у него есть авторизация по логину и паролю, привязка к конкретному узлу и предсказуемое поведение. Если узел ваш собственный, вы контролируете порт, нагрузку и то, кто ещё через него ходит.
На практике для корпоративных задач, парсинга и работы с внешними API я давно использую именно SOCKS5. Стабильность выше: нет зависимости от того, обновился ли клиент мессенджера и не сломали ли очередной параметр в TLS-хэндшейке. Протокол живёт своей жизнью, клиент своей.
Что делать руками: пошагово по интерфейсу
Самый простой сценарий: вам нужно, чтобы Telegram снова нормально работал, и у вас есть доступ к прокси-серверу - своему VPS, корпоративному узлу или арендованному.
В мобильном клиенте: Настройки, дальше Данные и память, потом Прокси, кнопка Добавить прокси. Выбираете тип SOCKS5, вводите адрес узла, порт, логин и пароль, сохраняете. Клиент сразу покажет статус подключения. Если статус зелёный, а сообщения не уходят, проверьте, не висит ли в настройках старый MTProxy-профиль. Он перехватывает соединение и мешает новому.
На десктопе путь почти такой же: Настройки, Продвинутые настройки, Тип подключения, Прокси. Дальше SOCKS5 и те же поля. После сохранения перезапустите клиент полностью, не просто закройте окно. Самая частая причина «не работает» на десктопе: процесс висит в трее и держит старое соединение, а вы смотрите на новый профиль и не понимаете, почему он мёртвый.
В браузере: Настройки, Система, Настройка прокси для компьютера. Откроется системное окно, где вы указываете адрес и порт узла. Не забудьте галочку «не использовать прокси для локальных адресов», иначе домашний роутер перестанет открываться и вы решите, что всё сломалось.
Отдельно про публичный Wi-Fi. В кафе, аэропортах и коворкингах я поднимаю туннель до своего узла раньше, чем открою хоть одну вкладку. Не потому что там кто-то сидит и ворует пароли, а потому что в таких сетях трафик между вами и точкой доступа видит любой желающий. Один раз настроенный SOCKS5-профиль закрывает вопрос навсегда.
Для корпоративного узла логика та же, только адрес и учётные данные выдаёт администратор. Разница в том, что такой узел не делят с тысячей незнакомцев, и ведёт он себя предсказуемо в любое время суток.
Свой узел или готовый каталог
Держать собственный VPS - вариант честный, но требует времени. Нужно поднять сервис, настроить авторизацию, следить за нагрузкой, менять конфиги, обновлять софт. Для одного человека это оверкилл, для команды из десяти разработчиков - нормальная история.
Если времени на администрирование нет, логичнее брать готовые узлы в каталоге. Я держу под рукой каталог прокси 3seller, там есть SOCKS5 и другие типы, с фильтрами по стране и протоколу. Удобно тем, что не нужно гадать, живой узел или нет: подставил в настройки, проверил статус в клиенте.
При выборе смотрите не на количество узлов в списке, а на наличие авторизации по логину и паролю и явно указанный тип протокола. Узлы без авторизации в открытом доступе - лотерея. Сегодня работает, завтра через него ходит половина района, а скорость падает до нуля.
Почему на одном устройстве работает, а на другом нет
Классика, которую я слышу каждый день: на телефоне всё летает, на ноутбуке вечный коннектинг. Или наоборот. Причина почти всегда в версии клиента. Сборки обновляются не одновременно, десктоп и мобилка живут разными циклами. Стоит на одном устройстве сборка с той самой ошибкой в ECH-параметре, а на другом нет - поведение будет разным на одном и том же узле.
Второй вариант - энергосбережение. Android любит придушивать фоновые процессы, и прокси-демон засыпает вместе с ними. Отсюда жалобы «утром работало, вечером нет». Зайдите в настройки батареи и снимите ограничения с клиента, который держит туннель.
Третий вариант - на устройстве включён системный прокси, а внутри приложения стоит свой. Два профиля конфликтуют, и трафик идёт в никуда. Проверяется за минуту: отключите всё, оставьте один профиль, перезапустите.
Что проверять, если ничего не помогает
Порядок диагностики у меня такой. Сначала смотрю, инициируется ли соединение вообще. Ноль попыток в логах клиента - дело в клиенте, обновляйте или откатывайте версию. Потом проверяю узел отдельно, любым сетевым инструментом вне мессенджера. Потом смотрю на протокол: если MTProxy не поднимается, меняю на SOCKS5, не тратя время на танцы с секретами.
И главное: не держите один профиль. Два-три узла с разными протоколами спасают в девяти случаях из десяти. Переключение занимает десять секунд, а нервов экономит на целый день.
Если у вас сейчас вечный коннектинг, начните с малого: зайдите в каталог прокси, возьмите SOCKS5-узел, вбейте его в настройки Telegram и проверьте статус в клиенте. Дальше видно, куда копать: в сторону клиента, в сторону узла или в сторону протокола. Три шага, полчаса времени, и мессенджер снова живой.