前向安全性（PFS）是现代HTTPS基础要求，必须使用ECDHE或DHE密钥交换实现；RSA密钥交换无PFS，私钥泄露将导致历史通信全被解密；Nginx通过OpenSSL调用ECDHE/DHE动态生成临时密钥对，确保每次握手密钥唯一；TLS 1.3强制PFS且无需配置cipher。
前向安全性（PFS）不是可选功能，而是现代 HTTPS 的基础要求。Nginx 本身不生成密钥，它通过 OpenSSL 调用 DHE 或 ECDHE 算法，在每次 TLS 握手时动态生成临时密钥对——即使服务器私钥日后泄露，历史通信仍无法被解密。
为什么必须用 DHE 或 ECDHE，而不是 RSA 密钥交换
RSA 密钥交换（如 RSA-AES128-SHA）在 TLS 1.2 中直接用服务器公钥加密预主密钥，整个会话依赖长期私钥。一旦私钥暴露，所有过往抓包流量都可解密。DHE 和 ECDHE 则完全不同：
- DHE 基于传统有限域 Diffie-Hellman，计算开销中等，兼容性好（支持老嵌入式设备），但需配置
ssl_dhparam文件，否则 Nginx 可能回退到弱 DH 参数 - ECDHE 基于椭圆曲线，同等安全强度下密钥更短、运算更快，且天然支持现代曲线（X25519、P-256），是当前首选
- 两者都确保每次握手生成全新临时密钥，实现真正的前向保密
ssl_ciphers 字符串里怎么体现 PFS
判断一个 cipher 是否具备前向保密，只需看其名称是否以 ECDHE- 或 DHE- 开头。例如：
-
ECDHE-RSA-AES128-GCM-SHA256✅ 含 ECDHE，PFS 有效 -
DHE-RSA-AES256-GCM-SHA384✅ 含 DHE，PFS 有效 -
RSA-AES128-GCM-SHA256❌ 静态 RSA，无 PFS -
ECDH-ECDSA-AES128-SHA❌ 静态 ECDH，无 PFS（已淘汰）
配置中若混入非 ECDHE/DHE 套件，且启用 ssl_prefer_server_ciphers on，可能让客户端被迫协商出无 PFS 的旧算法，导致等保或合规审计失败。
TLS 1.3 下的 PFS 是自动保障的
TLS 1.3 协议彻底移除了静态密钥交换机制，所有密钥交换均基于临时密钥（ECDHE 是唯一选项）。这意味着：
-
ssl_ciphers对 TLS 1.3 完全无效，它的套件（如TLS_AES_128_GCM_SHA256）由协议硬编码，强制 PFS - 只要
ssl_protocols包含TLSv1.3，且客户端支持（Chrome 70+、Firefox 63+、OpenSSL 1.1.1+），连接就默认获得最强前向保密 - 无需为 TLS 1.3 单独写 cipher，也不应试图在
ssl_ciphers中加入 TLS 1.3 套件名（语法错误）
实际配置建议与常见误区
一套兼顾安全、性能与兼容性的最小可行配置如下：
- 明确禁用不安全协议：
ssl_protocols TLSv1.2 TLSv1.3（严禁保留 TLS 1.0/1.1） - cipher 列表只保留 ECDHE/DHE 开头、AES-GCM 或 CHACHA20-POLY1305 加密、SHA256/SHA384 摘要的组合
- 若确认无老旧 DHE 设备依赖，可移除所有
DHE-套件，简化配置并提升性能 - 启用
ssl_prefer_server_ciphers off（TLS 1.3 下该指令失效，设为 off 可避免对 TLS 1.2 产生副作用） - 搭配
ssl_ecdh_curve X25519:prime256v1:secp384r1，兼顾 TLS 1.3 效率与 TLS 1.2 兼容性
