curl 报错 77 是节点坏了吗？先检查 CA 文件路径与权限

命令行经机场客户端发起 HTTPS 请求时，看到 curl: (77) 不应立刻换节点。curl 官方把 77 定义为读取 SSL CA 证书材料出问题，典型方向是路径或访问权限。它和“远端证书本身验证不过”的排查起点不同。

先保留原始命令和错误

记录 curl 的完整错误文本、当前工作目录以及是否使用了 --cacert；分享给别人前删掉 URL 中的订阅凭据和认证头。先用 curl --version 确认实际运行的是 curl，并留意其 TLS 后端。不要用 -k 掩盖错误：curl 官方也建议生产使用时不要跳过验证。

先核对本机 CA 文件的位置与读取权限，再根据复测结果继续排查。 原创概念示意，非软件界面截图或测试结果。

按本机文件、证书验证、代理分层排查

1. 若命令显式使用 --cacert，核对路径是否拼错、文件是否存在、当前用户是否能读取；相对路径要结合当前工作目录理解。只对自己信任且来源清楚的 CA 文件做测试。
2. 若使用 CURL_CA_BUNDLE、SSL_CERT_FILE 等环境变量，核对是否意外指向旧文件。curl 的具体 CA 处理与 TLS 后端有关，Windows 的 Schannel 构建通常使用系统证书存储；不要照搬另一台电脑的证书包路径。
3. 在不暴露凭据的前提下，用同一 URL 和同一代理设置，移除误设的 CA 文件覆盖后重试。若 77 消失但出现其他 TLS 错误，按新的错误继续核对服务器名称、证书链和时间。

若你只是想验证代理是否连通，先在可信 HTTPS 测试地址做小请求。CA 文件错误修好后，还要看 HTTP 状态和实际响应；没有 77 不等于目标业务已经可用。

验收和边界

保留“原错误、改动的 CA 路径、复测错误码与结果”四项。只有在相同命令条件下 77 不再出现，才算这一层修复；若其他设备仍失败，继续分别排查代理设置和目标站点。

可核验来源

• curl/libcurl 错误码：77 的含义。核验日期：2026-10-15。
• curl TLS 证书验证说明：--cacert、系统证书存储与安全验证边界。核验日期：2026-10-15。