Публикация была переведена автоматически. Исходный язык: Русский
19 августа 2026 года вышла новая mainline-версия nginx — 1.31.4. Релиз небольшой по числу пунктов, но разноплановый: новая возможность в транспортных модулях, изменение поведения при проксировании на бэкенды по HTTP/2 и gRPC и несколько исправлений, среди которых устранение регрессии месячной давности. Раздела Security в этой версии нет — в отличие от двух предыдущих релизов ветки.
PROXY protocol версии 2 в stream и mail
Главное новшество: директива proxy_protocol в модулях stream и mail теперь поддерживает вторую версию протокола PROXY — раньше эти модули умели только первую.
Протокол PROXY решает известную проблему: когда перед сервисом стоит балансировщик, приложение видит его адрес, а не адрес реального клиента. Протокол передаёт исходный адрес и порт отдельным заголовком в начале соединения. Для stream-модуля это про проксирование произвольного TCP и UDP, для mail-модуля — про почтовые прокси, где потеря адреса клиента ломает и антиспам-логику, и разбор инцидентов. Поддержка второй версии снимает ограничение на стыке с балансировщиками и облачными сервисами, которые давно отдают именно её.
Заголовки при проксировании стали единообразными
Второй пункт помечен в списке изменений как Change, а не Bugfix, и это важный сигнал: поведение сервера изменилось. Теперь запросы к бэкендам по HTTP/2 и gRPC всегда отправляются с псевдозаголовком «:authority», а запросы по HTTP/1.1 — с заголовком «Host».
Формально это приведение к букве спецификаций: в HTTP/2 имя виртуального хоста передаётся именно псевдозаголовком, а не обычным полем. Практически же смешение двух вариантов раньше давало трудноуловимые расхождения: если бэкенд или система сбора логов ожидали одно поле, а получали другое, поведение зависело от версии протокола на конкретном участке.
Исправления: select, неполные ответы gRPC и совместимость модулей
Список исправлений в 1.31.4 короткий, но каждый пункт по делу:
- устранено аварийное завершение рабочего процесса при использовании метода обработки соединений select;
- неполные ответы gRPC с ненулевым Content-Length теперь считаются некорректными — раньше оборванный ответ мог быть принят как валидный;
- восстановлена бинарная совместимость со сторонними модулями, использующими script codes; дефект, как указано в списке изменений, появился в версии 1.31.3;
- исправления в модуле для Perl, а также в HTTP/2, HTTP/3, модуле фильтра изображений и модуле gRPC.
Для сравнения: релиз 1.31.3 от 15 июля 2026 года закрывал три уязвимости, среди них переполнение буфера в куче при работе директивы map с регулярными выражениями, а релиз 1.31.2 от 17 июня 2026 года — ещё три, включая дефект в обработке сессий QUIC. На этом фоне 1.31.4 выглядит как передышка.
Что это значит на практике
Первое, на что стоит смотреть при обновлении, — изменение с заголовками. Если в схеме есть проксирование по HTTP/2 или gRPC, проверьте, на какое поле опирается бэкенд при выборе виртуального хоста, маршрутизации и записи логов. Приложения, читающие Host напрямую из окружения, а не через фреймворк, нормализующий оба варианта, — первые кандидаты на сюрприз. То же касается правил доступа, написанных по имени заголовка.
Второе — сторонние модули. Если nginx собирается с внешними модулями и вы уже перешли на 1.31.3, обновление обязательно, но модули нужно пересобрать и прогнать тестами: несовпадение здесь проявляется не ошибкой при старте, а неправильной работой в бою.
Третье — исправление в методе select актуально не для типовой Linux-инсталляции, где по умолчанию работает epoll, а для сборок под другие платформы и конфигураций, где метод задан явно. Стоит проверить, что в конфиге не осталось унаследованной директивы use.
И общий совет: mainline — ветка активной разработки, и регрессия в 1.31.3 напоминает, почему такие обновления стоит сначала прогонять на канареечном узле с реальным профилем трафика.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальный файл изменений CHANGES проекта nginx.
19 августа 2026 года вышла новая mainline-версия nginx — 1.31.4. Релиз небольшой по числу пунктов, но разноплановый: новая возможность в транспортных модулях, изменение поведения при проксировании на бэкенды по HTTP/2 и gRPC и несколько исправлений, среди которых устранение регрессии месячной давности. Раздела Security в этой версии нет — в отличие от двух предыдущих релизов ветки.
PROXY protocol версии 2 в stream и mail
Главное новшество: директива proxy_protocol в модулях stream и mail теперь поддерживает вторую версию протокола PROXY — раньше эти модули умели только первую.
Протокол PROXY решает известную проблему: когда перед сервисом стоит балансировщик, приложение видит его адрес, а не адрес реального клиента. Протокол передаёт исходный адрес и порт отдельным заголовком в начале соединения. Для stream-модуля это про проксирование произвольного TCP и UDP, для mail-модуля — про почтовые прокси, где потеря адреса клиента ломает и антиспам-логику, и разбор инцидентов. Поддержка второй версии снимает ограничение на стыке с балансировщиками и облачными сервисами, которые давно отдают именно её.
Заголовки при проксировании стали единообразными
Второй пункт помечен в списке изменений как Change, а не Bugfix, и это важный сигнал: поведение сервера изменилось. Теперь запросы к бэкендам по HTTP/2 и gRPC всегда отправляются с псевдозаголовком «:authority», а запросы по HTTP/1.1 — с заголовком «Host».
Формально это приведение к букве спецификаций: в HTTP/2 имя виртуального хоста передаётся именно псевдозаголовком, а не обычным полем. Практически же смешение двух вариантов раньше давало трудноуловимые расхождения: если бэкенд или система сбора логов ожидали одно поле, а получали другое, поведение зависело от версии протокола на конкретном участке.
Исправления: select, неполные ответы gRPC и совместимость модулей
Список исправлений в 1.31.4 короткий, но каждый пункт по делу:
- устранено аварийное завершение рабочего процесса при использовании метода обработки соединений select;
- неполные ответы gRPC с ненулевым Content-Length теперь считаются некорректными — раньше оборванный ответ мог быть принят как валидный;
- восстановлена бинарная совместимость со сторонними модулями, использующими script codes; дефект, как указано в списке изменений, появился в версии 1.31.3;
- исправления в модуле для Perl, а также в HTTP/2, HTTP/3, модуле фильтра изображений и модуле gRPC.
Для сравнения: релиз 1.31.3 от 15 июля 2026 года закрывал три уязвимости, среди них переполнение буфера в куче при работе директивы map с регулярными выражениями, а релиз 1.31.2 от 17 июня 2026 года — ещё три, включая дефект в обработке сессий QUIC. На этом фоне 1.31.4 выглядит как передышка.
Что это значит на практике
Первое, на что стоит смотреть при обновлении, — изменение с заголовками. Если в схеме есть проксирование по HTTP/2 или gRPC, проверьте, на какое поле опирается бэкенд при выборе виртуального хоста, маршрутизации и записи логов. Приложения, читающие Host напрямую из окружения, а не через фреймворк, нормализующий оба варианта, — первые кандидаты на сюрприз. То же касается правил доступа, написанных по имени заголовка.
Второе — сторонние модули. Если nginx собирается с внешними модулями и вы уже перешли на 1.31.3, обновление обязательно, но модули нужно пересобрать и прогнать тестами: несовпадение здесь проявляется не ошибкой при старте, а неправильной работой в бою.
Третье — исправление в методе select актуально не для типовой Linux-инсталляции, где по умолчанию работает epoll, а для сборок под другие платформы и конфигураций, где метод задан явно. Стоит проверить, что в конфиге не осталось унаследованной директивы use.
И общий совет: mainline — ветка активной разработки, и регрессия в 1.31.3 напоминает, почему такие обновления стоит сначала прогонять на канареечном узле с реальным профилем трафика.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальный файл изменений CHANGES проекта nginx.
Поделиться
