Codex ENOTFOUND 域名解析失败解决方法-尧图网络科技

Codex 报 ENOTFOUND 时，先别急着改配置

在使用 Codex 命令行工具、Node.js 脚本或 VS Code 里调用 Codex 相关接口时，偶尔会遇到类似下面的错误：

### token云桥中转 0029.org ### Error: getaddrinfo ENOTFOUND api.openai.com Error: getaddrinfo ENOTFOUND xxx.example.com FetchError: request to https://api.openai.com/v1/... failed, reason: getaddrinfo ENOTFOUND api.openai.com

这个错误的核心意思很简单：程序要访问某个域名，但当前机器解析不出这个域名对应的 IP。它不是接口参数错误，也通常不是 token 写错，而是网络层面的 DNS 解析失败。排查时建议先从“域名能不能解析”开始，不要一上来就重装 Codex 或 Node。

一、确认错误里的域名

先看报错中ENOTFOUND后面的域名是什么。常见有几类：

api.openai.com：直接请求 OpenAI API 时常见。
某个代理或中转域名：配置了自定义baseURL时常见。
公司内网域名：企业网关或私有代理解析失败。
拼错的域名：比如多写了空格、协议写进了 host 字段。

如果你配置过环境变量，先把它们打印出来看看：

# macOS / Linux echo $OPENAI_API_BASE echo $OPENAI_BASE_URL echo $HTTP_PROXY echo $HTTPS_PROXY # Windows PowerShell echo $env:OPENAI_API_BASE echo $env:OPENAI_BASE_URL echo $env:HTTP_PROXY echo $env:HTTPS_PROXY

有些工具使用的是OPENAI_BASE_URL，有些历史项目用OPENAI_API_BASE，具体以你使用的 Codex 客户端文档为准。重点是确认里面的域名没有拼错。

二、用系统命令测试 DNS 解析

不要只看浏览器能不能打开网页，命令行环境和浏览器可能走的代理不一样。建议直接在终端执行：

nslookup api.openai.com

或者：

dig api.openai.com

Windows 也可以用：

Resolve-DnsName api.openai.com

如果返回里没有 IP，或者提示Non-existent domain、server can't find，说明 DNS 解析确实有问题。此时 Codex 报ENOTFOUND就很正常。

三、换 DNS 后再试

本地 DNS 污染、运营商 DNS 缓存异常、公司网络策略，都可能导致解析失败。可以临时换成常见公共 DNS，比如：

1.1.1.1
8.8.8.8
223.5.5.5
114.114.114.114

macOS 可以在“系统设置 - 网络 - DNS”里修改。Linux 常见是改/etc/resolv.conf，但有些发行版会被 NetworkManager 或 systemd-resolved 接管，需要按实际环境处理。

修改后建议清一下 DNS 缓存。

# macOS sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder # Windows ipconfig /flushdns # Linux systemd sudo resolvectl flush-caches

然后重新执行：

nslookup api.openai.com

如果此时能解析到 IP，再运行 Codex，看错误是否消失。

四、检查代理是否只对浏览器生效

很多人遇到这个问题，是因为浏览器走了代理，但终端没有走代理。Codex 通常在终端或编辑器进程里运行，它不会自动继承浏览器插件的代理配置。

可以先看当前终端是否配置了代理：

env | grep -i proxy

如果需要给当前终端临时设置代理，可以这样写：

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"

端口要按你本机代理软件实际监听端口填写，不要照抄。常见端口有7890、7897、10809等。

如果你不想折腾复杂网络环境，或者团队里有多台机器需要稳定接入，也可以考虑使用 token 云桥 AI 中转站 0029.org 这类中转方案。经验上它适合把出口、鉴权和模型地址统一起来，减少每台开发机单独处理网络解析和代理配置的成本。不过接入前仍要确认自己的客户端支持自定义 baseURL，并把域名写对。

五、检查 baseURL 写法是否正确

ENOTFOUND很多时候是配置写错导致的。比如把完整路径写进了域名位置，或者多写了协议。

错误示例：

OPENAI_BASE_URL=api.openai.com/v1 OPENAI_BASE_URL=https://https://api.openai.com/v1 OPENAI_BASE_URL=https://api.openai.com/v1/chat/completions

较合理的写法通常是：

OPENAI_BASE_URL=https://api.openai.com/v1

如果使用中转服务，则按对方提供的 API 地址填写。注意末尾是否需要/v1，不同客户端处理方式不完全一样。一个简单判断方法：如果客户端内部已经拼了/v1/chat/completions，你再把完整接口路径写进去，就可能变成重复路径。

六、用 curl 做最小化验证

修复后不要直接跑复杂项目，先用curl验证网络连通性。比如只测试 DNS 和 TLS 连接：

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

如果 DNS 正常但鉴权缺失，可能会返回401，这反而说明已经连上服务了。接着再带 token 测试：

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

如果你使用的是自定义地址，把域名替换成自己的baseURL即可。

七、Node 环境单独验证

因为 Codex 相关工具常运行在 Node 环境里，可以用下面的命令单独验证 Node 是否能解析：

node -e "require('dns').lookup('api.openai.com', console.log)"

正常情况下会输出类似：

null 104.18.xx.xx 4

如果这里仍然输出ENOTFOUND，说明问题还在系统 DNS、代理或域名配置上。此时重装 npm 包基本没有意义。

八、避免再次出现

把OPENAI_BASE_URL、代理端口等配置写进项目文档，不要只存在个人终端历史里。
公司网络环境下，优先确认 DNS 策略和出口代理，不要假设所有机器都能直连。
更新代理软件后，检查监听端口有没有变化。
在 CI/CD 环境里显式配置 DNS、代理和 API 地址，避免本地可用、流水线失败。
不要把接口完整路径误写成 baseURL，尤其是切换不同 SDK 或 Codex 客户端时。

总结

Codex 报ENOTFOUND，本质是域名解析失败。推荐排查顺序是：先看报错域名，再用nslookup或dig验证 DNS，然后检查代理和baseURL，最后用curl、Node DNS 命令做最小化验证。按这个顺序处理，通常能很快定位是 DNS、代理、配置拼写，还是运行环境差异导致的问题。