MTProto sur le port 443 avec routage SNI nginx

Proxy MTProto sur un seul port 443 avec routage SNI

Les développeurs de proxies MTProto pour Telegram sont souvent confrontés à des blocages rapides d'adresses IP et de ports. La solution consiste à organiser plusieurs proxies sur un seul port 443 en utilisant le module stream de nginx et un routage basé sur SNI. Cela permet de masquer le trafic comme provenant de domaines populaires et de faire évoluer le réseau sans changer d'adresses IP.

L'approche est divisée en un panneau de contrôle et un agent serveur. Le panneau génère les configurations, et l'agent déploie des conteneurs Docker. Chaque proxy obtient un SNI unique à partir d'un pool de domaines (par exemple, wikipedia.org, netflix.com). Nginx analyse le SNI et redirige la connexion TLS vers le conteneur correspondant.

Avantages de ce schéma :

• Tous les proxies sur le port HTTPS standard
• Masquage en tant que trafic légitime
• Passage à l'échelle vers plusieurs conteneurs sans changer de ports
• Gestion automatisée via une interface web

Configuration de nginx pour le routage Stream

L'élément clé est le module ssl_preread dans le bloc stream de nginx. Il extrait le SNI sans déchiffrer le TLS, garantissant une latence nulle et une transparence totale pour le 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;
    }

}

Paramètres importants :

• resolver 127.0.0.11 — DNS au sein du réseau Docker
• worker_connections 4096 — limite élevée pour la concurrence
• Timeouts optimisés pour les connexions mobiles
• Journalisation SNI pour le débogage des blocages

Architecture du panneau de contrôle et de l'agent

Le panneau de contrôle (Node.js/Go) fonctionne indépendamment du serveur proxy. L'agent sur le serveur reçoit des commandes API et gère les conteneurs Docker basés sur l'image telemt/telemt.

Processus de création d'un proxy :

• Le panneau génère une clé secrète et sélectionne un SNI dans le pool
• Envoie la configuration à l'agent
• L'agent exécute docker run avec des volumes uniques
• Nginx recharge avec un nouveau bloc map

Le pool de domaines est mis à jour manuellement, en excluant les CDN bloqués. Chaque domaine est strictement utilisé par un seul proxy.

Passage à l'échelle et résilience face aux blocages

Les tests ont montré que les proxies sur des ports non standard (4443+) sont bloqués en 3-4 jours avec 15-20 utilisateurs. Le schéma avec le port 443 et le routage SNI assure une durée de vie de >7 jours avec 50+ appareils.

Recommandations opérationnelles :

• Utiliser des VPS dans des juridictions sans DPI (par exemple, Allemagne, Pays-Bas)
• Faire tourner les SNI tous les 7-10 jours
• Surveiller les journaux nginx pour détecter les schémas de blocage
• Limiter les utilisateurs par proxy (max 20-30)

Pour la tolérance aux pannes, déployez des agents sur plusieurs VPS avec un seul domaine de panneau.

Points clés

• Port unique 443 : Masque MTProto en tant que trafic HTTPS
• Routage SNI : Permet 10+ proxies sur une seule IP sans conflits
• Automatisation : Panneau + agent minimisent le travail manuel
• Résilience : Durée de vie >7 jours avec 50+ connexions
• Évolutivité : Facile d'ajouter de nouveaux nœuds

— Editorial Team