Claude 内部服务器错误怎么处理：网页、Code 和 API 分别排查
先保存未发出的内容并查实时状态。网页报错先区分容量、登录与连接问题；Claude Code 先核对自动重试和已完成的工具动作；API 或网关则保留错误类型及请求 ID，再决定是否重试。
文章目录
Claude 显示“内部服务器错误”时，先保存输入框里尚未发送的文字、附件信息和已有结果，再打开 Claude 实时状态页。有正在处理的事故，就按事故进展等待；没有公开事故，也要继续区分网页、Claude Code、直接 API 和第三方应用，不能据此认定是你的电脑出了问题。
接下来决定的是重试、续接，还是停止发送并联系支持。网页对话可以在短暂等待后做一次简单对照；Claude Code 已经自动重试过，还可能完成了文件修改或工具调用；API 和网关则需要先看实际错误类型。只要任务涉及部署、发消息、扣款或其他外部写入，先核对结果，再考虑重复请求。
先确认错误出现在哪里
“Internal Server Error”是报错文字，单凭它不能确定出错的服务。先选你正在使用的入口：
| 你看到的情况 | 先做什么 | 下一步依据 |
|---|---|---|
| Claude.ai 网页对话失败 | 保存未发出的内容，查 Claude Status，短暂等待 | 提示是否明确写了容量不足、用量上限或对话过长 |
| Claude.ai 登录时报错 | 查状态，再逐项排查 VPN、扩展和浏览器会话 | 是否只在登录阶段或某个浏览器出现 |
Claude Code 显示 API Error: 500 | 读完整错误及保留输出，确认实际服务方 | 自动重试是否结束、正文或工具调用是否已经完成 |
应用拿到 Anthropic API 的 500 api_error | 保存响应正文、响应头和请求 ID | 是否确为 Anthropic 直连、请求能否安全重复 |
| 第三方应用或网关显示 500 | 保存该应用的报错和时间，查服务商状态 | 网关自己的错误，还是上游返回后被转述的错误 |
| 只有连接失败，没有收到可用 HTTP 响应 | 检查网络、代理、防火墙和连接超时 | 是否根本没有收到 API 错误响应 |
Claude Code 的当前错误说明写明，500 后面的状态检查地址会随配置变化：可能是 Anthropic、Amazon Bedrock、Google Cloud 的 Agent Platform、Microsoft Foundry，也可能是 ANTHROPIC_BASE_URL 指向的自定义网关。先读这个地址，比看到 Claude 名字就只查 Anthropic 更有用。
如果你只是某个第三方应用的普通用户，没有网关日志，也无需自行抓取开发者级别的响应头。先把报错时间、应用名称、选用模型和截图交给该应用支持，让它确认实际调用了哪家服务。
网页报错：容量、额度、登录和连接要分开
Claude.ai 对话中的通用错误不一定会显示 HTTP 状态。没有响应正文，就不要把网页提示直接解释成 API 的 500 api_error。
状态正常，仍然可能暂时无法回答
官方错误消息帮助区分容量限制与服务事故。看到 Due to unexpected capacity constraints 一类提示时，Claude 正在处理高需求，官方建议过几分钟再试；这类容量限制不会作为事故出现在状态页上。因此，状态页全绿只能说明没有在那里公布的活动事故，不能排除你遇到的短时容量问题。
如果是普通对话的通用报错，可以先保留原对话，等一小会儿，再发送一次简单请求或用新对话作对照。新对话成功而旧对话失败，说明旧会话或其中的输入值得继续检查，不能仅凭这一次对照宣布找到了根因。不要先删除有用的历史。
明确显示额度或长度限制，就按提示处理
5-hour limit reached 属于用量限制，应看提示中的恢复时间和你的账户用量设置；重复发送同一条消息不会让用量窗口提前恢复。Your message will exceed the length limit for this chat 属于输入长度问题，可以减少附件、拆分内容或开始新对话。这些处理方向来自同一份官方帮助，不能用“服务器错误，稍后再试”替代。
清缓存只适合有依据的浏览器排查
如果错误发生在登录阶段，官方帮助建议检查 VPN、浏览器扩展、缓存与 Cookie。实际排查时可以先用无痕窗口作一次对照，再逐项改变设置；清除浏览器数据或退出登录前，先保存尚未发送的内容。
如果是连接错误，官方中文连接帮助指出，应检查网络、防火墙和 VPN。连接失败与已经返回的 HTTP 500 是两种不同信号：前者先查能否连接，后者先查返回错误的服务。清理 Claude.ai Cookie 不能替代 Claude Code、API 或网关的服务端排查。
Claude Code：先读自动重试结果，再决定重发还是继续
看到最终错误之前，Claude Code 可能已经做过自动恢复。官方自动重试说明写的是临时失败最多自动重试 10 次，并采用指数退避；这是重试次数，不是“总共发送 10 次”的通用公式。不同中断阶段还有各自的处理条件，不能给所有失败套同一个次数。
对内部服务器错误，最关键的是下面三种情况：
| 失败发生时，响应进展到哪里 | 当前 Claude Code 的处理 | 你应该先检查什么 |
|---|---|---|
| 尚未开始流出响应 | 服务端错误、过载等可进入自动退避重试 | 是否仍显示重试倒计时，是否已经出现最终错误 |
| 已完成 thinking，但尚未开始任何正文或工具调用 | 自 v2.1.284 起，这个阶段的服务端错误可自动重试最多 2 次；过载也属于可重试情形 | 版本及终端最终提示，不能因出现思考内容就认定工具执行过 |
| 已完成正文或工具调用块，或完成 thinking 后已开始正文或工具调用，但整轮尚未完成 | 不重放原请求；保留已完成内容，执行已经完成的工具调用，并从工具结果继续 | 文件、进程与外部系统实际状态，以及屏幕上保留的完整内容 |
这张表概括的是当前官方流式恢复规则。连接断开、流停止到达与服务端 500 的具体重试预算不同；应按实际提示检查，不能只凭“出现了一点文字”判断是否重试。
显示“响应可能不完整”时，保护已有工作
如果看到 The response above may be incomplete，先读屏幕上保留的内容。Claude Code 会保留已完成的块，但在结束这一轮时丢弃被中断的最后一个块，所以最后几句文字或未完成的工具调用可能缺失。报错不代表文件修改已经撤销，也不代表外部操作没发生。
先确认三件事：
- 文件和命令结果是否已经存在，是否仍有测试、构建或其他进程在运行。
- 部署、消息、工单或数据库写入是否已经在目标系统完成，能否用任务 ID、记录或幂等标识核对。
- 哪个完整步骤是最后一次确认完成的，接下来还缺什么。
核对后，在交互式会话回复 continue，让 Claude 从最后一个完整块继续；必要时明确告诉它哪些动作已经完成、哪些结果仍待确认。官方不完整响应说明也区分非交互模式：自 v2.1.246 起，主对话中只有文字、没有工具调用的中断响应可自动续写最多 3 次。这不是重新执行整项任务的授权，也不是所有运行方式都会自动完成的保证。
需要进一步盘点文件、进程和部署结果时，可看Claude Code 宕机后的会话续接与副作用核对。
没有已完成工作时，再做有限的同路重试
对于最终 API Error: 500，官方处理建议是查看错误中指定的服务状态，等待约一分钟再发送消息；原消息仍在对话中，可以回复 try again，不用重新粘贴长提示词。
实际操作前，仍要确认自动重试已结束、没有待核对的工具动作，而且任务可以安全重复。这里建议只做一次手动对照：保持模型、服务地址和主要输入不变，仍然失败就停止连续发送，保存错误并联系支持。这个“一次”是便于保留证据的排查建议，不是所有客户端统一的官方重试上限。
如果提示变成 Repeated 529 Overloaded errors，Claude Code 已经执行过适用的自动重试，应先等几分钟、看当前服务方的容量状态；任务允许且账户有其他可用模型时，也可以按官方建议用 /model 切换。不能把 529 当成个人额度耗尽，更不能保证换模型一定成功。
直接 API：500、529、429 和 504 的动作不同
已经拿到 Anthropic API 响应的开发者，可以按官方 API 错误定义分支处理：
| 状态与类型 | 含义 | 下一步 |
|---|---|---|
500 api_error | Anthropic 系统内部发生未预期错误 | 保存请求 ID，检查状态，对可安全重复的请求做有上限的指数退避 |
529 overloaded_error | API 暂时过载 | 退避等待，降低自己控制的并发，避免集中重发 |
429 rate_limit_error | 可能是速率限制，也可能是用量等级的月度支出上限或 Claude Code 工作区支出限制 | 读错误正文与响应头；限流按等待提示处理，支出上限需要恢复访问条件 |
504 timeout_error | 请求处理超时 | 查看持续时间和已收到的流式内容；长请求考虑流式接口，重试前核对已执行动作 |
尤其不要把所有 429 都写成“过几秒再试”。官方说明，用量等级的月度支出上限导致的 429 没有 retry-after，在访问恢复前会继续失败。它与短时限流的恢复条件不同。
官方 SDK 默认对连接错误、限流和 5xx 等临时失败自动重试两次，支持用 max_retries 调整，并在有 retry-after 时遵循它。应用、队列、网关还可能各自重试；应看各层实际日志，设置总次数或总耗时上限，不能把 SDK 的两次与 Claude Code 的十次简单相加。另外，SSE 流可能在 HTTP 200 之后报错，200 本身不证明整轮生成成功。以上条件均见API 错误参考。
直接 API 的错误正文包含 error.type、error.message 和 request_id；响应头中的 request-id 通常是同一标识。Python 和 TypeScript SDK 的顶层响应对象也提供 _request_id。保存实际取得的字段，别因为应用没有展示某个 ID 就反推服务从未收到请求。
可以使用下面的脱敏记录模板；它是排查字段示例，不是真实失败日志：
发生时间与时区：<准确时间>
使用入口：<直接 API / Claude Code / 网关>
服务方与模型：<实际服务方、准确模型 ID>
HTTP 状态与错误类型：<实际取得的值>
错误消息：<已脱敏的完整文字>
请求 ID：<request-id / request_id / 网关 ID>
客户端及版本：<SDK 或应用版本>
自动与手动重试：<实际观察的次数和时间>
已完成工作：<结果已确认 / 未确认 / 没有>生产环境的退避、业务去重、熔断和日志实现，可继续看Claude API 500 的恢复与生产控制。
经过网关时，先让服务商确认出错的那一跳
第三方网关的 500 可能是它自身失败、透传的上游错误，也可能是超时被重新映射后的状态。Claude Status 正常不会证明网关的地区、项目和路由正常；网关显示 500 也不能单独证明 Anthropic 发生了事故。
能查看日志时，成对保存两侧证据：应用收到的状态、错误文字和网关请求 ID；网关实际选择的上游、上游状态、请求 ID 和重试记录。若需要用直连作对照，先确认已完成工作能够安全重复，再尽量固定实际模型、输入、超时和运行环境。模型别名指向不同模型、网关改了重试或超时，都会影响对照结果。
“换服务商以后成功”可以帮你恢复部分工作，但不足以定位根因。先保存原始失败，再把替代服务是否满足当前任务作为单独选择。
再次失败，带这些材料找正确的支持方
有活动事故就按官方更新等待；没有公开事故，同一请求在有限重试后仍失败，就停止随机换配置。准备报错时间与时区、使用入口、完整错误、实际服务方、模型与客户端版本、重试记录、已完成工作、可用请求 ID 和最小脱敏复现。
- Claude.ai 普通用户：向 Claude 支持提供截图、时间和对话现象，没有 API 请求 ID 也可以说明问题。
- Claude Code：按当前官方说明使用
/feedback；环境不支持时，使用错误文档中的报错渠道，并附实际服务方和中断阶段。 - Anthropic 直连 API：向 Anthropic 提供请求 ID 和错误响应。
- Bedrock、Google Cloud、Foundry 或第三方网关：先找能追踪对应请求的云厂商或服务商，保留其自己的标识。
API key、私密提示词、客户资料和未脱敏的环境变量不要放进工单。若使用 Claude Platform on AWS，官方请求 ID 说明另外区分 x-amzn-requestid 与 Anthropic 的 request-id：前者用于 CloudTrail 查询，后者用于 Anthropic 支持。这个规则属于 Claude Platform on AWS，不能直接当作 Amazon Bedrock 的统一日志规则。
常见问题
Claude 现在是不是宕机了？
查看实时状态页的活动事故和受影响组件。过去某次状态正常不能回答“现在”；状态正常也不能排除容量限制或第三方网关问题。
内部服务器错误是不是 API key 或余额有问题？
直接 Anthropic API 的 500 api_error 表示内部未预期错误；认证、账单和权限分别有 401、402、403 等信号。支出上限还可能返回 400 或特定的 429。按实际状态和错误正文处理，不要仅凭 500 换 key 或充值。
看到一点输出后还能重试吗？
先判断完成了什么。当前 Claude Code 中，仅完成 thinking、尚未开始正文或工具调用的服务端错误有自动重试分支；已经完成正文或工具调用块，或 thinking 后已开始正文或工具调用时，则保留完成内容并继续处理。按官方自动重试条件核对版本和提示，不要把所有部分输出视为同一种情况。
错误消失了，是否可以直接重做整个任务？
先核对已有结果。文件、部署或消息可能已经完成，最后一个响应块也可能丢失；恢复连接不等于之前的工作被撤销。确认最后完成的步骤后再续接，能避免重复执行。
清缓存能解决 Claude Code 的 500 吗？
浏览器缓存排查主要适用于 Claude.ai 登录或网页会话问题。Claude Code 的 500 应按错误中指定的服务方、自动重试与响应阶段处理；清除 Claude.ai Cookie 不能替代这些检查。
