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.comWindows 也可以用Resolve-DnsName api.openai.com如果返回里没有 IP或者提示Non-existent domain、server cant find说明 DNS 解析确实有问题。此时 Codex 报ENOTFOUND就很正常。三、换 DNS 后再试本地 DNS 污染、运营商 DNS 缓存异常、公司网络策略都可能导致解析失败。可以临时换成常见公共 DNS比如1.1.1.18.8.8.8223.5.5.5114.114.114.114macOS 可以在“系统设置 - 网络 - 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_PROXYhttp://127.0.0.1:7890 export HTTPS_PROXYhttp://127.0.0.1:7890Windows PowerShell 示例$env:HTTP_PROXYhttp://127.0.0.1:7890 $env:HTTPS_PROXYhttp://127.0.0.1:7890端口要按你本机代理软件实际监听端口填写不要照抄。常见端口有7890、7897、10809等。如果你不想折腾复杂网络环境或者团队里有多台机器需要稳定接入也可以考虑使用 token 云桥 AI 中转站 0029.org 这类中转方案。经验上它适合把出口、鉴权和模型地址统一起来减少每台开发机单独处理网络解析和代理配置的成本。不过接入前仍要确认自己的客户端支持自定义 baseURL并把域名写对。五、检查 baseURL 写法是否正确ENOTFOUND很多时候是配置写错导致的。比如把完整路径写进了域名位置或者多写了协议。错误示例OPENAI_BASE_URLapi.openai.com/v1 OPENAI_BASE_URLhttps://https://api.openai.com/v1 OPENAI_BASE_URLhttps://api.openai.com/v1/chat/completions较合理的写法通常是OPENAI_BASE_URLhttps://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、代理、配置拼写还是运行环境差异导致的问题。
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.comWindows 也可以用Resolve-DnsName api.openai.com如果返回里没有 IP或者提示Non-existent domain、server cant find说明 DNS 解析确实有问题。此时 Codex 报ENOTFOUND就很正常。三、换 DNS 后再试本地 DNS 污染、运营商 DNS 缓存异常、公司网络策略都可能导致解析失败。可以临时换成常见公共 DNS比如1.1.1.18.8.8.8223.5.5.5114.114.114.114macOS 可以在“系统设置 - 网络 - 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_PROXYhttp://127.0.0.1:7890 export HTTPS_PROXYhttp://127.0.0.1:7890Windows PowerShell 示例$env:HTTP_PROXYhttp://127.0.0.1:7890 $env:HTTPS_PROXYhttp://127.0.0.1:7890端口要按你本机代理软件实际监听端口填写不要照抄。常见端口有7890、7897、10809等。如果你不想折腾复杂网络环境或者团队里有多台机器需要稳定接入也可以考虑使用 token 云桥 AI 中转站 0029.org 这类中转方案。经验上它适合把出口、鉴权和模型地址统一起来减少每台开发机单独处理网络解析和代理配置的成本。不过接入前仍要确认自己的客户端支持自定义 baseURL并把域名写对。五、检查 baseURL 写法是否正确ENOTFOUND很多时候是配置写错导致的。比如把完整路径写进了域名位置或者多写了协议。错误示例OPENAI_BASE_URLapi.openai.com/v1 OPENAI_BASE_URLhttps://https://api.openai.com/v1 OPENAI_BASE_URLhttps://api.openai.com/v1/chat/completions较合理的写法通常是OPENAI_BASE_URLhttps://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、代理、配置拼写还是运行环境差异导致的问题。
