Nginx HTTPS 配置最佳实践：从 A+ 评级到 HSTS 预加载

在当今的 Web 环境中，HTTPS 已不再是可选项，而是网站安全与用户信任的基石。然而，仅仅安装一张 SSL 证书并开启 443 端口，远不足以应对日益复杂的安全威胁。一个配置不当的 HTTPS 站点，可能依然会遭受降级攻击、中间人劫持或混合内容警告。本文将从 Nginx 的实际配置出发，带你一步步实现从 SSL Labs A+ 评级到最终启用 HSTS 预加载的完整最佳实践。

一、基础：从一份可靠的 SSL 配置开始

在调整任何参数之前，请确保你的 Nginx 已编译支持 HTTP/2 和 TLS 1.3（Nginx 1.13.0+ 及 OpenSSL 1.1.1+）。以下是一份经过验证的 ssl 基础配置模板，建议放置在 http 或 server 块中：

ssl_protocols TLSv1.2 TLSv1.3;
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;

关键点解读：

• 禁用 TLS 1.0 和 1.1，它们已被证实存在安全缺陷。
• 优先使用 ECDHE 密钥交换，提供前向保密。
• 在 TLS 1.3 中，密码套件由客户端主导，因此 ssl_prefer_server_ciphers 应设为 off，避免干扰现代客户端的优选顺序。

二、会话复用与性能优化

HTTPS 握手带来的延迟不容忽视。通过会话缓存和会话票据，可以显著减少重复握手的开销，同时不影响安全性。

ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_session_tickets off;

为什么关闭会话票据？
会话票据（Session Tickets）虽然能提升性能，但其密钥若未定期轮换，可能导致前向保密性失效。对于大多数站点，使用共享会话缓存已足够，且更易于管理。如果你必须启用票据，请确保配置 ssl_session_ticket_key 并定期轮换。

三、OCSP Stapling：加速证书验证

OCSP Stapling 允许服务器在握手时直接提供证书吊销状态，避免客户端额外请求 CA 的 OCSP 服务器，既提升速度又保护隐私。

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/fullchain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

注意：ssl_trusted_certificate 应指向包含根证书和中间证书的链文件，通常与 fullchain.pem 相同。

四、安全响应头：从 HSTS 到 Expect-CT

达到 A+ 评级的关键之一，是正确设置 HTTP 安全响应头。以下配置应添加到 server 块中：

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

HSTS 的阶梯式部署策略：
直接设置 max-age=63072000（两年）并申请预加载是危险的——一旦子域名未支持 HTTPS，将导致用户无法访问。建议分阶段：

1. 先设置 max-age=300，观察一周。
2. 逐步提升至 max-age=86400、max-age=31536000。
3. 确认所有子域名均支持 HTTPS 后，添加 includeSubDomains。
4. 最后提交至 hstspreload.org。

关于 Expect-CT：
随着证书透明度（CT）的普及，Expect-CT 已逐渐被弃用，现代浏览器默认要求 CT。因此，除非有特殊合规需求，否则无需再添加该头。

五、HTTP/2 与 TLS 1.3 的协同

在 listen 指令中启用 HTTP/2 和 TLS 1.3：

listen 443 ssl http2;
listen [::]:443 ssl http2;

TLS 1.3 将握手往返次数从 2-RTT 降至 1-RTT，甚至支持 0-RTT（需谨慎启用）。配合 HTTP/2 的多路复用，可大幅提升首屏加载速度。但请注意：HTTP/2 的服务器推送（Server Push）已不被主流浏览器支持，不必为此耗费精力。

六、重定向与混合内容治理

所有 HTTP 流量必须 301 重定向至 HTTPS，且重定向应发生在应用逻辑之前：

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

同时，确保页面内所有资源（图片、脚本、样式）均使用 HTTPS 或协议相对 URL。混合内容会破坏安全锁标志，甚至被浏览器直接阻止。

七、验证与持续监控

完成配置后，使用以下工具验证：

• SSL Labs Server Test：目标为 A+，检查证书链、协议支持、密钥交换等。
• Security Headers：确认 HSTS、X-Frame-Options 等头已正确返回。
• HSTS Preload 状态：提交后可在 hstspreload.org 查询审核进度。

建议将 SSL Labs 的 API 集成到 CI/CD 流程中，每次部署后自动检测评级，防止配置回退。

八、常见陷阱与规避

• 证书链不完整：仅部署域名证书而缺少中间证书，导致部分客户端（尤其是 Android）报错。务必使用 fullchain.pem。
• HSTS 过早预加载：未覆盖所有子域名便提交预加载，造成不可逆的访问中断。
• 忽略 IPv6：仅监听 IPv4 的 443 端口，导致 IPv6 用户无法访问。务必添加 listen [::]:443 ssl http2;。
• DH 参数过弱：若使用 DHE 套件，需生成至少 2048 位的 DH 参数，或直接禁用 DHE 以简化配置。

结语

Nginx 的 HTTPS 配置并非一劳永逸，而是一个持续迭代的过程。从禁用老旧协议、启用 OCSP Stapling，到谨慎部署 HSTS 预加载，每一步都关乎用户数据的安全与访问体验。遵循上述最佳实践，你不仅能轻松获得 SSL Labs A+ 评级，更能为用户构建一个默认安全、面向未来的 Web 环境。记住：安全不是功能，而是基础。

未经允许不得转载：任鹏个人博客 » Nginx HTTPS 配置最佳实践：从 A+ 评级到 HSTS 预加载