应用发布前，如何检查代理环境下的 TLS 证书兼容性
先分清直连、隧道转发和代理中间人三类链路，再逐级核对证书链、信任库位置与 SAN；本机正常而容器失败的，多为 CA 没进镜像。
代理环境下的 TLS 问题，先要分清证书由谁签发：直连看目标证书，隧道转发看目标证书，代理中间人看代理自签 CA。代理IP 本身不改变 TLS 握手，但企业代理或抓包工具会替换证书链，发布前必须把这条链路完整验一遍。
先确认代理是否会替换目标站的 TLS 证书
直连或 HTTP CONNECT 隧道通常保留目标站点的证书，应检查证书链、有效期和 SAN（证书允许使用的域名）。如果企业代理会解密并重新签发 TLS 流量，客户端看到的是企业代理签发的站点证书；此时要确认该证书能连到受信任的企业 CA。先判断代理是否替换了证书，再确定检查对象。
核对代理协议与客户端接入方式时，可参考代理设置帮助。
使用 OpenSSL 查看代理连接返回的证书链
```bash
openssl s_client -proxy proxy.example.com:8080 \
-connect target.example.com:443 \
-servername target.example.com -showcerts \
-verify_hostname target.example.com -verify_return_error \
-CAfile /path/to/ca-bundle.pem
```
查看输出中的 issuer、有效期和 SAN，并重点看两件事：证书链能否构建到受信锚、主机名是否匹配。服务端通常只提供叶证书和中间证书，不要求它回传根证书；根证书应该来自你信任的本地信任库（-CAfile 或 -CApath），而不是从连接里“捡”到一个就信。验收看退出码和验证输出（Verify return code），不要只看“连接成功”；最后仍在真实应用运行时或容器里做一次正负对照。
-proxy 参数需要 OpenSSL 1.1.0 或更高版本，且默认只支持 HTTP CONNECT；SOCKS5 场景改用支持该协议的工具（如 curl 的 --proxy socks5h://）或对应的客户端验证。运行 openssl version 可先检查本机版本。
检查系统、运行时和容器使用的证书信任库
信任库位置取决于应用使用的运行时：Linux 系统证书通常位于 /etc/ssl/certs，Java 使用自己的 cacerts，Node 可通过 NODE_EXTRA_CA_CERTS 指定额外 CA，Python 的 requests 常使用 certifi。容器还要单独检查镜像内的证书。本机正常而容器失败时，先比较两边实际加载的 CA。
根据 TLS 错误定位证书链和主机名问题
出现 unable to get local issuer certificate 时，先检查证书链是否缺少中间 CA；出现 self signed certificate 时，确认它是否为预期的企业 CA 或测试证书。hostname mismatch 通常表示证书 SAN 不包含目标域名；protocol version 或 cipher mismatch 则需要核对客户端与服务端支持的 TLS 版本和加密套件。
发布前检查证书有效期、信任链和轮换结果
在预发布环境验证证书更新和轮换
发布前记录证书到期时间，证书轮换后复测一次；灰度环境的信任库要和生产一致，否则灰度通过、生产失败。
记录证书签发者、有效期和信任库位置
发布前记录目标域名和端口、证书签发者与到期时间、信任库位置，以及代理是否会重新签发证书。
检查清单四项：链能构建到受信锚、CA 在信任库、主机名匹配 SAN、证书未过期。任一项不满足就不能发布；发现证书替换影响生产流量时，立即回滚配置。
证书链异常仍无法归因时，可从全球代理帮助中心查找对应接入文档。
OpenSSL 参数以手册为准：
openssl s_client手册（-proxy、-verify_hostname、-verify_return_error）
常见问题
代理环境下证书报错一定是代理问题吗？
不一定。先看证书链和信任库，主机名不符或 CA 缺失更常见。
为什么本机正常、容器里失败？
容器镜像没有导入同一个 CA，信任库不一致。