Codex中端口配置错误排查与解决的实战指南

目录

• 导语
• 环境信息
• 现象
• 排查过程
• 第一步：理解 Codex 的架构
• 第二步：检查端口是否存活
• 第三步：验证正确端口
• 第四步：确认错误来源
• 根因
• 修复
• 速查命令
• 总结

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 (http://127.0.0.1:15721/v1/responses)

关键信息：

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

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

先搞清楚 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 = "http://127.0.0.1:15721/v1"

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

# 直接测试 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，那就直接试：

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"}'

返回：

{
  "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 的自动备份：

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 = "http://127.0.0.1:15721/v1"

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

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

用途	命令
查看配置	cat ~/.codex/config.toml
检查实际端口	netstat -ano | findstr LISTENING | findstr 127.0.0.1
测试代理连通性	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

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

到此这篇关于Codex中端口配置错误排查与解决的实战指南的文章就介绍到这了,更多相关Codex端口配置错误内容请搜索风君子博客以前的文章或继续浏览下面的相关文章，希望大家以后多多支持风君子博客！