MTProto-прокси для Telegram на Linux обычно вспоминают в двух сценариях. Первый - нужен собственный узел вместо чужих публичных прокси, которым никто не доверяет. Второй - Telegram Desktop или мобильный клиент должны ходить через отдельную точку, не трогая остальной трафик системы. Оба сценария рабочие, но вокруг MTProto накопилось слишком много лишних ожиданий. MTProto не превращает VPS в VPN, не анонимизирует весь трафик и не решает все сетевые проблемы одним щелчком.
Нормальный путь здесь довольно скучный. Берём официальный код, собираем бинарник, запускаем службу через systemd, отдельно обновляем служебные файлы Telegram и только потом подключаем клиент. В коротком разборе очень точно сформулирована главная мысль: MTProxy хорош как специализированный транспорт именно для Telegram, но не как универсальная палочка-выручалочка.
Материал описывает штатные возможности Telegram и администрирование собственного Linux-сервера. Перед запуском проверьте требования закона в вашей юрисдикции, правила провайдера, корпоративную политику безопасности и договор с хостингом. Не используйте MTProto-прокси для обхода блокировок, сетевых запретов, ограничений работодателя и любых иных мер, которые вы не вправе обходить.
Что такое MTProto-прокси и где у него границы
MTProto-прокси нужен только для Telegram. Клиент мессенджера подключается к вашему серверу, а сервер уже работает с инфраструктурой Telegram. Никакой системной маршрутизации для браузера, игр, почты или других программ тут нет. По этой причине MTProto часто удобнее VPN в узком сценарии, когда нужен только Telegram, но бесполезнее VPN во всех остальных сценариях.
Telegram сам поддерживает прокси во всех основных клиентах. Путь для Telegram Desktop и мобильных приложений описан в официальной документации. А команды сборки, запуск, пример systemd и рекомендация периодически обновлять конфигурацию лежат в официальном README.
Что понадобится для установки MTProto на Linux
| Что нужно | Минимум | Зачем нужно |
|---|---|---|
| Сервер | VPS с Debian 12, Ubuntu 22.04 или 24.04 | На этих системах сценарий ниже работает предсказуемо |
| Сеть | Публичный IPv4 и открытый TCP-порт | Клиенты Telegram должны видеть сервер снаружи |
| Доступ | root или sudo | Нужен для установки пакетов, сервиса и firewall |
| Ресурсы | 1 vCPU, 512 МБ ОЗУ | Для личного сервера или небольшой команды обычно хватает |
| Порт | 443/tcp или любой другой свободный | 443 часто удобен, но не обязателен |
Если 443 уже занят nginx, Caddy или другим сервисом, не надо устраивать борьбу двух процессов за один порт. Возьмите другой внешний порт и подставьте его дальше в команды и ссылку подключения. Если VPS стоит за NAT, заранее выясните внешний адрес, который реально виден из интернета.
Почему лучше не брать случайные one-click скрипты
Установка MTProto через первый попавшийся инсталлятор кажется соблазнительной ровно до первой поломки. Потом выясняется, что скрипт раскидал файлы по непонятным каталогам, добавил свои таймеры, открыл лишние порты и поставил бинарник, происхождение которого вы не проверяли. Для сервиса, который будет сидеть на публичном адресе, такой подход слишком беспечный. Здесь разумнее один раз собрать всё руками и потом спокойно поддерживать.
Пошаговая установка MTProto-прокси на Debian и Ubuntu
Ниже будет сценарий для Debian и Ubuntu. Для RHEL-подобных дистрибутивов логика та же, меняются пакеты и привычные команды администрирования.
Шаг 1. Обновляем пакеты и ставим зависимости
sudo apt update
sudo apt install -y git curl build-essential libssl-dev zlib1g-dev openssl ufw
Этого набора достаточно для сборки официального MTProxy из исходников и базовой настройки firewall.
Шаг 2. Создаём системные каталоги и пользователя
sudo adduser --system --group --home /opt/mtproxy mtproxy
sudo mkdir -p /opt/mtproxy/config
sudo mkdir -p /usr/local/src
sudo chown -R mtproxy:mtproxy /opt/mtproxy
Отдельный системный пользователь нужен не ради красоты. Так проще контролировать права и не держать сервис вечно под root.
Шаг 3. Забираем официальный код и собираем бинарник
cd /usr/local/src
sudo git clone https://github.com/TelegramMessenger/MTProxy.git
cd MTProxy
sudo make
sudo install -m 755 objs/bin/mtproto-proxy /opt/mtproxy/mtproto-proxy
После этого рабочий бинарник окажется в /opt/mtproxy/mtproto-proxy. Если сборка упала, чаще всего виноваты неустановленные зависимости или старая локальная копия репозитория.
Шаг 4. Скачиваем служебные файлы Telegram
sudo curl -fsSL https://core.telegram.org/getProxySecret -o /opt/mtproxy/config/proxy-secret
sudo curl -fsSL https://core.telegram.org/getProxyConfig -o /opt/mtproxy/config/proxy-multi.conf
sudo chown -R mtproxy:mtproxy /opt/mtproxy
proxy-secret и proxy-multi.conf нужны серверу для нормального обмена с инфраструктурой Telegram. В официальном README отдельно отмечено, что конфигурацию стоит периодически обновлять, потому что она может меняться.
Шаг 5. Генерируем пользовательский секрет
SECRET=$(openssl rand -hex 16)
echo "$SECRET"
Сохраните значение секрета в менеджер паролей или хотя бы в защищённые заметки. Сервер запускается с «сырым» секретом длиной 32 hex-символа. Для клиентской ссылки обычно используют префикс dd, а вот в параметре -S на стороне сервера префикс добавлять не нужно.
Шаг 6. Создаём systemd-сервис
Ниже пример для порта 443 и одного worker-процесса. Для домашнего сервера или маленькой команды одного worker обычно хватает. Бездумно увеличивать -M смысла нет.
sudo tee /etc/systemd/system/mtproxy.service >/dev/null <<EOF
[Unit]
Description=Telegram MTProxy
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
WorkingDirectory=/opt/mtproxy
ExecStart=/opt/mtproxy/mtproto-proxy -u mtproxy -p 8888 -H 443 -S $SECRET --aes-pwd /opt/mtproxy/config/proxy-secret /opt/mtproxy/config/proxy-multi.conf -M 1
Restart=on-failure
RestartSec=3
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
EOF
Параметры здесь важны. -H 443 задаёт внешний порт для клиентов. -p 8888 поднимает локальный служебный порт со статистикой, он доступен только на loopback. Ключ -u mtproxy нужен, чтобы процесс после старта сбросил привилегии.
Шаг 7. Открываем порт в firewall
sudo ufw allow 443/tcp
sudo ufw reload
Если используете не UFW, а nftables, firewalld или правила безопасности в панели облака, откройте тот же внешний TCP-порт и там. Очень частая ошибка выглядит так: сервис на сервере уже работает, а соединения снаружи не доходят из-за облачного security group.
Шаг 8. Запускаем сервис и проверяем статус
sudo systemctl daemon-reload
sudo systemctl enable --now mtproxy
sudo systemctl status mtproxy --no-pager
Если статус «active», идём дальше. Если нет, сразу открывайте журнал, а не начинайте наугад пересобирать всё заново.
sudo journalctl -u mtproxy -n 100 --no-pager
Шаг 9. Проверяем локальную статистику
curl -fsSL http://127.0.0.1:8888/stats
Если статистика открывается, значит бинарник жив, локальный порт поднят, и базовая конфигурация уже отрабатывает. Если здесь пусто или ошибка соединения, проблема почти всегда в самом сервисе, а не в Telegram-клиенте.
Как сделать автоматическое обновление конфигурации
Официальная документация советует периодически обновлять конфигурацию Telegram. На практике проще один раз завести systemd timer и забыть про ручной режим.
Шаг 10. Пишем маленький скрипт обновления
sudo tee /usr/local/bin/mtproxy-refresh.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
curl -fsSL https://core.telegram.org/getProxySecret -o /opt/mtproxy/config/proxy-secret.new
curl -fsSL https://core.telegram.org/getProxyConfig -o /opt/mtproxy/config/proxy-multi.conf.new
install -m 640 /opt/mtproxy/config/proxy-secret.new /opt/mtproxy/config/proxy-secret
install -m 640 /opt/mtproxy/config/proxy-multi.conf.new /opt/mtproxy/config/proxy-multi.conf
chown mtproxy:mtproxy /opt/mtproxy/config/proxy-secret /opt/mtproxy/config/proxy-multi.conf
rm -f /opt/mtproxy/config/proxy-secret.new /opt/mtproxy/config/proxy-multi.conf.new
systemctl restart mtproxy
EOF
sudo chmod +x /usr/local/bin/mtproxy-refresh.sh
Шаг 11. Добавляем service и timer
sudo tee /etc/systemd/system/mtproxy-refresh.service >/dev/null <<'EOF'
[Unit]
Description=Refresh Telegram MTProxy config
[Service]
Type=oneshot
ExecStart=/usr/local/bin/mtproxy-refresh.sh
EOF
sudo tee /etc/systemd/system/mtproxy-refresh.timer >/dev/null <<'EOF'
[Unit]
Description=Daily MTProxy config refresh
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now mtproxy-refresh.timer
sudo systemctl list-timers --all | grep mtproxy
Ежедневного обновления для большинства сценариев достаточно. Делать обновление каждые пять минут бессмысленно.
Как подключить Telegram Desktop на Linux к своему MTProto-прокси
Теперь нужен адрес сервера, внешний порт и секрет для клиента. Если сервер слушает 443, а ваш секрет хранится в переменной SECRET, ссылка выглядит так:
tg://proxy?server=ВАШ_ПУБЛИЧНЫЙ_IP&port=443&secret=ddВАШ_СЕКРЕТ
Здесь есть важная мелочь, на которой регулярно спотыкаются. Для клиентской ссылки используется dd перед секретом. Если забыть префикс, часть клиентов просто не подключится так, как вы ожидали.
В Telegram Desktop на Linux ручной путь обычно такой: «Настройки» → «Продвинутые настройки» → «Тип подключения» → «Использовать собственный прокси» → «Добавить прокси» → «MTProto». Дальше вводите IP сервера, внешний порт и секрет с префиксом dd. Второй вариант проще: отправляете себе ссылку tg://proxy?... в «Избранное» и открываете её прямо из клиента.
Нужен ли MTProxybot и что такое tag
В официальном README есть шаг с регистрацией прокси через @MTProxybot и добавлением параметра -P. Для личного сервера или небольшого частного использования обычно сначала поднимают базовую рабочую схему без лишних сущностей, а уже потом решают, нужен ли tag. Если вы сознательно регистрируете прокси через бот и получаете значение tag, добавьте его в ExecStart так:
-P ВАШ_PROXY_TAG
Если у вас нет ясной причины использовать tag, не усложняйте конфигурацию заранее.
Что чаще всего ломается и как чинить без шаманства
Порт уже занят
Проверьте, кто слушает 443.
sudo ss -ltnp | grep :443
Если там уже nginx, Apache или другой сервис, смените внешний порт у MTProxy. Не пытайтесь «как-нибудь совместить» два процесса на одном и том же TCP-порту без отдельного обратного прокси и без понимания, зачем вообще такая конструкция нужна.
Сервис стартует, но Telegram не подключается
Обычно виноват firewall, security group у провайдера или неверный внешний IP. Проверяйте не только UFW на самой машине, но и сетевую политику в панели облака.
Секрет введён верно, а клиент всё равно молчит
Проверьте, что в серверной команде стоит сырой секрет без dd, а в клиентской ссылке и при ручном вводе - секрет уже с dd. Путаница между этими двумя вариантами встречается постоянно.
После пары дней всё внезапно перестало работать
Проверьте актуальность proxy-secret и proxy-multi.conf. Именно поэтому выше есть timer на ежедневное обновление.
Сервис работает от root и вам от этого не по себе
Нормальная тревога. Привязка к порту ниже 1024 требует привилегий на старте, но дальше процесс должен сбросить их через -u mtproxy. Альтернатива - выбрать порт выше 1024 и совсем не касаться привилегированных портов.
Почему я бы не делал такую установку в Docker без особой нужды
Docker здесь не даёт принципиального выигрыша, а местами только добавляет новый слой непонятностей. Когда MTProxy стоит как обычный systemd-сервис, его проще читать, обновлять, логировать и чинить. Отдельный нюанс из официального README: официальный Docker-образ помечен как устаревший. Для production-схемы такой сигнал лучше не игнорировать.
Базовая гигиена после установки
- Не раздавайте публично адрес и секрет без необходимости.
- Не ставьте на тот же сервер случайные панели, боты и веб-морды неизвестного происхождения.
- Держите систему обновлённой и периодически проверяйте журналы
journalctl. - Если прокси нужен двум-трём людям, не превращайте сервер в публичную точку для всего интернета.
- Храните секрет вне заметок в открытом виде и не кидайте его в общие чаты.
Практический вывод
MTProto-прокси на Linux поднимается довольно прямолинейно, если не пытаться срезать углы. Самая здравая схема выглядит так: официальный исходный код, отдельный системный пользователь, systemd-сервис, ежедневное обновление служебных файлов Telegram, ручная проверка логов и только потом подключение клиента. Такой вариант не делает сервер «невидимым» и не заменяет VPN, зато даёт предсказуемую и понятную инфраструктуру именно для Telegram.
Если нужен аккуратный личный или командный узел без сюрпризов, этого достаточно. Если нужен публичный сервис, сложная маршрутизация, масштабирование, метрики, доступ для десятков и сотен пользователей, изоляция секретов и формальная юридическая модель, простой домашний MTProxy уже заканчивается и начинается отдельный инженерный проект.
FAQ
MTProto-прокси на Linux заменяет VPN?
Нет. MTProto обслуживает только Telegram. Остальные приложения через него не пойдут.
Обязательно ли использовать порт 443?
Нет. Подойдёт любой свободный внешний TCP-порт. Просто 443 часто удобен, если он не занят другим сервисом.
Нужно ли обновлять proxy-multi.conf вручную?
Лучше не вручную, а через timer. Telegram прямо рекомендует обновлять конфигурацию периодически.
Почему в ссылке для клиента секрет начинается с dd?
Потому что для клиентского подключения обычно используют секрет с префиксом dd. На стороне сервера в параметре -S остаётся исходный hex-секрет без префикса.
Можно ли поднять MTProto в Docker?
Технически можно, но для обычного личного сервера systemd-сервис проще сопровождать. К тому же официальный Docker-образ в README отмечен как устаревший.