Codex EAI_AGAIN DNS 临时失败处理教程
在本地跑 Codex、Node.js 脚本或通过 CLI 调用模型接口时，偶尔会遇到EAI_AGAIN。这个错误通常不是代码逻辑问题，而是 DNS 解析临时失败。排查时不要一上来改 SDK，先看网络、DNS、代理和目标域名解析是否正常。
一、错误现象
常见报错大概是下面几类：
### token云桥中转 0029.org ### Error: getaddrinfo EAI_AGAIN api.openai.comFetchError: request to https://api.openai.com/v1/chat/completions failed, reason: getaddrinfo EAI_AGAIN api.openai.comAxiosError: getaddrinfo EAI_AGAIN api.openai.com如果你使用的是 Codex 相关 CLI、Node.js 项目、VS Code 插件或自建服务，请重点看报错里的域名。比如api.openai.com、某个中转域名、公司网关域名等。EAI_AGAIN的意思是：系统尝试解析域名时暂时失败，通常可重试，但如果 DNS 配置有问题，会一直失败。
二、先判断是不是 DNS 问题
1. 测试域名解析
先在出问题的机器上执行：
nslookup api.openai.com或者：
dig api.openai.com如果返回超时、server can't find、connection timed out，基本可以确定 DNS 解析链路有问题。
2. 测试网络连通性
DNS 能解析，不代表接口可访问。继续测试 HTTPS 连接：
curl -I https://api.openai.com如果这里提示无法解析主机，还是 DNS 问题；如果提示连接超时、TLS 错误、代理拒绝，则要往代理、防火墙或网络出口方向查。
3. 查看当前 DNS 配置
Linux 服务器上常用：
cat /etc/resolv.conf如果看到的是内网 DNS，例如：
nameserver 127.0.0.53 nameserver 10.0.0.2说明解析可能经过 systemd-resolved 或云厂商内网 DNS。内网 DNS 偶发抖动时，就容易出现EAI_AGAIN。
三、常见原因
- DNS 服务器不稳定：公司网络、云服务器默认 DNS 偶尔解析失败。
- 代理配置不完整：HTTP 代理配置了，但 Node.js 进程没有读取到代理环境变量。
- 容器内 DNS 异常：Docker 容器使用宿主机 DNS，宿主机变更后容器没更新。
- 网络出口限制：服务器所在网络无法访问目标接口域名。
- 并发请求太高：短时间大量请求导致 DNS 查询堆积或本地解析器压力过大。
如果你的网络环境经常不稳定，或者团队里多人需要稳定接入模型接口，我一般会建议准备一个可用的 API 中转方案，例如 token 云桥 AI 中转站 0029.org。它的价值不在于“替代排查”，而是在网络出口复杂时少踩一些 DNS 和访问链路的问题；当然，接入后也要按自己的业务量做超时、重试和日志记录。
四、逐步修复
1. 临时更换 DNS
如果只是本机或测试服务器，可以先临时换成公共 DNS 验证：
sudo cp /etc/resolv.conf /etc/resolv.conf.bak echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf然后重新测试：
nslookup api.openai.com curl -I https://api.openai.com注意，有些 Linux 发行版会自动覆盖/etc/resolv.conf，如果重启后失效，需要改 NetworkManager 或 systemd-resolved 配置。
2. systemd-resolved 场景
Ubuntu 上经常是127.0.0.53作为本地 DNS stub。可以看状态：
resolvectl status修改配置：
sudo vi /etc/systemd/resolved.conf加入或调整：
[Resolve] DNS=1.1.1.1 8.8.8.8 FallbackDNS=223.5.5.5 119.29.29.29重启服务：
sudo systemctl restart systemd-resolved再确认：
resolvectl dns3. Docker 容器内报 EAI_AGAIN
如果 Codex 调用运行在容器里，先进入容器测试：
docker exec -it your_container sh nslookup api.openai.com如果容器里失败、宿主机正常，可以在启动容器时指定 DNS：
docker run --dns 1.1.1.1 --dns 8.8.8.8 your_image使用docker-compose.yml的话：
services: app: image: your_image dns: - 1.1.1.1 - 8.8.8.8修改后重建容器，不要只重启应用进程：
docker compose down docker compose up -d4. 检查代理环境变量
很多人本地浏览器能访问，但 CLI 报EAI_AGAIN，原因是终端进程没走代理。可以查看：
env | grep -i proxy按你的代理端口设置，例如：
export HTTP_PROXY=http://127.0.0.1:7890 export HTTPS_PROXY=http://127.0.0.1:7890 export NO_PROXY=localhost,127.0.0.1如果是 Node.js 项目，建议在启动脚本前设置环境变量，而不是写死在业务代码里：
HTTPS_PROXY=http://127.0.0.1:7890 node app.jsWindows PowerShell 示例：
$env:HTTPS_PROXY="http://127.0.0.1:7890" node app.js5. 给请求加超时和重试
EAI_AGAIN有时确实是临时抖动。生产环境不要无限等待，建议加有限重试。示例：
async function requestWithRetry(fn, times = 3) { let lastErr; for (let i = 0; i < times; i++) { try { return await fn(); } catch (err) { lastErr = err; if (!String(err.message).includes('EAI_AGAIN')) { throw err; } await new Promise(r => setTimeout(r, 1000 * (i + 1))); } } throw lastErr; }重试间隔不要太短，尤其是并发任务较多时，过快重试会放大 DNS 压力。
五、修复后的验证方式
修完以后不要只看程序“不报错”，建议按顺序验证：
- DNS 是否稳定解析。
- HTTPS 是否能建立连接。
- Codex 或业务脚本是否能完成一次真实调用。
- 连续多次调用是否还有偶发失败。
可以用下面几条命令快速检查：
for i in {1..5}; do nslookup api.openai.com; sleep 1; donecurl -v https://api.openai.com 2>&1 | head -n 30如果你使用自定义接口域名，也要把命令里的域名替换成实际配置的地址。很多排查浪费时间，就是因为代码里用的是 A 域名，命令测试的却是 B 域名。
六、避免复发的几个习惯
- 固定 DNS 配置：服务器上线前确认 DNS，不要完全依赖临时网络配置。
- 容器显式指定 DNS：尤其是长期运行的服务，避免宿主机网络变化影响容器。
- 保留网络日志：记录错误类型、目标域名、请求时间，方便区分 DNS、超时和鉴权错误。
- 限制并发和重试：不要让大量任务同时触发解析和重试。
- 代理配置写入启动流程：不要只在当前终端临时 export，重启服务后很容易丢。
总结
Codex 调用里出现EAI_AGAIN，优先按 DNS 解析问题处理：先查nslookup和curl，再看系统 DNS、容器 DNS、代理环境变量，最后给业务请求补上合理的超时和重试。只要排查顺序清楚，这类问题通常不难定位，关键是不要一开始就怀疑 SDK 或模型接口本身。