Codex-端口配置错误排查案例（stream disconnected before completion）

一次 Codex "stream disconnected" 报错的完整排查过程

导语

Codex（原 ChatGPT 桌面版）是很多开发者的主力 AI 工具。但当你用自定义模型提供商（如 DeepSeek）时，偶尔会踩到一些坑。本文记录了一次「切换手机热点后 Codex 无法使用」的问题排查全过程------从报错信息出发，逐层定位，最终一行配置改动修复。

环境信息

Windows 11
Codex 26.616.6631.0
自定义模型提供商：DeepSeek（deepseek-v4-flash）
网络：笔记本连接手机热点

现象

打开 Codex 发起对话后，立刻报错：

bash 复制代码

stream disconnected before completion:
error sending request for url (http://127.0.0.1:15721/v1/responses)

关键信息：

目标地址是 127.0.0.1:15721
报错是 "stream disconnected"（流中断），不是 "connection refused"（拒绝连接）

这说明不是连不上，而是连上之后断了。

排查过程

第一步：理解 Codex 的架构

先搞清楚 Codex 自定义模型是怎么工作的：

scss 复制代码

Codex 前端 (Electron)
  → config.toml 中的 base_url
  → 本地代理 (codex-plus-plus.exe，Rust 编写)
  → 外部模型 API (DeepSeek)

配置文件在 ~/.codex/config.toml，问题就出在这里：

toml 复制代码

[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "http://127.0.0.1:15721/v1"

配置里写的是 15721 端口。接下来看这个端口对不对。

第二步：检查端口是否存活

bash 复制代码

# 直接测试 15721
curl http://127.0.0.1:15721/v1/responses
# → curl: (7) Failed to connect to 127.0.0.1 port 15721

# 查看 Codex 相关进程实际监听的端口
netstat -ano | grep LISTENING | grep 127.0.0.1

输出：

端口	进程
57319	codex-plus-plus-manager.exe
57320	codex-plus-plus.exe
57321	codex-plus-plus.exe

15721 根本不在列表里。配置写的端口和实际监听的端口不一致。

第三步：验证正确端口

既然 codex-plus-plus 实际监听的是 57320 和 57321，那就直接试：

bash 复制代码

curl -X POST http://127.0.0.1:57321/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer test" \
  -d '{"model":"test","input":"hello"}'

json 复制代码

{
  "error": {
    "message": "...supported API model names are deepseek-v4-pro or deepseek-v4-flash...",
    "type": "upstream_error",
    "code": "400"
  }
}

🔑 这就是答案 。返回的是上游 API 的报错（模型名不对），而不是连接错误。说明 57321 上的代理服务一切正常，请求已经穿透到了 DeepSeek。

💡 小技巧：57320/57321 这两个端口接受 TCP 连接但不响应裸 HTTP GET 请求 ，需要 POST 正确的 JSON 才会返回。所以一开始用 curl http://... 看到超时也别慌，试试 POST。

第四步：确认错误来源

翻了下 Codex 的自动备份：

bash 复制代码

ls ~/.codex/backups/
# → codex-plus-live-1781875699298/
# → codex-plus-live-1781876648784/

# 第二份备份的配置
cat ~/.codex/backups/codex-plus-live-1781876648784/config.toml

发现早期备份里端口是正确的 57321，后来被改成了 15721。问题锁定了。

根因

维度	分析
直接原因	`config.toml` 中 `base_url` 端口写错（15721 → 应为 57321）
为何发生	手动修改模型配置时误填了端口号
为何切换热点后才暴露	热点触发网络变化 → Codex 后端可能重启 → 重新写入配置时带入了错误值
为何没第一时间发现	Codex 内部通过 stdio 通信（App ↔ 后端），端口错误只影响模型 API 调用路径

修复

编辑 ~/.codex/config.toml：

toml 复制代码

# 修改前
base_url = "http://127.0.0.1:15721/v1"

# 修改后
base_url = "http://127.0.0.1:57321/v1"

修改后无需重启 Codex，对话立刻恢复正常。

速查命令

用途	命令
查看配置	`cat ~/.codex/config.toml`
检查实际端口	`netstat -ano
测试代理连通性	`curl -X POST http://127.0.0.1:xxxx/v1/responses -H "Content-Type: application/json" -d '{"model":"test","input":"hi"}'`
查看历史备份	`ls ~/.codex/backups/`
强制重启 Codex	`taskkill /f /im Codex.exe & taskkill /f /im codex-plus-plus.exe`

总结

遇到 127.0.0.1 报错先别怪网络，本地代理端口可能对不上
netstat 配 curl 快速定位，比对配置和实际监听端口
善用 Codex 的自动备份 ，~/.codex/backups/ 经常能救命
Codex 自定义模型的端口号目前不稳定，建议官方在后续版本中提供固定端口或自动修正机制

如果这篇文章帮你解决过类似问题，欢迎点赞收藏～ 👏