Claude Code Request timed out 超时报错:API_TIMEOUT_MS 与代理排查
Wokey Team · 2026-09-24
结论先说: Request timed out 表示 Claude Code 在截止时间内没收到 API 的响应,默认截止时间是 10 分钟(API_TIMEOUT_MS=600000)。接中转站时,最常见的原因往往不是模型太慢,而是中间某一层把流式响应攒着不发,或者把长时间没有数据的连接掐断了。这一层可能是本地代理、公司网络或网关。先用 curl 确认流式输出是一段一段到达的,再决定要不要调大超时。
你看到的是哪一种
| 提示 | 含义 |
|---|---|
转圈时显示 Waiting for API response · will retry in … · check your network |
20 秒没收到任何数据,Claude Code 还在等,没有报错 |
Retrying in Ns · attempt x/y |
正在自动重试,默认最多 10 次 |
Request timed out |
超过 API_TIMEOUT_MS 仍没有响应 |
API Error: No response from API (waited …, then … on the retry) |
两轮都没等到响应的第一个字节 |
| HTTP 504,响应体是 Wokey 的 JSON | Wokey 等上游超时 |
| HTTP 408 | 请求体上传太慢,网关没等到完整的请求 |
前四种是 Claude Code 自己的提示,后两种来自服务端。
Wokey 返回的超时错误
Wokey 的超时错误都是 504,用统一的错误格式,看 code 就能知道卡在哪一步:
code |
含义 |
|---|---|
upstream_gateway_timeout |
上游自己的网关超时,没产生任何输出 |
official_exit_first_byte_timeout |
上游一直没开始回复,包括换通道重试的时间都用完了 |
provider_timeout |
请求上游时连接中断或超时,没拿到结果 |
例如:
{"error":{"code":"upstream_gateway_timeout","message":"Upstream gateway timed out before producing a response.","type":"invalid_request_error"}}
如果超时发生在回复已经开始输出之后,错误会以流内的 error 事件出现,而不是 HTTP 504。
Wokey 在长时间没有输出时(比如模型在长时间思考),会定期往流里写一行 SSE 注释来保持连接:
: wokey-transport-keepalive-v1
客户端会忽略这种注释行。用 curl 测试时看到它,说明连接是活的,模型还在处理。
排查步骤
1. 用 curl 看流式输出是不是逐段到达。
curl -N https://api.wokey.ai/v1/messages \
-H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":300,"stream":true,"messages":[{"role":"user","content":"从 1 数到 60"}]}'
-N 关掉 curl 自己的缓冲。event: 和 data: 一行行滚出来,说明整条链路正常。如果等了很久后一次性全部出现,说明中间有东西在缓冲响应,Claude Code 在这种链路上就容易超时。
2. 检查本地代理。 Claude Code 会使用 HTTPS_PROXY 和系统代理设置。TUN 模式、规则代理或公司网关都可能缓冲流式响应,或者掐断空闲连接。如果你的网络能直连 api.wokey.ai,让这个域名不走代理再试一次;如果必须走代理,换一个节点对比。
3. 调大超时。 确认链路没问题、只是请求确实很长时,在 ~/.claude/settings.json 的 env 里调大:
{
"env": {
"API_TIMEOUT_MS": "1200000"
}
}
API_TIMEOUT_MS是单次请求的超时,单位毫秒,默认 600000(10 分钟)。- 如果网络上的代理会把响应攒到结束才转发,Claude Code 的报错会建议同时调大
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS。 - 流中途停住的检测由
CLAUDE_STREAM_IDLE_TIMEOUT_MS控制,低于 5 分钟的值会被提到 5 分钟,最高 30 分钟。
4. 缩小上下文。 上下文越大,上传越慢,首个 token 也越晚。运行 /compact 压缩会话,或者开一个新会话。
5. 遇到 408。 408 是请求体在上传过程中长时间没有数据,网关不再等待。它几乎只出现在超长上下文加上不稳定的网络上。直接重试通常就能成功;频繁出现时,先按第 2 步查代理,再用 /compact 缩小请求。
Codex 的超时
Codex 的流式空闲超时默认 300000 毫秒(5 分钟)。触发时会看到 idle timeout waiting for SSE 或 stream disconnected before completion,自动重试时显示 Reconnecting... n/max。这些参数都写在 provider 表里:
[model_providers.wokey]
name = "Wokey"
base_url = "https://api.wokey.ai"
env_key = "WOKEY_API_KEY"
wire_api = "responses"
stream_idle_timeout_ms = 600000
stream_max_retries = 10
stream_max_retries 默认 5,request_max_retries 默认 4,上限都是 100。完整配置见 Codex config.toml 指南。
常见问题
Claude Code 默认超时是多久?
单次请求默认 10 分钟,由 API_TIMEOUT_MS 控制,默认值 600000。可以在 ~/.claude/settings.json 的 env 里调大,比如 "API_TIMEOUT_MS": "1200000"。
怎么判断是网络还是模型的问题?
用 curl -N 发一个 "stream":true 的请求。data: 行逐条出现说明链路正常;等很久后一次性全部出现,说明中间有代理在缓冲响应,这种链路容易超时。
Wokey 返回 504 是什么意思?
Wokey 的超时都是 504,code 说明卡在哪一步:upstream_gateway_timeout 是上游网关超时,official_exit_first_byte_timeout 是上游一直没开始回复,provider_timeout 是和上游的连接中断或超时。
流里出现 wokey-transport-keepalive-v1 是什么?
这是 Wokey 在长时间没有输出时写入的 SSE 注释行,用来保持连接不被中间设备掐断。客户端会忽略它,看到它说明连接正常、模型还在处理。
Codex 的超时怎么调?
在 config.toml 的 provider 表里设置 stream_idle_timeout_ms(默认 300000)和 stream_max_retries(默认 5)。