Rather than hand-picking individual settings, generate a current, well-maintained configuration block and adjust from there — TLS best practices shift over time as new weaknesses are found.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;Mozilla's SSL Configuration Generator produces a ready-to-use block for Nginx (with "modern," "intermediate," and "old" presets depending on how much legacy client compatibility you need) rather than requiring you to manually track which cipher suites are currently considered acceptable.
Confirming the result
After applying and reloading, run an SSL scan tool against your domain to confirm the intended protocol versions and cipher suites are actually what's being served, and check the overall grade for anything unexpectedly flagged.
What to do if applying a strict configuration breaks compatibility for some visitors
If a strict, modern-only configuration causes connection issues for a portion of your audience, checking your actual visitor analytics for browser and OS versions helps determine whether Mozilla's intermediate compatibility preset, rather than the strictest modern one, better fits your specific audience's real needs.
How to verify your configuration changes took effect after reloading Nginx
Running an SSL scan tool or a direct OpenSSL cipher check against your domain after reloading confirms the new configuration is actually active, rather than assuming a successful reload command means the intended changes took effect exactly as written.
What Mozilla's SSL Configuration Generator specifically provides for Nginx users
Mozilla's tool generates a ready-to-use Nginx configuration block for your chosen compatibility level (modern, intermediate, or old), reflecting current best-practice cipher suites and protocol versions — a reliable starting point rather than manually assembling a cipher suite list from scratch.
How to verify your chosen cipher suite list doesn't inadvertently break older but still-relevant clients
Checking your actual visitor analytics for browser and OS version distribution before applying a strict, modern-only cipher suite list confirms you're not inadvertently cutting off a meaningful portion of your real audience — Mozilla's intermediate compatibility tier is a safer default absent specific evidence your audience skews entirely modern.
Why revisiting your configuration periodically matters as best practices continue to evolve
The recommended cipher suite and protocol configuration shifts over time as new research emerges and old options are deprecated, covered throughout our SSL History category — periodically regenerating your configuration against Mozilla's current tool, rather than treating a configuration written once as permanently correct, keeps your server aligned with current best practice.
What to do if a specific older client can't connect after hardening your configuration
If a specific, known-legitimate older client can no longer connect after hardening, checking exactly which protocol version or cipher suite that client requires against your new configuration identifies precisely what would need to be selectively re-enabled, rather than reverting your entire hardening effort.
How to apply hardened TLS settings consistently across multiple Nginx server blocks
Defining your hardened TLS settings once in a separate, included configuration snippet, then referencing that snippet from every server block needing it, ensures consistency and means a future update to your standards only needs to happen in one place rather than being manually repeated across every individual server block.
A closing note on treating TLS hardening as ongoing maintenance, not a one-time task
Given how the recommended configuration shifts over time as covered throughout this site's SSL History category, treating TLS hardening as periodic, recurring maintenance rather than a one-time setup task keeps your server aligned with current best practice rather than gradually falling behind.
A final practical tip for future deployments
Saving your finalized, tested configuration as a template for future servers ensures every new Nginx deployment starts from the same hardened baseline, rather than needing to regenerate and re-verify a strong configuration from scratch each time.