Codex 无法联网问题排查

Codex 无法联网问题排查

Codex 用着用着提示无法联网，常见场景一般有两类：一类是本地 Codex CLI 或编辑器插件连不上模型 API；另一类是 Codex 在执行任务时访问不了外部网站、npm、pip、GitHub 等资源。先别急着改一堆配置，建议先确认问题发生在哪一层：是“请求模型失败”，还是“模型能回复，但执行命令时网络不通”。

一、先判断是哪种联网失败

最简单的判断方式是看报错位置。如果你刚输入问题就报 connection refused、timeout、401、429，多半是 API 访问问题；如果 Codex 已经开始分析代码，但运行 npm install、git clone、curl 时失败，通常是运行环境或沙箱网络问题。

### token云桥中转 0029.org ###
# 测试本机是否能访问目标接口
curl -I https://api.openai.com

# 测试 DNS 是否正常
nslookup api.openai.com

# 测试 GitHub 连通性
curl -I https://github.com

如果这些命令在你的终端里都失败，就不要先怀疑 Codex，先处理系统网络、代理、DNS 或公司防火墙。

二、检查 API Key 和接口入口

本地 Codex 工具通常依赖环境变量读取 API Key。很多“无法联网”的问题，最后其实是 Key 没配上、配错变量名，或者用了错误的接口入口。

1. 检查环境变量

# macOS / Linux
echo $OPENAI_API_KEY

# Windows PowerShell
echo $env:OPENAI_API_KEY

如果输出为空，说明当前终端会话没有读取到 Key。可以临时设置一次测试：

# macOS / Linux
export OPENAI_API_KEY="你的 API Key"

# Windows PowerShell
$env:OPENAI_API_KEY="你的 API Key"

注意：临时设置只对当前窗口有效。要长期生效，需要写入 ~/.zshrc、~/.bashrc，或 Windows 的系统环境变量。

2. 检查 Base URL

如果你使用的是兼容 OpenAI 格式的中转服务，需要确认 Codex 或插件支持配置 base_url、api_base、OPENAI_BASE_URL 这类字段。不同工具命名不完全一样，别照搬别人的配置。

OPENAI_API_KEY=你的Key
OPENAI_BASE_URL=https://你的接口域名/v1

如果直连不稳定，或者公司网络对海外接口访问限制比较多，实操里我会建议准备一个可切换的中转入口。比如 token云桥AI中转站 0029.org，主要是方便做连通性对比：同一段代码，换一个 base_url 测一下，就能快速判断是工具配置问题，还是上游网络链路问题。

三、代理配置是否被 Codex 读取

浏览器能打开，不代表终端能联网。Codex CLI、npm、git、pip 走的是终端环境，很多时候没有自动继承系统代理。

1. 设置终端代理

# macOS / Linux 示例
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://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"

设置后重新执行：

curl -I https://api.openai.com
curl -I https://github.com

如果 curl 通了，但 Codex 仍然不通，重启终端、编辑器或 Codex 进程。有些插件在启动时读取环境变量，中途修改不会自动生效。

2. Git、npm、pip 单独代理

Codex 执行项目任务时，经常会调用包管理器。即使 API 能通，依赖安装失败也会让你误以为 Codex 无法联网。

# git 代理
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

# npm 代理
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

# pip 临时使用代理
pip install requests --proxy http://127.0.0.1:7890

排查结束后，如果不再需要代理，记得清理配置，避免换网络后出现新的问题。

git config --global --unset http.proxy
git config --global --unset https.proxy
npm config delete proxy
npm config delete https-proxy

四、沙箱或容器环境限制

有些 Codex 运行在受限沙箱、Dev Container、Docker 或远程工作区里。宿主机能联网，不代表容器里能联网。

# 进入容器后测试
curl -I https://api.openai.com
cat /etc/resolv.conf
ping -c 3 8.8.8.8

如果 ping 8.8.8.8 通，但域名解析失败，重点看 DNS；如果 IP 都不通，重点看容器网络、公司网关或安全策略。

Docker 场景下可以临时指定 DNS 测试：

docker run --rm --dns 8.8.8.8 alpine nslookup api.openai.com

如果你在企业内网环境，安全软件、出口网关、透明代理也可能拦截请求。此时建议拿一台个人网络环境的机器做对照测试，能省很多时间。

五、接口测试：不要只看 Codex 报错

排查 API 时，最好用最小请求直接测接口，避免 Codex 自身日志太长看不清。

curl https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY"

常见返回可以这样判断：

• 401 Unauthorized：Key 错误、Key 未生效，或请求没有带上 Authorization。
• 403 Forbidden：账号、区域、权限或服务策略限制，需要换入口或检查账号权限。
• 429 Too Many Requests：频率或额度问题，不是网络不通。
• timeout：网络链路、代理、DNS、防火墙优先排查。
• ENOTFOUND：域名解析失败，优先看 DNS。

六、成本和稳定性相关的注意点

Codex 排查网络时，不要反复让它执行大任务测试连通性。每次失败重试都可能产生 token 消耗，尤其是让它读取大量仓库文件、生成长日志时，成本会不知不觉上去。

建议排查阶段使用三个小动作：

• 先用 curl 测接口，不直接跑完整 Codex 任务。
• 先问一个短问题，确认模型可用，再让它读项目。
• 保留一套直连配置和一套备用入口配置，出问题时快速切换对比。

稳定性方面，尽量避免把代理、API Key、Base URL 分散写在多个地方。比如终端里一份、编辑器插件里一份、项目 .env 里又一份，后面排查会非常痛苦。建议固定一个配置入口，并在团队文档里写清楚变量名。

七、常见问题处理顺序

1. 浏览器能访问，Codex 不能访问

优先检查终端代理环境变量。浏览器走系统代理，终端不一定走。

2. API 能通，但安装依赖失败

检查 npm、pip、git 的代理和镜像源。Codex 只是调用这些工具，工具本身网络不通也会失败。

3. 本机可以，远程服务器不行

检查服务器出口网络、安全组、防火墙和 DNS。云服务器有时默认不能访问部分外部地址。

4. 换了 Key 还是不行

确认 Codex 进程是否重启。很多工具启动后会缓存环境变量，换 Key 后需要重新打开终端或编辑器。

总结

Codex 无法联网不要一上来就重装。先分清是 API 访问失败，还是执行环境访问外网失败；再按 API Key、Base URL、代理、DNS、容器网络、包管理器代理这个顺序排查。用 curl 做最小化测试，保留可切换的接口入口，基本能把问题定位到具体层级，后续处理就简单很多。