MTProto na porcie 443 z nginx SNI routingiem

MTProxy na jednym porcie 443 z routingiem SNI

Twórcy proxy MTProto dla Telegrama często borykają się z szybkim blokowaniem adresów IP i portów. Rozwiązaniem jest organizacja wielu proxy na jednym porcie 443 przy użyciu modułu stream nginx i routingu SNI. Pozwala to maskować ruch jako popularne domeny i skalować sieć bez zmiany IP.

Podejście dzieli się na panel zarządzania i agenta na serwerze. Panel generuje konfiguracje, agent wdraża kontenery Docker. Każde proxy otrzymuje unikalny SNI z puli domen (np. wikipedia.org, netflix.com). Nginx analizuje SNI i przekierowuje połączenie TLS do odpowiedniego kontenera.

Zalety schematu:

• Wszystkie proxy na standardowym porcie HTTPS
• Maskowanie jako legalny ruch
• Skalowanie na wiele kontenerów bez zmiany portów
• Automatyczne zarządzanie przez interfejs webowy

Konfiguracja nginx do routingu stream

Kluczowy element to moduł ssl_preread w bloku stream nginx. Wyodrębnia on SNI bez deszyfrowania TLS, co zapewnia zerowe opóźnienie i pełną przejrzystość dla klienta.

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;
    }

}

Ważne parametry:

• resolver 127.0.0.11 — DNS wewnątrz sieci Docker
• worker_connections 4096 — wysoki limit dla współbieżności
• Timeouty zoptymalizowane pod połączenia mobilne
• Logowanie SNI do debugowania blokad

Architektura panelu i agenta

Panel zarządzania (Node.js/Go) działa niezależnie od serwera proxy. Agent na serwerze odbiera komendy API i zarządza kontenerami Docker na bazie obrazu telemt/telemt.

Proces tworzenia proxy:

• Panel generuje klucz tajny i wybiera SNI z puli
• Wysyła konfigurację do agenta
• Agent uruchamia docker run z unikalnymi wolumenami
• Nginx przeładowuje się z nowym blokiem map

Pula domen jest aktualizowana ręcznie, wykluczając zablokowane CDN. Każda domena jest używana tylko przez jedno proxy.

Skalowanie i odporność na blokady

Testy wykazały, że proxy na niestandardowych portach (4443+) są blokowane w 3-4 dni przy 15-20 użytkownikach. Schemat z portem 443 i routingiem SNI zapewnia żywotność >7 dni przy 50+ urządzeniach.

Rekomendacje eksploatacyjne:

• Używaj VDS w jurysdykcjach bez DPI (Niemcy, Holandia)
• Rotacja SNI co 7-10 dni
• Monitorowanie logów nginx pod kątem wzorców blokad
• Ograniczenie użytkowników na proxy (max 20-30)

Dla odporności na awarie wdrażaj agentów na wielu VDS z jedną domeną-panelem.

Co jest ważne

• Jeden port 443: Maskuje MTProto jako ruch HTTPS
• Routing SNI: Pozwala na 10+ proxy na jednym IP bez konfliktów
• Automatyzacja: Panel + agent minimalizują pracę ręczną
• Odporność: >7 dni żywotności przy 50+ połączeniach
• Skalowalność: Łatwe dodawanie nowych węzłów

— Editorial Team