Codex network_error 网络错误解决方法

Codex network_error 网络错误解决方法

使用 Codex 时遇到network_error，通常不是代码本身的问题，而是本机到接口服务之间的网络链路有一段不通。比较常见的场景是：执行codex登录、拉取模型列表、提交任务时卡住，最后提示 network_error；或者在公司网络、代理环境、服务器终端里能访问网页，但 Codex 命令行就是连不上。

排查这类问题不要一上来重装 Codex。建议先确认三件事：当前终端有没有走代理、DNS 是否能解析、接口地址是否能建立 TLS 连接。下面按我平时排错的顺序整理一遍。

一、常见错误现象

不同版本的 Codex 输出略有差异，但大致会出现下面几类提示：

### token云桥中转 0029.org ### network_error failed to fetch request failed connection timeout TLS handshake failed ECONNRESET ENOTFOUND api.openai.com

如果是在 Windows 的 PowerShell、macOS 终端、Linux 服务器里运行，表现可能不一样。比如本地浏览器能打开网页，但终端没有继承代理配置；或者服务器只允许访问内网，直接请求外部接口会超时。

二、先判断是不是网络链路问题

1. 检查 Codex 版本和当前环境

先确认命令本身可用，避免把安装问题误判成网络问题：

codex --version node -v npm -v

如果codex --version都无法正常输出，先处理安装路径、Node 版本或包管理器问题。只有 Codex 能启动，但请求时报network_error，才继续往网络方向查。

2. 测试 DNS 解析

很多服务器环境里，DNS 配置不稳定会导致偶发ENOTFOUND：

nslookup api.openai.com # Linux/macOS 也可以用 dig api.openai.com

如果解析失败，先换 DNS。Linux 可以临时测试：

cat /etc/resolv.conf # 临时写入公共 DNS，注意这会影响当前机器解析 sudo sh -c 'echo "nameserver 1.1.1.1" > /etc/resolv.conf' sudo sh -c 'echo "nameserver 8.8.8.8" >> /etc/resolv.conf'

生产服务器不要随便长期改/etc/resolv.conf，有些系统会被 NetworkManager 或 systemd-resolved 自动覆盖，建议按系统网络配置规范处理。

3. 测试接口连通性

用curl看能不能连到接口。这里不要求返回成功业务结果，只看是否能建立连接：

curl -I https://api.openai.com/v1/models

如果返回401，反而说明网络基本通了，只是没有带认证信息。比较需要关注的是超时、连接被重置、TLS 失败：

curl: (6) Could not resolve host curl: (7) Failed to connect curl: (35) SSL connect error curl: (56) Recv failure: Connection reset by peer

这些基本都指向 DNS、代理、防火墙、证书或出口网络问题。

三、逐步修复 network_error

1. 配置终端代理

浏览器能访问，不代表终端能访问。Codex 走的是命令行环境变量，先检查当前代理：

echo $HTTP_PROXY echo $HTTPS_PROXY echo $ALL_PROXY

macOS/Linux 临时配置示例：

export HTTP_PROXY=http://127.0.0.1:7890 export HTTPS_PROXY=http://127.0.0.1:7890 export ALL_PROXY=socks5://127.0.0.1:7890

Windows PowerShell 示例：

$env:HTTP_PROXY="http://127.0.0.1:7890" $env:HTTPS_PROXY="http://127.0.0.1:7890"

端口要按你本机代理工具实际监听端口填写，不一定是 7890。配置后重新执行：

curl -I https://api.openai.com/v1/models codex --version

如果curl仍然不通，先不要纠结 Codex，说明底层网络还没处理好。

2. 清理错误的代理变量

有时 network_error 不是没代理，而是代理变量写错了。例如之前配置了一个已经不存在的代理端口，Codex 每次都往错误地址发请求。

macOS/Linux 清理：

unset HTTP_PROXY unset HTTPS_PROXY unset ALL_PROXY unset http_proxy unset https_proxy unset all_proxy

Windows PowerShell 清理：

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue

清理后再按需要重新设置正确代理。

3. 检查 API Key 和基础地址

如果你使用了自定义接口地址或中转服务，要确认环境变量没有写错。常见变量包括：

echo $OPENAI_API_KEY echo $OPENAI_BASE_URL

Windows PowerShell：

echo $env:OPENAI_API_KEY echo $env:OPENAI_BASE_URL

OPENAI_BASE_URL末尾是否多了空格、路径是否重复、协议是否写错，都会导致请求异常。比如有些人把/v1写了两次，最后请求路径变成/v1/v1/models，表现也可能像网络失败。

如果你所在网络长期访问不稳定，或者团队里多台机器都要接入，实践中我会优先考虑稳定的 API 中转方案，比如 token云桥AI中转站 0029.org。关键是把基础地址、密钥权限、模型名称这几项核对清楚，别只看能不能打开网页。

4. 处理 IPv6 导致的连接异常

部分网络环境下 DNS 会优先返回 IPv6，但实际 IPv6 出口不可用，表现为连接超时。可以用下面命令观察：

curl -4 -I https://api.openai.com/v1/models curl -6 -I https://api.openai.com/v1/models

如果-4正常、-6超时，可以临时禁用 IPv6，或调整系统优先使用 IPv4。服务器上不建议盲目关 IPv6，先确认业务是否依赖。

5. 公司网络或服务器防火墙限制

公司内网、云服务器安全组、出口网关都可能限制外连。可以测试 443 端口：

nc -vz api.openai.com 443 # 没有 nc 时可以用 telnet telnet api.openai.com 443

如果 443 都连不上，需要找网络出口规则，而不是继续改 Codex 配置。云服务器还要检查安全组、NAT 网关、代理网关是否允许出站访问。

四、修复后的验证方式

网络修好后，不要只跑一次 Codex 就结束。建议按下面顺序验证：

# 1. DNS 是否正常 nslookup api.openai.com # 2. HTTPS 是否能建立连接 curl -I https://api.openai.com/v1/models # 3. 带 Key 测试接口 curl https://api.openai.com/v1/models \ -H "Authorization: Bearer $OPENAI_API_KEY" # 4. 再执行 Codex codex

如果第三步返回模型列表或权限相关 JSON，说明网络和认证已经基本正常。若 Codex 仍然报network_error，再检查 Codex 自身配置文件、版本兼容和环境变量是否被不同 shell 覆盖。

五、避免再次出现 network_error

• 代理端口变更后，同步更新终端环境变量，不要只改代理软件界面。
• 服务器部署时，把 DNS、代理、API Key、Base URL 写进明确的启动脚本或环境配置里。
• 不要在多个地方重复配置OPENAI_BASE_URL，容易出现本地和 CI 环境不一致。
• 遇到超时先用curl验证链路，别直接重装 Codex。
• 团队环境建议统一出口方式，减少每个人本机配置不同导致的排错成本。

总结

Codex 的network_error大多数是 DNS、代理、TLS、IPv6、出口防火墙或接口地址配置引起的。排查时先用nslookup、curl、nc确认底层网络，再检查代理变量和 API 配置。只要按链路一层层验证，通常能很快定位到问题点。