检测方法

脚本仓库：https://github.com/relaywatch-cn/relaywatch-scripts（MIT 许可）。本页描述与仓库 commit 63884093 的代码一致；运行 python3 run_all.py 依次执行下列 5 项检测，并用 validate_result.py 校验输出。

原则：脚本开源，在你自己的电脑上用你自己的 key 运行，每次运行会在你的账户上消耗少量 token（必须显式设置 RELAY_CONFIRM_SPEND=yes）。我们不收集、不保存 key；输出的 result.json 只含通过/失败、usage 数字、日期、脚本版本和中转站域名，不含 prompt 原文。任何单次结果都只是「某日某样本的观察」，不是对站方的定性。

所有检测已在本地 mock 服务器（模拟官方 Messages API 格式，含流式 SSE）上验证：诚实变体全部通过；无签名、伪造签名、usage 虚报、换模型、不缓存、慢速、固定回复、错误格式等变体均被对应检测识别。

1. Thinking 签名检测

做法：开启 extended thinking（budget_tokens=1024）发一个简单算术问题，检查是否至少有一个 thinking 块，且每个 signature 非空、只含 base64/URL-safe 字符、长度 ≥100（check_signature.py）。可选的强检测：若你另设自己的官方 key（OFFICIAL_ANTHROPIC_KEY），脚本会把该轮回复（含 thinking 块）作为对话历史回放给 api.anthropic.com；官方返回 HTTP 400 视为签名无效，其他错误记为「无法判定」。

能说明：签名由 Anthropic 服务端生成，中转理论上无法伪造，回放通过 ≈ 这一次请求确实到达了 Claude。社区工具 veridrop 也把这一项作为最高权重检测。

局限：只证明「这一次」；混合路由（按比例换模型）需要多次、多日抽样；不做官方回放时只是格式启发式，可被模仿；长度阈值是未校准的假设。

误报可能：中转站未透传 thinking 参数（不支持该功能 ≠ 掺水）；官方未来改变签名格式；请求的模型本身不支持 extended thinking。

来源：veridrop（项目自述，二手）；混合路由难以规避的讨论见 linux.do 帖（二手）。

2. 协议指纹检测

做法：用同一个短请求各发一次非流式和流式（check_format.py）。非流式检查 id 是否 msg_ 前缀、type=message、返回的 model 是否与请求一致、usage 字段是否齐全、工具调用 id 是否 toolu_ 前缀；流式检查 SSE 事件顺序 message_start → content_block_start/delta/stop → message_delta → message_stop（忽略 ping），并对 message_start 里的 message 做同样的 id/type/model/usage 检查。

能说明：响应是否符合官方 Messages API 格式；model 字段不一致是换模型的直接线索。

局限：格式容易被模仿，「通过」不代表是真 Claude；只能发现粗糙的套壳或协议转换。

误报可能：中转站用别名映射模型名（如返回带日期的完整版本号）；官方新增事件类型（如 ping，脚本已忽略）；中间代理改写 id。

来源：Anthropic 流式文档（一手）；RelayScope（GitHub 公开仓库，未声明开源许可，故不加链接）；veridrop。

3. Token 与缓存计费检测

做法：(a) 你可用自己的官方 key 调用官方 count_tokens 得到期望 input tokens，填入 EXPECTED_INPUT_TOKENS，脚本比对中转返回的 usage（含缓存字段合计），偏差 >5% 标红；(b) 每次运行随机生成约 1500 词的 system prompt（避免命中旧缓存），标记 cache_control 后连发两次，第二次应出现 cache_read_input_tokens > 0 且计费 input_tokens 低于第一次的 input+缓存写入（check_billing.py）；(c) 实际扣费金额请你在中转控制台手工核对（我们不登录、不抓取任何账户）。

能说明：是否虚报 token、是否真正提供 Prompt Cache（逆向渠道常常没有缓存）。

局限：usage 数字是中转自报的，可以「报得对、扣得多」，所以 (c) 不可省；不提供期望值时 (a) 跳过。

误报可能：缓存有最短长度和过期时间，两次请求间隔过长或 prompt 不够长会正常未命中；不同模型的 tokenizer 不同，务必用同一模型计算期望值。

来源：Anthropic Prompt Caching 文档（一手）；RelayScope 缓存倍率检测；阿里云开发者社区文（二手，称逆向渠道无缓存）。

4. 每日随机能力题

做法：每次运行在本地用随机种子生成有标准答案的新题：5 个 10–99 随机数组成的算术式、在 2000 个随机 8 字母词中找一个随机 10 位大写 SECRET 值（needle-in-haystack），答案包含在回复中即判通过（daily_prompts.py）。结果只上报通过/失败和种子哈希，题目不离开你的电脑。

能说明：防止中转针对公开固定用例硬编码答案；低档模型在长上下文检索和算术上更容易出错。

局限：题目简单，只测能力下限，强一些的小模型也能答对；通过 ≠ 是指定模型。

误报可能：模型偶发计算错误；回复格式多余（脚本已做宽松匹配）；max_tokens 太小被截断。

来源：固定用例被针对的案例见 linux.do 帖（2026-03-28，二手）。

5. 速度与重复性检测

做法：同一开放式 prompt（max_tokens=200，temperature=1）流式请求两次（check_speed_repeat.py）：记录首 token 时间（只记录，不判定）和输出 tokens/s，任一次 tokens/s 超出区间即不通过；两次输出逐字相同且长于 50 字符即不通过。

能说明：异常快可能被换成小模型，异常慢可能是多层转发或排队；两次完全相同强烈暗示固定回复。

局限：默认区间（15–400 tokens/s）是未核实的占位值，请先在官方 API 实测并用 RELAY_MIN_TPS/RELAY_MAX_TPS 校准；速度受网络、负载、地区影响很大。

误报可能：网络慢、高峰期排队；中转做了响应缓存（相同请求返回缓存结果本身也值得记录，但不一定是掺水）。

来源：吐字异常快 + 两次输出相同的案例见 linux.do 帖（二手）。

怎么解读