如果 Claude Code 提示 API Error: 500，先不要把它理解成一种统一的“再试一次就好”。这类报错最容易浪费时间的地方，就在于很多人把所有 500 都当成 Anthropic 暂时抽风，然后不断重复同一条失败路径。更稳的做法是先看 Claude Status，再判断你现在面对的是实时事故、登录或 OAuth 失败、旧的 resumed session 已经坏掉，还是 Claude Code 实际走了你没意识到的鉴权路径。
这四条分支的第一步并不一样。状态页发红时，最正确的动作通常是停手等待，而不是继续改本地设置。状态页是绿的，也不代表你接下来该做的事情还是盲目重试。真正有价值的下一步，往往是重新登录、开一个新会话，或者检查 Claude Code 当前到底在用哪条鉴权路径发请求。
你还需要保留对原始症状的敏感度。Internal server error 可能出现在登录过程中，而不只是执行任务的中途；同样，状态页已经恢复为绿色时，某个旧会话也仍然可能继续报 500。这就是为什么这篇文章只做一件事: 帮你把 API Error: 500 分流清楚，而不是顺手把使用量、限流、安装和计费问题都塞进来。
先按下面的路由表选分支。做完一条分支的最小修复后，用同一路径再验一次。如果在绿色状态页下，同一条路径仍然报错，就把 request_id、/status 和 /debug 的证据留下，再升级处理。
Start Here: Which 500 Branch Are You In?
症状看起来很窄，但第一步并不窄。Anthropic 的 API 文档把 HTTP 500 定义为 api_error，表示发生了意外的内部错误；而 HTTP 529 是单独的 overloaded_error 分支。这个定义能帮你建立底线，但它还不足以告诉你下一步该等、该重登、该开新会话，还是该先确认 Claude Code 真正使用的请求路径。
| 你现在看到什么 | 最可能归谁管 | 最安全的第一步 | 如何在同一路径验证 | 什么时候该升级 |
|---|---|---|---|---|
| Claude Status 正在报红，或刚有新事故 | Anthropic 侧事故、认证故障或平台波动 | 停止改本地设置，先等状态恢复 | 事故结束后，重试之前那条同样失败的路径 | 状态恢复为绿后，同一路径仍然报 500 |
登录或 OAuth 过程中出现 Internal server error | OAuth 过期、登录链路异常、机器时间偏差或本地凭证状态损坏 | 先跑 /status，再 /login，必要时跑 claude doctor | 确认同一条登录路径已经恢复 | 绿色状态下，登录路径仍然报错 |
| 状态页是绿的，但旧的 resumed session 一直失败 | 会话状态损坏、旧上下文污染或恢复后的残留问题 | 直接开一个新会话，不要继续猛敲旧会话 | 用新会话重跑同一个任务 | 新会话也以同样方式失败 |
| Claude Code 可能实际走了 API key、代理或别的 provider 路由 | ANTHROPIC_API_KEY 覆盖、路径选错、代理或鉴权 owner 不一致 | 先看 /status、环境变量和当前路由配置 | 在已知正常的路径上对比同一个请求 | 同一路由在新凭证下仍然失败 |
这张分流表不是装饰。很多社区答案会把所有 API Error: 500 压缩成“Anthropic 挂了”或者“过会儿再试”。这对真正急着恢复服务的读者帮助不大。实时事故是一条真分支，但它不是唯一分支。
If Claude Status Shows an Incident Right Now
先看状态页，是因为它能帮你省掉大量无效的本地排查。Claude Status 在 2026-04-10 检查时是绿色，但状态历史里能看到 2026-04-08 到 2026-04-09 之间确实发生过和 authentication、Claude Code、Claude.ai 以及 elevated error rates 相关的事故。这个事实很重要，因为它证明 API Error: 500 确实可能来自平台侧事故，而不只是你本机的配置问题。
这条分支的操作原则很简单。如果相关组件正在报红，就先别继续折腾本地环境。你在实时事故期间重装、切换路由、反复改配置，得到的通常不是更快恢复，而是更多噪音。等事故恢复后，再回到之前那条同样失败的路径做一次验证。只有同路径复验，才能说明事故是不是唯一原因。
这里也要把 500 和 529 分开记。500 是 Anthropic 文档里的泛内部错误桶，529 表示系统过载。对用户来说，它们都可能表现成“服务看起来不太行”，但如果你稍后需要升级支持，保留精确错误码会更有用。
这条分支不该扩张成整篇文章的唯一答案。如果状态页持续为绿，正确下一步就不是继续等待，而是回到故障分流。真正好的 500 排障页，应该知道何时等待，也知道何时立刻进入下一条分支。
If the Error Appears During Login or OAuth
登录分支很容易被误判。用户看到的还是 Internal server error，于是默认它和会话中途的运行失败是一回事。但 Claude Code 当前的故障排查文档给出的路线更窄: 先用 /status 看当前鉴权方法，再用 /login 刷新登录状态，如果反复提示登录或行为异常，再用 claude doctor 检查本地环境、机器时间或 keychain 状态。
这条官方路线有价值，是因为登录失败和执行中失败根本不是同一个修复任务。如果错误发生在登录时，你真正要问的是: 登录路径坏了，是因为 OAuth 降级、token 过期、机器时间不对，还是本地保存的凭证状态已经损坏？这篇文章应该直接回答这个问题，而不是把它淹没在泛泛的 Claude Code 背景介绍里。
安全顺序可以保持很短。先跑 /status，确认当前究竟在用哪种鉴权；接着重新跑 /login；如果仍然不对，就用 claude doctor 做机器级检查。这个顺序的好处在于，它尽量不让你在 OAuth、机器时间和本地凭证状态之间瞎猜。
这里的验证边界也必须收紧: 验证同一条登录路径。不要在别的网页或别的工具里能登录，就当成 Claude Code 也已经恢复。绿色状态下，如果 Claude Code 自己的登录路径在重新登录后仍然失败，这就已经不是“再登一遍看看”的级别，而是值得带着干净证据升级的问题了。
If Status Is Green but the Resumed Session Still Fails
状态页是绿的，并不代表你眼前这个旧会话还是健康的。这正是很多泛泛建议会漏掉的分支。当前 anthropics/claude-code 的 issue 里已经有人把 API Error: 500 和 resumed session 绑定起来: 上下文已经掉到零附近，旧会话继续失败，而开一个新 chat 会改善结果。它不能证明所有 500 都来自旧会话，但它足够说明，遇到这种症状时，第一步不该是继续猛试原来的 session。
这里最好的控制实验，是放下对旧会话上下文的执念，直接开一个新会话，然后用最少必要上下文重跑同一个任务。如果新会话正常，你已经学到一个关键事实: 出问题的可能是旧会话状态，而不是平台整体。如果新会话仍然以同样方式报错，你也能更快排除“会话坏了”这条支线，转向别的分支。
很多人恰恰是在这里耗掉最多时间。状态页既然是绿的，他们就默认等待已经没意义，于是继续在旧 session 里做一模一样的重试，因为旧 session “知道上下文”。这个直觉能理解，但经常是错的。上下文本身就可能是故障源。对 500 来说，新会话比第十次重复点击更有诊断价值。
如果你最后发现，自己的真实问题其实不是 500 恢复，而是使用量异常、共享消耗、计费路径混淆，那么这页就不该继续承担那份任务。那时更合适的下一页是我们的 Claude Code 使用量诊断指南。
If You May Be on an API Key, Provider, or Proxy Route
不少 Claude Code 用户默认以为，工具一定走自己的订阅 OAuth 路线。但 Anthropic 的排障文档明确写着: 如果环境里存在 ANTHROPIC_API_KEY，Claude Code 会优先使用这个 key，而不是你的订阅 OAuth。光这一条，就足以解释很多“我明明已经登录了，为什么还是报 500”的混乱现场。
这就是为什么 /status 应该出现在恢复流程前半段。它能告诉你当前活跃的鉴权方法是什么。如果它和你以为自己在测试的路径不一致，那么后面所有判断都会失真。官方状态页是绿的，并不能自动解释 API key 路线、代理路线或其他 provider 的实际行为。
这条分支最安全的动作不是立刻去换另一个 provider，而是先确认当前活跃路径，清掉错误或陈旧的凭证，再把同一个请求拿到一个已知正常的路径上做对照。如果移除意外出现的 ANTHROPIC_API_KEY，或切回原本预期的 auth owner 之后，500 消失了，那真正的问题就是路径不一致。如果同一路由在新凭证下仍然失败，你才真正拥有一个可以升级的清晰案例。
这部分也要避免越界。若最终暴露出来的是本地安装不完整、先决条件缺失或首次配置错误，那么更合适的后续页是我们的 Claude Code 安装指南。分流的目的，是把页内任务收紧，而不是让一页替所有 Claude Code 问题兜底。
Verify the Fix and Know When to Escalate
Anthropic 的 API 文档说明，错误响应会带 request_id，而普通 API 响应也会带 request-id header。拿到这些信息时，不要丢。Claude Code 当前的命令文档也给你 /status、/debug 和 /cost 这些诊断面。你不需要准备一份巨大的报告，但你确实需要一组足够让支持判断你已经排过哪条分支的证据。
在升级之前，先从同一条失败路径收集这些最小材料:
- 精确错误字符串，以及任何
request_id或request-id - 报错发生时
/status显示的是红还是绿 - 问题发生在登录阶段、单个旧 session，还是某条特定的鉴权路径
/debug输出，或你能稳定重现的最小步骤
这些材料会直接改变沟通质量。“Claude Code 给我 500”是个很弱的描述；“绿色状态下，同一条登录路径在 /login 后仍然失败，并附上 request_id”就很有用；“绿色状态下，新会话正常，旧 resumed session 仍然报 500”也很有用。目标不是写一段情绪化投诉，而是减少歧义。
升级边界应该写得很明确: 如果在绿色状态下，同一路径经过最小的分支修复后仍然失败，就停下随机试错，带着证据升级。到这一步，再多来几次随手重试，帮助通常已经不如一次干净交接。
如果最后确认根因其实是用量耗尽、显式 rate limit 或成本路径问题，而不是 500 恢复问题，就转到我们的 Claude Code token 使用与限流指南。那一页讲的是额度、共享消耗和成本解释；这一页讲的是先把 500 修对。
Frequently Asked Questions
Claude Code 的 API Error: 500 和 529 overloaded_error 是一回事吗？
不是。Anthropic 的 API 文档把 500 定义为 api_error，把 529 定义为 overloaded_error。两者都可能让用户感觉“平台现在不稳定”，但它们是不同的官方分支。
为什么 Claude Status 是绿的，我还是会看到 500？
因为绿色状态页只能排除“当前实时事故”这条分支。你仍然可能落在登录路径问题、旧会话损坏，或者意外鉴权路径这几条分支上。
我是不是应该先重装 Claude Code？
通常不应该。对这个症状来说，重装几乎不是优先动作。先看状态、先分支、先做同路径验证，比重装更容易保留有效信号。
如果旧会话一直失败，最好的第一个测试是什么？
直接开一个新会话，用最少必要上下文重跑同一个任务。这是判断问题是不是卡在旧会话状态上的最快方法。
升级支持时最该带什么？
带上精确错误文本、任何 request_id、当时 /status 的结果、你测试的是哪条分支、以及最小复现步骤。清楚的分支证据，比一大段泛泛描述更有帮助。
The Working Rule
Claude Code 的 API Error: 500 更适合被当成“分支恢复问题”，而不是“统一重试提示”。先看状态，先选分支，做一个小修复，用同一路径复验；如果在绿色状态下同一路径仍然失败，就带证据升级。