Telemt: установка MTProxy для Telegram в Docker на порту 443 с Fake TLS

Ссылка, чтобы проверить, как работает установленный TeleMT

Telemt — MTProxy-сервер для Telegram на Rust. В отличие от классического официального образа, поддерживает Fake TLS: трафик снаружи выглядит как обычный HTTPS к реальному сайту, без локального SSL-сертификата. Если на порт приходит кто-то без правильного секрета — DPI, сканер, просто браузер — соединение прозрачно уходит на настоящий github.com (или любой другой домен, который вы укажете). Проверяющая сторона получает живой TLS-handshake и ничего не понимает.

Ниже — пошаговая установка в Docker Compose на порт 443.

Про SSL-сертификат — сразу главное

Локальный сертификат не нужен. Не нужен Certbot, не нужен Let’s Encrypt, не нужен ACME. Вы просто указываете в конфиге реальный HTTPS-домен — Telemt использует его как маску. Это принципиальное отличие от Nginx или любого классического прокси.

Шаг 1. Подготовка сервера

Нужно:

• Linux-сервер с публичным IP;
• Docker Engine + Docker Compose plugin;
• свободный порт 443.

Сначала проверьте, не занят ли порт:

ss -ltnp 'sport = :443'

Если там уже сидит Nginx или Caddy — либо освобождайте порт, либо запускайте Telemt на другом порту и делайте L4-проброс.

Создайте рабочую директорию:

install -d -m 0750 /opt/telemt
cd /opt/telemt

Шаг 2. Генерация секрета

Секрет — 16 байт, то есть 32 hex-символа:

openssl rand -hex 16

Или без OpenSSL:

xxd -l 16 -p /dev/urandom

Пример:

7a2f8b5c9d0e1f2a3b4c5d6e7f8a9b0c

Сохраните это значение — оно идёт в секцию [access.users]. В конфиг пишется именно этот короткий hex. Полная клиентская ссылка с префиксом ee и кодом домена появится в логах после запуска — не надо собирать её вручную.

Шаг 3. Конфиг config.toml

nano /opt/telemt/config.toml

Минимальный рабочий конфиг для Fake TLS:

[general]
use_middle_proxy = true
log_level = "normal"

[general.modes]
classic = false
secure = false
tls = true

[general.links]
show = "*"
# Если хотите домен вместо IP в ссылках:
# public_host = "proxy.example.com"
# public_port = 443

[server]
port = 443
max_connections = 10000

# Метрики Prometheus — только localhost
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", "::1/128"]
minimal_runtime_enabled = false
minimal_runtime_cache_ttl_ms = 1000

[[server.listeners]]
ip = "0.0.0.0"

[censorship]
# Домен-маска. После выдачи ссылок не меняйте — ссылки сломаются.
tls_domain = "github.com"
mask = true
tls_emulation = true
tls_front_dir = "tlsfront"

[access.users]
tg_user1 = "7a2f8b5c9d0e1f2a3b4c5d6e7f8a9b0c"

Замените github.com на любой рабочий HTTPS-сайт, tg_user1 — на удобное имя, hex-строку — на свой секрет.

Важный момент: tls_domain, mask, tls_emulation — всё это живёт в секции [censorship], не в [general]. Положите не туда — конфиг не заработает.

Шаг 4. docker-compose.yml

nano /opt/telemt/docker-compose.yml

services:
  telemt:
    image: ghcr.io/telemt/telemt:latest
    container_name: telemt
    restart: unless-stopped

    ports:
      - "443:443"
      - "127.0.0.1:9090:9090"
      - "127.0.0.1:9091:9091"

    working_dir: /etc/telemt

    volumes:
      - ./config.toml:/etc/telemt/config.toml:ro

    tmpfs:
      - /etc/telemt:rw,mode=1777,size=4m

    environment:
      - RUST_LOG=info

    healthcheck:
      test: [ "CMD", "/app/telemt", "healthcheck", "/etc/telemt/config.toml", "--mode", "liveness" ]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 20s

    cap_drop:
      - ALL

    cap_add:
      - NET_BIND_SERVICE

    read_only: true

    security_opt:
      - no-new-privileges:true

    ulimits:
      nofile:
        soft: 65536
        hard: 262144

    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "5"

В продакшене лучше зафиксировать версию образа:

image: ghcr.io/telemt/telemt:3.4.12

NET_BIND_SERVICE здесь нужен потому, что процесс внутри контейнера работает не от root, но должен слушать порт 443 — привилегированный. Docker port binding сам по себе этого не решает.

Шаг 5. Запуск

cd /opt/telemt
docker compose up -d
docker compose ps
docker compose logs -f telemt

В логах появятся ссылки:

tg://proxy?server=SERVER_IP&port=443&secret=ee...

Это и есть рабочая ссылка — ee + ваш 32-символьный секрет + hex-код домена.

Шаг 6. Получение ссылок через Control API

Можно не смотреть в логи, а дёрнуть API:

curl -s http://127.0.0.1:9091/v1/users | jq -r '
  .data[]
  | "[\(.username)]",
    (.links.classic[]? | "classic: \(.)"),
    (.links.secure[]? | "secure: \(.)"),
    (.links.tls[]? | "tls: \(.)"),
    ""
'

Если команда ничего не возвращает — проверьте server.api.listen, server.api.whitelist и Docker binding 127.0.0.1:9091:9091. Наружу API открывать не нужно.

Шаг 7. Проверка маскировки

Проверьте, что без MTProxy-секрета сервер ведёт себя как обычный HTTPS:

SERVER_IP="203.0.113.10"
TLS_DOMAIN="github.com"

curl -vkI --resolve "${TLS_DOMAIN}:443:${SERVER_IP}" "https://${TLS_DOMAIN}/"

TCP идёт на ваш сервер, SNI указывает на tls_domain — в ответе должен быть нормальный TLS от реального сайта.

Шаг 8. Несколько пользователей

На каждого — отдельный секрет:

openssl rand -hex 16
openssl rand -hex 16
openssl rand -hex 16

[access.users]
team1 = "00000000000000000000000000000001"
team2 = "00000000000000000000000000000002"
team3 = "00000000000000000000000000000003"

После правки конфига проверьте через API, что новые пользователи появились. Теоретически reload без перезапуска работает, но на практике в Docker-окружении я всегда делаю docker compose restart и проверяю логи.

Шаг 9. Ограничение по IP на ссылку

Если не хотите, чтобы одной ссылкой пользовалась толпа:

[access.user_max_unique_ips]
team1 = 1

Ограничение по уникальным IP. Устройства за одним NAT/роутером будут выглядеть как один IP.

Шаг 10. Метрики Prometheus

curl http://127.0.0.1:9090/metrics

Не выставляйте метрики наружу — 0.0.0.0/0 в metrics_whitelist открывает их всем.

Troubleshooting

Порт 443 занят

ss -ltnp 'sport = :443'

Найдите, кто занял, и остановите или переведите Telemt на другой порт.

Старые ссылки перестали работать

Если поменяли tls_domain — ссылки сломались, домен входит в ee-секрет. Перевыпустите ссылки через API или логи.

Ошибка Unknown TLS SNI

Клиенты со старыми ссылками после смены домена. Можно замаскировать:

[censorship]
unknown_sni_action = "mask"

Или отвергать хендшейк:

[censorship]
unknown_sni_action = "reject_handshake"

Telegram-звонки не работают

MTProxy не поддерживает звонки — это ограничение самого Telegram, не Telemt. Для звонков нужен SOCKS5 или VPN.

Справочник параметров

Итог

Telemt хорош для тех случаев, когда стандартный MTProxy уже блокируется. Fake TLS делает трафик неотличимым от обычного HTTPS — без возни с сертификатами. Главное: не меняйте tls_domain после выдачи ссылок, держите API и метрики только на localhost, и помните — MTProxy не заменяет VPN для звонков и других функций Telegram.

Ссылка, чтобы проверить, как работает установленный TeleMT