Codex CLI 连接超时和登录失败，先判断卡在哪一层
Codex CLI 装好之后一运行就转圈、登录页打不开、提示连接超时，是最常见的开局问题。排查 Codex CLI 连接超时，最省时间的办法不是反复重装，而是先判断失败发生在认证、网络还是出口线路这三层中的哪一层：认证层看凭据和登录方式，网络层看终端到目标域名的通路，出口线路层看长连接是否稳定。本文按这个顺序给出可以直接复制的检查命令，内容对照 OpenAI 官方 Codex 文档整理，查阅日期为 2026 年 9 月 20 日，具体子命令和配置项请以你本机 codex --help 的输出为准。
很多人的第一反应是「浏览器里能打开 ChatGPT，为什么终端不行」。原因在于浏览器和命令行走的是两条不同的通路：浏览器会读取系统级网络设置，而命令行程序通常只看当前 shell 里的环境变量。所以「网页正常、终端超时」本身就是一个有价值的信号，它把问题范围缩小到了终端这一侧。
认证层：登录方式选错，比网络不通更常见
官方文档把 Codex 的登录分成两类：用 ChatGPT 账号做浏览器登录，或者用 OpenAI Platform 的 API Key 按量计费。两种方式对应的命令不同，先确认自己走的是哪一种。
怎么确认当前登录状态
直接在终端执行下面这条命令，它会显示当前使用的认证方式。如果提示未登录，说明问题出在认证层，还谈不上网络。
codex login status需要清掉旧凭据重新来过时，用 codex logout，然后再执行 codex login。反复失败前先做这一步，可以排除旧的 token 残留造成的干扰。
浏览器登录卡在回调页怎么办
默认的 codex login 会拉起浏览器，登录完成后回调到本机的一个本地端口。官方文档里提到的默认回调端口是 1455。如果你是在远程服务器、容器或者没有图形界面的环境里运行，浏览器根本打不开本机的回调地址，登录就会一直等待。此时有三种做法：
- 改用设备码登录：
codex login --device-auth，适合没有浏览器的环境，需要先在 ChatGPT 的安全设置里启用设备码登录。 - 通过 SSH 端口转发把远程机器的 1455 端口转到本机，让本机浏览器完成回调。
- 在一台已经登录成功的机器上，把
~/.codex/auth.json拷贝到目标机器。这个文件里是访问令牌，要像密码一样保管，不要提交到代码仓库。
用 API Key 登录时的写法
API Key 登录是把密钥通过标准输入交给 codex login --with-api-key，而不是写在命令参数里，避免密钥留在 shell 历史中。凭据保存位置由配置项 cli_auth_credentials_store 决定，可选值是 file、keyring、auto 和 ephemeral：file 对应 CODEX_HOME（默认 ~/.codex）下的 auth.json，keyring 使用系统凭据库，ephemeral 只在当前进程内存里保留。如果换了机器或容器后总是提示未登录，多半是凭据存储方式与环境不匹配。
网络层：让终端和浏览器走同一条路
认证状态正常、命令依旧超时，就进入网络层。这一层的目标是回答一个问题：在同一个终端窗口里，能不能到达 OpenAI 相关域名。
先看当前 shell 里有没有代理变量
命令行程序常见的代理变量有 HTTPS_PROXY、HTTP_PROXY、ALL_PROXY 和 NO_PROXY。我查阅的官方文档里没有单独说明 Codex 对这些变量的读取行为，社区里也仍有相关的功能讨论，所以不要想当然，用下面的方式自己对照：
env | grep -i proxy
curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_appconnect}\n" https://api.openai.com/v1/models第二条命令没有带密钥，返回 401 是正常的，说明域名可达、TLS 握手成功；真正要看的是后面两个耗时：time_connect 是 TCP 连接完成的时间，time_appconnect 是 TLS 握手完成的时间。如果直接超时、返回空，或者握手时间明显偏长，就是网络层有问题。代理端口需要换成你本机实际使用的端口，下面的写法只是格式示例：
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890同时把 chatgpt.com 也用 curl -I 测一遍。ChatGPT 账号登录与 API Key 调用涉及的域名并不相同，两边都通才算通。
流式响应中断和「一直 Reconnecting」怎么看
登录成功、任务也能开始，但跑到一半提示重连，是另一类问题。官方配置示例里，模型提供方的网络参数有三个：request_max_retries（请求重试次数，默认 4）、stream_max_retries（流式中断后的重连次数，默认 5）、stream_idle_timeout_ms（流式响应空闲多久判定为断开，默认 300000 毫秒，也就是 5 分钟）。这三项写在 ~/.codex/config.toml 的 model_providers 段里，官方给出的 Azure 示例就是这样配置的。调大重试次数只能让它多试几次，并不能改善线路本身，把它当成缓冲手段而不是修复手段。
需要更详细的日志时，可以设置 RUST_LOG 环境变量提高日志级别，日志和缓存位于 CODEX_HOME 目录下。看日志时注意区分：TLS 握手失败、连接被重置、读取超时是三种不同的现象，对应的排查方向也不同。
出口线路层：认证和网络都正常，仍然断断续续
如果上面两层的检查都通过，但长任务依然会在几分钟后断开，问题多半在出口线路上。Codex 的一次任务往往是一条持续几十秒到几分钟的流式连接，线路只要出现短时丢包或路由抖动，短请求（比如 curl）看不出问题，长连接却会被打断。这一层可以用一个简单的自测思路来验证：
- 在同一台机器上，每隔一分钟执行一次上面的 curl 耗时命令，连续记录 30 分钟以上，把结果放进表格。
- 把记录分成不同时段和不同网络环境（办公网络、手机热点）各测一轮。
- 观察
time_connect的波动幅度，而不是只看平均值。波动大说明线路不稳，和 Codex 本身无关。
这套方法产生的是你自己环境里的数据，比任何通用结论都可靠。下表把常见现象和更可能的层对应起来：
| 现象 | 更可能的层 | 优先动作 |
|---|---|---|
| codex login status 提示未登录 | 认证层 | 重新登录，确认登录方式与凭据存储位置 |
| 浏览器登录一直等待回调 | 认证层 | 改用 --device-auth 或转发 1455 端口 |
| curl 到 api.openai.com 直接超时 | 网络层 | 检查 shell 中的代理变量与 DNS |
| curl 正常，任务中途反复重连 | 出口线路层 | 做多时段耗时记录，比较不同出口 |
| 只在某个网络环境下失败 | 网络层或线路层 | 换网络对照，确认是否与出口相关 |
到了这一步，如果对照记录显示线路抖动确实存在，换一条更稳定的出口通常比调参数有效。NasaCode 的 AI 智能路由就是针对 AI 平台访问设计的，会为这类长连接选择更合适的线路，同一套出口也覆盖 Claude Code、Cursor 等开发工具的使用场景。是否适合你的网络环境，建议先用上面的耗时记录法做一轮前后对照，再决定要不要长期使用。
一份可以照着走的排查顺序
把上面的内容压缩成五步，遇到 Codex CLI 连接超时时按顺序执行，通常十分钟内就能定位到具体的层：
- 执行
codex login status，确认认证状态与登录方式。 - 在同一个终端里执行
env | grep -i proxy，确认代理变量是否存在、格式是否正确。 - 用 curl 分别测试
api.openai.com和chatgpt.com，记录连接与握手耗时。 - 如果任务中途断开，查看
stream_idle_timeout_ms等配置，并用RUST_LOG打开日志观察断开原因。 - 做一轮多时段的耗时记录，判断是否需要更换出口线路。
Codex 的命令和配置项会随版本调整，本文内容以 2026 年 9 月 20 日查阅的官方文档为准。如果你的开发环境经常需要同时访问多个 AI 平台，可以在做完耗时记录之后，用 NasaCode 试一轮稳定出口的效果，再把结果和自己的记录对照。
延伸阅读
