nginx 1.24

NGINX 1.24 is the stable line that incorporates the changes made during the preceding 1.23 mainline series, relative to the earlier 1.22 stable line. Its most consequential configuration-level change is the deprecation of HTTP/2 server push. The http2_push and http2_push_preload directives remain available in 1.24, but deployments using them should regard them as transitional: later NGINX lines remove HTTP/2 server-push support. The line also carries the accumulated HTTP, stream, proxy-protocol, build, compatibility, and defect fixes from that mainline work. It is an evolutionary upgrade rather than a wholesale redesign of NGINX configuration or request processing.

This cycle has reached end of life, so newly identified defects and security issues are not expected to receive fixes in 1.24. Continuing to run it leaves the service dependent on an unmaintained NGINX code line even when the host operating system, TLS libraries, container base image, or upstream services continue to change. The practical risks are unpatched vulnerabilities, defects that are fixed only in newer lines, declining compatibility with surrounding software, and a larger, less-tested jump when migration is eventually forced. HTTP/2 server-push users have an additional migration risk: retaining those directives postpones work needed for later NGINX versions, where that functionality is no longer present.

Plan a move to a currently supported NGINX line and test it first in an environment representative of production traffic. Inventory the installed package source, compile-time options, included configuration files, loaded dynamic modules, TLS settings, upstream protocols, and any third-party modules; externally built modules generally need to be rebuilt and validated for the target NGINX version. Search configuration and generated configuration for http2_push and http2_push_preload, remove or replace server-push behavior, and verify the resulting asset-loading behavior in browsers. Review the intervening NGINX change logs for directives used by the deployment, then test configuration parsing, reloads, TLS handshakes, HTTP/2 behavior, reverse-proxying, caching, rate limits, logging, and failure handling. Roll out with metrics and error-log monitoring, retain a tested rollback path, and update the base image or operating-system packaging process so subsequent NGINX upgrades are routine rather than another long-lived exception.