// DevOps

Telemt: instalación de MTProxy para Telegram en Docker en el puerto 443 con TLS falso

Publicado el 29.05.2026

Enlace para comprobar cómo funciona el TeleMT instalado

Telemt — servidor MTProxy para Telegram en Rust. A diferencia de la imagen oficial clásica, soporta TLS falso: el tráfico desde el exterior parece HTTPS normal hacia un sitio real, sin certificado SSL local. Si al puerto llega alguien sin el secreto correcto — DPI, un escáner, simplemente un navegador — la conexión se redirige de forma transparente al verdadero github.com (o a cualquier otro dominio que indiques). La parte que inspecciona recibe un TLS-handshake válido y no entiende nada.

A continuación — instalación paso a paso con Docker Compose en el puerto 443.


Sobre el certificado SSL — lo esencial

No se necesita certificado local. No hace falta Certbot, ni Let’s Encrypt, ni ACME. Simplemente indicas en la configuración un dominio HTTPS real — Telemt lo usa como máscara. Esta es la diferencia fundamental respecto a Nginx o cualquier proxy clásico.


Paso 1. Preparación del servidor

Necesitas:

  • Servidor Linux con IP pública;
  • Docker Engine + plugin Docker Compose;
  • puerto 443 libre.

Primero verifica si el puerto está ocupado:

ss -ltnp 'sport = :443'

Si allí ya está Nginx o Caddy — libera el puerto o ejecuta Telemt en otro puerto y haz un reenvío L4.

Crea el directorio de trabajo:

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

Paso 2. Generación del secreto

El secreto son 16 bytes, es decir, 32 caracteres hex:

openssl rand -hex 16

O sin OpenSSL:

xxd -l 16 -p /dev/urandom

Ejemplo:

7a2f8b5c9d0e1f2a3b4c5d6e7f8a9b0c

Guarda este valor — va en la sección [access.users]. En la config se escribe precisamente este hex corto. El enlace completo del cliente con el prefijo ee y el código del dominio aparecerá en los logs después de arrancar — no hace falta construirlo a mano.


Paso 3. Configuración config.toml

nano /opt/telemt/config.toml

Configuración mínima funcional para TLS falso:

[general]
use_middle_proxy = true
log_level = "normal"

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

[general.links]
show = "*"
# Si desea un dominio en lugar de una IP en los enlaces:
# public_host = "proxy.example.com"
# public_port = 443

[server]
port = 443
max_connections = 10000

# Métricas Prometheus — solo 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]
# Dominio-máscara. Después de emitir enlaces no lo cambies — los enlaces dejarán de funcionar.
tls_domain = "github.com"
mask = true
tls_emulation = true
tls_front_dir = "tlsfront"

[access.users]
tg_user1 = "7a2f8b5c9d0e1f2a3b4c5d6e7f8a9b0c"

Sustituye github.com por cualquier sitio HTTPS funcional, tg_user1 por un nombre cómodo, y la cadena hex por tu secreto.

Punto importante: tls_domain, mask, tls_emulation — todo esto vive en la sección [censorship], no en [general]. Si lo pones en otro sitio — la configuración no funcionará.


Paso 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"

En producción es mejor fijar la versión de la imagen:

image: ghcr.io/telemt/telemt:3.4.12

NET_BIND_SERVICE es necesario porque el proceso dentro del contenedor no corre como root, pero debe escuchar el puerto 443 — privilegiado. El binding de puertos de Docker por sí solo no resuelve esto.


Paso 5. Arranque

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

En los logs aparecerán enlaces:

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

Ese es el enlace funcional — ee + tu secreto de 32 caracteres + el código hex del dominio.


Paso 6. Obtener enlaces vía Control API

Puedes no mirar los logs y llamar al API:

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

Si el comando no devuelve nada — revisa server.api.listen, server.api.whitelist y el binding Docker 127.0.0.1:9091:9091. No hace falta exponer el API al exterior.


Paso 7. Verificar la máscara

Comprueba que sin el secreto MTProxy el servidor se comporte como HTTPS normal:

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

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

El TCP va a tu servidor, el SNI apunta a tls_domain — en la respuesta debe venir un TLS normal del sitio real.


Paso 8. Varios usuarios

Cada uno necesita un secreto separado:

openssl rand -hex 16
openssl rand -hex 16
openssl rand -hex 16
[access.users]
team1 = "00000000000000000000000000000001"
team2 = "00000000000000000000000000000002"
team3 = "00000000000000000000000000000003"

Tras editar la config verifica vía API que los nuevos usuarios aparecieron. Teóricamente un reload sin reiniciar funciona, pero en la práctica en entornos Docker yo siempre hago docker compose restart y reviso los logs.


Paso 9. Límite de IP por enlace

Si no quieres que mucha gente use un solo enlace:

[access.user_max_unique_ips]
team1 = 1

Límite de IPs únicas. Dispositivos tras un mismo NAT/enrutador contarán como una sola IP.


Paso 10. Métricas Prometheus

curl http://127.0.0.1:9090/metrics

No expongas las métricas al exterior — 0.0.0.0/0 en metrics_whitelist las abre para todo el mundo.


Solución de problemas

Puerto 443 ocupado

ss -ltnp 'sport = :443'

Encuentra quién lo está usando y para o mueve Telemt a otro puerto.

Enlaces antiguos dejaron de funcionar

Si cambiaste tls_domain — los enlaces se rompieron, el dominio forma parte del secreto ee. Vuelve a emitir los enlaces vía API o revisa los logs.

Error Unknown TLS SNI

Clientes con enlaces antiguos tras cambiar el dominio. Puedes enmascarar:

[censorship]
unknown_sni_action = "mask"

O rechazar el handshake:

[censorship]
unknown_sni_action = "reject_handshake"

Las llamadas de Telegram no funcionan

MTProxy no soporta llamadas — es una limitación del propio Telegram, no de Telemt. Para llamadas necesitas SOCKS5 o VPN.


Referencia de parámetros

ParámetroDescripción
use_middle_proxy = trueModo Middle-End; si es false — enrutamiento directo a DC.
[general.modes].tls = trueActiva TLS falso / modo ee.
[censorship].tls_domainDominio-máscara, entra en los enlaces de cliente.
[censorship].mask = trueFallback para conexiones no identificadas.
[censorship].mask_hostUpstream separado para la máscara. Por defecto — tls_domain.
[censorship].tls_emulation = trueEmulación TLS usando datos cacheados de sitios reales.
[server].metrics_portMétricas Prometheus.
[server.api]Control API: usuarios, enlaces, info de runtime.
[access.users]Usuarios y sus secretos hex.
[access.user_max_unique_ips]Límite de IPs únicas por usuario.

Resumen

Telemt es útil cuando el MTProxy estándar ya está siendo bloqueado. TLS falso hace que el tráfico sea indistinguible del HTTPS normal — sin líos con certificados. Lo importante: no cambies tls_domain después de emitir enlaces, mantén el API y las métricas solo en localhost, y recuerda — MTProxy no sustituye a una VPN para llamadas y otras funciones de Telegram.

Enlace para comprobar cómo funciona el TeleMT instalado

// Reviews

Reseñas relacionadas

Había que hacer funcionar n8n, Redis y la base de datos. Lo había encargado antes a otro proveedor; todo se rompía constantemente. Se lo encargué a Mijaíl y al día siguiente todo funcionó rápido, ¡como un reloj!

Había que poner en marcha n8n, redis y la base de datos. Contraté antes a otro proveedor, y todo se rompía constantemente. Lo encargué a Mikhail, y al día siguiente ¡todo empezó a funcionar rápido, como un reloj!

christ_media

Instalación de n8n en su servidor VPS. Configuración de n8n, Docker, IA, Telegram

24.09.2025 · ★ 5/5

Comprador experimentado

ladohinpy

Instalación de n8n en su servidor VPS. Configuración de n8n, Docker, IA, Telegram

25.08.2025 · ★ 5/5

// Contact

¿Necesitas ayuda?

Escríbeme y te ayudaré a resolver el problema

Enviar solicitud
Escribir y recibir una respuesta rápida