DEV Community

Ramer Labs
Ramer Labs

Posted on

Performance Tuning for Nginx with TLS and HTTP/2 on High‑Traffic Sites

#nginx #security #performance #devops

Introduction

As a DevOps lead, you know that a secure, fast web layer is non‑negotiable for high‑traffic applications. Nginx is a popular reverse proxy, but its default TLS configuration is often sub‑optimal. In this practical tutorial we’ll walk through a hardened TLS setup, enable HTTP/2, and sprinkle in performance tweaks that together shave milliseconds off your Time‑to‑First‑Byte (TTFB).

Why TLS and HTTP/2 Matter for Nginx

  • Security – Modern browsers reject weak ciphers and TLS 1.0/1.1. Enforcing TLS 1.2+ protects data in transit.
  • Performance – HTTP/2 multiplexes streams over a single connection, reducing round‑trips. Combined with strong ciphers that support forward secrecy, you get both speed and privacy.
  • SEO & Trust – Google uses HTTPS as a ranking signal; a proper TLS handshake also boosts user confidence.

Prerequisites

  • A server running Ubuntu 22.04 (or similar) with nginx ≥ 1.21.
  • Root or sudo access.
  • A domain name pointing to the server’s IP.
  • Basic familiarity with systemctl and apt.

Step‑by‑Step TLS Hardening

1. Obtain a Certificate

For most projects, Let’s Encrypt offers a free, automated solution. Install the certbot client and request a certificate:

sudo apt update && sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d example.com -d www.example.com
Enter fullscreen mode Exit fullscreen mode

Certbot will automatically edit your Nginx server block to include ssl_certificate directives.

2. Configure SSL Settings

Create a dedicated snippet file to keep your SSL config tidy:

# /etc/nginx/snippets/ssl-params.conf ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; ssl_ciphers \ "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"; ssl_ecdh_curve X25519:secp384r1; ssl_session_timeout 1d; ssl_session_cache shared:SSL:10m; ssl_session_tickets off; # OCSP Stapling ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 5s;
Enter fullscreen mode Exit fullscreen mode

Include this snippet in each server block that serves HTTPS:

server { listen 443 ssl http2; server_name example.com www.example.com; include snippets/ssl-params.conf; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # ... your location blocks ... }
Enter fullscreen mode Exit fullscreen mode

3. Enable HTTP/2

The listen 443 ssl http2; directive turns on HTTP/2. Verify it’s active with:

curl -I -s -o /dev/null -w "%{http_version}\n" https://example.com
Enter fullscreen mode Exit fullscreen mode

You should see 2 as the output.

4. Fine‑Tune Cipher Suites

The ssl_ciphers line above selects only AEAD suites that support forward secrecy and are widely supported. Avoid legacy suites like RSA‑only or 3DES.

5. Enable OCSP Stapling

OCSP stapling reduces the extra network hop required for browsers to verify certificate revocation. The snippet already sets ssl_stapling on; and points to Google’s DNS resolvers for fast lookups.

Performance Boosters that Complement TLS

While TLS secures the channel, you still need to squeeze out raw speed:

  • gzip / brotli compression – serve pre‑compressed assets.
  • keepalive_timeout – keep connections alive for reuse.
  • proxy_cache_path – cache upstream responses.
  • client_body_buffer_size – avoid disk spillage for small POST bodies.
  • sendfile on; – let the kernel handle static file transfers.

Example of enabling Brotli (requires the ngx_brotli module):

brotli on; brotli_comp_level 6; brotli_types text/plain text/css application/javascript image/svg+xml;
Enter fullscreen mode Exit fullscreen mode

Monitoring and Testing

  1. SSL Labs – Run a free scan at https://www.ssllabs.com/ssltest/ to confirm you have an "A+" rating.
  2. curl – Check protocol negotiation: 
 curl -vvv https://example.com 2>&1 | grep -i "http/2"
Enter fullscreen mode Exit fullscreen mode
  1. nginx -T – Dump the full configuration and look for duplicate ssl_ directives.
  2. Prometheus + node_exporter – Track nginx_upstream_response_time and TLS handshake latency.

Common Pitfalls to Avoid

  • Forgetting to reload Nginx after editing snippets (sudo systemctl reload nginx).
  • Using outdated ciphers – keep the ssl_ciphers line up‑to‑date with Mozilla’s recommendations.
  • Disabling TLS 1.3 – it provides the best latency; only turn it off if you have legacy client constraints.
  • Neglecting OCSP stapling – without a proper resolver, stapling can cause handshake failures.
  • Over‑compressing – Brotli on already compressed files (e.g., JPEG) wastes CPU.

Conclusion

A hardened TLS setup with HTTP/2, modern cipher suites, and OCSP stapling transforms Nginx from a simple reverse proxy into a high‑performance, security‑first front‑door. Pair these settings with compression, caching, and proper monitoring, and you’ll see measurable drops in TTFB and improved security posture.

If you’re looking for a reliable partner to audit or host your Nginx workloads, consider checking out https://lacidaweb.com for a no‑pressure conversation.

Top comments (0)