ocsp stapling 与多域名 sni 共存响应错乱，核心是证书、ocsp 响应、sni 三者未对齐；需逐域名验证 openssl s_client -servername + -showcerts + -verify_hostname 是否闭环，并确保各 server 块独立配置 ssl_certificate、ssl_stapling 相关指令及匹配的 ssl_trusted_certificate 和 resolver。
遇到 OCSP Stapling 和多域名 SNI 共存时响应错乱，核心不是“谁先谁后”，而是 Nginx 没有把正确的证书、正确的 OCSP 响应、正确的 SNI 三者对齐。错乱表现通常是：某个域名访问时 TLS 握手慢、报 ERR_CERT_COMMON_NAME_INVALID、或客户端提示“证书已吊销”（实则未吊销），本质是返回了错误证书，或该证书的 OCSP 响应根本没装订/校验失败。
确认每个 server 块是否真正独立且完整
多个域名共用 443 端口时，Nginx 不靠配置顺序匹配，而靠 SNI 字符串精确命中 server_name。若出现错乱，往往是因为：
- 多个域名写在同一个
server块里，比如server_name api.example.com *.example.com;—— 这样 Nginx 只认第一个有效值（api.example.com），泛域名逻辑失效 - 某个
server块漏配ssl_certificate或ssl_certificate_key，Nginx 回退到默认 server，返回的是另一张证书 - 泛域名证书（如
*.example.com）和精确域名（如admin.example.com）被不同server块监听，但其中一块没启用 OCSP Stapling 配置，导致部分域名有 stapling、部分没有，客户端行为不一致
逐域名验证 SNI + 证书 + OCSP 响应是否闭环
不能只看配置文件，要模拟客户端真实握手路径：
- 用
openssl s_client -connect IP:443 -servername your.domain.com -showcerts查看实际返回的证书 Subject 和 SAN，确认是否为你预期的那张 - 在同一命令输出中，检查
OCSP Response Data是否存在；若无，说明 stapling 未生效 - 追加
-verify_hostname your.domain.com参数，观察是否输出Verify return code: 0 (ok)；若为非零值（如 20、21），说明 OCSP 校验失败，常见于ssl_trusted_certificate缺失或顺序错误 - 对每个关键域名重复以上步骤，确保各自闭环，不互相干扰
检查 ssl_trusted_certificate 是否按域名隔离或复用得当
ssl_trusted_certificate 是 OCSP 校验链的起点，它不绑定具体域名，但必须能覆盖当前 server 块所用证书的颁发者。常见陷阱：
- 所有
server块共用一个ssl_trusted_certificate文件，但其中混入了不相关的根证书（比如把 Let’s Encrypt 和私有 CA 的根证书全塞进去），导致校验时选错路径 - 泛域名证书和精确域名证书由不同 CA 签发（如一个是 Sectigo，一个是 ZeroSSL），却只配了一个 CA Bundle，造成其中一个域名的 OCSP 校验失败
- 正确做法：为不同 CA 签发的证书，准备各自的
ssl_trusted_certificate文件，并确保每个server块中指向对应的那个
排查 resolver 是否对所有域名都可达
OCSP 查询依赖 DNS 解析 OCSP 响应器地址（如 ocsp.int-x3.letsencrypt.org）。若 resolver 配置不当，会导致部分域名 stapling 静默关闭：
- 只配置 IPv4 resolver（如
resolver 8.8.8.8;），但某些 OCSP 域名仅支持 AAAA 记录，IPv6 网络下查询失败 - resolver 列表中某个 DNS 不稳定（如内网 DNS 延迟高或丢包），Nginx 默认会轮询，可能某次查询超时，触发 stapling 降级
- 验证方法：在服务器上执行
dig ocsp.int-x3.letsencrypt.org @1.1.1.1和dig ocsp.digicert.com @8.8.8.8，确认各 CA 的 OCSP 域名都能快速解析到 A/AAAA 记录
