一次刚好落在国内深夜的短故障。真正值得说的不是宕机本身，而是它顺手暴露了一个老问题：报错弹出来的那一刻，你其实分不清是官方挂了，还是自己这条线路出了事。
如果你昨晚睡得早，这事大概率完全没影响到你——故障窗口整段压在国内的后半夜。但海外时区正是工作日下午，社交平台上抱怨"跑到一半被打断"的人不少。事故页面把这次记为 Elevated errors across all models，影响范围写的是全部模型，而不是某一条产品线。
按官方事故页的更新节奏，换算成北京时间大致是这样：
最常见的报错形态是 529 Overloaded——服务端过载类的返回码。至于过载是由什么触发的，事故页从头到尾没写，外媒的报道也只提到官方未披露根因，所以这一段目前只能存疑，不适合替官方下结论。
纯粹是时差。Anthropic 的事故记录用 UTC，19:49 UTC 对应的就是北京时间次日 03:49。海外白天出的故障，落到国内往往是凌晨——这也是很多人"第二天才知道昨晚挂过"的原因。
顺带说一句，时区这件事在 Claude 生态里不只是看新闻方便与否的问题。客户端和网页端会读取你本机的时区、语言等环境信息，这些值和出口 IP 的实际地理位置对不上时，本身就是一类需要留意的信号。这块可以看 Claude 时区自查 那篇，讲得比较细。
官方过载、线路被墙、出口 IP 被风控、DNS 解析跑偏——这几种情况落到用户屏幕上，表现常常高度相似：转圈、断流、报个数字错误码、或者干脆一句语焉不详的提示。对国内和走代理的用户来说，这就意味着每次出问题都要先花时间做一道判断题：到底该等，还是该换线路。
判断顺序其实不复杂，先排除自己这一侧，剩下的才交给时间：
如果上面四步都干净，那大概率就是官方侧的事了——这种时候唯一正确的动作是等，反复重连、频繁切节点反而容易在恢复期给自己招来额外的风险标记。
这次故障的持续时间不算长，但覆盖了 API，也就意味着挂在 Claude 上的自动化任务、CI 流程、定时脚本都可能在那个窗口里静默失败。凌晨跑批的话，值得回头翻一眼日志，确认没有任务是"失败了但没人发现"。
命令行侧的重试、超时、代理相关配置如果没调好，遇到服务端过载会放大成一连串莫名其妙的中断，Claude Code 稳定使用指南 里那几项配置建议一次性对完，比每次出事再临时改省心。