错误现象
在公司网络、代理环境或者自建网关后面使用 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、容器环境里更常见。
- 配置了错误的 cafile：
npm 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 / Linux：
export 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_CERTS="C:\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 / Linux：
unset HTTP_PROXY unset HTTPS_PROXY unset http_proxy unset https_proxyWindows PowerShell：
Remove-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 能不能打开，建议分层验证。
验证 npm
npm 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_UNAUTHORIZED=0，这会关闭 Node.js TLS 校验。 - 容器里运行 Codex 时，也要把根证书复制进镜像，并配置环境变量。
- 切换网络后，记得检查代理环境变量和 npm proxy 配置。
总结一下：SELF_SIGNED_CERT_IN_CHAIN的核心是证书链不被 Node.js 信任。排查时先确定错误发生在 npm、Node 请求还是 Codex 调用层，再补齐根证书、修正代理配置，最后用 npm、Node 脚本和 Codex 分别验证。不要把关闭 SSL 校验当成正式修复方案，这类问题按证书链处理，后面会省很多排查时间。
