Telegram-прокси не подключается: диагностика по шагам

Прокси вчера работал, а сегодня Telegram висит на «Connecting…»? Или подключается, но сообщения не грузятся? Разберём по шагам, где обрыв — от закрытого порта до устаревшего конфига и рассинхрона часов.

Привет! Я, Семёнов Евгений Сергеевич, директор АйТи Фреш. Жалоба «прокси не подключается» — одна из самых частых, что прилетает нам от клиентов, и почти всегда за ней прячется одна из десятка типовых причин. Хорошая новость: почти каждую из них можно локализовать за пару минут, если действовать методично, а не дёргать наугад. Ниже — тот самый чек-лист, по которому мои инженеры проходят диагностику: симптом → вероятная причина → команда для проверки → фикс. Материал одинаково применим и к официальному MTProxy, и к популярному mtg от 9seconds.

Сначала — локализуем обрыв

Прежде чем лезть в конфиги, важно понять, на каком участке рвётся цепочка. Она простая: клиент Telegram → интернет-провайдер (возможный DPI) → ваш VPS → процесс прокси → дата-центры Telegram. Первый же вопрос, который я задаю: «А с мобильного интернета работает?»

• Не работает вообще нигде — проблема на сервере: упал процесс, закрыт порт, устарел конфиг или сбито время.
• Не работает только в офисе/у провайдера, но работает с мобильного — сам прокси жив, режет сеть клиента (фаервол или DPI).
• Подключается, но не грузит — TCP-сессия есть, но прокси не достаёт до внутренних серверов Telegram.

Этот один вопрос экономит половину времени. Дальше идём по шагам.

Шаг 1. Жив ли процесс и слушает ли порт

Самое частое и самое обидное: сервис просто упал после обновления или ребута, а автозапуск забыли включить. Проверяем состояние юнита и слушающий сокет.

# официальный MTProxy
systemctl status mtproxy
journalctl -u mtproxy -n 50 --no-pager

# mtg
systemctl status mtg
journalctl -u mtg -n 50 --no-pager

# слушает ли порт (замените 443 на свой)
ss -tlnp | grep 443

Если в выводе ss нет строки с вашим портом и именем процесса — прокси не запущен или упал. Смотрите последние строки журнала: там будет причина (не найден конфиг, занят порт, ошибка secret). Фикс — systemctl enable --now mtproxy и устранение ошибки из лога.

Шаг 2. Открыт ли порт снаружи

Порт слушается локально, но клиенты не подключаются — классика. Между вашим процессом и интернетом стоит как минимум один фаервол, а часто и два: ufw/iptables на самом VPS и группа безопасности (security group) в панели хостера.

# что открыто локальным фаерволом
ufw status verbose
iptables -L -n -v | grep 443

# проверка снаружи (с другой машины или телефона в режиме модема)
nc -vz ВАШ_IP 443
# или
telnet ВАШ_IP 443

Если локально ss показывает порт, а nc снаружи выдаёт «connection refused» или таймаут — трафик режется по пути. Откройте порт: ufw allow 443/tcp, а также проверьте firewall/security-group в панели провайдера (Timeweb, Hetzner, Selectel и т.п.) — про этот второй слой забывают чаще всего.

Шаг 3. Правильный ли secret и его префикс

Если клиент честно пишет «неверный ключ» или молча отваливается сразу после попытки — почти наверняка проблема в secret. Требования жёсткие:

• Тело secret — ровно 32 hex-символа (16 байт), без пробелов и лишних символов.
• Префикс dd — простая обфускация (padded intermediate).
• Префикс ee — режим fake-TLS: после ee идут 16 байт ключа в hex, а затем hex-представление домена-маски.
• Secret на сервере обязан совпадать с secret в ссылке t.me/proxy?..., которую вы раздали.

Для mtg удобнее всего не собирать ссылку руками, а попросить сам прокси её отдать — так исключаются опечатки:

# mtg сгенерирует корректные tg://proxy и QR из вашего конфига
mtg access /etc/mtg.toml

Частая ловушка fake-TLS: домен, зашитый в ee-секрет, должен совпадать с доменом-маской, заданным при запуске прокси. Если раздали secret с одним доменом, а сервис поднят под другой — хендшейк не сложится.

Шаг 4. «Подключается, но не грузит» — конфиг и исходящий трафик

Самый коварный симптом. Значок соединения загорается, но чаты пустые. TCP-сессия до вашего сервера есть, а вот от сервера до Telegram — нет. Две главные причины.

Устаревший proxy-multi.conf (для официального MTProxy). Telegram периодически меняет адреса внутренних дата-центров. Если файл старый, прокси стучится в никуда.

# обновляем список серверов Telegram
curl -s https://core.telegram.org/getProxyConfig -o /opt/MTProxy/objs/bin/proxy-multi.conf
systemctl restart mtproxy

Заблокирован исходящий трафик. Убедитесь, что сервер сам достаёт до Telegram, и что фаервол не режет OUTPUT.

# проверяем связность сервера с сетью Telegram
curl -sSI https://core.telegram.org/ | head -n 1
# у mtg — полная самопроверка связности и фронтинга
mtg doctor /etc/mtg.toml

Команда mtg doctor отдельно проверит доступность фронтинг-домена, совпадение SNI и DNS, а заодно измерит рассинхрон времени — переходим к следующему пункту.

Шаг 5. Время сервера и NTP

Недооценённая причина. MTProto и особенно fake-TLS чувствительны к рассинхрону часов: во fake-TLS есть окно допустимого расхождения времени (в mtg по умолчанию порядка нескольких секунд), и если часы VPS «уплыли», прокси начинает отклонять клиентские хендшейки. Внешне это выглядит как «подключается через раз» или «не подключается вовсе».

# смотрим синхронизацию времени
timedatectl status
# должно быть: System clock synchronized: yes, NTP service: active

# если нет — включаем
timedatectl set-ntp true
systemctl restart systemd-timesyncd

После синхронизации перезапустите прокси. Если mtg doctor раньше жаловался на «time skew» — сообщение должно исчезнуть.

Шаг 6. Блокировка IP провайдером и DPI

Если прокси жив, порт открыт, secret верный, а с мобильного всё летает, но у клиента из конкретной сети — глухо, значит соединение режется на стороне провайдера. Два сценария:

• IP сервера попал под блокировку. Проверьте с проблемной сети доступность порта (nc -vz IP 443). Если таймаут именно оттуда — адрес, скорее всего, заблокирован. Решение — сменить IP у хостера или поднять прокси на новом адресе.
• DPI распознаёт трафик прокси. Простая dd-обфускация в агрессивных сетях уже опознаётся. Лечится переходом на fake-TLS (ee-секрет) на порту 443 под видом обычного HTTPS к популярному домену — так трафик сливается с массой легитимного.

По нашему опыту связка «fake-TLS + 443 + резервный IP» переживает большинство волн блокировок, тогда как «голый» MTProto отваливается первым. Тем, кому Telegram-прокси уже мало и нужен полноценный доступ к сети, стоит смотреть в сторону связки протоколов — мы разбирали её в материале про OpenConnect и VLESS для устойчивого обхода блокировок.

Шаг 7. MTU и обрывы на «тяжёлом» контенте

Отдельный редкий, но неприятный случай: текст ходит, а картинки, файлы и видео обрываются, соединение «залипает». Похоже на проблему MTU — особенно если сервер за туннелем (WireGuard, GRE, PPPoE), где эффективный MTU меньше стандартных 1500.

# подбираем максимальный размер пакета без фрагментации
ping -M do -s 1472 core.telegram.org
# если пакеты теряются — уменьшайте 1472 (шаг ~10), пока не пойдут

Найдя рабочий размер, зафиксируйте MTU на интерфейсе (для туннеля обычно 1420 для WireGuard). Симптом «мелочь грузится, крупное рвётся» — почти всегда про фрагментацию.

Шаг 8. Версия прокси и клиента

Если всё вышеперечисленное чисто, а проблема массовая и началась «вдруг» — проверьте версии. Устаревший бинарник mtg или официального MTProxy может не знать актуальной инфраструктуры Telegram или не поддерживать свежий режим маскировки. Аналогично устаревший клиент Telegram иногда ломает работу с fake-TLS после обновлений протокола.

# версия mtg
mtg --version

# обновление официального MTProxy — пересборка из исходников
cd /opt/MTProxy && git pull && make && systemctl restart mtproxy

Обновите прокси до актуального релиза, попросите пользователей обновить приложение — и перепроверьте.

Таблица: симптом → причина → решение

Мини-стат: жив ли прокси и сколько на нём клиентов

Полезно уметь одним взглядом оценить нагрузку. У официального MTProxy при запуске с флагом --http-stats есть локальная статистика (доступна только с loopback и приватных сетей, не с публичного IP):

curl -s localhost:8888/stats

А число активных TCP-соединений на порту прокси быстро считается так:

ss -tn state established '( sport = :443 )' | wc -l

Если счётчик держится около нуля при живом процессе и открытом порте — клиенты не доходят, возвращайтесь к шагам 2, 3 и 6.

Частые вопросы

Прокси подключается, но Telegram не грузит сообщения. В чём дело?

Чаще всего сервер держит TCP-соединение, но не может достучаться до внутренних дата-центров Telegram: устарел proxy-multi.conf (для MTProxy) или заблокирован исходящий трафик к подсетям Telegram. Обновите конфиг из getProxyConfig, проверьте исходящие правила фаервола и время сервера — при рассинхронизации часов MTProto-хендшейк отклоняется.

Как понять, что порт прокси вообще открыт снаружи?

С самого сервера проверьте, что процесс слушает порт: ss -tlnp | grep 443. Затем с внешней машины сделайте telnet или nc до IP и порта. Если локально порт слушается, а снаружи нет — виноват фаервол (ufw/iptables), группа безопасности у хостера или NAT.

Клиент пишет «неверный secret» — что проверить?

Secret должен быть ровно 32 hex-символа (16 байт). Для fake-TLS используется префикс ee и hex домена-маски, для простой обфускации — префикс dd. Убедитесь, что secret в ссылке t.me/proxy совпадает с тем, что задан на сервере, и что домен в ee-секрете совпадает с параметром запуска.

Работает через мобильный интернет, но не работает в офисной сети. Почему?

Значит сам прокси жив, а офисная сеть режет соединение: корпоративный фаервол закрывает нестандартный порт либо DPI-система провайдера распознаёт и блокирует трафик. Помогает fake-TLS на 443 порту под видом HTTPS и смена IP, если адрес попал под блокировку.

Как быстро понять, жив ли прокси на mtg?

У mtg есть встроенная диагностика: mtg doctor config.toml проверяет связность, домен фронтинга, совпадение SNI и рассинхрон времени. Команда mtg access config.toml выдаёт готовые ссылки tg://proxy и QR-код. Если doctor жалуется на time skew — синхронизируйте часы через NTP.

Помогает ли перезапуск и обновление прокси?

Часто да. Устаревшая версия mtg или официального MTProxy может не знать актуальных серверов Telegram или не поддерживать нужный режим маскировки. Обновите бинарник до последней версии, перезапустите сервис и обновите proxy-multi.conf — это закрывает значительную долю жалоб «вчера работало, сегодня нет».

Заключение

«Прокси не подключается» — это не одна проблема, а восемь разных, у каждой свой характерный симптом и своя команда для проверки. Начните с главного вопроса «работает ли с мобильного?», затем идите по шагам: процесс и порт → фаервол → secret → конфиг и исходящий трафик → время → DPI и IP → MTU → версии. В 90% случаев причина находится за пять минут. Если же прокси нужен как надёжный корпоративный сервис, а не разовая самоделка, — это ровно та рутина, которую мы в АйТи Фреш держим на потоке.