Ставите MTProto на свой VPS, вбиваете адрес и секрет в Telegram, а клиент висит на «соединении» и через минуту отваливается. У меня половина таких кейсов заканчивалась сменой порта. Не протокола, не сервера, не провайдера. Меняешь 1080 на 443, и всё оживает.
Порт в прокси — это не косметика. Это то, как пакет выглядит для сети по пути к серверу, какой обработчик его встретит и попадёт ли он вообще в список разрешённого трафика. Дальше разберу по протоколам, с конкретными номерами и логикой выбора под задачу.
Портов 65535, а реально нужны пять-шесть
Диапазон 0-1023 привилегированный: чтобы слушать такой порт, процессу нужен root или capability CAP_NET_BIND_SERVICE. Всё выше 1023 доступно обычному пользователю, поэтому самодельные конфиги чаще всего живут в 1024-65535. Но выбирать порт по принципу «лишь бы свободный» — это как выбирать дверь в доме по цвету ручки.
Вокруг Telegram-прокси на практике крутятся семь номеров. Каждый со своим характером и своим типом сетей, где он проходит.
- 443: HTTPS, самый дружелюбный порт в любой сети
- 80: HTTP, второй по проходимости, но некоторые сети рвут на нём долгие соединения
- 8443: альтернативный HTTPS, спасает, когда 443 занят веб-сервером
- 8080 и 3128: классика корпоративных прокси, часто единственные открытые
- 5222: исторический XMPP-порт, MTProto его любил в ранние годы
- 1080: дефолт SOCKS5, самый узнаваемый и самый часто режемый
MTProto: 443 закрывает большинство задач
Официальный MTProto-прокси в Telegram — это сервер плюс секрет вида dd... или ee..., который клиент подставляет в рукshake. Порт здесь влияет на две вещи: пройдёт ли TCP-соединение через промежуточные узлы и насколько быстро установится сессия на мобильной сети.
443 выигрывает почти всегда. На уровне порта соединение неотличимо от обычного HTTPS: тот же TCP, тот же трёхсторонний рукшейк, та же манера держать keepalive. Корпоративные шлюзы, гостевые сети в отелях, captive portals в аэропортах и кафе пропускают 443 по умолчанию, потому что иначе у пользователя не откроется ни один сайт. Согласовывать что-то с админом не придётся.
80 держите как второй вариант. Он тоже почти везде открыт, но с нюансами: часть провайдеров и WiFi-контроллеров подрезает долгоживущие соединения именно на 80, а некоторые прокси-серверы в корпоративных сетях кешируют HTTP и начинают ломать нестандартный трафик. Для коротких сессий нормально, для постоянного подключения на телефоне я ставлю 443.
5222 сейчас выбирают редко. Порт ассоциируется с XMPP, в офисных сетях его часто закрывают превентивно, а на мобильных операторах он не даёт никаких преимуществ. Если он у вас работает, это не значит, что он будет работать у коллег с другим оператором.
8443 нужен в одном сценарии: на сервере уже стоит nginx или другой веб-сервер на 443, и вы не хотите двигать его с места. Тогда MTProto садится на 8443, а в клиенте просто указывается другой номер. Работает так же стабильно, просто чуть реже встречается в белых списках гостевых сетей.
SOCKS5: ставьте 443, а не 1080
1080 — это дефолт SOCKS5, и именно поэтому он проблемный. Номер настолько привязан к протоколу, что любой мало-мальски настроенный фильтр в офисе или общежитии смотрит на 1080 первым делом. В домашней сети на своём роутере он проживёт долго, в чужой инфраструктуре шансы заметно ниже. Как отмечают разработчики в обсуждениях на Reddit, именно порт 1080 чаще всего вызывает жалобы на обрывы в корпоративных сетях.
Я ставлю SOCKS5 на 443 или 8443 и не жалею. Telegram в настройках SOCKS5 спрашивает только адрес, порт и, опционально, логин с паролем, поэтому клиенту всё равно, какой номер вы выбрали. А вот сеть на пути видит привычный HTTPS-порт и ведёт себя спокойно. 1080 оставляю как резервный вход на случай, если 443 занят другим сервисом.
Про возможности протокола: SOCKS5 в клиенте Telegram работает по TCP, голосовые звонки через него, как правило, не идут или идут с артефактами. Если нужны звонки, смотрите в сторону MTProto, но и там стабильность зависит от нагрузки на узел. Для переписки, каналов и файлов SOCKS5 полностью достаточен.
3128 и 8080: порты, которые любят корпоративные сети
В компаниях, где интернет выдается через HTTP-прокси, наружу открыты 3128 или 8080, а иногда оба. Если вы поднимаете узел для команды и хотите, чтобы он работал прямо из офисной сети без заявки в IT, эти два номера стоит проверить в первую очередь. Схема простая: разворачиваете прокси на 3128, проверяете с рабочей машины, и только потом раздаёте конфиг коллегам.
Обратная сторона: 8080 часто занят чем-то ещё на том же сервере (панели, тестовые приложения, админки). Перед запуском проверьте, что порт свободен, иначе получите загадочное поведение, где половина запросов уходит не туда.
Как проверить порт до того, как лезть в настройки Telegram
Первое правило: проверяйте с того типа сети, где прокси будет жить. Открытый порт с вашего домашнего Wi-Fi ничего не говорит о том, что он открыт с мобильного интернета или из офиса. Я видел конфиги, которые идеально работали у автора и не поднимались ни у кого из пользователей. В технических блогах подчеркивают, что именно этот шаг спасает часы отладки.
Минимальная проверка — это TCP-коннект с чужой сети: nc -vz ваш-домен 443 или telnet в терминале. Отдаёт «succeeded» — значит порт слышно. Дальше полезно посмотреть, что отвечает сервис: curl -v https://ваш-домен:443/ покажет, отвечает ли что-то вообще или соединение висит. Для MTProto нормальная картина — это установленный TCP и молчание в ответ на HTTP-запрос, потому что сервер ждёт свой рукшейк.
И отдельно проверьте firewall на двух уровнях: локальный (ufw, firewalld, iptables) и облачный (security groups, файрвол панели хостера). Классическая история: порт открыт в ufw, а в security group провайдера закрыт, и вы полчаса ищете проблему в клиенте.
Номер порта не ускоряет прокси, ускоряет другое
Частый миф: «поставлю порт получше, и Telegram будет летать». Номер порта на скорость почти не влияет, если не считать редких случаев, когда провайдер шейпит конкретные диапазоны. Реально на отзывчивость влияют другие вещи.
География узла: сервер в Франкфурте при пользователях в Сибири даст заметный RTT, и вы это почувствуете на отправке фото. Нагрузка: shared-узел на 200 человек в час пик просядет независимо от порта. Железо и виртуализация: один vCPU на дешёвом VPS с MTProto на 300 соединений — это грустно. Настройки ядра: размер буферов, keepalive, TCP Fast Open. И тип секрета в MTProto: dd-вариант даёт дополнительный слой шифрования и чуть больше CPU, ee-вариант легче, но и трафик менее защищён от анализа.
Поэтому порядок действий такой: сначала нормальный узел и адекватная нагрузка, потом порт. Не наоборот.
Куда нажимать в Telegram
Мобильный клиент, iOS и Android: Настройки, далее Данные и память, далее Прокси, кнопка Добавить прокси. Выбираете тип MTProto или SOCKS5, вводите сервер, порт и, для MTProto, секрет. Включаете переключатель Use proxy, клиент переподключается сразу.
Десктоп: Настройки, Продвинутые настройки, Тип соединения, Прокси. Логика та же, поля те же. На macOS путь совпадает с десктопным клиентом.
WhatsApp и браузеры настраиваются иначе: в WhatsApp отдельного поля для прокси нет, он ходит через системные настройки сети. В браузерах прокси задаётся в настройках системы или в расширении, и там обычно указывают SOCKS5 с портом 1080 или 443. Для публичного Wi-Fi в кафе я советую держать готовый конфиг под рукой: поднял, проверил, работаешь.
Где брать конфиг и не собирать его руками
Своя инфраструктура — это хорошо, пока узлов два. Когда нужно пять гео под разные задачи, проще взять готовые из каталога. В каталоге прокси можно отфильтровать по протоколу, стране и типу подключения, и сразу видно, на каком порту живёт узел. Это экономит тот самый час, который обычно уходит на перебор 1080 против 443.
На что смотреть при выборе: протокол (MTProto для Telegram-клиента, SOCKS5 для универсальных задач), гео (ближе к вам — значит меньше задержка), выделенный узел против общего (для команды из десяти человек общий не стоит брать), лимиты по трафику. Если планируете парсинг каналов и мониторинг упоминаний для бизнеса, берите пул адресов, а не один: распределение запросов по нескольким узлам снижает риск упереться в лимиты и даёт ровные задержки.
Пять сценариев и пять разных ответов
Свой VPS для себя: MTProto на 443, nginx при необходимости переехал на 8443. Всё.
Команда в офисе с HTTP-прокси: пробуете 3128 и 8080, для Telegram-клиента ставите MTProto на тот, что открыт, остальное решаете через него.
Публичный Wi-Fi: 443 и только 443, потому что гостевые сети режут всё остальное.
Парсинг и мониторинг каналов: SOCKS5 на 443, пул из нескольких узлов в разных гео, ротация по расписанию. Порт здесь второстепенен, важнее равномерность нагрузки.
Несколько аккаунтов на разных устройствах: отдельный узел на аккаунт, порт 443 или 8443, чтобы не плодить одинаковые отпечатки сети.
Ошибки, из-за которых порт «не работает»
Сервис слушает 127.0.0.1 вместо 0.0.0.0. Порт открыт, снаружи недоступен, вы меняете номера и не понимаете, почему ничего не меняется. Проверяется одной строкой в конфиге или в выводе ss -tlnp.
Забытый секрет в MTProto. Без него клиент просто не установит соединение, а сообщение об ошибке будет максимально невнятным. Секрет должен совпадать символ в символ.
Docker с маппингом портов. Контейнер слушает 443 внутри, наружу проброшен 8443, в клиент вы вписали 443 и ждёте чуда. Смотрите на пару портов целиком, а не на один.
Занятый порт. 443 уже занят веб-сервером, прокси молча не стартует или падает через минуту. В логах это видно сразу, но в них никто не смотрит.
Проверка только из своей сети. О самом частом случае я уже сказал выше, но повторю, потому что он съедает больше всего времени.
Начните с одного действия: возьмите свой текущий конфиг, подставьте в клиент 443 вместо того номера, что стоит сейчас, и подключитесь с мобильного интернета, а не с домашнего Wi-Fi. Если соединение встало и держится хотя бы десять минут под нагрузкой, порт выбран правильно. Если нет, смотрите firewall и нагрузку на узел, а не перебирайте номера дальше. А когда надоест собирать конфиги вручную, загляните в каталог прокси: там узлы уже разложены по протоколам, гео и портам, и выбор занимает пару минут вместо вечера.