Оптимизация MTProxy: настройка сервера под высокие нагрузки

Базовый запуск MTProxy в Docker из инструкции работает. Но если к вашему прокси подключаются сотни или тысячи пользователей, вы начнёте замечать симптомы: медленная загрузка медиа, задержки, разрывы соединений. Это не баг MTProxy — это просто то, что случается с любым сервером при достижении системных лимитов.

Эта статья — полный гайд по тюнингу. Применяйте по мере роста нагрузки.

Диагностика: определяем узкое место

Прежде чем что-то настраивать, найдите причину проблемы.

Базовые команды для диагностики:

# Статистика контейнера в реальном времени
docker stats mtproxy

# Состояние TCP-соединений
ss -s

# Количество установленных соединений
ss -tn state established | wc -l

# Количество TIME-WAIT (должно быть < 10000)
ss -tn state time-wait | wc -l

# Логи ошибок
docker logs --tail 100 mtproxy 2>&1 | grep -i error

Настройка WORKERS

WORKERS — количество рабочих процессов MTProxy. Официальная реализация (C) очень эффективна и обслуживает около 60 000 соединений на воркер.

Изменение WORKERS в Docker:

docker stop mtproxy && docker rm mtproxy

docker run -d \
  --name mtproxy \
  --restart always \
  -p 443:443 \
  -e SECRET="ВАШ_СЕКРЕТ" \
  -e WORKERS=4 \
  -e TAG="ВАШ_TAG" \
  -v proxy-config:/data \
  telegrammessenger/proxy:latest

Оптимизация ядра Linux (sysctl)

MTProxy открывает большое количество TCP-соединений. Linux по умолчанию ограничивает их. Оптимизируйте /etc/sysctl.conf:

# Количество открытых файловых дескрипторов
fs.file-max = 1000000

# Размер очереди входящих соединений
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192

# Управление TIME-WAIT соединениями
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# Диапазон локальных портов
net.ipv4.ip_local_port_range = 1024 65000

# Буферы TCP для высокого трафика
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728

# Алгоритм управления перегрузкой (BBR, ядро 4.9+)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Применить изменения:

sysctl -p

Что делает каждый параметр

tcp_max_syn_backlog = 8192 — максимальный размер очереди SYN-пакетов. При высокой нагрузке новые подключения теряются, если очередь переполнена.

tcp_tw_reuse = 1 — разрешает повторное использование TIME-WAIT сокетов. Снижает накопление «зависших» соединений.

tcp_fin_timeout = 15 — сокращает время ожидания закрытия соединения с 60 секунд до 15. Освобождает ресурсы быстрее.

BBR (Bottleneck Bandwidth and RTT) — алгоритм управления перегрузкой от Google. Вместо реактивного поведения (снижать скорость после потери пакета) BBR активно зондирует полосу пропускания. Особенно эффективен на каналах с переменными потерями — что типично для пользователей из ограниченных регионов.

Проверить, применился ли BBR:

sysctl net.ipv4.tcp_congestion_control
# Должно вернуть: net.ipv4.tcp_congestion_control = bbr

Лимиты файловых дескрипторов

Каждое TCP-соединение в Linux требует открытый файловый дескриптор. По умолчанию лимит — 1024. Для тысяч соединений нужно его поднять.

Системный лимит (добавьте в /etc/security/limits.conf):

* soft nofile 1000000
* hard nofile 1000000
root soft nofile 1000000
root hard nofile 1000000

Для Docker-контейнера добавьте флаг в команду запуска:

docker run -d \
  --name mtproxy \
  --restart always \
  -p 443:443 \
  --ulimit nofile=1000000:1000000 \
  -e SECRET="ВАШ_СЕКРЕТ" \
  -e WORKERS=2 \
  -v proxy-config:/data \
  telegrammessenger/proxy:latest

Проверить текущий лимит процесса:

docker exec mtproxy cat /proc/1/limits | grep "open files"

Мониторинг нагрузки

Для публичного прокси рекомендуется базовый мониторинг. Простейший вариант — cron-задача:

# Каждые 5 минут записывать статистику в файл
*/5 * * * * echo "$(date): connections=$(ss -tn state established | wc -l), tw=$(ss -tn state time-wait | wc -l)" >> /var/log/mtproxy-stats.log

Для более детального мониторинга рассмотрите mtg (Go-реализация MTProxy) — она имеет встроенные метрики в формате Prometheus, которые можно подключить к Grafana.

Обновление конфигурации Telegram

Список IP-адресов серверов Telegram периодически меняется. MTProxy нужен актуальный конфиг. В официальном Docker-образе это обновляется автоматически. При нативной установке обновляйте вручную:

curl -s https://core.telegram.org/getProxyConfig -o /path/to/proxy-secret
curl -s https://core.telegram.org/getProxyMultiConfig -o /path/to/proxy-multi-secret
systemctl restart mtproxy

Добавьте в cron (раз в сутки):

0 4 * * * curl -s https://core.telegram.org/getProxyConfig -o /root/MTProxy/proxy-secret && curl -s https://core.telegram.org/getProxyMultiConfig -o /root/MTProxy/proxy-multi-secret && systemctl restart mtproxy

Типичные конфигурации по размеру сервера

FAQ

Сколько WORKERS нужно? Правило: 1 воркер = 1 ядро CPU. На слабых серверах иногда помогают 2 воркера при 1 ядре.

Когда оптимизировать sysctl? Когда в логах появляются "too many open files" или ss -s показывает тысячи TIME-WAIT соединений.

Что такое BBR? Алгоритм управления перегрузкой TCP от Google. Улучшает пропускную способность в условиях потерь пакетов.

Как понять, что прокси перегружен? docker stats показывает CPU 80-100%; пользователи жалуются на медленную загрузку; ss -s показывает тысячи CLOSE-WAIT.

Настроили оптимизацию? Изучите, как монетизировать прокси через Promoted Channels и как добавить поддержку IPv6 для большей устойчивости к блокировкам.

Готовые рабочие прокси без настройки, обновляются каждые 60 секунд.