使用 VPN 时 OpenAI Codex 报错「stream disconnected before completion」怎么办？

如果你在连接 VPN 的情况下使用 OpenAI Codex（命令行工具），可能会遇到类似下面的报错， 导致任务中断、代码审查跑不完：

■ stream disconnected before completion: error sending request for url
(https://chatgpt.com/backend-api/codex/responses)

或者在重试若干次后失败：

Reconnecting... 1/5 (stream disconnected before completion ...)
Reconnecting... 2/5 ...
...
Falling back from WebSockets to HTTPS transport.

这篇文章解释原因，并给出在 Windows 和 macOS 上的完整解决方法。

一句话结论

如果你使用 ZibVPN 1.4.0 或更新版本，请优先在客户端中将协议锁定为 VLESS。这样连接期间不会再由自动协议切换打断 Codex 的长连接；根据我们的测试，锁定 VLESS 后可解决 这类 stream disconnected before completion 中断。

优先解决方法：在 ZibVPN 中锁定 VLESS 协议

Codex 的 WebSocket 或 HTTP/SSE 响应可能持续数分钟。ZibVPN 处于「自动」模式时，会根据延迟和 近期连接质量在 Reality、ShadowTLS、Hysteria2、AnyTLS 之间选择路径；正常网页访问通常感觉不到 切换，但正在运行的 Codex 流式连接可能因此需要重新建立。

如果你正在使用 ZibVPN 1.4.0 或更新版本，请按下面操作：

1. 打开 ZibVPN 客户端，确认版本为 1.4.0 或更新版本；
2. 进入客户端的协议选择 / 协议偏好设置；
3. 将「自动」改为 VLESS（实际连接为 VLESS+Reality）；
4. 重新连接 ZibVPN，再重新运行 Codex 任务。

为什么会断开？

OpenAI Codex 新版默认使用 WebSocket 作为传输通道。WebSocket 是一种「长连接」—— 需要长时间保持不断开。而这种长连接在经过任何代理/VPN 时，都容易因为以下原因被中断：

• 中间网络设备对长时间连接的空闲回收；
• WebSocket 握手在代理环境下超时；
• 基于 UDP/QUIC 的传输协议在长连接场景下更易被运营商网络掐断。

这是 Codex 客户端层面的传输兼容性问题，社区已有大量相同反馈。好在有成熟的解决办法。

兼容方案：让 Codex 改走 HTTP/SSE

如果你暂时无法升级 ZibVPN，或者锁定 VLESS 后仍受其它网络因素影响，可以继续采用下面的 Codex 兼容方案：禁用 WebSocket、强制使用更稳定的 HTTP/SSE 传输。 只需修改 Codex 的配置文件 config.toml。

第 1 步：找到 / 创建配置文件

Windows：

C:\Users\你的用户名\.codex\config.toml

macOS：

~/.codex/config.toml

如何快速打开（可选）

Windows（PowerShell）：

notepad "$env:USERPROFILE\.codex\config.toml"

macOS（终端）：

mkdir -p ~/.codex && open -e ~/.codex/config.toml

第 2 步：写入以下配置

把下面内容写入 config.toml。如果文件里已经有内容，切勿整段直接追加到末尾——model_provider = "openai_http" 这一行必须放到文件最顶端（所有 [...] 段之前）， 下方的 [model_providers.openai_http] 配置块才可以和其它段落并列摆放：

model_provider = "openai_http"   # ← 必须是第一行，放在所有 [ ] 段之前

[model_providers.openai_http]
name = "OpenAI HTTP only"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false
# ↓ 容忍长时间无数据的推理阶段，断开后多重试几次
stream_idle_timeout_ms = 600000
stream_max_retries = 10
request_max_retries = 8

supports_websockets = false 会让 Codex 跳过最容易断开的 WebSocket 通道、改用更稳定的 HTTP/SSE；最后三行则放宽「长时间无数据」的断线判定、增加断开后的重试次数。 模型深度思考时经常几十秒不返回任何数据，而默认的 5 分钟 idle 超时在代理环境下容易被误判为断线—— 调大后能明显减少中断。（这几项只对自定义 provider 生效，我们这里用的正是自定义的openai_http，所以会真正起作用。）

❌ 错误顺序（写在段落后面 → 每次启动被删、失效）：

[model_providers.openai_http]
name = "OpenAI HTTP only"
supports_websockets = false
model_provider = "openai_http"   # ← 放这里无效，会被删掉

✅ 正确顺序：model_provider = "openai_http" 就是文件第一行， 所有 [...] 段落都排在它之后（即上方完整示例的写法）。改完后可在 Codex 里用/status 确认 Model provider 显示为 openai_http。

第 3 步：保存并重启 Codex

保存文件后，完全关闭并重新启动 Codex（命令行用户请退出当前会话、重新运行codex），让新配置生效。

验证是否解决

1. 重新运行一个 Codex 任务（例如代码审查或较长的对话）。
2. 观察是否还会出现 stream disconnected 或 Reconnecting... x/5。

绝大多数情况下，禁用 WebSocket 后即可恢复稳定。如果仍偶发断开，可尝试切换到 VPN 的 其他节点后再试。

常见疑问