API 中转站检测怎么做？协议、性能、故障、账单逐项验收

检测 API 中转站，不要凭一次返回 200 的请求下结论。先固定测试条件，再依次核对协议、性能、故障和账单，并保留每次请求的原始记录。

先给结论：四层都通过才算检测完成

一次连通只证明当时、该请求能到达某个端点。完整验收必须分别回答：请求和响应是否兼容、交互性能是否符合本业务、错误语义是否可定位、用量能否与账单对齐。任何一层缺少原始记录，都只能标记为“未验证”。

层	输入	证据	通过条件
协议	固定 JSON 与参数	状态、响应头、正文/SSE 事件	字段可解析且结束语义明确
性能	同模型、地区、时段与超时	逐请求 TTFT、总耗时、完成标记	仅与预先写明的业务阈值比较
故障	无效 key、模型、限流场景	错误类型、Retry-After、request ID	错误可区分且不会无限重试
账单	usage 与计价规则	请求记录、用量明细、结算记录	差异可解释并能按请求追溯

可复制的最小协议命令

在隔离测试环境设置占位变量，先保存头和正文；不要把真实密钥写入脚本或日志。

export RELAY_BASE_URL="https://relay.example/v1"
export TEST_KEY="replace-with-lab-key"
export MODEL_ID="replace-with-model-id"
curl -sS -D response-headers.txt -o response.json   "$RELAY_BASE_URL/chat/completions"   -H "Authorization: Bearer $TEST_KEY"   -H "Content-Type: application/json"   --data "{\"model\":\"$MODEL_ID\",\"messages\":[{\"role\":\"user\",\"content\":\"Reply with exactly: ok\"}],\"temperature\":0,\"max_tokens\":8}"
python3 -m json.tool response.json

再用同一请求体启用流式模式，记录 Content-Type、首个有效事件、结束事件与中断位置。OpenAI 将流式响应描述为事件流；Anthropic 也提醒 SSE 在 HTTP 200 后仍可能出现中途错误，因此 200 不是“完整成功”的充分条件。

性能层：指标与记录口径

性能层看四个数：成功率、TTFT、P95 和流式中断率。四个指标的定义和分母见测评篇的指标定义表。P95 用哪种分位算法、失败是否计入，要在报告里写明。检测阶段只跑小批次，结果只和预先写好的业务阈值比较。

每行至少记录时间、地区、网络出口、SDK/客户端版本、模型、请求体版本、流式开关、超时、重试、状态、TTFT、总耗时、完成标记、脱敏 request ID 与 usage。不同模型、输入长度或时段不能直接混算。

具体校验清单

1. 先写测试目标、不可比较条件和停止规则。
2. 固定模型、提示词、参数、客户端、出口、并发、超时与重试开关。
3. 普通响应检查状态、JSON、model、finish reason、usage 和请求 ID。
4. 流式响应检查事件顺序、首个有效内容、正常结束和未知事件兼容。
5. 把 401、429、5xx、超时和流中断分开统计。
6. 按 request ID、模型和时间窗口对齐用量与账单，再重复同一批次。

故障定位路径：客户端 → 网关 → 上游 → 结算

客户端层先核对最终 URL、请求 JSON、超时与 SDK 自动追加路径；网关层核对鉴权、配额、路由和网关 request ID；上游层依据上游请求 ID、错误类型和流状态判断；结算层再核对 usage 来源、重试尝试和账单。具体状态语义可查API 中转站错误码。

RFC 9110 将 4xx 定义为客户端错误、5xx 定义为服务器未能完成表面有效请求；这只是分类入口，不能代替逐层证据。兼容中转未必保留 OpenAI 或 Anthropic 的厂商特定响应头，应分别记录“存在、缺失、被改名”，不要据此虚构保证。

常见错误与误读

• 把 HTTP 200 当成流式完整成功，忽略中途错误或缺失结束事件。
• 只看平均延迟，不给 P95 的样本数、失败口径和时段。
• 开启 SDK 自动重试却把每次上游尝试当成一个用户请求。
• 拿不同模型、输入、地区或输出上限的数字横向排名。
• 只看余额变化，不按请求和计价项目复算。

费用口径可继续核对倍率与账单复算。本文不提供服务排行、固定阈值或供应商保证；占位端点和空白表格用于生成你自己的证据，不代表任何实际测量。

验收报告与复核节奏

报告首页先写测试对象、目的、负责人、方法版本和日期，不写脱离条件的“好/坏”。环境栏逐项填写客户端及版本、操作系统、地区、网络出口、DNS/代理、Base URL、端点族、声明模型、请求体版本、流式开关、连接超时、总超时、并发、请求间隔与 SDK 重试设置。任何未固定字段都标记为限制，不从后续表格中删除。

原始记录一行只记一次实际尝试。建议字段为 started_at、user_request_id、attempt_id、端点、model、status、error_class、TTFT、total_ms、stream_started、stream_completed、finish_reason、input/output usage、脱敏 vendor request ID。其中 usage 和 request ID 用于账单复算。聚合表的分母口径同测评记录模板：计划请求、实际发送、完整成功、部分流、取消、429、5xx 和超时。重试不能改变分母。

复核分三轮：执行者先确认命令与 CSV 行数；第二人抽取至少一条成功、失败、流式和账单记录回到原始文件；最后才写结论。若模型、路由、SDK 或计价规则变化，应创建新方法版本和新批次，不能覆盖旧数据。报告的“证据不足”与“失败”是两个不同结论：前者要求补采，后者必须指向明确的预设通过条件。

选择候选时用门槛而非总分：协议或数据边界失败可直接淘汰；性能、稳定性和费用只在满足前置门槛后比较。即使本次通过，也只表示该时间窗口和条件下通过，后续以低强度定期探针复核。这样形成“计划 → 原始行 → 聚合 → 证据抽查 → 条件化结论”的可审计链。

请求、响应与参数边界验收表

把一次 API 中转站检测写成可重放实验，而不是“随手发一个请求”。请求边界包括最终 Base URL、方法、模型、消息哈希、是否流式、超时、重试关闭状态与测试 key 的额度；响应边界包括 HTTP 状态、Content-Type、模型字段、结束原因、usage、首个有效事件、完成事件和脱敏 request ID。参数边界必须固定温度、最大输出、并发、请求间隔、地区和时间窗口，任何一项变化都创建新批次。

验收对象	请求/参数边界	响应证据	失败模式	验证指标与动作
普通 JSON	固定消息哈希、模型、超时，禁用自动重试	状态、响应头、可解析正文、结束原因、usage	401/404、422、429、5xx、解析失败	协议通过率按失败类型分组；修复模板后从单次请求重跑
流式 SSE	同一输入，显式 stream=true，记录客户端取消	首事件时间、每个事件类型、完成标记、中断位置	200 后中断、未知事件、空流、超时	TTFT、流完成率与中断率分开计算；不静默拼接重放
用量结算	按模型、时段和请求 ID 限定核对集合	客户端 usage、网关明细、结算明细	重复 attempt、字段缺失、时间窗口错位	逐请求差异进入待核对队列，不用余额变化代替 API 账单对账

这也解释了 API 中转站原理为何必须从“请求转发”扩展到路由、事件与结算证据。回答“API 中转服务 Token 用量怎么核对”时，要连接同一请求的 usage 和账单；回答“API 中转 429 和 5xx 怎么测试”时，只做低频、可停止的故障分支，不制造负载。若响应 schema、事件终止语义或费用来源无法确认，结果标为未验证并回滚到上一版请求模板。

一手资料

• RFC 9110 §15：HTTP 状态语义
• RFC 6585 §4：429 Too Many Requests
• OpenAI：Streaming API Responses
• Anthropic：Streaming Messages

停止、回滚与恢复步骤

停止条件包括密钥/权限错误未修复、费用到达预设测试预算、连续解析失败、出现非预期真实写入或日志可能含敏感内容。立即停止新请求，撤销测试 key，保留只读原始记录并清理含密钥的临时 shell 历史；不要删除失败行。回滚到上一个已知可复现的请求模板、客户端版本和配置快照，先用 dry-run/单次短请求确认协议恢复，再按一小批相同样本恢复。恢复后对照停止前后的 request ID、错误分类和账单，确认无未结算尝试才扩大批次。

执行问题与参数边界

以下回答用于定位常见执行问题。实际判断仍需结合本文的参数、失败模式和验证指标，不应仅凭一项现象推断服务能力。TTFT、P95 怎么测，稳定性记录怎么写，见稳定性测评一文。

API 中转站怎么检测

先核对协议，再抽查性能、故障和账单，四层都有记录才算通过。

API 中转站协议兼容性测试

普通 JSON 与 API 流式响应测试分开记录，不能只验证连通。

API 流式响应如何测试是否完整

记录首事件、有效内容、结束事件与中断位置。

基础概念与请求链路可参考 API 中转站是什么。

常见问题

API 中转站怎么检测？

先固定模型、请求体、网络、超时、重试和时段，再按协议、性能、故障、账单四层执行，保存响应头、正文或事件流、逐请求指标和脱敏请求 ID。

HTTP 200 是否等于检测通过？

不等于。普通响应还要能解析并满足结束语义；流式响应还要收到有效内容和正常完成事件，HTTP 200 后也可能中途失败。

中转站检测、测评和模型真假检测有什么区别？

检测是接入前的一次整体验收，看协议、性能、故障和账单。测评是在多个时段重复跑同一负载，看稳不稳。模型真假检测核对拿到的是不是你付费的模型。

API Token 用量怎么和账单核对？

按 request ID、模型和时间窗口连接客户端 usage、网关记录与账单明细，单列重试和回退尝试；无法连接的差异进入待核对队列，不用余额变化代替复算。