MTProto on port 443 with nginx SNI routing

MTProto Proxy on a Single 443 Port with SNI Routing

Developers of MTProto proxies for Telegram often face rapid IP and port blocking. The solution is to organize multiple proxies on a single 443 port using nginx stream and SNI-based routing. This masks traffic as popular domains and scales the network without changing IPs.

The approach is split into a control panel and a server agent. The panel generates configurations, and the agent deploys Docker containers. Each proxy gets a unique SNI from a pool of domains (e.g., wikipedia.org, netflix.com). Nginx analyzes the SNI and redirects the TLS connection to the corresponding container.

Advantages of this scheme:

• All proxies on the standard HTTPS port
• Masquerading as legitimate traffic
• Scaling to multiple containers without changing ports
• Automated management via a web interface

Configuring nginx for Stream Routing

The key element is the ssl_preread module in the nginx stream block. It extracts the SNI without decrypting TLS, ensuring zero latency and full transparency for the client.

user nginx;
worker_processes auto;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 4096;
}

stream {
    resolver 127.0.0.11 valid=10s;

    log_format proxy '$remote_addr [$time_local] $ssl_preread_server_name $status';
    access_log /dev/stdout proxy;

    map $ssl_preread_server_name $backend {
        en.wikipedia.org mtproto-proxy-3d9d46ba:443;
        netflix.com mtproto-proxy-475ecb29:443;
        assets.msn.com mtproto-proxy-3f8875a4:443;
        default mtproto-proxy-3d9d46ba:443;
    }

    server {
        listen 443;
        proxy_pass $backend;
        ssl_preread on;
        proxy_connect_timeout 10s;
        proxy_timeout 300s;
    }

}

Important parameters:

• resolver 127.0.0.11 — DNS within the Docker network
• worker_connections 4096 — high limit for concurrency
• Timeouts optimized for mobile connections
• SNI logging for debugging blocks

Control Panel and Agent Architecture

The control panel (Node.js/Go) operates independently from the proxy server. The agent on the server receives API commands and manages Docker containers based on the telemt/telemt image.

Proxy creation process:

• The panel generates a secret key and selects an SNI from the pool
• Sends the configuration to the agent
• The agent runs docker run with unique volumes
• Nginx reloads with a new map block

The domain pool is updated manually, excluding blocked CDNs. Each domain is strictly used by one proxy.

Scaling and Resilience to Blocking

Testing showed that proxies on non-standard ports (4443+) are blocked within 3-4 days with 15-20 users. The scheme with port 443 and SNI routing ensures a lifespan of >7 days with 50+ devices.

Operational recommendations:

• Use VPS in jurisdictions without DPI (e.g., Germany, Netherlands)
• Rotate SNIs every 7-10 days
• Monitor nginx logs for blocking patterns
• Limit users per proxy (max 20-30)

For fault tolerance, deploy agents on multiple VPS with a single panel domain.

Key Points

• Single port 443: Masks MTProto as HTTPS traffic
• SNI routing: Allows 10+ proxies on one IP without conflicts
• Automation: Panel + agent minimize manual work
• Resilience: >7 days lifespan with 50+ connections
• Scalability: Easy to add new nodes

— Editorial Team