How to Enable HTTP/2 in Nginx: Complete Config Guide with SSL & Server Push

How to Enable HTTP/2 on Nginx Web Server

Table of Contents

Verified by Priya Mervana, SSL Security Researcher at SSLInsights - Last reviewed: June 2026 | Based on SSL/TLS and server infrastructure analysis across web security and DevOps environments.

QUICK DEFINITION

HTTP/2 is the second major version of the HTTP network protocol, standardized in RFC 7540, that replaces HTTP/1.1's text-based request model with binary framing and full multiplexing over a single TCP connection. Unlike HTTP/1.1, where each asset requires a separate connection handshake, HTTP/2 sends CSS, JS, fonts, and images simultaneously. The practical result: page load times drop 20–50% on asset-heavy sites when the server is correctly configured.

How to enable HTTP/2 on Nginx requires three concrete steps: add http2 to the listen directive, confirm your SSL configuration meets TLS 1.2/1.3 requirements, and restart Nginx. This guide covers each step with exact configuration blocks, explains what is HTTP/2 and how does it work, shows how to verify activation with curl, and walks through server push, tuning, and fallback handling - all for Nginx 1.9.5+.

Is HTTP/2 faster than HTTP/1.1?

In controlled benchmarks, HTTP/2 reduces page load time by 20–50% on sites with 20+ assets, primarily through multiplexing and header compression. A single persistent connection replaces dozens of sequential HTTP/1.1 handshakes.

Also Read: How to Enable HTTP/2 on IIS Web Server (Step-by-Step Guide)

Does HTTP/2 Require an SSL Certificate on Nginx?

Yes - does HTTP/2 work without HTTPS is one of the most common configuration questions, and the answer is: not in practice. While the HTTP/2 specification technically allows unencrypted connections (h2c), every major browser enforces HTTPS-only for HTTP/2. Nginx requires a valid SSL certificate installed before the http2 parameter in the listen directive will function for browser traffic.

What Nginx version supports HTTP/2?

Nginx 1.9.5 (released September 2015) introduced native HTTP/2 support. Run nginx -v to confirm your installed version. Nginx 1.25.1+ additionally supports HTTP/3 over QUIC, but that is a separate configuration path.

Before proceeding, confirm:

  • Nginx 1.9.5 or higher (nginx -v)
  • OpenSSL 1.0.2 or higher (openssl version)
  • A valid SSL/TLS certificate bound to your domain

Step-by-Step Guide to Enable HTTP/2 on Nginx Web Server

Step 1: How to Enable HTTP/2 on Nginx - Modify the Listen Directive

The Nginx configuration file lives at /etc/nginx/nginx.conf or /usr/local/nginx/conf/nginx.conf. Open the server block for your HTTPS site and change the listen directive to include http2:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    # ... remaining configuration
}

This single parameter instructs Nginx to negotiate HTTP/2 with clients that support it, while falling back transparently to HTTP/1.1 for older user agents. If you run multiple server blocks, update each one independently - the http2 flag applies per-block, not globally.

How to enable HTTP/2 in Nginx Ubuntu follows the same directive regardless of distribution. On Ubuntu 22.04 and 24.04 with the default apt Nginx package, the binary includes HTTP/2 support out of the box. On older Ubuntu 18.04 installs with Nginx below 1.9.5, add the official Nginx PPA first: sudo add-apt-repository ppa:nginx/stable.

Step 2: How to Configure SSL for HTTP/2 Nginx

How to configure SSL for HTTP/2 Nginx means enforcing TLS 1.2 or 1.3 and selecting cipher suites that provide forward secrecy. HTTP/2 blacklists weak ciphers (defined in RFC 7540 Appendix A), so misconfigured SSL settings will cause connection failures even after adding the http2 flag.

Add or confirm these directives in your server block:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve secp384r1;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

OCSP stapling (ssl_stapling on) is particularly important for HTTP/2 performance: it eliminates the client's separate round-trip to the CA for certificate revocation checks, shaving 100–300ms from TLS handshake time.

In SSLInsights' analysis of Nginx deployments, the single most common HTTP/2 activation failure comes from servers running TLS 1.0 or 1.1 with RC4 or DES cipher suites - both are on HTTP/2's blacklist. The fix is the cipher block above.

Step 3: Restart Nginx and Apply Configuration

Test the configuration syntax before restarting - a malformed directive will take your site offline:

sudo nginx -t

Expected output: nginx: configuration file /etc/nginx/nginx.conf test is successful. If errors appear, the output will identify the file and line number.

Apply the new configuration:

# Linux (systemd)
sudo systemctl restart nginx

# Linux (init.d)
sudo service nginx restart

# Windows
nginx -s reload

How to Check If HTTP/2 Is Enabled on Nginx

How to check if HTTP/2 is enabled on Nginx uses two methods: curl and browser DevTools.

Method 1: curl

curl -I --http2 https://yourdomain.com

Look for HTTP/2 200 in the response headers. If you see HTTP/1.1 200, HTTP/2 is not active - return to Step 1 and verify the listen directive.

Method 2: Browser DevTools

Open Chrome or Firefox DevTools → Network tab → reload the page → right-click any column header → enable "Protocol". Requests served over HTTP/2 display h2 in the Protocol column.

Method 3: Online tools

tools.keycdn.com/http2-test provides an external verification without requiring shell access.

How to test HTTP/2 with curl is the fastest diagnostic when browser access is unavailable - particularly useful in CI/CD pipelines or automated deployment verification.

What Is HTTP/2 Server Push and When Should You Use It

What is HTTP/2 server push is a mechanism that lets Nginx preemptively send assets to the client's cache before the browser requests them. When a user requests index.html, the server can simultaneously push style.css and app.js - eliminating the round-trip between HTML parse and asset discovery.

HTTP/2 server push best practices center on restraint. Push 2–6 critical above-the-fold assets maximum. Pushing more than that wastes bandwidth and can block page render if the browser throttles non-critical pushed assets.

Configure server push in Nginx:

server {
    listen 443 ssl http2;

    location = / {
        http2_push /css/style.css;
        http2_push /js/app.js;
        root /var/www/html;
        index index.html;
    }

    location /css/style.css {
        root /var/www/html;
    }
}

Use Nginx's $http2 variable to restrict push to HTTP/2 clients only:

if ($http2) {
    http2_push /css/style.css;
}

Tuning Nginx for HTTP/2 Performance

Nginx worker_connections for HTTP/2

Nginx worker_connections for HTTP/2 needs a significant increase from Nginx's default of 512. HTTP/2 multiplexes thousands of requests over a single connection, but each multiplexed stream still consumes a worker connection slot. Set worker_connections relative to your traffic volume:

events {
    worker_connections 8000;
    use epoll;        # Linux
    # use kqueue;     # FreeBSD / macOS
}

epoll (Linux) and kqueue (BSD/macOS) are event notification interfaces that outperform the default select() mechanism under high concurrency - this matters specifically for HTTP/2 because a single client connection holds open far longer than under HTTP/1.1.

Nginx HTTP/2 Timeout Settings

Nginx HTTP/2 timeout settings require adjustment because HTTP/2 connections are persistent and multiplexed. The HTTP/1.1-era defaults of 60 seconds are too aggressive:

http {
    keepalive_timeout 300s;
    client_header_timeout 300s;
    client_body_timeout 300s;
    send_timeout 300s;
}

Increase Header Buffer Size

HTTP/2 uses HPACK-compressed binary headers that can exceed Nginx's 4KB default buffer. Increase it to prevent 400 Bad Request errors on header-heavy requests:

http {
    large_client_header_buffers 8 16k;
}

HTTP/2 Server Push Gotchas to Avoid

These are the four mistakes that consistently degrade performance when using server push:

  • Pushing already-cached assets - sends duplicate data to returning visitors with no benefit. Use Cache-Control headers to detect cache state where possible.
  • Pushing too many assets - limit to 2–6 critical resources. More than that creates head-of-line blocking on the push channel.
  • No push prioritization - browsers may deprioritize non-critical pushed assets, delaying render. Push only render-blocking CSS and critical-path JS.
  • Pushing on every page indiscriminately - match push directives to specific location blocks, not the entire server block.

HTTP/2 vs HTTP/1.1 Performance Difference

HTTP/2 vs HTTP/1.1 performance difference comes down to four protocol changes: binary framing (faster parsing vs. text), multiplexing (parallel streams vs. sequential requests), header compression via HPACK (eliminates repeated header overhead), and server push (proactive asset delivery vs. request-response). On a page with 50 resources, HTTP/1.1 requires up to 6 parallel TCP connections with queuing; HTTP/2 handles all 50 over one connection with true parallelism.

HTTP/2 vs HTTP/3 Nginx is a separate question: HTTP/3 runs over QUIC (UDP) rather than TCP, eliminating TCP head-of-line blocking entirely. Nginx 1.25.1+ supports HTTP/3 experimentally via listen 443 quic reuseport. For production deployments without specific QUIC requirements, HTTP/2 over TLS remains the stable, widely-supported choice.

Priya Mervana
SSL Security Researcher, SSLInsights

"The most overlooked step in HTTP/2 enablement is cipher suite validation. Servers that were configured years ago for HTTP/1.1 often carry TLS 1.0 or deprecated RC4 ciphers - both will silently block HTTP/2 negotiation. Run openssl s_client -connect yourdomain.com:443 and confirm the negotiated protocol before debugging anything else."

Final Words on Enable HTTP/2 on Nginx Web Server

Enabling HTTP/2 on Nginx reduces page load time by eliminating the sequential request bottleneck that limits HTTP/1.1 performance. The configuration requires three steps: add http2 to the listen directive, validate TLS cipher suites against HTTP/2 requirements, and restart Nginx. Server push, tuning worker_connections, switching to epoll, and increasing header buffer sizes all compound those gains - but the listen directive change alone produces the most measurable improvement.

Verify HTTP/2 activation with curl -I --http2 https://yourdomain.com and confirm HTTP/2 200 in the response before moving to optimization. Check your SSL certificate installation is valid and the certificate chain is complete - an incomplete chain causes TLS errors that prevent HTTP/2 negotiation.

Frequently Asked Questions About HTTP/2 on Nginx

Does Nginx support HTTP/2 by default?

Nginx includes HTTP/2 support in all builds from version 1.9.5 onward, but it is not active by default. You must explicitly add http2 to the listen directive in your server block. Run nginx -v to confirm your version, then follow Step 1 above.

Why is HTTP/2 not working on Nginx after configuration?

Nginx HTTP/2 not working is almost always caused by one of three issues: (1) the http2 parameter was added to a non-SSL server block, (2) the SSL cipher suite includes blacklisted ciphers from RFC 7540 Appendix A, or (3) Nginx version is below 1.9.5. Run nginx -t to validate syntax, then curl -I --http2 https://yourdomain.com to test the live response.

Does HTTP/2 work without HTTPS on Nginx?

No, for browser traffic. While the HTTP/2 spec defines an unencrypted mode (h2c), Chrome, Firefox, Edge, and Safari all require HTTPS for HTTP/2. Nginx will refuse to serve h2 on port 80. Install a valid SSL certificate first.

What is the difference between HTTP/2 and HTTP/3 on Nginx?

HTTP/2 vs HTTP/3 Nginx: HTTP/2 runs over TCP with TLS. HTTP/3 runs over QUIC (UDP), eliminating TCP handshake latency and head-of-line blocking. Nginx 1.25.1+ supports HTTP/3 experimentally; for production stability, HTTP/2 remains the standard recommendation.

How many assets should I push with HTTP/2 server push?

Limit server push to 2–6 render-critical assets (typically your primary CSS and critical-path JS). Pushing more assets than this creates bandwidth waste for returning visitors who already have those resources cached, and can delay time-to-interactive by competing with the main document request.

Can I enable HTTP/2 on Nginx without recompiling?

Yes. If your Nginx binary was compiled with --with-http_v2_module (all official packages from nginx.org and most distribution repositories include this), no recompilation is needed. Confirm with nginx -V 2>&1 | grep http_v2.