必须仅配置 ssl_protocols TLSv1.2 TLSv1.3，禁用 TLSv1 和 TLSv1.1；因二者存在不可修复设计缺陷，TLS 1.0 易受 POODLE/BEAST 攻击，TLS 1.1 缺乏强制前向保密，私钥泄露将导致历史通信被批量解密。
在生产环境中，ssl_protocols 配置不是性能调优项，而是安全基线。必须只保留 TLSv1.2 和 TLSv1.3，彻底移除 TLSv1 和 TLSv1.1 —— 这不是“建议”，而是当前（2026年）运行的硬性前提。
协议本身存在不可修复的设计缺陷
TLS 1.0（1999年）和 TLS 1.1（2006年）诞生于现代密码学成熟之前，其核心机制无法抵御当前已知攻击：
- TLS 1.0 不支持 AEAD 加密模式（如 AES-GCM），易受 POODLE、BEAST 等填充预言类攻击
- TLS 1.1 未强制前向保密（PFS），一旦私钥泄露，历史通信可被批量解密
主流环境已全面拒收，不是“淘汰中”，而是“已失效”
禁用不是为未来做准备，而是适配当下真实运行环境：
- Chrome、Firefox、Edge、Safari 自 2020 年起默认拒绝 TLS 1.0/1.1 握手
- AWS ALB、Cloudflare、Azure 存储（自 2026 年 2 月 3 日起）已强制仅接受 TLS 1.2+
- Windows 11（含 25H2）、Microsoft 365、Let’s Encrypt 新证书均不再兼容旧协议
- 启用 TLS 1.0/1.1 的站点，新证书握手失败率显著上升
合规审计直接判为高风险，无缓冲期
继续保留等于主动触发合规红线：
- PCI DSS 4.1 明确要求最低 TLS 1.2，违规将导致支付业务资格取消
- 等保2.0三级系统将弱加密协议列为中高风险项，不予备案或限期整改
- GDPR 第32条与 HIPAA 视其为“未采取适当技术措施”，面临最高 4% 全球营业额罚款
- NIST SP 800-52 Rev.2 将 TLS 1.0/1.1 列为“不应使用”级别
一处宽松配置即全站降级，检查必须全覆盖
ssl_protocols 是继承式覆盖配置：只要任意 http 块、server 块或 include 文件（如 conf.d/ssl.conf）中存在 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3，整个 Nginx 实例就会回退到最弱支持级别。
快速确认命令：
nginx -T 2>/dev/null | grep -A2 "ssl_protocols"
若输出中含 TLSv1 或 TLSv1.1，说明尚未清理干净。务必逐个检查所有配置层级，包括子配置文件。
