21 октября 2026 года на nginx.org вышла основная ветка nginx 1.31.8. В шапке сайта рядом с датой одна фраза: mainline version has been released. Стабильная ветка на странице загрузки в тот же день остаётся 1.30.6. В CHANGES у 1.31.8 нет блока Security и нет новых CVE.
Пять дыр от 14 октября закрыты раньше, в 1.31.7 и в стабильной 1.30.6. Разбор той пары лежит отдельно: nginx 1.31.7 и 1.30.6. У сегодняшнего номера другой список. Относительный путь в working_directory теперь считается от prefix. Кривой каталог отсекается, пока конфигурация ещё читается, а не после того, как воркеры уже поднялись. На платформах со строгим выравниванием HTTP/3 мог завершать процесс по SIGBUS. При kernel TLS и OpenSSL 3.2.0 или новее в лог при закрытии SSL попадала строка recv() failed (5: Input/output error). Дальше в том же списке внутренний JSON-парсер и сборка с --with-control-api на Solaris.
Архив Ubuntu и архив Debian этот номер сами не привезут. Он лежит в mainline-репозитории nginx.org. В пуле Ubuntu пакет nginx 1.31.8-1 собран для jammy, noble и resolute, архитектуры amd64 и arm64. В пуле Debian тот же 1.31.8-1 для bookworm и trixie, тоже amd64 и arm64. Если в sources.list уже есть packages/mainline, apt-cache policy nginx покажет кандидата 1.31.8-1 с origin nginx.org. Репозиторий packages без слова mainline смотрит на stable. Туда 1.31.8 не кладут: на странице загрузки stable по-прежнему 1.30.6.
Рядом с пакетами на странице загрузки лежат исходники nginx-1.31.8.tar.gz и сборка nginx/Windows-1.31.8. Подпись pgp у обоих файлов на той же странице. Пока nginx -v печатает 1.31.7 или старше, ни одна из сегодняшних правок в процесс не попала. Номер в анонсе и номер в nginx -v после обновления должны совпасть. Пакет из архива дистрибутива с версией 1.24 или 1.26 этим релизом не становится, даже если apt upgrade сказал, что nginx уже новый.
working_directory считается от prefix
Директива из модуля ядра задаёт текущий каталог воркера. В документации она нужна в первую очередь, чтобы процесс мог записать core-файл: у пользователя воркера должна быть запись в этот каталог. Сайт на WordPress, nginx и php-fpm чаще всего строку не задаёт. Тогда смена базы пути конфиг не задевает, и ради одного только prefix обновление можно отложить.
Если строка есть, смотрите первый символ. В 1.31.8 значение приводится к полному пути от prefix. Путь, который начинается с /, остаётся как написан: /var/lib/nginx/cores так и будет /var/lib/nginx/cores. Путь без начального слэша склеивается с prefix. Какой prefix у этой сборки, печатает nginx -V, аргумент --prefix=. У пакета nginx.org и у пакета из архива дистрибутива prefix часто разный. Берите значение из своего nginx -V.
Раньше тот же относительный путь считался от текущего каталога процесса. У сервиса systemd текущий каталог часто /. Каталог cores при этом искался как /cores, а не как каталог внутри prefix. После обновления он ищется уже от prefix. Каталога там нет, и конфигурация не применяется. Это как раз тот случай, когда «вчера reload проходил» после смены бинарника перестаёт проходить, хотя файл конфига вы не трогали.
Вторая половина той же правки про отказ, а не про новый синтаксис. В CHANGES прямо сказано: воркеры выходили на старте или при перечитывании, если в working_directory был неверный каталог. В 1.31.8 каталог проверяется, пока конфигурация ещё читается. Путь не открывается: в лог уходит emerg, в тексте stat() и имя пути. Открылся файл, а не каталог: строка is not a directory. nginx -t показывает это до reload. Ошибочный reload старые воркеры не подменяет.
Если каталог был на месте во время -t и пропал к старту воркера, процесс всё ещё завершится. В логе alert chdir(...) failed, код выхода 2. Проверка на чтении конфига этот поздний случай не отменяет. Каталог для core-файлов лучше держать абсолютным путём и не удалять его между reload и стартом воркеров. Относительное имя после 1.31.8 живёт уже от prefix, и «как вчера от корня» больше не работает.
Перед правкой скопируйте файл конфигурации. Путь к нему тоже в nginx -V, аргумент --conf-path=. Копия рядом, с датой в имени. Потом правка, потом -t, потом reload. restart в обход проверки здесь не нужен: при битом каталоге он как раз может оставить мастер без рабочих процессов. php-fpm из-за этой директивы перезапускать не надо. Каталог воркера nginx к пулу FPM не относится, и сайт на WordPress из-за самого факта reload nginx сессии в базе не теряет.
HTTP/3 и SIGBUS
Воркер мог завершиться по сигналу SIGBUS, когда использовался HTTP/3, и только на платформах со строгим выравниванием. В CHANGES благодарность Daewoo Choi. CVE у строки нет. Оценки severity тоже нет: это bugfix основной ветки, не строка Security.
Сначала сборка. В выводе nginx -V ищите http_v3_module. Нет модуля, значит бинарник HTTP/3 не содержит, и SIGBUS из этой правки ему не грозит. Модуль в сборке ещё не значит, что сайт принимает QUIC. Пока HTTP/3 в конфиге выключен, воркеры этот код не исполняют. Типичный виртуальный хост WordPress слушает 443 с ssl и отдаёт PHP в php-fpm. QUIC к этому сам не приклеивается.
В CHANGES платформа названа одной формулой: строгое выравнивание. Если воркеры живы и в error.log нет SIGBUS, переходить с 1.31.7 на 1.31.8 только из-за этой строки незачем. Если HTTP/3 включён и воркеры уже падают с SIGBUS, как раз этот бинарник. Падение воркера снаружи выглядит как оборванные соединения, пока мастер не поднимет процесс снова. К proxy_cache и к FastCGI-кэшу WordPress эта строка отношения не имеет.
recv() failed при kernel TLS
Третья ошибка выглядит как шум, и из-за этого её легко списать на сеть. При закрытии SSL-соединения в лог могли сыпаться сообщения recv() failed (5: Input/output error). Условие из CHANGES узкое: kernel TLS и OpenSSL 3.2.0 или новее. Пятёрка в скобках это код Input/output error, он уже написан в тексте сообщения. Новой дыры здесь нет. Соединение закрывалось, alert был ложный.
Смотреть две вещи. nginx -V и кусок built with OpenSSL. Если версия старше 3.2.0, эта строка не из сегодняшнего бага. И сам error.log: есть ли фраза recv() failed (5: Input/output error) именно на закрытии SSL. Пока фразы нет, mainline ради тишины в логе можно не трогать. Если фраза есть и OpenSSL в сборке 3.2.0 или новее, 1.31.8 как раз убирает этот alert. Отключать TLS, чтобы лог замолчал, не нужно. Сертификат и ssl_certificate эта правка не меняет.
JSON-парсер и сборка на Solaris
Первый пункт CHANGES помечен как изменение внутреннего API. Парсер JSON теперь отдаёт строки с escape-последовательностями отдельными событиями. Функция ngx_json_unescape_string() раскодирует такую строку в отдельный буфер. Буфер на входе должен быть не короче исходной строки. На успехе в нём длина уже без escape. Кривая последовательность даёт ошибку.
В заголовках 1.31.8 обычная строка и строка со escape разведены по разным событиям, то же для ключа объекта. Свой динамический модуль, собранный против парсера 1.31.7, с этим бинарником лучше пересобрать и заново подключить через load_module. Модуль из того же тарбола, что и nginx 1.31.8, едет уже с новым парсером. Сайт, который только проксирует PHP в php-fpm, функцию ngx_json_unescape_string() не вызывает. Переписывать location из-за этого пункта не нужно.
Сборка на Solaris с ключом --with-control-api в 1.31.8 снова проходит. В предыдущей основной версии она ломалась. Сам Control API в основной ветке с 1.31.5. На Ubuntu и Debian готовый пакет этот ключ не требует: бинарник уже собран. Воркер на VPS из-за солнцевской правки не меняет ни proxy_pass, ни сокет php-fpm.
nginx -V и пакет 1.31.8-1
Сначала поставьте бинарник, потом проверяйте. Пока в PATH лежит старый nginx, -t проверяет старое поведение пути. Имеет смысл смотреть и версию, и откуда она приехала. Кандидат 1.31.8-1 с origin nginx.org и словом mainline в строке репозитория как раз этот релиз. Кандидат из archive.ubuntu.com или из debian.org им не является.
nginx -v nginx -V 2>&1 | tr ' ' '\n' | grep -E 'prefix=|conf-path=|openssl|http_v3_module' sudo nginx -T 2>/dev/null | grep working_directory apt-cache policy nginx sudo nginx -t && sudo systemctl reload nginx
reload в последней строке не выполнится, если nginx -t вернул ошибку. Так и задумано. Если тест ругается на stat() или is not a directory, поправьте путь или заведите каталог, снова -t, и только потом reload. systemctl restart nginx вместо этой связки не запускайте. Копию конфига, если путь пришлось менять, вы уже положили рядом до правки.
Кому уже стоит mainline 1.31.7 и в конфиге относительный working_directory, обновиться стоит до следующего reload: путь начнёт считаться от prefix, и -t это поймает. Кому хватает стабильной 1.30.6, HTTP/3 выключен, а строки про Input/output error в логе нет, номер 1.31.8 можно не ставить. Дыры от 14 октября в 1.30.6 уже закрыты. Сегодняшние четыре bugfix и смена базы пути в стабильную ветку не входили.
