nginx 不支持证书透明度（ct）强制校验，也无 sslct* 类指令；所谓“ct 容错”实为误判，真正需解决的是证书是否含有效 sct 或上游 ct 策略是否过度严格。
Nginx 本身不支持证书透明度（Certificate Transparency, CT）的强制校验，也没有内置指令（如 ssl_ct_verify 或类似机制）来启用或容错处理 CT 日志验证失败。所谓“CT 强制校验失败”在标准 Nginx 场景中并不存在——CT 是客户端（如 Chrome、Firefox、curl ≥7.65.0 配合 --cert-status 或 --ct）、或特定 TLS 库（如 BoringSSL、OpenSSL 3.0+ 实验性支持）的行为，不是 Nginx 作为服务端或代理端的验证责任。
如果你遇到的是以下某类现象，实际根源并非 Nginx 的 CT 校验，而是常被误归因的其他 TLS/证书问题：
- ✅ 浏览器报
ERR_CERTIFICATE_TRANSPARENCY_REQUIRED（Chrome 65+ 对部分公开 CA 签发证书的强制 CT 要求） - ✅ curl 报
SSL certificate problem: certificate transparency required but not satisfied - ✅ 后端服务（如 Java Spring Boot + Netty、Go http.Server 启用 CT 检查）拒绝连接
这些都不是 Nginx 在拦，而是下游客户端或上游服务端主动执行了 CT 策略。Nginx 作为中间组件，既不生成 SCT（Signed Certificate Timestamp），也不验证 SCT 是否有效或存在。
那么，如何实现“自动化容错处理”？
真正可行的容错，是绕过或缓解 CT 导致的连接中断，分两类场景处理：
▪ 场景一：Nginx 作为反向代理，上游 HTTPS 服务因 CT 检查失败而拒连
（例如上游是启用了 require_sct 的 gRPC 服务或自研网关）
原因：上游服务 TLS 层校验客户端（即 Nginx）是否提供了合法 SCT，但 Nginx 不发送 SCT（也不可能发送，它无私钥签名能力）
-
解决方向：让上游服务放宽 CT 要求，而非在 Nginx 做“容错”
- 若上游可控：关闭
require_sct或配置为warn_only模式 - 若上游不可控（如 SaaS 接口）：确认其证书是否已入主流 CT 日志（crt.sh 可查），否则换用合规证书
- 若上游可控：关闭
-
Nginx 侧可配合的配置（非容错，而是避免干扰）：
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/nginx/ssl/ca-bundle.crt;
proxy_ssl_server_name on;
⚠️ 切勿设置 `proxy_ssl_verify off` 来“绕过”——这会关闭全部证书信任校验，引入严重安全风险。
▪ 场景二：Nginx 自身作为 HTTPS 服务端，客户端因 CT 失败拒绝建连
- 真实问题：你的证书未嵌入有效 SCT（比如用 Let’s Encrypt 签发但未启用 OCSP stapling + SCT stapling，或私有 CA 证书根本不在 CT 日志中）
-
自动化修复路径：
- ✅ 使用支持 SCT stapling 的 ACME 客户端（如
certbot ≥1.21或acme.sh --issue --ocsp）自动获取含 SCT 的证书 - ✅ 在 Nginx 配置中启用 OCSP stapling（间接传递 SCT）：
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/fullchain.crt;
- ✅ 验证是否生效：
openssl s_client -connect your.site:443 -status -servername your.site 2>/dev/null | grep -A 1 "OCSP response"
若输出含
valid since和signed at，且无no response sent，说明 SCT 已 stapling 成功。
- ✅ 使用支持 SCT stapling 的 ACME 客户端（如
▪ 场景三：想完全屏蔽客户端 CT 检查？（不推荐，仅限内网测试）
- 仅适用于你完全控制客户端的场景（如内部 curl 脚本、Postman、测试脚本）：
- curl 加
-k（跳过全部证书检查，含 CT）→ ❌ 生产禁用 - curl 加
--ciphers DEFAULT@SECLEVEL=1（降级安全策略）→ ⚠️ 极不推荐 - Java 客户端禁用 CT：JVM 启动参数
-Djdk.tls.client.enableSniExtension=false（副作用大，不治本）
- curl 加
总结关键点
- Nginx 不做 CT 校验，也无
ssl_ct_*类指令；所谓“CT 容错”本质是误判 - 真正要解决的，是证书是否满足 CT 要求（对公共 Web）、或上游是否过度强制 CT（对内网服务）
- 自动化方向只有两个：
- 用合规 ACME 工具签发带 SCT 的证书，并启用
ssl_stapling - 调整上游服务的 CT 策略，而非在 Nginx “打补丁”
- 用合规 ACME 工具签发带 SCT 的证书，并启用
- 所有关闭校验（
verify off、-k）的方案，都是用安全换可用，应严格限定于开发/测试环境
不复杂，但容易忽略根本责任边界。
