nginx 1.28

NGINX 1.28 is the stable line that incorporates the development and fixes from the preceding 1.27 mainline series, replacing the earlier 1.26 stable baseline. Notable inherited capabilities include variable-based rate limits for proxied, FastCGI, SCGI, and uWSGI responses, and proxy_pass_trailers for passing selected upstream response trailers to clients. The line also carries the accumulated HTTP, stream, TLS, resolver, QUIC/HTTP/3, and upstream-handling fixes made during that mainline cycle. Existing configurations are generally portable, but deployments that use dynamic modules, non-default build options, custom patches, TLS providers, HTTP/3, or third-party modules need compatibility testing against the exact replacement build.

This cycle has reached end of life. The NGINX project no longer provides ongoing fixes for defects or security issues in this line, so newly identified problems may remain unresolved unless an operating-system or commercial package vendor independently backports a patch. Staying on 1.28 also increases operational risk when newer client behavior, TLS libraries, operating systems, or upstream services expose defects fixed only in maintained NGINX releases. Local patches and unsupported module rebuilds can reduce short-term exposure, but they create a separate maintenance burden and do not restore upstream support.

Inventory every NGINX instance, its source or package origin, enabled modules, compile-time options, configuration includes, certificates, and traffic roles. Select a currently maintained NGINX release and a supported package source, then compare its documented directive and module compatibility with the deployed configuration. Rebuild or replace any dynamic and third-party modules for the target version rather than reusing old binaries. Test configuration parsing, reload behavior, TLS negotiation, HTTP/2 and HTTP/3 where enabled, proxying, caching, rate limiting, authentication, logging, and health checks in a representative environment. Roll out through a canary or staged pool, monitor error logs, upstream failures, latency, and connection behavior, and retain a tested rollback path until the upgraded fleet is stable.