curl 连接 HTTPS 代理报 60，检查代理自己的 CA 信任

curl 经 https:// 代理访问 HTTPS 网站，刚连接代理就报 curl: (60) SSL certificate problem。已经给目标网站指定 --cacert，错误却没有变化时，先看失败的是哪一段 TLS：curl 会分别验证 HTTPS 代理和隧道内的目标服务器。

--cacert 用于目标服务器，--proxy-cacert 用于 HTTPS 代理。给前者增加代理 CA，不等于配置了代理连接的信任。这个区别适用于真正提供 TLS 的 HTTPS 代理；普通 HTTP CONNECT 代理没有这层代理 TLS，不能仅凭目标 URL 是 HTTPS 就套用。

从详细输出辨认出错位置

查看 curl -V，确认版本、TLS 后端及 HTTPS 代理支持。代理证书选项从 curl 7.52.0 起提供，旧版本或不同构建需要按实际支持情况处理。

用一次获授权的请求查看 --verbose 输出，先找连接地址、代理证书验证和 CONNECT 的先后顺序。代理环境变量、NO_PROXY 与 curl 配置文件可能改变实际路径；显式写了代理参数，也要核对日志确实走了它。

如果代理 TLS 校验已经失败，还没有成功建立 CONNECT 隧道，应检查代理证书的签发者、有效期、代理主机名和证书链。此时调整目标网站的 CA 文件无法修复代理验证。若代理验证成功且 CONNECT 返回成功，随后目标证书失败，则处理目标侧信任或实际 TLS 拦截行为。

诊断输出可能包含认证信息、Cookie、内部地址或请求参数，对外分享前需要脱敏。不要把日志中的一段 SSL certificate verify ok 单独作为两段验证都通过的证明。

给代理与目标分别指定可信材料

从代理管理员提供并可核实身份的渠道取得代理 CA，确认它对应预期代理。PEM 文件可以包含多个 CA，但不要为了消除报错收集不明证书加入信任。

以下例子假设代理使用内部 CA，目标网站已经能被当前默认信任库验证：

curl --verbose \
  --proxy https://proxy.example.net:3127 \
  --proxy-cacert ./proxy-ca.pem \
  https://service.example.net/status

如果目标也有独立的内部 CA，再加目标侧配置：

curl --verbose \
  --proxy https://proxy.example.net:3127 \
  --proxy-cacert ./proxy-ca.pem \
  --cacert ./service-ca.pem \
  https://service.example.net/status

域名、端口、文件名均需替换为实际值。proxy-ca.pem 用来验证代理身份，service-ca.pem 用来验证目标身份；两份文件即使最终包含同一个企业 CA，也应按各自用途判断。CA 信任不能修复过期证书、名称不匹配或代理端漏发的证书链。

TLS 后端和系统会影响默认信任库。某个浏览器或另一份 curl 成功，不足以证明当前 curl 使用同一套 CA。先核对实际二进制与构建，再决定使用单次调用的 CA 参数，还是按组织策略维护系统信任。

HTTPS 代理与 TLS 拦截要分开判断

代理 URL 的 https:// 表示 curl 到代理这一段加密。CONNECT 隧道内的目标 TLS 仍有独立证书验证；代理也可能按既有策略拦截目标 TLS，并向客户端出示由企业 CA 签发的目标证书。

发生拦截时，应确认这是预期策略，并核对目标侧实际签发者。不能用 --proxy-cacert 自动解决隧道内所有证书错误，也不能把企业代理 CA 当成任意目标证书都可信的理由。

若错误是 wrong version number 且发生在代理 TLS 握手，先核对该端口是否真的提供 HTTPS 代理；这与有效 TLS 连接上的证书校验失败不同。

验证时保留两段校验

修正后，重新使用原来的代理、目标和请求条件，确认代理证书校验、CONNECT、目标证书校验及业务响应均符合预期。代理握手成功只完成了其中一步，302 或 200 也要按目标接口的预期解释。

--insecure 和 --proxy-insecure 分别跳过不同连接的验证，不应留在最终调用中。没有移除这些参数的成功结果，不能作为身份验证已恢复的证据。

优先在单次调用中验证 CA 文件后再调整自动任务，保存旧参数。若撤销本次变更，应同时核对是否曾向系统信任库添加 CA；恢复脚本不会自动撤销系统信任。