Установка и настройка telemt: практический гайд MTProto Proxy на TeleMT (Production Guide)
1. Что такое telemt и зачем он нужен
telemt — это современная альтернатива mtg и официальному MTProxy, написанная с упором на устойчивость к DPI и гибкость конфигурации. Ключевые особенности:
- Поддержка TLS-fronting: исходящий трафик выглядит как обычный HTTPS-запрос к легитимному домену.
- Встроенный HTTP API для получения ссылок и управления пользователями.
- Метрики (Prometheus-совместимые) на отдельном порту.
- Поддержка нескольких SNI-доменов одновременно для генерации множества
tg://ссылок. - Нативный бинарник — без зависимостей, без рантаймов.
2. Архитектура и ключевые понятия
Перед настройкой важно понять несколько концептов — иначе легко получить нерабочую конфигурацию.
public_host vs tls_domain
Это разные вещи с разными функциями:
|
Параметр |
Что делает |
Куда смотрит |
|---|---|---|
|
|
Имя сервера в генерируемых
ссылках |
Ваш домен / IP |
|
|
SNI-домен для fake TLS handshake (fronting) |
Внешний HTTPS-сайт, не ваш |
Критическая ошибка-ловушка: если поставить один и тот же домен в public_host и tls_domain, а этот домен указывает на тот же сервер, где работает telemt, — возникает петля самофронтинга. Прокси будет пытаться проксировать сам себя вместо внешнего upstream-хоста.
Схема работы TLS-fronting
Клиент → [443/tcp] → telemt
↓
TLS SNI = www.example-cdn.com ← это tls_domain
↓
Upstream: реальный HTTPS сайт (не ваш сервер)
Клиент видит трафик, направленный на легитимный HTTPS-домен. Интерпретация снаружи: «пользователь ходит на www.example-cdn.com».
3. Подготовка сервера
Требования
- Чистый VPS/DS с публичным IP
- Открытый порт (рекомендуется
7443/tcp, также подходит443/tcp) rootили возможность работы черезsudo- Ваш домен должен иметь A-запись, указывающую на IP сервера
Установка зависимостей
apt-get update && apt-get install -y wget curl jq openssl ufw
Проверка DNS
Убедитесь, что домен резолвится в нужный IP:
dig +short A proxy.example.com
# Ожидаемый вывод: 203.0.113.10 (ваш IP)
4. Установка бинарника
telemt распространяется как статически скомпилированный бинарник — никаких зависимостей от интерпретаторов или рантаймов.
cd /tmp
# Скачиваем и распаковываем последний релиз (автоопределение архитектуры и libc)
wget -qO- "https://github.com/telemt/telemt/releases/latest/download/telemt-$(uname -m)-linux-$(ldd --version 2>&1 | grep -iq musl && echo musl || echo gnu).tar.gz" | tar -xz
# Устанавливаем в /bin
install -m 0755 telemt /bin/telemt
# Проверяем
/bin/telemt --version
Версия: на момент написания стабильная ветка — 3.3.27/3.3.28. Для продакшн-узла нет смысла бежать за самым свежим релизом в первый день выхода. Проверяйте страницу релизов.
5. Конфигурация
Создаём директории и секрет
mkdir -p /etc/telemt /opt/telemt
# Генерируем случайный секрет (32 hex-символа)
SECRET_MAIN="$(openssl rand -hex 16)"
echo "Ваш секрет: $SECRET_MAIN"
# Сохраните это значение — оно понадобится при написании конфига
Полный конфиг /etc/telemt/telemt.toml
cat > /etc/telemt/telemt.toml <<'EOF'
[general]
use_middle_proxy = true
[general.links]
show = "*"
public_host = "proxy.example.com" # ← ваш домен для ссылок
public_port = 7443
[general.modes]
classic = false
secure = false
tls = true
[server]
port = 7443
metrics_port = 9090
metrics_whitelist = ["127.0.0.1/32", "::1/128"]
[server.api]
enabled = true
listen = "127.0.0.1:9091"
whitelist = ["127.0.0.1/32"]
[[server.listeners]]
ip = "0.0.0.0"
[censorship]
tls_domain = "www.microsoft.com" # ← внешний HTTPS-сайт, НЕ ваш домен
mask = true
tls_emulation = true
tls_front_dir = "/opt/telemt/tlsfront"
[access.users]
main = "ВСТАВЬТЕ_СЮДА_СЕКРЕТ"
EOF
После этого вставьте реальный секрет:
sed -i "s/ВСТАВЬТЕ_СЮДА_СЕКРЕТ/$SECRET_MAIN/" /etc/telemt/telemt.toml
Пояснения к параметрам
|
Параметр |
Значение |
Зачем |
|---|---|---|
|
|
|
Домен в
ссылках — ваш |
|
|
|
Порт в ссылках — совпадает с
|
|
|
|
Реальный порт прослушивания |
|
|
|
Fake SNI — чужой внешний HTTPS-сайт |
|
|
|
API только на loopback — не светим наружу |
|
|
|
Метрики тоже только для
|
|
|
|
Включить traffic masking |
|
|
|
Эмулировать TLS handshake целевого домена |
Выбор tls_domain
Правило простое и важнее конкретного имени:
- домен должен быть реальным HTTPS-сайтом
- он не должен указывать на ваш IP
- должен быть доступен из сетей клиентов
- должен выглядеть поведенчески правдоподобно для геолокации вашего сервера
Хорошие кандидаты для старта (протестируйте по одному):
tls_domain = "www.microsoft.com"
# или
tls_domain = "www.apple.com"
# или
tls_domain = "www.bing.com"
6. Systemd unit
# Создаём системного пользователя
useradd -d /opt/telemt -m -r -U telemt 2>/dev/null || true
chown -R telemt:telemt /etc/telemt /opt/telemt
# Unit-файл
cat > /etc/systemd/system/telemt.service <<'EOF'
[Unit]
Description=telemt MTProxy
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=telemt
Group=telemt
WorkingDirectory=/opt/telemt
ExecStart=/bin/telemt /etc/telemt/telemt.toml
Restart=on-failure
RestartSec=5
# Без этого получите "Too many open files" при нагрузке
LimitNOFILE=65536
# Нужен для прослушивания портов < 1024 (если используете 443)
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now telemt
Почему
LimitNOFILE=65536? При большом количестве одновременных подключений Linux исчерпывает лимит открытых файловых дескрипторов.telemtпредупреждает об этом в документации — это не украшательство, а обязательный параметр для продакшна.
7. Фаервол
# Открываем порт прокси
ufw allow 7443/tcp
# API (9091) и метрики (9090) наружу НЕ открываем — они на loopback
# Если ранее открывали 443, закрываем
# ufw delete allow 443/tcp
# Проверяем
ufw status verbose
Что не открывать наружу: порты 9091 (API) и 9090 (метрики). Оба сервиса по умолчанию слушают только 127.0.0.1 — не меняйте это без необходимости.
8. Запуск и проверка
Статус сервиса
systemctl status telemt --no-pager -l
journalctl -u telemt -n 100 --no-pager
Проверка портов
# Прокси слушает снаружи
ss -ltnp | grep ':7443 '
# API только на loopback
ss -ltnp | grep ':9091 '
# Метрики только на loopback
ss -ltnp | grep ':9090 '
Ожидаемый вывод для прокси-порта:
LISTEN 0 128 0.0.0.0:7443 0.0.0.0:* users:(("telemt",...))
Проверка DNS
dig +short A proxy.example.com
# Должен вернуть IP вашего сервера
9. Получение ссылок через API
telemt генерирует tg:// ссылки через локальный HTTP API. Для каждой комбинации public_host + tls_domain создаётся отдельная ссылка.
curl -s http://127.0.0.1:9091/v1/users | jq
Пример вывода:
{
"users": {
"main": {
"links": {
"tls": [
"tg://proxy?server=proxy.example.com&port=7443&secret=ee..."
]
}
}
}
}
Ссылку вида tg://proxy?server=proxy.example.com&port=7443&secret=ee... можно передавать пользователям напрямую или публиковать в Telegram-канале.
10. Работа с несколькими TLS-доменами
Если хотите сравнить стабильность разных SNI-доменов, telemt поддерживает параметр tls_domains (массив).
Конфиг с несколькими доменами
[censorship]
tls_domain = "www.microsoft.com"
tls_domains = ["www.apple.com", "www.bing.com"]
mask = true
tls_emulation = true
tls_front_dir = "/opt/telemt/tlsfront"
API вернёт несколько ссылок — по одной на каждый домен. Они будут отличаться значением secret= (в нём закодирован SNI-домен).
Рекомендуемая стратегия
- Стартуйте с одним
tls_domain— проще дебажить. - Проверьте стабильность на Android/Desktop-клиентах.
- Добавьте
tls_domainsс двумя-тремя вариантами. - Сравните, какая ссылка даёт лучший latency и меньше обрывов.
- Оставьте победителя.
Не стройте зоопарк из десяти доменов на старте — вы просто не поймёте, что именно работает.
11. Типичные ошибки и их диагностика
telemt не запускается
journalctl -u telemt -n 50 --no-pager
Частые причины:
- Порт занят. Проверьте:
ss -ltnp | grep ':7443 ' - Ошибка в TOML. Проверьте синтаксис конфига вручную.
- Нет прав на порт < 1024. Если используете
443безCAP_NET_BIND_SERVICE.
API не отвечает
curl -v http://127.0.0.1:9091/v1/users
Проверьте, что в конфиге:
[server.api]
enabled = true
listen = "127.0.0.1:9091"
И что сервис запущен: systemctl is-active telemt
Ссылки не работают у клиентов
- Проверьте, что
proxy.example.comрезолвится в IP сервера. - Проверьте, что порт
7443открыт снаружи:ufw status verbose - Проверьте, что
public_hostиpublic_portв конфиге совпадают с тем, что в ссылке. - Убедитесь, что
tls_domain— это внешний домен, не ваш.
Ошибка "Too many open files"
В systemd unit обязателен параметр:
LimitNOFILE=65536
После добавления: systemctl daemon-reload && systemctl restart telemt
Самофронтинг (петля)
Симптом: telemt запускается, но соединения зависают или сразу рвутся.
Причина: tls_domain указывает на тот же IP, что и ваш сервер.
Решение: замените tls_domain на настоящий внешний HTTPS-сайт.
Проверка:
# tls_domain из конфига
dig +short A www.microsoft.com
# IP вашего сервера
curl -s ifconfig.me
# Они НЕ должны совпадать
12. Ограничения и известные баги
Проблемы с iOS-клиентами
У части пользователей официального Telegram-клиента на iPhone наблюдались проблемы с отправкой фотографий через telemt, тогда как через mtg фото уходили нормально. Если у вас много iOS-клиентов — держите mtg как запасной вариант.
Нет привязки ссылки к конкретному SNI
API возвращает массив tls ссылок, но не указывает явно, какая ссылка соответствует какому tls_domain. Определить это можно только экспериментально или по порядку в массиве (совпадает с порядком в конфиге).
API не размечает ссылки по домену
Если вам критично знать соответствие «ссылка → SNI», пока это нужно отслеживать вручную — документация по API не даёт такой маркировки.
Итог: минимальная рабочая схема
Клиент → proxy.example.com:7443 → telemt
↓ fake TLS SNI: www.microsoft.com
upstream HTTPS
proxy.example.com— толькоpublic_host(имя в ссылках)www.microsoft.com— толькоtls_domain(fake fronting, не ваш)- API на
127.0.0.1:9091— не светить наружу - Метрики на
127.0.0.1:9090— тоже только локально LimitNOFILE=65536в systemd — обязательно
Гайд написан на основе официальной документации telemt: CONFIG_PARAMS, QUICK_START_GUIDE, API, FAQ.

No comments to display
No comments to display