Codex 每次先 Reconnecting 5 次才回答？代理与 WebSocket 排查指南

为什么是 5 次？#

OpenAI 的 Codex 配置参考显示，provider 的 stream_max_retries 默认值是 5，supports_websockets 决定是否使用 Responses API WebSocket 传输。

GitHub Issue #14297 中的日志展示了完整过程：客户端使用 responses_websocket 重试 5 次，随后记录 falling back to HTTP，切换到 responses_http 后请求立即成功。

常见原因包括：

• Codex 进程没有继承代理变量；
• HTTP、mixed 和 SOCKS 端口填写错误；
• 代理节点或防火墙不支持 WebSocket Upgrade；
• 浏览器走了代理，但 Codex App 走了另一条网络路径。

先检查日志#

Codex CLI 日志通常位于 ~/.codex/log/codex-tui.log。

Windows PowerShell：

1
Select-String `
2
  -Path "$env:USERPROFILE\.codex\log\codex-tui.log" `
3
  -Pattern "responses_websocket|falling back to HTTP|retrying sampling request" |
4
  Select-Object -Last 30

macOS / Linux：

1
grep -E 'responses_websocket|falling back to HTTP|retrying sampling request' \
2
  ~/.codex/log/codex-tui.log | tail -n 30

如果日志包含下面的组合，基本可以确认问题方向：

1
transport="responses_websocket"
2
stream disconnected - retrying sampling request (1/5 ...)
3
falling back to HTTP
4
transport="responses_http"

公开日志前请先脱敏，不要上传 auth.json、令牌或完整会话文件。

方案一：显式配置代理#

如果希望保留 WebSocket 和默认 provider，优先让 Codex 明确使用本地代理。

在 Codex 用户目录创建 .env：

1
HTTP_PROXY=http://127.0.0.1:7890
2
HTTPS_PROXY=http://127.0.0.1:7890
3
NO_PROXY=localhost,127.0.0.1,::1

文件位置：

• Windows：%USERPROFILE%\.codex\.env
• macOS / Linux：~/.codex/.env

把 7890 改为代理软件实际提供的 HTTP 或 mixed 端口。不要直接照抄 Clash、v2rayN 教程里的常见端口。

HTTP_PROXY 和 HTTPS_PROXY 的值通常都写成 http://127.0.0.1:端口。只有确认监听端口提供 SOCKS5 时，才使用 socks5:// 或 socks5h://。

配置后彻底退出 Codex App、CLI 和 IDE 扩展，再重新启动。已经运行的进程不会自动获得新环境变量。

也可以先在终端临时测试：

1
# Windows PowerShell
2
$env:HTTP_PROXY = "http://127.0.0.1:7890"
3
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
4
codex

1
# macOS / Linux
2
export HTTP_PROXY=http://127.0.0.1:7890
3
export HTTPS_PROXY=http://127.0.0.1:7890
4
codex

如果这样启动后不再重连，说明代理继承就是问题所在。

方案二：直接使用 HTTP/SSE#

如果代理始终无法稳定转发 WebSocket，可以在用户级 config.toml 中添加 HTTP-only provider：

1
model_provider = "openai_http"
2

3
[model_providers.openai_http]
4
name = "OpenAI HTTP only"
5
wire_api = "responses"
6
requires_openai_auth = true
7
supports_websockets = false

配置文件位置：

• Windows：%USERPROFILE%\.codex\config.toml
• macOS / Linux：~/.codex/config.toml

保存并彻底重启 Codex。新会话将跳过 WebSocket，直接使用 HTTP/SSE。

修改前建议先备份：

1
# Windows
2
Copy-Item "$env:USERPROFILE\.codex\config.toml" `
3
  "$env:USERPROFILE\.codex\config.toml.bak"

1
# macOS / Linux
2
cp ~/.codex/config.toml ~/.codex/config.toml.bak

方案三：TUN 或按进程代理#

如果环境变量无法覆盖 Codex 的所有网络路径，可以临时开启代理软件的 TUN 模式。TUN 从虚拟网卡层接管流量，通常能让 HTTPS 和 WebSocket 走同一条链路。

但 TUN 可能影响国内应用、局域网、Docker、WSL、虚拟机和本地开发服务，建议只把它作为诊断或兜底方案。

如果代理软件支持按进程分流，可以只让 Codex.exe、codex.exe 或 IDE 进程走代理，影响范围会更小。

两个容易混淆的配置#

features.network_proxy 管理的是 沙盒内命令和子进程 的出站网络，不是 Codex 连接模型服务时的 WebSocket 开关。

shell_environment_policy 控制 Codex 把哪些环境变量传给它启动的工具命令，也不能保证 Codex App 自身使用其中的代理。

因此，不建议为了修复 Reconnecting... 5/5 而修改 .codex/.sandbox/setup_marker.json、proxy_ports 或其他内部状态文件。一次只改一项，测试后再决定下一步。

验证与回滚#

彻底重启 Codex，新建会话并发送：

1
只回复 OK

如果几秒内开始响应，且不再出现连续 5 次重连，说明修复生效。

• 方案一或方案三：日志应能正常完成 responses_websocket；
• 方案二：日志应直接使用 HTTP/SSE；
• 如果 HTTP 也失败，应撤销修改并检查其他网络或认证问题。

回滚 HTTP-only provider 时，删除 model_provider = "openai_http" 和对应的 [model_providers.openai_http] 配置块，或者恢复备份。删除 .env、关闭 TUN 或进程规则后，也需要彻底重启 Codex。

总结#

推荐按照下面的顺序处理：

1. 查看日志，确认 WebSocket 重试后回退 HTTP；
2. 显式配置 Codex 使用的代理；
3. 代理确实不支持 WebSocket 时，切换到 HTTP-only provider；
4. 环境变量覆盖不全时，再使用 TUN 或按进程代理。

关键不是“代理开没开”，而是 Codex 的 WebSocket 和 HTTP 请求是否走了同一条可用链路。

参考资料：

• openai/codex #14297
• openai/codex #19821
• OpenAI Codex 配置参考
• Codex HTTP/SSE 修复方案