Nginx站点满足现代浏览器安全要求需协同配置：启用TLSv1.2/TLSv1.3、优先ECDHE密钥交换、指定AES-GCM/ChaCha20套件、开启ssl_prefer_server_ciphers并限定椭圆曲线。
要让 Nginx 站点满足现代浏览器（Chrome 70+、Firefox 63+、Safari 12+、Edge 79+）的安全要求，核心不是堆砌算法，而是精准排序 + 协同配置。只设 ssl_ciphers 不够，必须配合协议限制、密钥交换控制和椭圆曲线指定，才能真正让强套件被优先选用。
明确启用哪些加密套件
现代浏览器普遍支持并优先协商 AEAD 模式（如 AES-GCM、ChaCha20-Poly1305）和前向保密（PFS）密钥交换。推荐直接使用以下组合，兼顾安全与兼容性：
-
ECDHE-ECDSA-AES128-GCM-SHA256（ECDSA 证书场景） -
ECDHE-RSA-AES128-GCM-SHA256（最通用，RSA 证书首选） -
ECDHE-RSA-AES256-GCM-SHA384（更强密钥长度，兼容性无实质影响） -
ECDHE-RSA-CHACHA20-POLY1305（对移动网络更友好） -
DHE-RSA-AES128-GCM-SHA256（仅在需兼容极少数旧嵌入式设备时保留）
这些套件全部以 ECDHE 或 DHE 开头，确保前向保密；全部使用 AES128-GCM、AES256-GCM 或 CHACHA20-POLY1305，杜绝 CBC 模式带来的 Lucky13 等风险；不含 RC4、MD5、SHA1（签名/PRF 中）、DES、3DES、EXPORT、NULL、ANONYMOUS 等已淘汰项。
禁用不安全协议与弱算法
光靠 ssl_ciphers 排序无法阻止客户端降级到不安全套件，必须从协议层切断退路：
- 只启用 TLS 1.2 和 TLS 1.3：
ssl_protocols TLSv1.2 TLSv1.3;（务必禁用 TLSv1.0 和 TLSv1.1） - 不手动禁用弱套件（如
!RC4:!MD5），而应直接在ssl_ciphers中不列出它们——更干净、更可控 - TLS 1.3 套件由协议硬性规定，无需也不能在
ssl_ciphers中指定；只要启用了 TLSv1.3，其默认套件（如TLS_AES_256_GCM_SHA384）就会自动生效
强制服务端套件优先级并优化密钥交换
Nginx 默认不强制按你写的顺序选套件，客户端可能无视你的配置而挑它喜欢的（哪怕很弱）：
- 启用
ssl_prefer_server_ciphers on;—— 这对 TLS 1.2 至关重要（TLS 1.3 下该指令无效，但无影响） - 指定高效且抗侧信道的椭圆曲线：
ssl_ecdh_curve secp384r1:prime256v1;（优先secp384r1，fallback 到prime256v1） - 注意：Nginx 1.11.0+ 默认
ssl_prefer_server_ciphers off，若设为on可能干扰 TLS 1.3 协商，因此保持 on 是正确做法（资料明确指出“必须开启”以保障 TLS 1.2 安全）
验证是否真正生效
配置写完 reload 并不代表成功。必须实测确认客户端实际协商到的是你期望的强套件：
- 使用 SSL Labs Server Test 查看 “Handshake Simulation” 表格，观察 Chrome、Firefox、Safari 等主流客户端是否都协商到了
ECDHE-RSA-AES128-GCM-SHA256或类似强套件 - 命令行快速验证（需 OpenSSL 1.1.1+）：
openssl s_client -connect yourdomain.com:443 -tls1_2 -cipher 'ALL:COMPLEMENTOFALL' 2>/dev/null | grep Cipher
输出应显示类似Cipher : ECDHE-RSA-AES128-GCM-SHA256 - 若看到
AES256-SHA、ECDHE-RSA-AES128-SHA等非 GCM/ChaCha 套件，说明配置未生效或客户端太老——需回查ssl_prefer_server_ciphers是否开启、ssl_protocols是否误含 TLSv1.1 等
