错误现象在公司网络、代理环境或者自建网关后面使用 Codex 时比较容易碰到SELF_SIGNED_CERT_IN_CHAIN。常见场景有两个一个是安装或更新 Codex 相关 npm 包时失败另一个是 Codex CLI 调用接口时直接报证书链错误。典型报错类似下面这样### token云桥中转 0029.org ### request to https://api.openai.com/v1/... failed, reason: self-signed certificate in certificate chain Error: SELF_SIGNED_CERT_IN_CHAIN at TLSSocket.onConnectSecure (_tls_wrap.js:...)如果是 npm 安装阶段可能会看到npm ERR! code SELF_SIGNED_CERT_IN_CHAIN npm ERR! request to https://registry.npmjs.org/... failed, reason: self-signed certificate in certificate chain先不要急着改代码。这个错误大多数不是 Codex 本身的问题而是本机 Node.js 在校验证书链时发现链路中有一个自签名 CA但这个 CA 不在它信任的根证书列表里。先判断问题发生在哪一层排查时建议按顺序来不要一上来就关证书校验。先确认是 npm、Codex CLI、代理还是系统证书的问题。1. 看 npm 是否也报错npm ping npm config get registry npm config get strict-ssl npm config get cafile如果npm ping就报SELF_SIGNED_CERT_IN_CHAIN说明至少 npm 这层证书配置有问题。此时 Codex 调接口失败只是同一个问题的表现。2. 用 curl 看证书链curl -v https://api.openai.com/v1/models如果返回里能看到公司代理、网关、安全设备签发的证书例如 issuer 不是常见公共 CA而是公司内部 CA那么基本可以确认是代理做了 HTTPS 解密需要把内部根证书加到信任链。3. 检查代理环境变量echo $HTTP_PROXY echo $HTTPS_PROXY echo $NODE_EXTRA_CA_CERTSWindows PowerShell 可以这样看echo $env:HTTP_PROXY echo $env:HTTPS_PROXY echo $env:NODE_EXTRA_CA_CERTS有些机器以前配过代理后来网络环境换了但环境变量还在Node 请求仍然会走旧代理也会触发证书链错误。常见原因公司 HTTPS 代理拦截安全网关重新签发证书本机浏览器信任但 Node.js 不一定信任。npm 使用了自定义 registry私有源或镜像源证书链不完整。Node.js 没有加载系统根证书尤其在 macOS、Linux、容器环境里更常见。配置了错误的 cafilenpm config或环境变量指向了过期证书文件。系统时间不正确证书还没生效或已经过期也可能表现为 TLS 校验失败。逐步修复方法方法一导出公司或代理根证书如果你在公司网络里一般需要从浏览器或 IT 提供的入口导出根 CA 证书。注意要导出根证书不是某个网站的叶子证书。文件格式建议使用 PEM例如corp-root-ca.pem如果拿到的是.cer或.crt可以先看内容。如果是以-----BEGIN CERTIFICATE-----开头就是 PEM 格式如果是二进制 DER 格式可以转换openssl x509 -inform DER -in corp-root-ca.cer -out corp-root-ca.pem方法二让 Node.js 信任这个根证书对 Codex CLI 这类基于 Node.js 的工具比较稳的方式是配置NODE_EXTRA_CA_CERTS。macOS / Linuxexport NODE_EXTRA_CA_CERTS/Users/yourname/certs/corp-root-ca.pem codex如果希望长期生效可以写入 shell 配置文件echo export NODE_EXTRA_CA_CERTS/Users/yourname/certs/corp-root-ca.pem ~/.zshrc source ~/.zshrcWindows PowerShell$env:NODE_EXTRA_CA_CERTSC:\certs\corp-root-ca.pem codex长期生效可以用setx NODE_EXTRA_CA_CERTS C:\certs\corp-root-ca.pem注意setx设置后需要重新打开终端才会生效。方法三给 npm 配置 cafile如果错误出现在安装 Codex 或 npm 包阶段可以单独给 npm 配置证书文件npm config set cafile /Users/yourname/certs/corp-root-ca.pem npm config set strict-ssl true npm pingWindows 路径示例npm config set cafile C:\certs\corp-root-ca.pem npm config set strict-ssl true npm ping如果之前有人为了临时解决问题关闭过校验建议改回来npm config set strict-ssl truestrict-ssl false确实可能让安装继续跑但它绕过了证书校验不适合作为长期方案尤其不建议在生产环境或公司开发机上保留。方法四清理错误代理配置如果你已经不需要代理但环境变量还存在可以临时清掉再测试。macOS / Linuxunset HTTP_PROXY unset HTTPS_PROXY unset http_proxy unset https_proxyWindows PowerShellRemove-Item Env:HTTP_PROXY Remove-Item Env:HTTPS_PROXY Remove-Item Env:http_proxy Remove-Item Env:https_proxynpm 里也可能单独配置了代理npm config get proxy npm config get https-proxy npm config delete proxy npm config delete https-proxy如果你本来就是通过中转或代理访问模型接口建议选一个证书链正常、文档清楚、调用方式稳定的服务。实际项目里我会优先看是否支持标准 OpenAI API 格式、是否方便在 Cursor、VS Code、Codex CLI 里配置。比如 token 云桥 AI 中转站 0029.org适合作为排查网络和接口兼容性时的一个备选项但证书和代理配置仍然要按本机环境处理好。方法五检查系统时间和 Node 版本系统时间错误也会造成证书校验异常特别是虚拟机、WSL、Docker 容器里经常被忽略。date node -v npm -v如果 Node 版本太旧也建议升级到当前维护中的 LTS 版本。老版本 Node 内置证书和 TLS 行为可能和新环境不一致。修复后的验证方式证书配置改完后不要只看 Codex 能不能打开建议分层验证。验证 npmnpm ping npm view npm version如果这两条都正常说明 npm 访问 registry 的证书链已经没问题。验证 Node.js HTTPS 请求可以用一段最小脚本确认 Node 是否能正常建立 TLS 连接node -e require(https).get(https://api.openai.com, res { console.log(res.statusCode); }).on(error, err { console.error(err); })如果不再出现SELF_SIGNED_CERT_IN_CHAIN说明 Node 侧证书信任已经生效。返回 404、401 之类状态码都不一定是坏事至少说明 TLS 握手通过了。验证 Codex最后再回到 Codex 本身执行一次最简单的命令或发起一次最小请求。此时如果还失败就要看是否是 API Key、base URL、模型名或权限问题而不是证书链问题。codex --version codex避免复发的几个注意点证书文件路径尽量固定不要放在临时目录或下载目录。公司根证书更新后要同步更新NODE_EXTRA_CA_CERTS指向的 PEM 文件。不要长期使用NODE_TLS_REJECT_UNAUTHORIZED0这会关闭 Node.js TLS 校验。容器里运行 Codex 时也要把根证书复制进镜像并配置环境变量。切换网络后记得检查代理环境变量和 npm proxy 配置。总结一下SELF_SIGNED_CERT_IN_CHAIN的核心是证书链不被 Node.js 信任。排查时先确定错误发生在 npm、Node 请求还是 Codex 调用层再补齐根证书、修正代理配置最后用 npm、Node 脚本和 Codex 分别验证。不要把关闭 SSL 校验当成正式修复方案这类问题按证书链处理后面会省很多排查时间。