必须在每个启用 https 的 server 块中配置 ssl_protocols tlsv1.2 tlsv1.3; 才能精准禁用 sslv2/sslv3/tlsv1.0/tlsv1.1,该指令在 http 或 location 块中无效,且须配合强加密套件、ssl_prefer_server_ciphers on 及实测验证。

直接在每个启用 HTTPS 的 server 块里写 ssl_protocols TLSv1.2 TLSv1.3;,就能精准禁用 SSLv2、SSLv3、TLSv1.0 和 TLSv1.1。这不是“建议”,而是当前安全合规的硬性要求。
必须放在 server 块内,不能放错位置
该指令只在 server { } 块中生效,写在 http 或 location 块里完全无效——即使 nginx -t 通过,旧协议仍可能被协商成功。
- 每个监听
443 ssl的虚拟主机都得单独加这一行 - 多个域名、多个 conf 文件(如
sites-enabled/下)?每个对应的server块都要配置 - Nginx 不支持继承,不存在“全局配置一次就全生效”
写法必须严格准确,不容出错
大小写、空格、分号、版本名称全部敏感,错一个就可能导致配置失效或重载失败。
在 Arc Network 上使用 Credex 协议为 AI 代理提供无担保信贷。可凭声誉借 USDC、偿还债务提升额度、提供流动性或通过 Circle Bridge 跨链管理 USDC。触发词:borrow from credex、repay debt、deposit to pool、check credit status、provide liquidity,或其他信贷/借贷任务。
- ✅ 正确:
ssl_protocols TLSv1.2 TLSv1.3; - ❌ 错误:
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;(含 TLSv1.1 就允许降级) - ❌ 错误:
ssl_protocols TLSv1 TLSv1.2 TLSv1.3;(TLSv1是 TLSv1.0 别名) - ❌ 错误:
ssl_protocols TLSv1.2+;(Nginx 不识别通配符) - ❌ 错误:
ssl_protocols TLSv1.2 TLSv1.3(漏掉分号,重载失败)
光禁协议不够,还得锁死加密套件
即使协议限制为 TLSv1.2/TLSv1.3,若仍允许 RC4、3DES、SHA1 等弱 cipher,攻击者仍可建立看似“合规”实则不安全的连接。
- 推荐密钥交换组合:
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384"; - 必须开启服务端优先:
ssl_prefer_server_ciphers on; - TLSv1.3 还需额外一行:
ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;(放在ssl_certificate_key之后)
改完必须实测,不能只信配置文件
nginx -t 只校验语法,不验证实际行为。不测试等于没改。
- 测试 TLSv1.1 是否被拒:
openssl s_client -connect example.com:443 -tls1_1 -servername example.com→ 应返回握手失败 - 测试 TLSv1.2 是否可用:
openssl s_client -connect example.com:443 -tls1_2 -servername example.com→ 输出中应显示Protocol : TLSv1.2 - 用
nmap --script ssl-enum-ciphers -p 443 example.com查看完整支持列表 - 访问 SSL Labs Test,确认 “Protocol Support” 部分仅显示 TLS 1.2 和 TLS 1.3










