你在 Claude Code 里发出一个提示，转圈等了三分钟，最后出现：API Error: No response from API (waited 3m, then 10m on the retry)。这表示 API 在首字节截止时间内连响应头都没有返回，Claude Code 中止后重试了一次，重试同样没有得到响应。
本文说明消息中每个数字的含义、应按什么顺序处理，以及哪些环境变量会改变行为。所有内容均已于 2026 年 10 月 11 日对照 Claude Code 官方文档核对。
"No response from API (waited 3m, then 10m on the retry)" 是什么意思？
意思是 Claude Code 发出了流式请求，而 API 在首字节截止时间之前没有返回响应头。Claude Code 不会等满 API_TIMEOUT_MS 的 10 分钟，而是中止请求并最多重发一次。如果重试同样没有响应，这一轮就以如下完整消息结束：
API Error: No response from API (waited 3m, then 10m on the retry). If a proxy or gateway on your network holds responses until they complete, raise API_TIMEOUT_MS or CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS to wait longer.消息里的两个时长就是两次等待：第一次尝试（3m）和重试（10m）。在这一轮结束之前，你可能会看到几秒钟的提示 No response from the API after 3m · retrying once, waiting up to 10m，表示重试已经开始。
Claude Code 在中止前会等多久？
在 Anthropic 直连 API 上，第一次尝试等待 180 秒，请求体每 32KB 再加 1 秒。重试比 API_TIMEOUT_MS 少等 1 秒，也就是默认接近 10 分钟。
| 项目 | 默认值 | 如何修改 |
|---|---|---|
| 第一次尝试，Anthropic 直连 API | 180 秒 + 每 32KB 请求加 1 秒 | CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS（限制在 10 秒到 30 分钟之间） |
| 第一次尝试，其他提供商 | 300 秒 + 每 32KB 加 1 秒 | 同一个变量 |
| 重试 | API_TIMEOUT_MS 减 1 秒（约 10 分钟） | API_TIMEOUT_MS |
通过 ANTHROPIC_BASE_URL 经过网关 | 首字节截止时间不生效 | 不适用 |
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS 需要 Claude Code v2.1.242 或更新版本，带有两个时长的消息从 v2.1.261 开始出现。在 v2.1.242 之前，Claude Code 会等满 10 分钟才报错。
出现这个错误时该怎么做？
重新发送消息。你的原始消息仍然保留在对话中，所以提示很长时只需输入 try again，不必重新粘贴。如果错误反复出现，就按网络或代理问题处理。
- 输入
try again，看响应是否到达。 - 如果反复出现，在 Claude Code 之外测试到 API 的连接（例如
curl -I https://api.anthropic.com），以区分网络问题和 Claude Code 的问题。 - 如果你的网络里有代理或网关会把响应扣住直到生成完成，就调大重试的等待时间：
export API_TIMEOUT_MS=900000 - 如果第一次尝试总是超时而重试能成功，就调整首字节截止时间：
export CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=300000
在 PowerShell 中的写法是 $env:CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS = "300000"。请在打开 Claude Code 之前设置这些变量。
切换网络或 Wi-Fi 之后出现这个错误？
正好有一个公开的报告描述了这种情况。在 issue #99524 中（2026 年 10 月 4 日提交，Claude Code 2.1.293，Linux），作者描述：把机器切换到另一个网络后，下一个提示大约 3 分钟没有响应，而重试在 3 秒内就成功。在同一网络上新启动的 Claude Code 则立刻就有响应。
同一份报告提到，设置 CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=30000 后，等待时间从 180 秒降到 30 秒，随后重试成功：这个变量只是缩短等待，并不能避免。该 issue 仍未关闭，旧连接被挂起的假设来自作者本人，而不是 Anthropic。
另一位用户评论说，他在稳定的网络上也遇到相同症状，没有切换 Wi-Fi，也没有 VPN 或代理，环境是 Linux 集群节点和 2.1.289，并用 CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS=60000 配合 claude --debug 来排查。所以切换网络并不是唯一可能的原因。
应该调大还是调小 CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS？
这取决于具体情况，官方文档和用户报告的方向是相反的。
| 情况 | 调整 | 来源 |
|---|---|---|
| 第一次尝试超时而重试成功，响应确实很慢 | 调大 CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS | 官方文档 |
| 代理或网关把响应扣住直到完成 | 调大 API_TIMEOUT_MS | 官方文档 |
| 切换网络后连接已失效 | 调小该变量（例如 30000）以少浪费时间，或者新开一个会话 | issue #99524 中的报告，非官方 |
注意限制：该值会被限制在 10 秒到 30 分钟之间。设得太低，可能会让 Claude Code 中止一个只是开头较慢的响应。
如何查看底层发生了什么？
用 claude --debug 打开 Claude Code。日志会显示请求何时发出、首字节截止时间何时到期，由此可以区分“网络没有送达”和“API 响应慢”。
如果拖慢你工作的是套餐额度而不是网络，Verboo Code 提供无限 token。
