stunnel vs Nginx stream: где терминировать TLS для TCP‑сервисов

TLS для TCP‑сервисов — это не только про безопасность «на бумаге», но и про реальную эксплуатацию: предсказуемые перезагрузки без простоя, экономия CPU на рукопожатиях, корректная передача клиентского IP и понятное логирование. В проде вопрос «чем терминировать TLS» часто упирается в две опции: stunnel — минималистичный TLS‑обёртчик, и Nginx stream — L4‑прокси внутри знакомого Nginx. Рассмотрим их трезво и по делу.

Зачем вообще выносить TLS‑терминацию

Терминировать TLS можно в самом приложении (PostgreSQL, Redis, RabbitMQ и т. п.) или на отдельном прокси. Вынос на прокси (L4/L7) делает обновления сертификатов, смену ключей и политику шифров унифицированной, а ещё позволяет не менять конфиг каждого сервиса. Это особенно полезно, если:

• приложений много, а политики шифрования должны быть одинаковыми;
• нужны прозрачные перезагрузки конфигурации без обрывов соединений;
• важны логирование, метрики и контроль времени жизни сессий;
• хотите разделить доверенные и недоверенные периметры сети простым правилом: наружу — TLS, внутрь — понятный TCP.

Задача сводится к двум режимам:

• TLS‑termination: прокси принимает TLS, дешифрует и проксирует «голый» TCP внутрь.
• TLS pass‑through: прокси просто пробрасывает шифрованный поток, иногда глядя в SNI (без расшифровки) для маршрутизации.

И stunnel, и Nginx stream умеют первое (терминацию). Второе (pass‑through с маршрутизацией по SNI без расшифровки) — это уже зона Nginx stream с ssl_preread.

Краткий портрет инструментов

stunnel

Классический «TLS‑обёртчик» для TCP. Конфиг прост: «слушаю порт X с сертификатом Y и пересылаю на хост:порт Z». Мало внешних зависимостей, небольшой footprint, ставится и заводится быстро, понятен администраторам, которые не хотят тянуть крупный reverse‑proxy ради одного порта.

Nginx stream

Модуль Nginx для L4‑проксирования TCP/UDP. Умеет TLS‑терминацию, маршрутизацию по SNI без расшифровки (ssl_preread), балансировку по пулу upstream‑ов, PROXY Protocol на вход/выход, логирование соединений и байтов. Встраивается в существующую инсталляцию Nginx, позволяет использовать единые практики деплоя и reload.

Функциональные различия, которые чувствует прод

Маршрутизация и мульти‑бэкенды

Nginx stream выигрывает, когда нужно больше, чем порт‑к‑порту:

• балансировка на несколько upstream‑ов (hash, least_conn и др.);
• приём или прокидка PROXY Protocol (сохранение реального IP до бэкенда);
• маршрутизация по SNI без расшифровки (ssl_preread) — полезно, если вы не хотите терминировать TLS на краю, а только развести трафик по именам;
• тонкие таймауты (proxy_connect_timeout, proxy_timeout), reuseport, привязка исходного IP (proxy_bind).

stunnel проще: один слушающий сервис — одно назначение. Балансировки, PROXY Protocol и SNI‑маршрутизации без расшифровки нет. Зато минимализм приводит к предсказуемости: меньше вариантов сломать конфигурацию.

Сертификаты и SNI

Оба подхода комфортно работают с одиночным сертификатом (включая SAN/wildcard). В сценариях «много имён на одном порту» без терминации (просто развести трафик) Nginx stream с ssl_preread незаменим. Если же нужно именно терминировать TLS и при этом динамически выбирать сертификат по SNI на одном порту — у open source Nginx stream возможностей меньше, чем у HTTP‑контекста; на практике чаще используют единый SAN/подстановочный сертификат или разводят по портам. Если требуются доверенные сертификаты для продакшена, рассмотрите SSL-сертификаты. Для справки по политике HSTS и 301 при переносе имён смотрите материал «Миграция домена: 301, HSTS и SSL» (руководство).

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Логирование и наблюдаемость

Nginx stream умеет писать структурированные access‑логи соединений: источник, назначение, количество байт, время сессии. Это удобно для биллинга, расследований и алертов на необычный поток. Поверх этого легко строятся метрики по логам. stunnel пишет компактные журналы о событиях TLS, но не тянет на полноценную систему наблюдаемости; обычно его обвязывают системными метриками (conntrack, netstat, ps) и общесистемными логами.

Горячие перезагрузки

Оба инструмента поддерживают перезагрузку конфигурации и сертификатов без обрыва текущих соединений. Nginx традиционно силён в zero‑downtime reload, предсказуемо перевешивая сокеты на новые воркеры. У stunnel при SIGHUP поведение тоже аккуратное, но диагностировать проблемы при массовых обновлениях сложнее из‑за скромных метрик.

Безопасность и изоляция

Оба умеют снижать привилегии процессов, работать под отдельным пользователем, ограничивать каталоги. Nginx интегрируется с привычными профилями усиления (SELinux/AppArmor) и не требует особых трюков. У stunnel плюс — минимальная поверхность атаки и небольшой размер кода. В сценариях с жёсткими требованиями к изоляции часто выбирают то, что уже стандартизовано в вашей инфраструктуре и снабжено готовыми профилями.

Производительность: где «горит» CPU и на что влияет выбор

Основная цена TLS — рукопожатие (ECDHE), вторая — шифрование данных (обычно AES‑GCM или ChaCha20‑Poly1305). Современные CPU ускоряют AES (AES‑NI), но под высокой конкуррентной нагрузкой и коротких сессиях разница между реализациями важна.

• Высокая конкуррентность: Nginx с событийной моделью и неблокирующим I/O масштабируется предсказуемо на многоядерных VDS и серверах. stunnel с потоками/процессами тоже справляется, но чаще упирается в переключения контекста и память на тысячи одновременных коннектов.
• Длинные живые соединения (БД‑клиенты, брокеры сообщений): рукопожатие случается редко; критичны стабильные RTT и отсутствие «микростопов». Оба решения дают схожую пропускную способность; выигрывает то, что проще отладить в вашем окружении.
• Короткие сессии (много подключений в минуту): экономьте на повторном использовании сессий TLS (tickets/session cache). Nginx гибко настраивает кеш сессий; у stunnel опции проще, но тоже дают эффект.
• Выбор шифров: ECDSA‑сертификаты уменьшают CPU на рукопожатиях по сравнению с RSA при прочих равных; ChaCha20 может выигрывать на CPU без AES‑NI.

Правило большого пальца: если у вас уже крутится Nginx как фронт, и вы ожидаете рост соединений или балансировку между бэкендами — берите stream. Если нужна одна тихая TLS‑обёртка для конкретного сервиса без лишней логики — stunnel закрывает задачу с минимальными зависимостями.

Типовые сценарии и подводные камни

Базы данных (PostgreSQL/MySQL)

Терминировать TLS на краю удобно: клиенты ходят по TLS, внутри — чистый TCP. Nginx stream позволяет держать пул бэкендов и плавно выводить инстансы на обслуживание. Важно правильно выставить таймауты, чтобы не обрывать долгие транзакции. Кэш сессий TLS полезен при частых переподключениях (пулы соединений на приложениях).

Redis

Redis традиционно работал без TLS, но всё чаще требуется шифрование в пути. Если нужна простая точка входа «один порт — один бэкенд», stunnel решит задачу за 5 минут. Если нужен PROXY Protocol до Redis‑sentinel/реплик, выбор — Nginx stream (на входе или на выходе), чтобы сохранить исходный IP.

MQTT/AMQP (RabbitMQ)

Для брокеров сообщений критичны стабильность и диагностика «долгоиграющих» подключений. Здесь ценится логирование объёма трафика и длительности сессий, что у Nginx stream из коробки удобнее. Если же у вас единичный брокер без балансировки — stunnel проще в сопровождении.

SMTP/IMAP/POP3

Помните, что STARTTLS — это уже не «чистый TCP‑TLS на входе»; такие протоколы корректнее обслуживать теми сервисами, которые их понимают на уровне L7 (MTA/IMAP‑сервер), либо специализированными прокси. Если у вас порты «сразу TLS» (например, 465, 993, 995), и вы хотите только шифрование, оба варианта применимы.

Операционная зрелость: что будет удобнее в реальной жизни

• Деплой и управление: если Nginx уже стандарт в инфраструктуре, добавление stream‑конфигов естественно впишется в пайплайны, мониторинг и алерты. stunnel удобен в контейнерах sidecar‑паттерном, минимален по образу. Полезно также оценить «Сравнение панелей для VDS в 2025» (обзор).
• Наблюдаемость: stream‑логи позволяют строить алерты по времени сессии и объёмам. Со stunnel придётся больше полагаться на системные метрики и трафик‑анализаторы.
• Обновления и ротации сертификатов: в обоих случаях автоматизируйте копирование новых сертификатов и HUP/reload. Nginx даёт устойчивые перезагрузки под нагрузкой и понятные сообщения об ошибках конфигурации.
• HA и масштабирование: Nginx stream проще объединять в кластер с VRRP/keepalived, DNS‑балансировкой, health‑checks и канареечными выкладками конфигов. stunnel чаще ставят на край каждого хоста как локальную обёртку.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Минимальные примеры конфигураций

Nginx stream: терминация TLS для PostgreSQL

stream {
    upstream pg_backend {
        server 10.0.0.11:5432 max_fails=2 fail_timeout=10s;
        server 10.0.0.12:5432 max_fails=2 fail_timeout=10s;
    }

    server {
        listen 0.0.0.0:6432 ssl reuseport;
        proxy_pass pg_backend;

        ssl_certificate /etc/nginx/certs/pg.crt;
        ssl_certificate_key /etc/nginx/certs/pg.key;
        ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;
        ssl_protocols TLSv1.2 TLSv1.3;

        access_log /var/log/nginx/stream_pg_access.log basic;
        proxy_timeout 1h;
        proxy_connect_timeout 5s;
    }
}

stunnel: тот же кейс

foreground = no
setuid = stunnel
setgid = stunnel
; при необходимости chroot = /var/lib/stunnel

[pg]
accept = 0.0.0.0:6432
connect = 10.0.0.11:5432
cert = /etc/stunnel/pg.pem
; включите шифры и протоколы под вашу политику
sslVersion = TLSv1.2
ciphers = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
TIMEOUTconnect = 5
TIMEOUTclose = 60

Оба примера иллюстрируют базовую терминацию. В проде для Nginx стоит включить кеш сессий TLS, лимиты и корректные логи; для stunnel — аккуратно задать шифры/протоколы и стратегии рестартов.

Частые ошибки

• Слишком агрессивные таймауты: обрывы длинных транзакций или потребителей очередей. Под TCP‑сервисы таймауты обычно больше, чем под HTTP.
• Отсутствие PROXY Protocol при терминации: бэкенд теряет исходный IP. Если он важен для ACL/логов, выбирайте прокси, умеющий PROXY Protocol, и включайте поддержку в приложении.
• Непродуманная ротация сертификатов: обновили файлы, забыли reload — клиенты получают просроченный сертификат. Автоматизируйте.
• Микс шифров без учёта CPU: на слабых CPU без AES‑NI ChaCha20 зачастую быстрее AES‑GCM.
• Непроверенные лимиты ОС: файловые дескрипторы, net.core.somaxconn, rmem/wmem. Прокси начинают «задыхаться» раньше приложения.

Как выбирать: быстрый чек‑лист

• Нужна балансировка/маршрутизация, PROXY Protocol, логи и единый контроль политик — Nginx stream.
• Один порт, один бэкенд, минимум зависимостей и крошечный след — stunnel.
• Много имён на одном порту без терминации — Nginx stream с ssl_preread (маршрутизация по SNI).
• Требуется одинаковая эксплуатация HTTP и TCP‑TLS — Nginx, чтобы не плодить зоопарк.
• Изоляция по хостам и sidecar‑паттерн — stunnel чаще оказывается удобнее.

Итог

Оба инструмента зрелые и годятся для продакшена. Если у вас насыщенная сетка сервисов, нужны балансировка, PROXY Protocol, внятные логи и предсказуемые перезагрузки — Nginx stream даёт больше управляемости и наблюдаемости. Если задача — быстро и надёжно зашифровать один TCP‑сервис без доплогики, stunnel остаётся отличным выбором. В любом случае тестируйте под свою нагрузку: профиль трафика (короткие/длинные сессии), доступный CPU, требуемые фичи (SNI‑маршрутизация, сохранение IP) и удобство эксплуатации в вашей команде.