Codex 一直报 stream disconnected？别急着换模型，这份配置把 401、404 和断流一起查清楚

刘先生864

361人浏览 · 2026-08-10 21:22:54

刘先生864 · 2026-08-10 21:22:54 发布

最近用 Codex CLI 写项目时，我碰到过一个很折磨人的问题：

明明同一个模型在网页里可以正常回答，放进 Codex 后却不是 401 Unauthorized，就是 404 Not Found；好不容易开始生成了，又突然出现 stream disconnected。

很多人的第一反应是：

是不是模型不行？换一个更贵的模型会不会好一点？

实际排查下来，我发现这类问题大多数与“模型聪不聪明”没有直接关系，真正容易出错的是 API 协议、Base URL、模型 ID、Key 读取方式和流式连接。

这篇不讨论模型排行榜，直接从一份能看懂、能排错的配置开始。

本文使用 Genvis 的 OpenAI 兼容接口作为示例。你已有其他兼容服务也可以照着检查，重点不是平台名称，而是每个字段必须对应得上。

一、先判断：你遇到的到底是哪种错误

别一看到红字就反复重装 Codex。不同状态码指向的问题完全不同。

报错表现	最常见原因	优先检查
`401 Unauthorized`	Key 没有读取到、Key 无效	环境变量、Key 状态
`404 Not Found`	Base URL 拼错、接口不支持 Responses	`/v1`、`/responses`
`model not found`	模型 ID 不存在或没有权限	控制台实际模型名
`429 Too Many Requests`	余额、额度或频率限制	账户余额、并发量
`stream disconnected`	SSE 流被中断、代理超时、上游波动	网络、网关、超时配置
一直转圈无输出	请求已发出但迟迟收不到流式数据	接口协议、线路和日志

这张表很重要，因为它能阻止你做一件最浪费时间的事：明明是接口问题，却不停换模型。

二、Codex 配第三方 API，关键不是只改 base_url

不少教程只给出一行：

openai_base_url = "你的接口地址"

这种写法虽然简单，但当你需要同时管理模型名、独立 Key、重试策略时，很快就会混乱。

更清晰的方式是为接口单独定义一个 Provider。

打开用户级配置文件：

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

写入下面的配置：

model = "gpt-5.6-sol"
model_provider = "genvis"

[model_providers.genvis]
base_url = "https://genvis.xyz/v1"
env_key = "GENVIS_API_KEY"
wire_api = "responses"

这里的 genvis 只是自定义 Provider ID，可以自己命名，但不要使用 openai、ollama、lmstudio 这些保留名称。

模型名也不能凭感觉填写。上面的 gpt-5.6-sol 是本文示例，实际使用时应以平台控制台显示的模型 ID 为准。

每个字段分别做什么

model：准备调用的模型 ID。
model_provider：告诉 Codex 使用下面哪一组接口配置。
base_url：API 基础地址，通常应包含 /v1。
env_key：保存 API Key 的环境变量名称，不是 Key 本身。
wire_api：Codex 与 Provider 通信使用的协议，目前填写 responses。

最容易忽略的是最后一项。

有些中转接口只兼容 /chat/completions，普通聊天程序可以使用，但 Codex 走的是 Responses 协议。这种情况下，不管换多少个模型，依然可能报 404 或无法正常执行工具。

三、不要把 API Key 直接写进配置文件

推荐把 Key 放进环境变量。

macOS / Linux

临时设置：

export GENVIS_API_KEY="你的API Key"

如果希望每次打开终端都生效，可以把这行写进自己的 Shell 配置文件，然后重新打开终端。

Windows PowerShell

当前窗口临时生效：

$env:GENVIS_API_KEY="你的API Key"

写完后先检查变量是否存在。为了安全，不要截图或公开完整 Key。

macOS / Linux：

test -n "$GENVIS_API_KEY" && echo "Key 已加载" || echo "Key 未加载"

Windows PowerShell：

if ($env:GENVIS_API_KEY) { "Key 已加载" } else { "Key 未加载" }

如果这里显示“Key 未加载”，Codex 报 401 就一点也不奇怪。

四、先别启动 Codex，直接测试 Responses 接口

排错时最忌讳把所有问题混在一起。

先绕过 Codex，用一个最小请求验证接口是否真的支持 Responses：

curl https://genvis.xyz/v1/responses \
  -H "Authorization: Bearer $GENVIS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "input": "只回复 OK"
  }'

你需要关注的不是回答有多聪明，而是接口返回什么：

返回正常 JSON：说明地址、Key、模型和 Responses 接口基本可用。
返回 401：优先检查 Key，而不是模型。
返回 404：检查 /v1/responses 是否存在，以及网关是否真正兼容 Responses。
返回 model_not_found：模型名不对，去控制台复制准确 ID。
返回 429：检查余额、限额或请求频率。

只有这一步通过后，再启动 Codex。这样可以把“接口问题”和“Codex 配置问题”彻底分开。

Windows PowerShell 的 curl 行为可能与 macOS、Linux 不同。如果命令解析失败，可以使用 curl.exe，或用 Postman 发出同样的请求。

五、Responses 测试通过，Codex 仍然断流怎么办

如果最小请求已经成功，但 Codex 执行长任务时仍出现 stream disconnected，问题通常集中在流式连接。

Coding Agent 与普通问答不同。一次任务可能持续数分钟，中间还要读取文件、调用终端、等待测试结果。只要反向代理、网络线路或上游服务提前断开 SSE 连接，Codex 就可能收到断流错误。

可以在 Provider 中补充重试和空闲超时配置：

[model_providers.genvis]
base_url = "https://genvis.xyz/v1"
env_key = "GENVIS_API_KEY"
wire_api = "responses"
request_max_retries = 6
stream_max_retries = 8
stream_idle_timeout_ms = 600000

这三个参数分别控制：