导语
Codex（原ChatGPT桌面版）至今仍是不少开发者的主力AI工具。但当你把它接入自定义模型提供商，比如DeepSeek时，偶尔总会踩到一些意想不到的坑。不久前切换手机热点后，突然发现Codex彻底用不了了——整个排查过程从一行报错开始，一层层往下挖，最后居然只改了一行配置文件。这事值得记录下来。
环境信息
- Windows 11
- Codex 26.616.6631.0
- 自定义模型提供商：DeepSeek（deepseek-v4-flash）
- 网络：笔记本连接手机热点
现象
好，打开Codex，随便发个对话试试——立刻就报错了：
stream disconnected before completion:
error sending request for url (https://127.0.0.1:15721/v1/responses)
关键信息在于：目标地址是127.0.0.1:15721，而报错是"stream disconnected"——注意，不是"connection refused"。
这意味着：不是连不上，而是连上了之后断掉了。问题出在连接成功后。
排查过程
第一步：理解Codex的架构
来，先把这个东西搞清楚，Codex的自定义模型是怎么工作的：
Codex 前端 (Electron) → config.toml 中的 base_url → 本地代&理 (codex-plus-plus.exe，Rust 编写) → 外部模型 API (DeepSeek)
配置文件在 ~/.codex/config.toml，问题很可能就在这块：
[model_providers.custom] name = "custom" wire_api = "responses" requires_openai_auth = true base_url = "https://127.0.0.1:15721/v1"
配置里写的是15721端口。接下来最关键的一步——确认这个端口到底对不对。
第二步：检查端口是否存活
# 直接测试 15721 curl https://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，直接拿它们测试看看：
curl -X POST https://127.0.0.1:57321/v1/responses
-H "Content-Type: application/json"
-H "Authorization: Bearer test"
-d '{"model":"test","input":"hello"}'
返回：
{
"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 https://...看到超时，别慌，换成POST试试。
第四步：确认错误来源
翻了一下Codex的自动备份目录：
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：
# 修改前 base_url = "https://127.0.0.1:15721/v1" # 修改后 base_url = "https://127.0.0.1:57321/v1"
改完无需重启Codex，对话立刻恢复正常。就是这么简单。
速查命令
| 用途 | 命令 |
|---|---|
| 查看配置 | cat ~/.codex/config.toml |
| 检查实际端口 | netstat -ano | findstr LISTENING | findstr 127.0.0.1 |
| 测试代&理连通性 | curl -X POST https://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自定义模型的端口号目前确实不稳定，希望官方后续版本能提供固定端口或者自动修正机制
