Codex Reconnecting 5 次后失败怎么解决？

1. 先看日志：你遇到的是哪一种重连

公众号文章把 Reconnecting 归纳为“没有正确走代理”和“请求到达后被服务器拒绝”两类。结合 Codex 的公开日志后，还可以再加一个判断：5 次重试以后有没有出现 falling back to HTTP。

2. 让 Codex 显式读取本地代理

桌面应用不一定会自动沿用浏览器的代理设置。公众号提供的实操方案是创建 ~/.codex/.env；Windows 对应 %USERPROFILE%\.codex\.env。端口必须换成你代理软件显示的 HTTP 或 mixed 端口，不能照抄示例端口。

HTTP_PROXY="http://127.0.0.1:PORT"
HTTPS_PROXY="http://127.0.0.1:PORT"
ALL_PROXY="socks5h://127.0.0.1:PORT"
NO_PROXY="localhost,127.0.0.1,::1"

1. 先在代理软件设置中确认 HTTP、mixed、SOCKS5 各自的监听端口。
2. 保留已有的其他环境变量，只新增或更新代理项。
3. 保存后完全退出 Codex，包括托盘和后台进程；已有进程不会自动继承新环境。
4. 重启后发送一个只读请求，观察是否还会重复 WebSocket 握手。

Windows 用户还可以把用户级环境变量与 WinHTTP 设置同步。它解决的是不同网络栈读取配置不一致的问题，不会改变 Codex 的模型或计费设置：

[Environment]::SetEnvironmentVariable("HTTP_PROXY", "<LOCAL_PROXY_URL>", "User")
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "<LOCAL_PROXY_URL>", "User")
[Environment]::SetEnvironmentVariable("ALL_PROXY", "<LOCAL_PROXY_URL>", "User")
[Environment]::SetEnvironmentVariable("NO_PROXY", "localhost,127.0.0.1,::1", "User")
netsh winhttp import proxy source=ie
netsh winhttp show proxy

3. TUN 还是强制 HTTP：按网络条件选择

路线 A：保留 WebSocket，使用 TUN 或系统级隧道

如果你的代理工具能在 TUN 模式下接管系统流量，WebSocket 通常可以直接建立，交互延迟也更低。先用 TUN 验证，而不是同时修改多处 Codex 配置；这样出问题时容易回滚。

路线 B：关闭 Responses WebSocket，直接走 HTTP

如果当前网络只能稳定访问 HTTPS，可以让 Codex 跳过失败的 WSS 尝试。当前版本 schema 中提供了 feature 开关；升级 Codex 后先运行 codex features list 核对当前版本是否仍提供该项：

[features]
responses_websockets = false

如果你的版本不识别这个 feature，也可以给自定义 provider 明确声明不支持 WebSocket：

model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
supports_websockets = false

4. Windows 配置代理后沙盒无法写文件

Windows 上可能出现“找不到指定的模块”、文件写入失败或自动审批超时。这与 WebSocket 本身不是同一个问题：代理变量被继承进 elevated sandbox 后，沙盒初始化的代理端口记录可能发生冲突。

1. 彻底退出 Codex，在任务管理器确认相关进程结束。
2. 在已有的 [features] 节下加入 network_proxy = true，不要重复创建节。
3. 在配置末尾加入下面的环境变量排除规则：

[features]
network_proxy = true

[shell_environment_policy]
inherit = "all"
exclude = ["HTTP_PROXY", "HTTPS_PROXY", "ALL_PROXY", "http_proxy", "https_proxy", "all_proxy"]

然后打开 %USERPROFILE%\.codex\.sandbox\setup_marker.json，只把已有的代理端口列表改为空数组：

"proxy_ports": []

保存后普通方式启动 Codex，先测试新建文件和读取文件。features.network_proxy是给沙盒命令使用的网络代理，不等于模型请求代理；模型请求仍由 .env、系统代理或 TUN 决定。若仍然失败，sandbox = "unelevated"只能作为临时诊断回退，因为它会降低隔离强度。

5. 代理正常后，再排查认证与中转兼容

公众号还提到 MFA 或旧登录会话导致服务端拒绝连接。这个线索适合放在代理之后：如果日志已经出现 401/403，或者完全退出并重新登录后问题消失，再把它归因到认证状态；没有状态码时，不要把 MFA 当成默认答案。

• 账号登录：在账号安全设置中确认 MFA/二次验证状态，完全退出 Codex 后重新登录。
• API Key：确认密钥没有过期、没有多余空格，且密钥分组允许当前 Codex 模型。
• Base URL：使用 https://www.codex789.com/v1，并确认提供方支持 /v1/responses。
• 模型代号：从 API 密钥页面复制准确代号，不要根据模型卡片标题手写。
• 中转兼容：普通 Chat Completions 能用，不代表 Responses API、流式事件和 WebSocket 都已兼容；必要时先用 HTTP 方案验证。

如果返回 429，优先查看额度、并发和上游限流；如果是 500/502/503/504，记录时间、模型和请求协议，再联系服务支持，不要反复删除本地登录状态。

6. 一次修改只验证一个变量

1. 保存 config.toml、.env 和 sandbox marker 的回滚副本。
2. 记录 Codex 版本、操作系统、代理协议和实际端口。
3. 先测试短文本只读请求，再测试文件读取，最后测试文件写入。
4. 观察日志：WebSocket 成功应不再连续等待；强制 HTTP 时应直接进入 Responses HTTP。
5. 恢复代理或配置后重复同一测试，确认修复不是偶然网络波动。

7. 常见问题