The latest NGINX open source updates arrive as a pair. NGINX 1.29.3 delivers new capabilities around TLS observability, header management, and TLS handshake efficiency. NGINX 1.29.4 adds new privacy enhancements and improved security.
Across the two releases, we’re focused on:
- Support for HTTP/2 protocol to upstreams
- New TLS signature algorithm variables for better observability
- Header inheritance control that simplifies configuration management in nested blocks
- TLS certificate compression support in BoringSSL and AWS-LC builds
- Encrypted Client Hello (ECH) support for enhanced privacy
- Stricter HTTP chunked transfer encoding parsing for improved security
Together, these updates make it easier for operators, security teams, and developers to maintain secure, efficient, and predictable infrastructure at scale.
HTTP/2 to Upstream Support
NGINX 1.29.4 adds native support for HTTP/2 connections to upstream servers (#771). This is one of the most requested features in NGINX’s history, and it enables true end-to-end HTTP/2 communication between clients and backend servers.
Previously, even when clients connected to NGINX using HTTP/2, NGINX would require a downgrade of those connections to HTTP/1.0 when proxying to upstream servers. This meant backends couldn’t take advantage of HTTP/2’s protocol-level improvements for the upstream leg of the connection.
Example:
upstream backend {
server api.example.com:8443;
keepalive 64; # a keepalive should be set when connecting via http/1.1 or http/2
}
server {
listen 443 ssl;
http2 on;
ssl_certificate server.crt;
ssl_certificate_key server.key;
location / {
proxy_pass https://backend;
proxy_http_version 2;
}
}Why it matters: HTTP/2 brings significant performance benefits including header compression via HPACK, which reduces overhead for requests with large or repetitive headers. For backends that are optimized for HTTP/2, eliminating the protocol downgrade at the proxy layer means those optimizations now apply across the entire request path.
Who it helps:
- Teams running HTTP/2-native backend services (gRPC, modern application servers)
- Operators looking to reduce latency and overhead in proxy-to-backend communication
- Anyone with backend services that benefit from HTTP/2’s header compression
Current limitations: This initial implementation does not yet support HTTP/2 multiplexing, which means each upstream connection handles one request at a time rather than interleaving multiple requests on a single connection. Multiplexing support is planned for future releases. Even without multiplexing, the header compression benefits of HTTP/2 are available immediately.
TLS Signature Algorithm Visibility
With 1.29.3, NGINX now exposes variables that show which signature algorithms were negotiated during a TLS handshake for both client and server sides. You can log these values or use them in conditional logic to verify which cryptography is actually in use on live connections.
These variables require OpenSSL 3.5 or higher. With older versions, the variable value will be an empty string.
Example:
log_format main '$remote_addr - $ssl_sigalg - $ssl_client_sigalg';
access_log /var/log/nginx/access.log main; Why it matters: Visibility into negotiated signature algorithms helps teams confirm they’re enforcing modern crypto (like ECDSA or Ed25519) and identify outdated or misconfigured clients without packet captures or manual inspection.
Who it helps:
- Security engineers auditing TLS configurations and algorithm usage
- Platform teams standardizing encryption policies across clusters
- SREs monitoring real-world handshake behavior during rollouts
Header Inheritance Control in Nested Blocks
In previous versions, defining add_header inside a nested block (like location) would replace headers defined at a higher level (like server). As a result, global headers could silently disappear unless they were re-declared. This sometimes broke security headers or created hard-to-debug config drift.
With 1.29.3, NGINX introduces the add_header_inherit directive, which lets you control this behavior explicitly. When set to merge, global headers remain intact and are combined with headers defined at the current level unless you explicitly override them.
Example:
server {
add_header_inherit merge;
add_header X-Frame-Options "DENY";
location /api/ {
add_header Content-Security-Policy "default-src 'self'";
}
} With add_header_inherit merge; in place, both X-Frame-Options and Content-Security-Policy headers are returned to the client. Without it, the old behavior applies and only the Content-Security-Policy header would be sent for /api/ requests.
Why it matters: This change reduces configuration surprises and makes it easier to combine global security headers (HSTS, CSP, and others) with per-application overrides without having to duplicate headers in every location block.
Who it helps:
- Developers managing per-route headers
- Security and compliance teams defining organization-wide header standards
- Platform engineers maintaining shared multi-tenant NGINX configurations
TLS Certificate Compression (BoringSSL and AWS-LC Builds)
The ssl_certificate_compression directive was introduced in 1.29.1 for OpenSSL 3.2+ builds. With 1.29.3, certificate compression is now also available for builds using BoringSSL or AWS-LC. This compresses the certificate chain before transmission, reducing the size of TLS handshakes, especially when chains include multiple intermediates or stapled OCSP responses.
Example:
ssl_certificate_compression on;Why it matters: Smaller handshakes mean faster connection setup and reduced bandwidth usage, which can translate into better performance for APIs, edge services, and mobile clients operating on slower or bursty networks.
Who it helps:
- Performance engineers optimizing TLS for latency-sensitive workloads
- Operators managing large-scale, high-connection environments
- Developers building applications where every millisecond and kilobyte count
A note on browser compatibility: RFC 8879 defines three compression algorithms for TLS certificate compression: zlib, Brotli, and zstd. NGINX’s current implementation uses zlib, while Chrome and Chromium-based browsers only advertise support for Brotli. Because certificate compression requires both client and server to agree on an algorithm, Chrome connections will not benefit from this feature until NGINX adds Brotli support or Chrome adds zlib support. Safari uses zlib, so certificate compression will work for Safari users.
Encrypted Client Hello (ECH) Support
NGINX 1.29.4 adds support for Encrypted Client Hello (ECH), a TLS 1.3 extension that encrypts the Server Name Indication (SNI) field during the TLS handshake. Without ECH, the SNI is sent in plaintext, revealing which website a user is connecting to even though the rest of the connection is encrypted. ECH addresses this privacy gap by encrypting the entire ClientHello message, including the SNI.
Example:
server {
ssl_ech_file /path/to/ech-keys.pem;
# ... other SSL configuration
} The ssl_ech_file directive specifies a PEM file containing ECH configuration and private keys. Multiple files can be specified to support key rotation, which is a common operational pattern. Cloudflare, for example, rotates ECH keys hourly.
Why it matters: ECH is a significant step forward for internet privacy. It prevents passive observers from determining which sites users visit based on TLS handshake metadata. This is particularly valuable for privacy-conscious deployments and environments where metadata leakage is a concern.
Who it helps:
- Privacy-focused organizations and services
- Operators in regions where connection metadata may be monitored
- Anyone deploying services where user privacy is a priority
Platform requirements: ECH support requires building NGINX against OpenSSL’s ECH feature branch. ECH is expected to be included in OpenSSL 4.0 (anticipated April 2026). The feature is available for both HTTP and Stream modules, and NGINX exposes $ssl_ech_status and $ssl_ech_outer_server_name variables for logging and conditional logic.
Stricter Chunked Transfer Encoding Parsing
NGINX 1.29.4 tightens how chunked transfer encoding is parsed by disabling support for bare LF (line feed) characters as line terminators in chunked message bodies. Previously, NGINX would accept either CRLF (carriage return + line feed) or a bare LF as the line terminator in chunked encoding. Going forward, NGINX requires the CRLF sequence specified by the HTTP/1.1 RFC.
Why we’re making this change: This change reflects a deliberate shift in philosophy from optimizing for compatibility to optimizing for security. While HTTP specifications have historically recommended that tolerant applications accept bare LF line terminators, this guidance applies to start lines and header fields, not to chunked transfer encoding. RFC errata ID 7633 explicitly reaffirms that strict CRLF parsing in chunked encoding is intentional “because it does not have to retain backwards compatibility with 1.0 parsers.”
More importantly, lenient parsing of chunked encoding can create conditions for HTTP request smuggling attacks in complex proxy chains. When different components in a request path interpret message boundaries differently, attackers can exploit this ambiguity to inject malicious requests. By enforcing strict RFC compliance, NGINX reduces the attack surface for these kinds of vulnerabilities.
Industry context: This is not a change unique to NGINX. The security community has increasingly focused on chunked encoding parsing as a vector for request smuggling. Other major infrastructure vendors have made comparable changes to their HTTP parsing and we agree that stricter adherence to the specification is the right path forward.
What operators should know: Most well-behaved HTTP clients and intermediaries already use CRLF line terminators, so this change should be transparent for the vast majority of deployments. However, if you have legacy systems or custom tooling that sends bare LF in chunked bodies, those requests will now be rejected with a 400 Bad Request response. We recommend testing your request chain to confirm compatibility before upgrading.
Who it helps:
- Security teams concerned about request smuggling in proxy architectures
- Organizations with strict compliance requirements for HTTP handling
- Anyone operating NGINX in a multi-tier environment with other proxies or load balancers
Wrapping Up
NGINX Open Source 1.29.3 and 1.29.4 continue our efforts to make secure, high-performance deployments easier to manage and to make NGINX more observable, predictable, and production-ready. Whether you’re tightening TLS compliance, streamlining configuration, or standardizing on 1.29.x for new environments, this pair of releases adds practical tools and refinements that show up in day-to-day operations.
You can view all updates and fixes in the GitHub milestones:
- 1.29.3 milestone → https://github.com/nginx/nginx/milestone/7?closed=1
- 1.29.4 milestone → https://github.com/nginx/nginx/milestone/8?closed=1
Download 1.29.4 and view full changelog.
