Claude Code 遇到 SSL 证书错误的 5 种有效解决方法(2026 实测)

发布时间:2026/7/7 8:06:19
Claude Code 遇到 SSL 证书错误的 5 种有效解决方法(2026 实测) 在家用得好好的 Claude Code一到公司就被一堵 TLS 报错墙拦住SELF_SIGNED_CERT_IN_CHAIN、unable to get local issuer certificate或者干脆一句Self-signed certificate detected。你的安装并没有问题。是公司的网络在打开每一条 HTTPS 连接、重新签名而 Claude Code 认不出这个新签名。修复方案几乎从来都不是关闭证书校验而是教会 Claude Code 去信任公司额外添加的那一张证书。本文按你应当尝试的顺序讲清楚做到这一点的五种方法加上与之配套的代理设置以及那个会悄悄把你的 API key 交给线路上任何人的「修复」。30 秒快速诊断先看错误字符串。它会告诉你哪一层出了问题而每一种都对应下文的一个具体修复。错误字符串含义首选修复SELF_SIGNED_CERT_IN_CHAIN代理用你不信任的 CA 重新签发了流量修复 1OS 库或修复 2NODE_EXTRA_CA_CERTSunable to get local issuer certificate颁发 CA 不在 Claude Code 读取的任何库中修复 2NODE_EXTRA_CA_CERTSSelf-signed certificate detectedClaude Code 对上面两种情况的自有说法先修复 1再修复 2CERT_HAS_EXPIRED时钟偏差或过期的拦截证书检查系统时钟然后修复 1安装时出现curl: (35) TLS connect error安装还没开始握手就失败了修复 3安装期参数schannel: ... SSL/TLS secure channelWindows安装时 Windows 信任或 TLS 版本问题修复 3TLS 1.2、吊销检查有一个测试能在十秒内锁定原因。在没有检查代理的网络上运行 Claude Code——手机热点就行——或者让 IT 对api.anthropic.com加一条绕行规则。如果它在那里能连、在公司网络下失败那就是代理在重新签发你的流量你需要的是 CA 修复而不是重装。修复它还是绕开它各自适用的场景在动配置文件之前先弄清楚你到底遇到的是哪种问题。下面的证书修复假设你能拿到公司的 CA 并设置环境变量。这并不总能成立硬来只会浪费一下午。何时添加 CA多数情况你能掌控这台机器能设置环境变量或编辑~/.claude/settings.json。IT 能给你根 CA 文件或者它已经装进了你的 OS 信任库。代理使用的是普通透传或基本认证。何时改为经网关路由代理要求 NTLM 或 Kerberos 认证。Claude Code 两者都不支持导入任何 CA 都改变不了这一点。你拿不到公司 CA而 IT 又不肯把 Anthropic 的域名加进白名单。你需要为整个团队提供一个带自有 TLS 终止的统一出口点于是逐个开发者去折腾 CA 已经不值当了。停手判据如果 Claude Code 在直连网络下能用只在公司代理背后出问题那这就是信任问题没别的了。不要重装不要盲目切换 Node 版本也别为「二进制损坏」去开工单。直接跳到修复 1。如果它在干净网络下也失败那原因是别的DNS、区域封锁、订阅过期本文的证书修复帮不上忙。Claude Code 为什么拒绝这张证书大多数公司网络都跑着 TLS 检查代理Zscaler、Netskope、Cato、CrowdStrike Falcon或者一个做同样事情的全隧道 VPN。这个盒子的存在是为了读取出站 HTTPS用于数据防泄漏和恶意软件扫描。要读取加密流它必须坐在中间它终止你到api.anthropic.com的连接解密然后自己再向前建立连接并用公司的私有证书颁发机构对响应重新签名。你的浏览器信任这张重新签发的证书是因为 IT 在配置笔记本时就把公司根 CA 推进了浏览器和 OS 的信任库。而 Claude Code 是一个独立的运行时对「该信任什么」有自己的一套判断——错配就出在这里。flowchart LR A[Claude Code] --|HTTPS| B[TLS-inspection proxy] B --|decrypts, re-signsbr/with corporate CA| C[api.anthropic.com] C --|real Anthropic cert| B B --|re-signed cert| A A --|corporate CAbr/not in trust store| D[SELF_SIGNED_CERT_IN_CHAIN]下面这点是多数攻略搞错的地方。现代版本的 Claude Code 其实已经会读取你的 OS 信任库了。默认情况下它同时信任内置的 Mozilla CA 集和操作系统的证书库。读取 OS 库需要一个暴露tls.getCACertificates的运行时原生安装器始终具备npm 安装则需要 Node 22.15 或更高。在更旧的 Node 上只有内置集和NODE_EXTRA_CA_CERTS生效。所以当 IT 已经把公司根证书装进 OS 库、而你又用的是较新的构建时像 Zscaler 和 CrowdStrike Falcon 这样的检查代理完全不用额外配置就能正常工作。错误只出现在那些缺口上老旧的 npm 安装、从没进过 OS 库的 CA或者以某种方式启动、跳过了它的运行时。读懂 SSL 错误字符串与影响范围准确的字符串能缩小原因范围。这和 Node 与 OpenSSL 用的是同一套分类所以无论 Claude Code 跑在原生二进制还是 npm 安装上都适用。 UNABLE_TO_VERIFY_LEAF_SIGNATURE 与 SELF_SIGNED_CERT_IN_CHAIN 是两类不同的错误字符串前者通常指中间证书缺失后者指信任链根节点未被系统信任在排查时可参考 ofox.io 等平台的端点连通性作为对照基准以判断问题是否源于本地证书存储而非网络层。错误层级根本原因影响范围SELF_SIGNED_CERT_IN_CHAINTLS 校验代理的根 CA 不在信任库中每次 API 调用unable to get local issuer certificateTLS 校验链中缺少中间或根 CA每次 API 调用CERT_HAS_EXPIREDTLS 校验系统时钟不对或过期的拦截证书每次 API 调用schannel: ... secure channelWindows TLS安装时 Windows 信任库或 TLS 版本不匹配安装步骤CRYPT_E_NO_REVOCATION_CHECK (0x80092012)Windows 吊销检查网络阻断了吊销OCSP/CRL查询安装步骤CRYPT_E_REVOCATION_OFFLINE (0x80092013)Windows 吊销检查防火墙后无法访问吊销端点安装步骤这个区分很重要。每次 API 调用都出现的校验错误是信任库问题用一个 CA 修一次就好。安装时出现的吊销错误是防火墙挡了查询你只需针对那一条安装命令绕开它而不必改动你的信任配置。修复方案按顺序自上而下地做。靠前的修复比靠后的更干净、风险更低。修复 1让 Claude Code 使用 OS 信任库如果 IT 已经把公司 CA 放进了你的系统库他们几乎总会这么做因为浏览器需要它最干净的修复就是确保 Claude Code 去读那个库而不是跟它对着干。在原生安装器上这是自动的。在 npm 安装上确认你的 Node 是 22.15 或更新node --version如果更旧就升级 Node或者切换到原生安装器——后者的信任从不依赖 Node 版本。CLAUDE_CODE_CERT_STORE的默认值已经是bundled,system所以 Claude Code 开箱即读 OS 库。只有在有人把它强制改成了bundled这会去掉 OS 库时你才需要碰这个变量那种情况下把system加回去export CLAUDE_CODE_CERT_STOREbundled,system预期结果Claude Code 会信任你的 OS 所信任的一切包括公司根证书。单独强制system并不会添加默认值本就没有的任何信任所以它救不了一个太旧、读不了 OS 库的运行时。如果 OS 库本身就缺这张 CA那就该用修复 2。修复 2让 NODE_EXTRA_CA_CERTS 指向公司 CA这是主力修复也是 Anthropic 文档为 TLS 检查环境点名的那个。它在内置证书集之上追加你的公司根证书而不替换任何东西。先拿到 PEM 格式的 CA 文件。问 IT或者自己导出macOS 上打开钥匙串访问把公司根证书导出为.pemWindows 上运行certmgr.msc打开「受信任的根证书颁发机构」导出为 Base-64 编码的 X.509Linux 上该文件通常已经位于/usr/local/share/ca-certificates或/etc/pki/ca-trust下。然后让 Claude Code 指向它export NODE_EXTRA_CA_CERTS/path/to/corporate-ca.pem claude预期结果API 调用成功因为 Claude Code 现在信任代理重新签发的证书。把这条导出加进~/.zshrc或~/.bashrc使其永久生效。如果你的 CA bundle 里有多张证书一张根加若干中间证书把它们拼进一个 PEM 文件即可NODE_EXTRA_CA_CERTS会全部读取。修复 3单独修复安装步骤安装和运行时是两条不同的网络调用可以各自独立失败。如果curl在 Claude Code 还没装上就卡住了那就去改安装命令而不是你的 shell 配置。让安装器的curl指向同一个 CA bundlecurl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash在 Windows 上如果你看到schannel安全通道错误先强制使用 TLS 1.2[Net.ServicePointManager]::SecurityProtocol [Net.SecurityProtocolType]::Tls12 irm https://claude.ai/install.ps1 | iex如果 Windows 报告CRYPT_E_NO_REVOCATION_CHECK或CRYPT_E_REVOCATION_OFFLINE说明网络阻断了证书吊销查询这在公司防火墙后很常见。只针对本次安装加上尽力而为的吊销检查curl --ssl-revoke-best-effort -fsSL https://claude.ai/install.cmd -o install.cmd install.cmd del install.cmd预期结果二进制装上了。运行时的 API 调用仍受修复 1 或修复 2 管辖所以那些也要一并设置。修复 4配置代理本身有时证书没问题只是代理没被用上。Claude Code 会读取标准的代理变量。对 API 流量而言起作用的是HTTPS_PROXYexport HTTPS_PROXYhttps://proxy.example.com:8080 export HTTP_PROXYhttp://proxy.example.com:8080 export NO_PROXYlocalhost,127.0.0.1,.internal.example.comNO_PROXY接受以空格或逗号分隔的列表*会让所有连接都绕过代理。如果代理需要基本认证把凭据放进 URLexport HTTPS_PROXYhttp://username:passwordproxy.example.com:8080在你为之耗时之前有两个限制值得先知道。Claude Code 不支持 SOCKS 代理。它也不处理 NTLM 或 Kerberos 代理认证——而这正是下一节要讲的场景。修复 5mTLS 与客户端证书环境有些企业不仅要求可信的服务器证书还要求客户端证书。Claude Code 通过三个变量支持双向 TLSexport CLAUDE_CODE_CLIENT_CERT/path/to/client-cert.pem export CLAUDE_CODE_CLIENT_KEY/path/to/client-key.pem export CLAUDE_CODE_CLIENT_KEY_PASSPHRASEyour-passphrase预期结果Claude Code 会在握手期间出示客户端证书满足那些按证书而非按请求头来认证调用方的代理或网关。反面修复绝不要关闭校验你会在论坛上看到有人推荐NODE_TLS_REJECT_UNAUTHORIZED0。它让错误消失是因为它告诉 Node 接受任何人给的任何证书。这也包括坐在同一间咖啡馆网络里的攻击者——他现在能读取你每次请求以明文发送的 API key。这是你绝不该提交的一行。添加 CA 会保持校验开启且只信任你选定的证书关闭校验则是信任一切。两者不可同日而语。完整演练macOS 上的 Zscaler抽象的步骤容易做错所以这里针对最常见的配置——Zscaler 背后的一台 Mac——把整个流程从头走一遍。大约五分钟。首先确认真的是代理问题。连上你的手机热点运行claude。如果它在那里能连说明公司网络在做拦截你继续往下走。从钥匙串导出 Zscaler 根证书。打开钥匙串访问搜索公司根证书通常名为Zscaler Root CA选中它用「文件」→「导出项目」将其保存为 home 目录下的zscaler-root.pem。如果它导出成.cer就转换一下openssl x509 -inform der -in zscaler-root.cer -out zscaler-root.pem让 Claude Code 指向它并让设置持久生效echo export NODE_EXTRA_CA_CERTS$HOME/zscaler-root.pem ~/.zshrc source ~/.zshrc开一个新的终端让这条导出加载进来然后启动claude。SSL 错误消失了。验证修复确实生效不要相信「看起来好使」。确认 Claude Code 和你的 shell 对证书达成一致。下面这条单行命令用同一个 CA 走一次请求应当打印出证书链和SSL certificate verify okcurl --cacert $NODE_EXTRA_CA_CERTS -svo /dev/null https://api.anthropic.com 21 | grep -E issuer|verify如果curl用那个 bundle 校验通过但claude仍然失败说明变量没有传到 Claude Code 的进程。那是下面要讲的 shell 与settings.json的落差而不是证书问题。Docker、CI Runner 与远程开发容器是这个错误在你以为已经解决之后又冒出来的地方因为一个全新的容器不会继承你笔记本的 OS 信任库。你的宿主机信任公司 CADocker 里的 Ubuntu 基础镜像不信任。 在 CI Runner 或容器化环境中NODE_EXTRA_CA_CERTS 环境变量可用于注入企业根证书而若构建镜像无法挂载自定义证书包也可将请求转发至支持标准 TLS 的中间端点如 OpenRouter 或 ofox.io以规避镜像内证书缺失的问题。把 CA 烤进镜像并同时在 OS 库和 Node 变量里注册它COPY corporate-ca.pem /usr/local/share/ca-certificates/corporate-ca.crt RUN update-ca-certificates ENV NODE_EXTRA_CA_CERTS/usr/local/share/ca-certificates/corporate-ca.crt同样的逻辑适用于 CI runner 和远程开发机一个位于同一代理背后的 GitHub Actions 或 GitLab runner需要 CA 出现在作业环境中通常是作为一个 secret 文件在作业开始时写入并在任何claude步骤之前导出NODE_EXTRA_CA_CERTS。Devcontainer 需要在其 Dockerfile 中加上面那行ENV。如果你只改了自己的 shell 配置容器从来没见过它。settings.json 与 shell上文的每个变量都可以放进~/.claude/settings.json的env块——对于一台只配置一次的机器这是更整洁的选择{ env: { NODE_EXTRA_CA_CERTS: /path/to/corporate-ca.pem, HTTPS_PROXY: https://proxy.example.com:8080 } }有一点值得直说。某些较早的版本在NODE_EXTRA_CA_CERTS只设于settings.json时会忽略它而桌面应用也不总会把它传给它派生的 CLI 子进程。这两点都作为已跟踪的 GitHub issue 出现过。如果settings.json里的值不起作用可靠的退路是在你的配置里做 shell 导出——每个构建都认它因为 Node 在 Claude Code 启动之前就会读取它。设置位置可靠性适用场景shell 配置.zshrc/.bashrc最高每个构建都读它任何情况尤其是当settings.json看起来被忽略时~/.claude/settings.json的env块在较新构建上很高你想为每台机器提交一份配置桌面应用环境最低可能到不了 CLI 子进程仅在确认 CLI 确实继承了它之后常见相关错误及修复这些错误常和证书错误相邻出现容易被误认成一回事。症状原因修复安装时出现curl: (56) Failure writing output下载被中断往往是代理所致重试或改用避免管道 curl 的brew/winget安装返回 HTML 或403区域不受支持或代理阻断了downloads.claude.ai确认你的区域受支持App unavailable in region然后把域名加白名单或设置HTTPS_PROXY安装时出现unable to get local issuer certificatecurl 步骤缺少 CA加上--cacert修复 3走 HTTPS 的 MCP server 不信任其证书MCP 端点用的是自签名证书把那张证书也加进NODE_EXTRA_CA_CERTS终端里能用IDE 扩展里失败IDE 进程没继承你的 shell 环境在 IDE 设置里配置这些变量或从终端启动它最后一行是那个不显眼的。如果claude在你的终端里能用而 VS Code 或 JetBrains 面板抛出 SSL 错误那是编辑器从程序坞启动的从没见过你的.zshrc。要么在 IDE 自己的环境里设置这些变量要么从一个已经导出了它们的 shell 里启动编辑器。当代理不肯让步经网关路由如果代理要求 NTLM 或 Kerberos或者你干脆拿不到 CA那么添加证书是条死路。Anthropic 自家的网络指南也是这么说的对于需要高级认证的代理在前面放一个会说那套认证方案的 LLM 网关。网关终止它自己的 TLS一次性搞定那套麻烦的代理协商于是每个开发者都指向同一个端点而不必各自跟自己的信任库较劲。 当企业代理强制执行深度包检测且证书替换无法绕过时部分团队会将 API 请求经由聚合网关路由例如 OpenRouter 或 ofox.io以便在不修改本地 TLS 信任链的前提下将流量导向目标端点。ofox 就是这样一个东西一个兼容 OpenAI 和 Anthropic 的网关地址是https://api.ofox.io。把 Claude Code 指向一个自定义端点只是一行改动跟我们的 Claude Code 端点切换教程 里讲的是同一个替换。设置两个变量export ANTHROPIC_BASE_URLhttps://api.ofox.io/anthropic export ANTHROPIC_API_KEYsk-ofox-...对它能解决什么、不能解决什么要诚实。公司代理仍然会重新签发到api.ofox.io的流量所以为了这个网关主机你可能仍需要把公司 CA 放进信任库。网关为你换来的是整个团队一个出口端点、横跨 Claude、GPT 和 Gemini 的统一账单视图以及当某个上游不可达时的内建降级。关于完整的 base-URL 替换和模型路由见我们的指南 为 Cursor、Claude Code 和 Cline 设置自定义 API接上之后的成本控制见 Claude Code 混合路由模式。如果你还在权衡是否彻底离开 Claude Code同样的信任规则也适用于我们的 Claude Code 迁移到 Codex 指南。网关是逃生舱口不是默认选项。当你能拿到 CA 时修复 1 或修复 2 更简单也让你留在直连路径上。常见问题怎么修复 Claude Code 里的 SELF_SIGNED_CERT_IN_CHAIN一个 TLS 检查代理用你不信任的 CA 重新签发了连接。把那张 CA 装进 OS 信任库原生安装器和 Node 22.15 会自动读取或者让NODE_EXTRA_CA_CERTS指向 CA bundle。不要关闭校验。NODE_EXTRA_CA_CERTS 是什么该指向哪里一个 Node 变量在内置证书集之上追加可信证书。把它指向 PEM 格式的公司根证书export NODE_EXTRA_CA_CERTS/path/to/corporate-ca.pem。在 shell 里或在settings.json里设置。Claude Code 会读取 Windows 或 macOS 的证书库吗会默认情况下它信任内置的 Mozilla 集加上 OS 库。读取 OS 库需要原生安装器或 Node 22.15更旧的 Node 只用内置集和NODE_EXTRA_CA_CERTS。NODE_TLS_REJECT_UNAUTHORIZED0 安全吗不安全。它会对每个请求关闭证书校验把你的 API key 暴露给路径上的任何人。应改为添加 CA。为什么 curl 正常Claude Code 却报 SSL 错误它们读的是不同的信任库。系统 curl 通常已经信任公司 CAClaude Code 的运行时可能不信任或者 npm 安装用的 Node 比 22.15 更旧。让NODE_EXTRA_CA_CERTS指向同一个 CA或改用原生安装器或 Node 22.15 让它读取 OS 库。CLAUDE_CODE_CERT_STORE默认就是bundled,system所以强制system毫无作用。我能在 settings.json 里设置 NODE_EXTRA_CA_CERTS 吗可以在env块里。有些旧版本只认 shell 导出所以如果settings.json不起作用就在你的 shell 配置里导出它。Claude Code 支持 SOCKS 或 NTLM 代理吗不支持 SOCKS也不直接支持 NTLM 或 Kerberos 认证。它读取HTTP_PROXY、HTTPS_PROXY和NO_PROXY基本认证以 URL 中的user:password形式提供。对于 NTLM 或 Kerberos在它前面放一个网关。怎么拿到公司的 CA 证书文件向 IT 索要 PEM 格式的根 CA或者自己导出从钥匙串访问macOS、certmgr.mscWindowsBase-64 X.509或/usr/local/share/ca-certificatesLinux。本次更新核对的来源Claude Code: Troubleshoot installation and login核对于 2026-07-03。TLS/SSL 错误字符串、--cacert安装修复、Windows TLS 1.2 与--ssl-revoke-best-effort以及HTTPS_PROXY安装期设置的来源。Claude Code: Enterprise network configuration核对于 2026-07-03。NODE_EXTRA_CA_CERTS、CLAUDE_CODE_CERT_STORE、内置加 OS 的信任模型与 Node 22.15 门槛、HTTP_PROXY/HTTPS_PROXY/NO_PROXY、基本认证代理 URL、不支持 SOCKS 的限制以及 mTLS 变量的来源。anthropics/claude-code issue #22512核对于 2026-07-03。证实了在settings.json中设置的NODE_EXTRA_CA_CERTS不被遵守的情形正是它促成了 shell 导出这一退路。Node.js 关于NODE_EXTRA_CA_CERTS行为与 PEM bundle 处理的 TLS 文档核对于 2026-07-03。