认证层倒了、模型层没红——这条边界决定了你该等公告还是该查自己的网络
这次故障赶在了一个很难被国内用户第一时间发现的时段。清晨 5:58（对应 8 月 16 日 21:58 UTC）Anthropic 状态页开始报警，最初的描述是"部分用户无法完成身份验证"，随后范围扩大，Claude.ai、Claude Code、Claude Cowork 三项都被标成了大规模故障。据外媒报道，恢复公告出现在 22:40 UTC，也就是北京时间 6 点 40 分左右，整段窗口大约 42 分钟。
比时长更值得看的是这次挂掉的东西的边界。
把受影响清单和未受影响清单摆在一起，分层就很清楚了：挂的三项——网页版、Claude Code、Cowork——全都是需要登录态的终端产品；没挂的两项——Claude API 和 Claude Console——是走 API Key 的通道。状态页最初那句"无法完成身份验证"基本已经指向了原因所在的那一层：不是模型推理能力出问题，是把用户识别成"你"的那套东西出问题了。
这也解释了故障现象为什么会那么杂。用户报上来的有登录直接失败的、有登录进去了但界面转圈的、有对话发出去没有回复的。这几种表现看着像三个不同的 bug，其实更像同一个认证/会话环节在不同入口上的不同摔法：有人卡在拿票的窗口，有人手里的票在半路失效。
值得一提的是，Anthropic 这套服务的分层并不像上面列表那么干净。API 端正常并不等于订阅用户手里那份 Claude Code 一定能跑——因为付费订阅走的是登录态，不是 API Key。同一个工具，用 Key 的人当时可能毫无感觉，用账号登录的人则完全动不了，这在故障当下最容易让两拨人互相不信。
如果只看"Claude 又挂了"这个标题，很容易把它和最近几次混为一谈，但故障的性质其实差得挺远。7 月 30 日凌晨那次持续 101 分钟的事故，报错是打在模型调用上的，全模型范围内请求失败；这一次模型端在状态页上从头到尾都没红，倒在了门口。
对使用者来说，两类故障的处置方式完全不同。模型层故障没有任何绕法，只能等；认证层故障往往会有"换个入口就能用"的余地——手里有 API Key 的人当时把工具切到 Key 上就能继续干活，而只有订阅账号的人只能等公告。这也是为什么把重要工作流完全绑死在单一登录通道上，风险比想象中大：挂的不一定是算力，可能只是发门票的那台机器。
这次事故有个不太好的巧合：认证层故障的外在表现，和网络环境不干净时的表现几乎一模一样。登录跳回登录页、请求卡住不返回、偶尔一个说不清的错误码，这些症状在国内用代理访问 Claude 的人身上本来就时不时出现，多数时候确实是出口 IP、时区、DNS 这类自己那边的问题。
于是清晨这 42 分钟里，大概有不少人第一反应是去折腾节点：换出口、清 cookie、重装客户端、翻配置文件。等到全都试完，服务自己好了，还以为是哪一步操作救回来的——下次同样的症状再出现，就会照着这套无效经验再折腾一遍。这种误判的成本不在那 42 分钟，而在于它污染了你对自己网络状况的判断。
官方至今没有披露这次故障的成因，按 Anthropic 过去的习惯，短窗口事故大多不会有后续的详细复盘。对用户来说能留下的东西也就是这条边界：Claude 这套产品里，最先塌的未必是最难的那一层。