Codex EAI_AGAIN DNS 临时失败处理教程

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 cant 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] DNS1.1.1.1 8.8.8.8 FallbackDNS223.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如果容器里失败、宿主机正常可以在启动容器时指定 DNSdocker 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_PROXYhttp://127.0.0.1:7890 export HTTPS_PROXYhttp://127.0.0.1:7890 export NO_PROXYlocalhost,127.0.0.1如果是 Node.js 项目建议在启动脚本前设置环境变量而不是写死在业务代码里HTTPS_PROXYhttp://127.0.0.1:7890 node app.jsWindows PowerShell 示例$env:HTTPS_PROXYhttp://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 21 | head -n 30如果你使用自定义接口域名也要把命令里的域名替换成实际配置的地址。很多排查浪费时间就是因为代码里用的是 A 域名命令测试的却是 B 域名。六、避免复发的几个习惯固定 DNS 配置服务器上线前确认 DNS不要完全依赖临时网络配置。容器显式指定 DNS尤其是长期运行的服务避免宿主机网络变化影响容器。保留网络日志记录错误类型、目标域名、请求时间方便区分 DNS、超时和鉴权错误。限制并发和重试不要让大量任务同时触发解析和重试。代理配置写入启动流程不要只在当前终端临时 export重启服务后很容易丢。总结Codex 调用里出现EAI_AGAIN优先按 DNS 解析问题处理先查nslookup和curl再看系统 DNS、容器 DNS、代理环境变量最后给业务请求补上合理的超时和重试。只要排查顺序清楚这类问题通常不难定位关键是不要一开始就怀疑 SDK 或模型接口本身。