核心是显式声明、精确筛选、严格排除——只保留ECDHE+AEAD套件（如ECDHE-RSA-AES128-GCM-SHA256、CHACHA20-POLY1305等），禁用RSA密钥交换、CBC、RC4、3DES、MD5、SHA1；配合ssl_protocols TLSv1.2 TLSv1.3、ssl_prefer_server_ciphers off和ssl_ecdh_curve，确保前向保密与认证加密。
要在 Nginx 中仅允许安全合规的加密算法套件，核心是**显式声明、精确筛选、严格排除**——不依赖默认值，不使用模糊宏（如 HIGH 或 DEFAULT），而是直接列出经审计支持前向保密（PFS）和认证加密（AEAD）的强套件，并配合协议与协商策略同步收紧。
只保留 ECDHE + AEAD 组合的套件列表
现代合规要求（等保三级、金融基线、GDPR）明确禁止静态密钥交换与非 AEAD 模式。必须剔除所有含 RSA（密钥交换）、CBC、RC4、3DES、MD5、SHA1 的套件：
-
ECDHE-ECDSA-AES128-GCM-SHA256（ECDSA 证书首选，轻量高效） -
ECDHE-RSA-AES128-GCM-SHA256（RSA 证书最通用兼容项） -
ECDHE-ECDSA-CHACHA20-POLY1305（移动弱网场景更优） ECDHE-RSA-CHACHA20-POLY1305-
ECDHE-ECDSA-AES256-GCM-SHA384（更高密钥强度） ECDHE-RSA-AES256-GCM-SHA384
写入配置时按优先级从左到右排列，Nginx 将采用第一个客户端支持的套件。TLS 1.3 套件（如 TLS_AES_256_GCM_SHA384）由协议自动启用，无需写入 ssl_ciphers，但必须启用 TLSv1.3 协议才能生效。
配套关键指令不可遗漏
仅设 ssl_ciphers 不足以确保生效，以下三项必须同步配置：
-
ssl_protocols TLSv1.2 TLSv1.3;—— 明确禁用 TLSv1.0/v1.1，防止降级 -
ssl_prefer_server_ciphers off;—— 让客户端自主选择其支持的最强 ECDHE 套件（更兼容、更可控；设为on会禁用 TLS 1.3） -
ssl_ecdh_curve X25519:secp384r1:prime256v1;—— 指定高效安全的椭圆曲线，提升 ECDHE 性能并规避弱曲线风险
验证是否真正生效
重载配置后，必须实测确认，不能仅凭 nginx -t 通过：
- 用
openssl s_client -connect example.com:443 -tls1_2查看实际协商出的Cipher，应为ECDHE-RSA-AES128-GCM-SHA256类型 - 用
nmap --script ssl-enum-ciphers -p 443 example.com扫描，输出中不应出现RC4、3DES、AES128-CBC、SHA1等关键词 - 访问 SSL Labs 测试页，检查 “Handshake Simulation” 是否对 Chrome/Firefox/iOS/Android 全部返回 ECDHE+GCM 或 ChaCha20 套件，且评级达 A+（“Key Exchange” 栏标记为 PFS）
常见错误配置需避免
这些看似细微的写法偏差，常导致合规检查被一票否决：
- 写成
ssl_ciphers DEFAULT或留空 —— 旧版 Nginx 默认含 RC4/3DES，新版虽已优化，但仍不可信 - 混用宏与具体套件，例如
HIGH:ECDHE-RSA-AES128-GCM-SHA256:!RC4—— OpenSSL 解析顺序可能导致弱套件意外保留 - 未统一证书类型与套件：ECDSA 证书却只配了
ECDHE-RSA-*套件，或 RSA 证书未包含对应ECDHE-RSA-*条目，将导致握手失败 - 忽略私钥与证书链完整性：私钥权限不是
600，或ssl_certificate指向的是cert.pem而非fullchain.pem，均可能在审计中被认定为配置不完整
