Как установить MTProxy на свой сервер и не превратить VPS в тыкву

Я много раз видел одну и ту же картину. Человек берет VPS, находит в поиске «волшебный one-click скрипт», запускает чужой bash из сомнительного репозитория, получает красивую ссылку для Telegram и считает задачу закрытой. Через пару недель прокси умирает, конфиг устаревает, порт занят каким-нибудь старым nginx, а владелец сервера смотрит на логи с лицом человека, который только что купил себе проблемы по подписке.

Поэтому нормальный путь выглядит скучнее, но работает лучше. Берем официальный исходный код, собираем бинарник сами, кладем служебные файлы в предсказуемые каталоги, запускаем сервис через systemd и отдельно настраиваем ежедневное обновление конфигурации Telegram. Без цирка, без магии и без мифа о том, что любой «автоинсталлер» делает жизнь проще. Обычно делает только хуже.

Ниже даю универсальную инструкцию для своего сервера. Основной сценарий рассчитан на Debian и Ubuntu, потому что именно такие системы чаще всего живут на VPS. Если у вас CentOS, AlmaLinux или Rocky, логика остается той же, меняются только пакеты и местами привычки администратора.

Что MTProxy умеет, а чего от него ждать не надо

MTProxy нужен не для того, чтобы превратить сервер в шпионский кинотеатр. MTProxy решает более узкую задачу: помогает клиенту Telegram подключаться к сети Telegram через собственный прокси. Для личного использования, для семьи, для небольшой команды такой вариант удобен. Контроль над сервером у вас, чужой публичный прокси не нужен, внезапный бан чужого узла не ломает весь сценарий.

Но не надо приписывать MTProxy свойства, которых у него нет. MTProxy не заменяет VPN, не делает весь трафик анонимным и не превращает обычный VPS в артефакт невидимости. Это специализированный транспорт для Telegram. Удобный, полезный, местами капризный, но все же не священный грааль сетевой свободы.

Для установки нужен обычный VPS с публичным IPv4, root или sudo, свободный внешний TCP-порт, чаще всего 443, и система с systemd. Если порт 443 уже занят веб-сервером, берите другой. Пытаться посадить два сервиса на один и тот же порт, а потом удивляться, почему все развалилось, не лучший жанр системного администрирования.

Базовая схема установки

Я обычно советую не растягивать процесс на двадцать мелких команд, а сразу подготовить один понятный сценарий. Ниже именно такой вариант. Скрипт ставит зависимости, создает системного пользователя, забирает официальный исходный код, собирает бинарник, скачивает актуальные файлы Telegram, создает systemd-сервис, добавляет таймер для ежедневного обновления конфигурации и в конце печатает готовые ссылки подключения.

Перед запуском проверьте только две вещи. Первая: выбранный порт свободен (443, если занят выберите любой другой свободный, например 4433). Вторая: сервер действительно имеет публичный IP. Если VPS стоит за NAT, публичный адрес придется подставить вручную. Серверы тоже любят сюрпризы, особенно когда их арендуют в дешевых облаках.

sudo -i
 
 PORT=443
 WORKERS=1
 
 cat >/root/install-mtproxy.sh <<'EOF'
 #!/usr/bin/env bash
 set -euo pipefail
 
 PORT="${PORT:-443}"
 WORKERS="${WORKERS:-1}"
 
 INSTALL_DIR="/opt/MTProxy"
 CONF_DIR="/etc/mtproxy"
 STATE_DIR="/var/lib/mtproxy"
 BIN="/usr/local/bin/mtproto-proxy"
 DEFAULTS_FILE="/etc/default/mtproxy"
 SERVICE_FILE="/etc/systemd/system/mtproxy.service"
 UPDATE_SCRIPT="/usr/local/sbin/mtproxy-update-config"
 UPDATE_SERVICE="/etc/systemd/system/mtproxy-update.service"
 UPDATE_TIMER="/etc/systemd/system/mtproxy-update.timer"
 
 echo "[1/10] Проверяю, что порт ${PORT} свободен"
 if ss -ltn "( sport = :${PORT} )" | grep -q ":${PORT}"; then
   echo "ОШИБКА: порт ${PORT} уже занят"
   ss -ltnp | grep ":${PORT}" || true
   exit 1
 fi
 
 echo "[2/10] Ставлю пакеты"
 apt update
 apt install -y git curl xxd openssl ca-certificates build-essential libssl-dev zlib1g-dev
 
 echo "[3/10] Создаю системного пользователя mtproxy"
 if ! id mtproxy >/dev/null 2>&1; then
   useradd --system --home "${STATE_DIR}" --create-home --shell /usr/sbin/nologin mtproxy
 fi
 
 echo "[4/10] Качаю исходники"
 rm -rf "${INSTALL_DIR}"
 git clone https://github.com/TelegramMessenger/MTProxy "${INSTALL_DIR}"
 
 echo "[5/10] Собираю MTProxy"
 make -C "${INSTALL_DIR}"
 install -m 0755 "${INSTALL_DIR}/objs/bin/mtproto-proxy" "${BIN}"
 
 echo "[6/10] Готовлю каталоги и конфиги"
 install -d -m 0750 -o root -g mtproxy "${CONF_DIR}"
 install -d -m 0750 -o mtproxy -g mtproxy "${STATE_DIR}"
 
 curl -fsSL https://core.telegram.org/getProxySecret -o "${CONF_DIR}/proxy-secret"
 curl -fsSL https://core.telegram.org/getProxyConfig -o "${CONF_DIR}/proxy-multi.conf"
 
 SECRET="$(openssl rand -hex 16)"
 printf '%sn' "${SECRET}" > "${CONF_DIR}/user-secret"
 
 chown root:mtproxy "${CONF_DIR}/proxy-secret" "${CONF_DIR}/proxy-multi.conf" "${CONF_DIR}/user-secret"
 chmod 0640 "${CONF_DIR}/proxy-secret" "${CONF_DIR}/proxy-multi.conf" "${CONF_DIR}/user-secret"
 
 echo "[7/10] Пишу настройки сервиса"
 cat > "${DEFAULTS_FILE}" <<CFG
 PORT=${PORT}
 WORKERS=${WORKERS}
 CFG
 
 cat > "${SERVICE_FILE}" <<'UNIT'
 [Unit]
 Description=Telegram MTProxy
 After=network-online.target
 Wants=network-online.target
 
 [Service]
 Type=simple
 EnvironmentFile=/etc/default/mtproxy
 ExecStart=/bin/sh -lc '/usr/local/bin/mtproto-proxy -u mtproxy -p 8888 -H "$PORT" -S "$(cat /etc/mtproxy/user-secret)" --aes-pwd /etc/mtproxy/proxy-secret /etc/mtproxy/proxy-multi.conf -M "$WORKERS"'
 Restart=on-failure
 RestartSec=3
 LimitNOFILE=65535
 
 [Install]
 WantedBy=multi-user.target
 UNIT
 
 echo "[8/10] Добавляю ежедневное обновление proxy-multi.conf"
 cat > "${UPDATE_SCRIPT}" <<'UPD'
 #!/bin/sh
 set -eu
 
 TMP="$(mktemp)"
 trap 'rm -f "$TMP"' EXIT
 
 curl -fsSL https://core.telegram.org/getProxyConfig -o "$TMP"
 install -o root -g mtproxy -m 0640 "$TMP" /etc/mtproxy/proxy-multi.conf
 systemctl try-restart mtproxy.service
 UPD
 
 chmod 0755 "${UPDATE_SCRIPT}"
 
 cat > "${UPDATE_SERVICE}" <<'USVC'
 [Unit]
 Description=Refresh Telegram MTProxy config
 
 [Service]
 Type=oneshot
 ExecStart=/usr/local/sbin/mtproxy-update-config
 USVC
 
 cat > "${UPDATE_TIMER}" <<'UTMR'
 [Unit]
 Description=Daily refresh for Telegram MTProxy config
 
 [Timer]
 OnCalendar=daily
 RandomizedDelaySec=30m
 Persistent=true
 
 [Install]
 WantedBy=timers.target
 UTMR
 
 echo "[9/10] Включаю сервисы"
 systemctl daemon-reload
 systemctl enable --now mtproxy.service
 systemctl enable --now mtproxy-update.timer
 
 echo "[10/10] Готовлю ссылки подключения"
 PUBLIC_IP="$(curl -4fsSL https://api.ipify.org || true)"
 if [ -z "${PUBLIC_IP}" ]; then
   PUBLIC_IP="$(hostname -I | awk '{print $1}')"
 fi
 
 CLIENT_SECRET="dd${SECRET}"
 
 echo
 echo "========== ГОТОВО =========="
 echo "Статус сервиса:"
 systemctl --no-pager --full status mtproxy.service || true
 echo
 echo "Секрет сервера:"
 echo "${SECRET}"
 echo
 echo "Ссылка tg://"
 echo "tg://proxy?server=${PUBLIC_IP}&port=${PORT}&secret=${CLIENT_SECRET}"
 echo
 echo "Ссылка https://t.me/proxy"
 echo "https://t.me/proxy?server=${PUBLIC_IP}&port=${PORT}&secret=${CLIENT_SECRET}"
 echo
 echo "Локальная статистика:"
 echo "curl -s http://127.0.0.1:8888/stats"
 EOF
 
 chmod +x /root/install-mtproxy.sh
 PORT="$PORT" WORKERS="$WORKERS" /root/install-mtproxy.sh

После выполнения скрипта вы получите две ссылки. Обе рабочие, просто одна в формате tg://, вторая через t.me/proxy. Обратите внимание на префикс dd перед клиентским секретом. Такая запись включает random padding на стороне клиента и помогает маскировать характер трафика лучше, чем голый секрет без префикса.

Внутри сервиса используется обычный секрет, без dd. На стороне клиента, в ссылке подключения, уже идет вариант с префиксом. Ломают эту мелочь постоянно. Потом пишут, что «вроде работает, но как-то странно». Да, странно, когда копируют инструкцию по кускам.

Что сделать сразу после установки

Сам факт запущенного сервиса еще не означает, что пользователи смогут подключиться. Сервер может быть жив, а доступ снаружи убит firewall, правилами облака или забытым security group в панели провайдера. Поэтому после установки я всегда прохожу короткий чек-лист.

• Откройте внешний TCP-порт на сервере и в панели облака.
• Проверьте, что сервис слушает нужный порт.
• Убедитесь, что локальный порт статистики доступен только с loopback.
• Сохраните сгенерированный секрет в безопасное место, а не в заметки, которые синхронизируются куда попало.

Для UFW команда выглядит так:

ufw allow 443/tcp
 ufw status

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

firewall-cmd --permanent --add-port=443/tcp
 firewall-cmd --reload
 firewall-cmd --list-ports

Проверка сервиса и порта выглядит так:

systemctl status mtproxy --no-pager -l
 ss -ltnp | grep ':443'
 curl -s http://127.0.0.1:8888/stats

Если статистика открывается локально, а Telegram все равно не подключается, обычно причина скучная. Либо закрыт внешний порт, либо у сервера кривой публичный IP, либо на VPS часы ушли в сторону, либо кто-то решил, что nginx важнее, и уже занял 443. Серверы редко ломаются загадочно. Люди ломают предсказуемо.

Типовые грабли и нормальные способы не наступать на них

Самая частая ошибка, которую я вижу, это любовь к «удобным» Docker-образам из старых статей. Исторически такой способ был популярен, но в официальном README образ прямо отмечен как устаревший. Поэтому базовый и самый вменяемый путь сейчас остается прежним: собрать официальный бинарник и запускать как обычный systemd-сервис. Чуть менее модно, зато работает без театра.

Вторая типовая ошибка связана с обновлением proxy-multi.conf. Telegram меняет конфигурацию не по вашему расписанию и не под настроение автора блога. Именно поэтому я включил отдельный systemd timer. Один раз настроили и забыли. Ручной режим тут плох по простой причине: ручной режим держится ровно до первого дня, когда вы заняты чем-то еще.

Третья ошибка совсем бытовая. Люди публикуют ссылку прокси где попало, а потом удивляются трафику, нагрузке и странным подключениям. Если прокси личный, раздавайте ссылку только тем, кому реально доверяете. Если нужен публичный сценарий, тогда уже стоит отдельно думать про мониторинг, ограничения, резервирование и дополнительные механизмы управления. Для домашнего или редакционного использования базовой схемы выше обычно хватает с запасом.

Если хотите регистрировать прокси через MTProxybot и использовать tag, можно добавить параметр -P <proxy_tag> в ExecStart вашего systemd-сервиса. Но для обычного частного прокси критичнее не tag, а нормальный аптайм, открытый порт и актуальная конфигурация. Остальное уже из серии «у меня есть свободный вечер и лишнее желание усложнить себе жизнь».

Для тех, кто любит держать все под рукой, оставлю и официальный исходник проекта: TelegramMessenger/MTProxy. Если через полгода захотите перепроверить параметры запуска, смотреть лучше туда, а не в случайный гайд с 2019 года, который до сих пор рассказывает, как славно живется миру в эпоху древнего Docker-образа.

Короткий итог

Рабочий MTProxy на своем сервере поднимается без особой драмы. Нужен свежий VPS, свободный порт, официальный репозиторий, systemd и одна здравая привычка: не лениться обновлять конфигурацию Telegram автоматически. Весь остальной шум обычно создают либо устаревшие инструкции, либо желание сэкономить пять минут и потом потерять полдня.

Если нужен практический ориентир в одну фразу, он такой. Не запускайте мутные one-click скрипты, не надейтесь на старый Docker, не забывайте про firewall и daily update, и тогда MTProxy будет просто работать. А в мире серверов «просто работает» уже звучит почти как роскошь.