Codex 一直 Reconnecting 怎么办？按端口、入口和登录状态排查

更新于 2026-10-24 · catcloud.buzz

简答：Codex 一直 Reconnecting，优先检查三个地方：本地 HTTP 类型端口是否在监听、当前入口是否读取了环境变量、登录状态是否仍然有效。本文只解决连接反复重试、连接慢和最小任务无法完成，不提供未核实的服务可用率或版本承诺。建议按“服务状态→doctor→端口→入口变量→登录→最小任务”的顺序处理，避免一开始就修改传输配置。

定义：Codex 稳定连接排查，是用状态页、诊断命令、本地端口、入口环境和最小任务逐层确认连接失败位置，并在每次只改一个配置后复核。

先看 30 秒速查卡：症状对应哪一步

本站是第三方信息页，不是 Codex 官网，与 Codex 无已核实关系。先根据现象选择最小检查，不要同时修改多个配置。

当前 Codex CLI 的 doctor 诊断报告包含配置、认证、网络、长连接、可达性和本地状态等检查；源码还说明它会输出每项检查的状态、详情和修复建议。正常验收不是“命令能运行”，而是关键检查没有失败，并且最小任务能够完成。参考 Codex doctor 源码。

第一步：先确认状态、版本和 doctor 参数

先确认是否属于服务端或公共网络侧的临时异常，再处理本地配置。打开 OpenAI Status 服务状态页，查看相关服务是否存在公告或异常。状态页正常不能完全排除个体账号、模型或入口问题，但可以避免把公共故障误判成本机配置错误。

在 CLI 中依次运行：

codex --version
codex doctor --help
codex login status

当前公开源码显示，codex doctor 支持机器可读报告、摘要和展开详细检查等参数，但参数会随版本变化。只有当当前版本的帮助信息列出对应参数时，才运行：

codex doctor --all
codex doctor --json

如果帮助信息没有 --all，使用基础命令：

codex doctor

如果没有 --json，不要强行添加。doctor 报告中可以重点看四类结果：配置是否加载、认证是否正常、网络与长连接检查是否成功、当前供应商端点是否可达。出现 fail 时，先按该行的 remedy 或提示处理；只有 warning 不一定代表连接必然失败。

第二步：确认本地端口确实是 HTTP 类型

仅看到端口被占用，不能证明 Codex 能通过它访问目标服务。端口检查要分成两步：先确认有程序监听，再确认该端口能处理 HTTP 请求。不要把非 HTTP 类型端口直接填入 HTTP_PROXY 或 HTTPS_PROXY。

Windows PowerShell 查看监听端口：

Get-NetTCPConnection -State Listen | Sort-Object LocalPort

macOS 或 Linux 查看监听端口：

lsof -nP -iTCP -sTCP:LISTEN

知道端口号后，可用一个不含账号信息的 HTTPS 地址做最小请求测试。将“端口”替换为实际监听端口：

curl -I --max-time 10 -x http://127.0.0.1:端口 https://status.openai.com/

返回 HTTP 响应头，说明该端口至少能够接受这种 HTTP 请求；超时、连接被拒绝或协议错误，则不能据此确认端口可用。这个测试只验证本地端口到测试地址的基本路径，不等于 Codex 的认证、供应商和长连接全部正常。

如果客户端设置页面明确标注端口类型，优先以页面中的 HTTP 类型为准。不同软件的默认端口可能不同，本文不把某个常见端口号当成通用值。端口未监听时，先启动提供该端口的本地网络客户端；端口已监听但请求失败时，检查端口类型、监听地址和本机安全软件，再回到 codex doctor 复核。

第三步：按入口区分 .env、用户变量和终端变量

这是 Codex 连接排查中最容易误判的地方。当前公开源码明确了 CLI 启动流程：它会在 CODEX_HOME 对应目录读取 .env；如果未设置该变量，通常使用用户目录下的 .codex。源码还明确规定，加载 .env 时会排除名称以 CODEX_ 开头的变量，也就是说，这类变量不会从 .env 生效，并不是只读取 CODEX_ 变量。依据见 Codex CLI 启动源码。

CLI 可先在当前终端临时设置普通环境变量。不要把真实密钥、完整配置链接或个人账号信息写入公开脚本：

export HTTP_PROXY="http://127.0.0.1:端口"
export HTTPS_PROXY="http://127.0.0.1:端口"
export NO_PROXY="localhost,127.0.0.1,::1"

Windows PowerShell 可临时设置：

$env:HTTP_PROXY="http://127.0.0.1:端口"
$env:HTTPS_PROXY="http://127.0.0.1:端口"
$env:NO_PROXY="localhost,127.0.0.1,::1"

先用临时变量验证，确认有效后再考虑写入用户环境或 CLI 的 .env。修改后必须完全退出并重新打开对应入口。Windows 用户查看变量时，使用下面的写法不会因为某个变量不存在而把缺失误判成配置错误：

$env:HTTP_PROXY
$env:HTTPS_PROXY
$env:NO_PROXY

如果 CLI 正常而桌面版或 VS Code 插件仍然 Reconnecting，当前公开资料不足以证明它们会读取同一个 .env。应把问题视为入口环境差异，分别检查，而不是继续重复修改 CLI 文件。

第四步：登录失效时，先重新确认认证状态

如果 doctor 的认证检查失败，或 Codex 反复要求登录，先不要继续调整端口。运行：

codex login status

如果当前版本支持并且状态确实异常，可先查看命令帮助：

codex login --help
codex logout --help

需要重新建立登录状态时，再按当前版本支持的方式执行：

codex logout
codex login

完成浏览器登录或设备登录后，再次验证：

codex login status
codex doctor

登录命令和本地回调流程可在 Codex CLI 登录源码 中核对。若重新登录后仍反复跳转，记录登录命令的错误提示、Codex 版本和 doctor 中的认证结果；不要公开粘贴令牌、认证文件内容、完整配置链接或带账号标识的日志。

第五步：不要把 supports_websockets 当成通用修复开关

supports_websockets 是供应商能力配置字段，用来声明对应供应商是否支持某类长连接传输。它不是“出现 Reconnecting 就关闭”的通用修复项。只有在当前供应商配置与其能力不匹配，或 doctor 明确显示长连接检查失败时，才有必要进一步核对配置参考。

修改前先备份 config.toml，每次只改一个字段，并避免出现重复的同名键。官方配置说明见 Codex 配置参考。如果修改后问题扩大，恢复备份并重新运行基础诊断。

长连接检查成功时，部分公开诊断示例会显示类似“WebSocket connected”以及“HTTP 101 Switching Protocols”的结果；这只能说明握手成功，不能单独证明后续模型请求、登录状态或桌面版调用链都正常。反过来，长连接检查失败也不等于所有请求都失败，应同时看普通网络检查、供应商可达性和最小任务结果。

第六步：用最小任务和两种状态完成验收

配置调整后，先断开本地网络客户端，完成一次测试；再开启它，完成第二次测试。Codex 是否关闭不会决定本地端口是否监听，真正需要切换的是提供端口的本地网络客户端。两个状态都建议执行以下检查：

1. 运行 codex doctor，记录配置、认证、网络、长连接和供应商可达性结果。
2. 运行 codex login status，确认登录状态没有变化。
3. 使用无敏感内容的最小任务，例如要求返回固定短句。
4. 记录任务是否完成、是否再次出现 Reconnecting、完成耗时是否明显变化。
5. 在晚高峰与非高峰各测一次，比较时段差异。

可把结果按下面的标准判断：

如果需要日志，优先使用当前版本帮助中列出的非交互命令或日志设置。Codex 官方安装文档说明，非交互模式可直接输出信息，交互式界面不适合直接接入管道保存。分享诊断前应遮盖 API Key、登录凭据、配置链接、用户名、项目路径和请求内容。参考 Codex 安装与日志说明。

常见问题

写入 .env 后，CLI、桌面版和 VS Code 插件都会生效吗？

不能这样假定。当前源码已核实 CLI 启动流程会读取 CODEX_HOME 对应目录下的 .env；桌面版和 VS Code 插件是否读取同一文件、是否继承同一组用户变量，本次检索到的公开资料未核实。三个入口应分别重启、分别验证。

为什么 .env 中以 CODEX_ 开头的变量没有生效？

这是源码明确的过滤规则。加载 .env 时，名称以 CODEX_ 开头的变量不会从该文件生效，并不是只读取这类变量。网络环境变量应使用实际名称，例如 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY。

本地端口能监听，为什么 Codex 仍然 Reconnecting？

监听只说明本机有程序占用该端口，不能证明它是 HTTP 类型，也不能证明目标服务可达。用第二步的 curl 最小请求测试，再运行 codex doctor，最后用最小任务验证。

codex doctor --all 或 --json 报参数错误怎么办？

先运行 codex doctor --help。帮助信息没有 --all 时使用 codex doctor；没有 --json 时不要继续添加该参数。命令参数以当前安装版本为准。

CLI 能连接，桌面版却不能连接怎么办？

先不要继续修改 CLI 的 .env。两个入口可能由不同进程启动，用户变量和终端变量的继承范围也可能不同。当前公开资料没有核实桌面版必然读取 CLI 的同一个 .env，应从桌面版自身的设置、进程环境和诊断结果单独确认。

是否应该直接关闭 supports_websockets？

不建议作为通用修复。它是供应商能力配置字段。只有当供应商能力不匹配或诊断明确指向长连接握手问题时，才考虑核对该字段，并先备份 config.toml。

服务状态页正常，是否就能排除服务端问题？

不能完全排除。状态页反映整体服务状态，个体仍可能受到账号、模型、入口、网络路径或本地配置影响。状态页正常时，继续比较端口、认证、入口环境和最小任务结果。

日志或 doctor 报告可以直接发到公开论坛吗？

不建议直接公开。先删除 API Key、登录凭据、完整配置链接、用户名、项目路径、请求内容和其他账号标识；保留版本、系统、检查项状态和经过脱敏的错误摘要即可。

参考资料

• Codex CLI 启动源码：.env 加载与 CODEX_ 变量过滤
• Codex doctor 诊断源码：检查项、状态与 JSON 报告
• Codex CLI 登录源码
• Codex 配置参考
• Codex 安装与日志说明
• OpenAI Status 服务状态页

核对日期：2026年10月24日。本文仅依据上述公开源码、官方配置文档、官方安装说明和状态页整理；桌面版与 VS Code 插件是否读取 CLI 的同一份 .env，仍以当前公开资料未核实为准。

常见问题

写入 .env 后，CLI、桌面版和 VS Code 插件都会生效吗？

不能这样假定。CLI 读取 .env 已有源码依据；桌面版和 VS Code 插件是否读取同一文件，本次检索到的公开资料未核实，应分别重启和测试。

为什么 .env 中以 CODEX_ 开头的变量没有生效？

Codex 加载 .env 时会排除名称以 CODEX_ 开头的变量，这类变量不会从 .env 生效，并不是只读取 CODEX_ 变量。

本地端口能监听，为什么 Codex 仍然 Reconnecting？

监听只说明端口被占用，还要确认端口是 HTTP 类型，并用 curl、codex doctor 和最小任务分别验证本地请求、诊断和实际任务。

codex doctor --all 或 --json 报参数错误怎么办？

先运行 codex doctor --help。当前版本没有 --all 时使用 codex doctor，没有 --json 时不要强行使用该参数。

CLI 能连接，桌面版却不能连接怎么办？

两个入口可能由不同进程启动，环境继承范围不同。不要默认桌面版读取 CLI 的 .env，应分别检查入口环境、设置和诊断结果。

是否应该直接关闭 supports_websockets？

不建议作为通用修复。该字段用于声明供应商的长连接能力，只有诊断明确指向能力不匹配或握手失败时才考虑调整，并先备份配置。

服务状态页正常，是否就能排除服务端问题？

不能完全排除。状态页正常后，仍需继续检查账号、模型、入口环境、网络路径和最小任务结果。

相关阅读

• 网络稳定性测试方法
• 电脑网络优化步骤
• 网络优化设置说明

参考资料

1. Codex CLI 启动源码：.env 加载与 CODEX_ 变量过滤
2. Codex doctor 诊断源码：检查项、状态与 JSON 报告
3. Codex CLI 登录源码
4. Codex 配置参考
5. Codex 安装与日志说明
6. OpenAI Status 服务状态页