Last checked and updated on 05 Jun 2026
What Is New in NGINX 1.1
| Category | Key Changes |
|---|---|
| New Features | WebSocket protocol support, SPDY protocol support |
| Core Improvements | Enhanced keepalive connections, backend SSL session reuse |
| Module Updates | Limit_req module speed fix, proxy module WebSocket handling |
| Bug Fixes | Resolver fixes, memory leak fixes, various core fixes |
What core protocol support was added in 1.1?
NGINX 1.1 introduced native support for two major protocols: WebSocket and SPDY. The WebSocket implementation allows NGINX to properly handle the HTTP Upgrade mechanism required for real-time bidirectional communication. SPDY support laid the groundwork for what would eventually become HTTP/2, offering reduced latency through multiplexing and compression.
In practice, this meant you could suddenly use NGINX as a reverse proxy for WebSocket applications without needing complex workarounds. The proxy module was updated to correctly pass the Connection and Upgrade headers, which are essential for the WebSocket handshake to succeed between client and backend.
How did connection handling improve?
The keepalive mechanism for both client and upstream connections received significant enhancements. Previously, HTTP/1.0 was used for upstream connections, but 1.1 switched to HTTP/1.1 by default, allowing persistent connections to backends.
This change drastically reduces the TCP handshake overhead between NGINX and your application servers. For high-traffic sites, this translates to lower CPU usage and better overall throughput because connections are reused instead of being constantly torn down and reestablished.
What performance optimizations were included?
Beyond keepalive improvements, NGINX 1.1 added SSL session reuse to upstream servers. This means SSL/TLS handshakes to backends can be resumed much faster, eliminating one of the major performance penalties of encrypting traffic between NGINX and your apps.
The limit_req module also got a fix for its "speed" parameter. This correction made rate limiting more accurate and reliable, ensuring that request bursting was controlled exactly as configured instead of allowing slightly more requests through than intended.
Were there any critical bug fixes?
Yes, several important stability issues were resolved. The resolver component was fixed to prevent crashes that could occur under specific conditions. Memory leaks were patched in the SSL module and in the error page creation process, which helped long-running processes maintain stable memory usage.
Other fixes addressed issues with proxy pass redirects, header filtering, and the handling of conditional requests. These weren't flashy changes, but they made the core engine more robust for production workloads where stability is non-negotiable.
FAQ
Does NGINX 1.1 automatically handle WebSocket connections?
Yes, the proxy module was updated to properly handle the Connection and Upgrade headers required for WebSocket protocol negotiation. You still need to configure the appropriate proxy_set_header directives, but the core support is now built-in.
What's the benefit of SSL session reuse to upstream servers?
It significantly reduces TLS handshake overhead. By reusing SSL sessions, NGINX avoids the expensive cryptographic operations required for full handshakes, resulting in lower latency and reduced CPU usage on both NGINX and your backend servers.
Is the SPDY protocol in 1.1 the same as HTTP/2?
SPDY was the precursor to HTTP/2 and shares many concepts like multiplexing and header compression. While not identical, the SPDY implementation in 1.1 provided the foundation that would later evolve into full HTTP/2 support in subsequent releases.
How did the keepalive changes affect performance?
Moving from HTTP/1.0 to HTTP/1.1 for upstream connections means persistent connections are maintained between NGINX and backend servers. This eliminates repetitive TCP and SSL handshakes, reducing latency and improving throughput for busy sites.
Were there any breaking changes in 1.1?
Most changes were additive, but the keepalive behavior modification could affect applications that relied on the previous HTTP/1.0 behavior. The bug fixes also changed some edge case behaviors, though these were corrections rather than intentional breaking changes.