在做多模型网关、或者用第三方/中转 API 时，我们常写个健康检查来判断接口能不能用。但如果你的健康检查只是「发个请求，看返回 200 就算通过」，那它其实很不可靠。这篇聊聊一个稍微严肃点的 API 健康检查该看哪些维度。

为什么「返回 200」不够

一条 API 返回 200 OK，只能说明网络通、鉴权过，但下面这些情况它照样返回 200：

• 返回体是空的，或者不是合法的对话结构；
• model 字段和你请求的模型对不上（被路由到了别的模型）；
• 多模态请求被降级处理，图根本没被识别；
• 中转层返回了一个缓存的、假的成功响应。

所以健康检查不能只看状态码，得看返回内容本身是否符合预期。

一个更靠谱的检查该看哪几层

1. 连通性 & 鉴权层

最基础的一层：能不能连上、Key 认不认。这一层要把错误分类清楚，而不是笼统报「失败」：

• 网络层：域名解析失败 / 连接被拒 / 超时 / SSL 证书错误；
• 鉴权层：401（Key 无效）、403（无权限）、429（限流或余额不足）。

分清楚是「网络问题」还是「Key 问题」，排查方向完全不同。

2. 结构层：返回体是不是合法对话结构

拿到 200 后，别急着信。校验返回体：

function isValidChatResponse(json, protocol) {
  if (!json) return false;
  if (protocol === "openai") {
    return Array.isArray(json.choices) && json.choices.length > 0;
  }
  // anthropic
  return Array.isArray(json.content) && json.content.some(c => c.type === "text");
}

结构不对，说明这个端点可能不是真正的对话接口（比如被套了一层壳）。

3. 一致性层：返回的 model 和你请求的一致吗

if (json.modelField && !json.modelField.includes(requestedModelFamily)) {
  // 请求 opus 却返回别的模型名，值得警惕
  warn("返回模型与请求不一致");
}

注意：model 字段也可能被伪造，所以它只是参考信号之一，不能单独作为结论。

4. 行为层：响应特征是否符合该模型

更进一步，可以看一些模型自己不太好伪造的特征：

• 响应 id 前缀、object/type 字段、stop_reason/finish_reason 的取值规律；
• 各家特有的响应头（限流头、版本头等）；
• 同一 prompt 下的 token 用量、停止行为、长度控制。

5. 能力层：声称支持的能力真的支持吗

比如声称多模态旗舰，那就传一张图让它描述，看是报错、胡说还是正确识别——这是判断是否被降级最直接的一层。

6. 性能层：延迟与稳定性

记录 latencyMs，多次采样看抖动。太慢或波动大的端点，即使功能正常也未必适合生产。

把检查组织成一个流水线

实际实现时，我把上面这些做成了一个多步检测流水线，每一步产出一个结果，最后汇总打分。示意：

连通/鉴权 → 结构校验 → 一致性 → 行为特征 → 能力(多模态) → 性能采样 → 汇总结论

单步失败不一定直接判死，而是记录下来交给汇总层加权，避免因为某一项抖动就误杀一条正常端点。

顺手做成了工具

这套「不止看 200」的检测逻辑，我做成了一个在线工具 Token检测：填接口地址 + API Key + 选模型，它会跑指纹 / 结构 / 行为 / 签名 / 多模态多项检测，判断 Key 是否有效、模型是否被降级替换、响应速度如何，支持 OpenAI、Claude、Gemini、DeepSeek、通义、Grok、MiniMax、Kimi。

如果你在给自己的网关写健康检查，可以参考上面的分层思路；懒得自己搭测试的话，也可以直接拿它验证端点。

你的 API 健康检查目前看了哪几层？欢迎评论区聊聊。