Nginx 1.31.0 — это mainline-релиз, в котором закрыли сразу несколько уязвимостей и появление новых возможностей для проксирования. Главные изменения: поддержка HTTP CONNECT через новый ngx_http_tunnel_module, открытие least_time для upstream-балансировки и исправления проблем в HTTP/2, HTTP/3, rewrite, SCGI, uWSGI, charset и OCSP.
Nginx 1.31.0 лучше воспринимать как технический и безопасностный релиз
Nginx 1.31.0 вышел 13 мая 2026 года в mainline-ветке. Это не стабильная ветка для максимально консервативных серверов, а актуальная линия разработки, куда быстрее попадают новые функции и изменения поведения. На момент проверки уже есть Nginx 1.31.1 от 22 мая 2026 года, поэтому для реального обновления стоит смотреть не только на 1.31.0, но и на свежий патч-релиз.
Главный смысл версии 1.31.0 — закрыть заметный набор уязвимостей и одновременно добавить несколько возможностей, которые раньше либо отсутствовали в open source-версии, либо были ограничены коммерческой поставкой. По официальному changelog, релиз исправляет проблемы в ngx_http_proxy_module, ngx_http_rewrite_module, ngx_http_scgi_module, ngx_http_uwsgi_module, ngx_http_charset_module, HTTP/3 и OCSP-обработке через resolver.
Исправления безопасности затрагивают реальные серверные сценарии
В 1.31.0 закрыта уязвимость CVE-2026-42926: при использовании директивы proxy_set_body злоумышленник мог внедрить данные в проксируемый запрос к HTTP/2-бэкенду. Для инфраструктур, где Nginx стоит перед приложением как reverse proxy, это особенно важный класс проблем: ошибка находится не в бизнес-коде сайта, а на уровне передачи запроса к upstream-серверу.
Также исправлена CVE-2026-42945 в ngx_http_rewrite_module: специально сформированный запрос мог привести к heap buffer overflow в worker-процессе и потенциально к выполнению произвольного кода. Отдельно закрыты buffer overread-проблемы в SCGI/uWSGI и charset-обработке, где последствия могли включать утечку памяти worker-процесса или падение процесса.
Для конфигураций с HTTP/3 важна CVE-2026-40460: проблема была связана с обработкой connection migration в QUIC и могла приводить к подмене адреса. Ещё одна важная правка — CVE-2026-40701, use-after-free при обработке DNS-ответов, если использовалась директива ssl_ocsp.
Практический вывод простой: если сервер использует HTTP/2-бэкенды, rewrite-правила, uWSGI/SCGI, HTTP/3 или OCSP, игнорировать ветку исправлений не стоит. Даже если вы не переходите на mainline, нужно проверить наличие соответствующих исправлений в стабильной ветке 1.30.x.
Новый ngx_http_tunnel_module добавляет поддержку HTTP CONNECT
Одно из главных функциональных изменений — появление ngx_http_tunnel_module. Этот модуль обрабатывает HTTP/1.1 CONNECT-запросы и устанавливает сквозное виртуальное соединение. Иными словами, Nginx получает более явный механизм для сценариев forward proxy, где клиент просит прокси открыть туннель до целевого хоста.
В документации Nginx показано, что модуль использует директиву tunnel_pass, а адрес по умолчанию берётся из $host:$request_port. При этом для безопасной настройки важно ограничивать допустимые порты и хосты, например через map, потому что открытый CONNECT-прокси без ограничений быстро превращается в риск для инфраструктуры.
Для обычного сайта на Laravel, WordPress или статическом фронтенде это изменение, скорее всего, не понадобится. Но для корпоративных прокси, внутренних сетей, тестовых стендов, сетевой отладки и специализированных gateway-сценариев это заметное расширение возможностей open source Nginx.
least_time стал доступнее для балансировки upstream-серверов
В Nginx 1.31.0 появилась важная деталь для балансировки: директива least_time внутри блока upstream. Она выбирает сервер с наименьшим средним временем ответа и наименьшим числом активных соединений с учётом веса серверов. Можно ориентироваться на время получения заголовков ответа (header) или полного ответа (last_byte).
Самое интересное — в документации указано, что до версии 1.31.0 эта директива была доступна только в рамках коммерческой подписки. Теперь её можно рассматривать как практический инструмент для open source-инфраструктур, где несколько backend-серверов отличаются по скорости ответа.
Пример сценария: есть несколько PHP-FPM/API-бэкендов за Nginx. Round-robin просто распределяет запросы по очереди, least_conn смотрит на количество активных соединений, а least_time помогает учитывать фактическую скорость ответа. Это не магическое ускорение сайта, но полезный механизм для более аккуратной маршрутизации нагрузки.
HTTP/2 и HTTP/3 стали строже относиться к опасным заголовкам
В 1.31.0 Nginx начал отклонять HTTP/2 и HTTP/3-запросы с заголовками Connection, Proxy-Connection, Keep-Alive, Transfer-Encoding, Upgrade, а также TE со значением, отличным от trailers. Это изменение поведения направлено на более строгую обработку протоколов и снижение риска некорректной интерпретации hop-by-hop-заголовков.
Для большинства обычных сайтов это изменение пройдёт незаметно. Но если перед Nginx стоят нестандартные прокси, старые клиенты, самописные gateway-компоненты или экзотические балансировщики, после обновления стоит внимательно посмотреть логи ошибок и поведение запросов.
Изменения в логировании SSL снизят шум в критических сообщениях
В changelog указано, что уровень логирования некоторых SSL-ошибок понижен с crit до info. Это касается, например, invalid alert, record layer failure и сообщений вида SSL alert number N.
На практике это полезно для администраторов: не каждое странное SSL-событие означает катастрофу на сервере. Часть таких сообщений может быть связана с поведением клиентов, сетевыми сбоями или несовместимостью. Понижение уровня логирования помогает не засорять критические алерты событиями, которые не всегда требуют немедленной реакции.
stream-модуль получил proxy_ssl_alpn для более гибкого TLS-проксирования
В 1.31.0 добавлена директива proxy_ssl_alpn в stream-модуле. ALPN используется при TLS-согласовании, чтобы стороны могли договориться о протоколе, например HTTP/2 или другом протоколе поверх TLS.
Это изменение особенно интересно тем, кто использует Nginx не только как HTTP-сервер, но и как L4/L7-прокси для TCP/TLS-трафика. Для типового сайта с server { listen 443 ssl; } изменение может быть неважным, но для сложной сетевой инфраструктуры оно добавляет больше контроля.
Обновление требует проверки конфигурации, а не слепой установки
Перед переходом на 1.31.0 или 1.31.1 стоит проверить, какая ветка Nginx используется сейчас. Если сервер стоит на Ubuntu LTS и использует системный пакет, там может быть заметно более старая версия. Это не всегда плохо: дистрибутивы часто бэкпортируют security-исправления без смены крупного номера версии.
Минимальный безопасный порядок обновления выглядит так:
- Проверить текущую версию:
nginx -v- Проверить конфигурацию:
nginx -t- Сохранить копию конфигов:
sudo cp -a /etc/nginx /etc/nginx.backup.$(date +%F)- После обновления снова выполнить:
nginx -t
sudo systemctl reload nginx- Проверить error/access logs, особенно если используются HTTP/2, HTTP/3, uWSGI, SCGI, rewrite-правила, OCSP и нестандартное проксирование.
Для продакшена лучше сначала прогнать обновление на тестовом сервере или хотя бы на копии конфигурации. Особенно если Nginx обслуживает не один сайт, а несколько виртуальных хостов, API, WebSocket, gRPC или нестандартные upstream-сценарии.
Обновление до версии 1.31.0 подходит не всем, но игнорировать исправления нельзя
Если серверу нужна максимальная предсказуемость, разумнее смотреть в сторону стабильной ветки 1.30.x с актуальными security-патчами. Официальная страница Nginx указывает, что вместе с 1.31.0 mainline была выпущена и стабильная 1.30.1 с аналогичными исправлениями безопасности, а позднее вышла 1.30.2 с дополнительным security-fix.
Если же вам нужны новые возможности mainline-ветки — HTTP CONNECT, least_time в open source, изменения в HTTP/2/HTTP/3 и свежие сетевые улучшения — 1.31.x выглядит интересной веткой для тестирования и аккуратного внедрения.
Nginx 1.31.0 — это релиз, который закрывает серьёзные классы уязвимостей и двигает open source-версию ближе к более гибким прокси- и балансировочным сценариям.
