很多人搜“中转站检测”“API 中转站检测”时，真正想解决的不是概念问题，而是：这个入口能不能稳定跑 Claude Code、Codex、Cursor 或自己的 OpenAI compatible 脚本。只看官网宣传、价格表或单次聊天成功，结论都太薄。
中转榜把这套测试流程整理成了一个 GitHub 开源清单：https://github.com/wuyabinde223/relayrank-checklist。它不是给某个服务商做背书，而是把可用率、延迟、模型兼容、错误返回、余额扣减和备用入口这些环节拆成可以复测的步骤。
为什么要把检测清单放到 GitHub
站内榜单适合做初筛，GitHub 清单适合做复测。前者回答“哪些服务值得进入候选名单”，后者回答“我手里的 Key 和真实任务能不能跑稳”。两者放在一起，才能减少只看排行榜或只看单次请求带来的误判。
- 方便开发者直接复制检查项，把中转站测试放进自己的项目 README、Issue 或运维记录里。
- 方便服务商提交可复现的测试样例，而不是只用一句“我们很稳定”来解释。
- 方便搜索用户从“中转站 GitHub”“中转站检测”“Claude Code 中转站稳定性测试”等长尾词找到可操作方法。
一次完整测试应该覆盖什么
我建议不要从大额充值开始，而是先用低额度跑一组稳定性验证。测试时记录请求时间、模型名、base url、返回码、错误文本、首 token 体感、完整任务耗时和费用扣减。
- 基础连通：用 OpenAI compatible 脚本确认 chat completions 是否能稳定返回。
- 模型真实性：检查模型列表、上下文长度、工具调用和流式输出是否符合预期。
- Claude Code 或 Codex 任务：跑一次 15 到 30 分钟的真实代码修改，观察中途是否超时、限流或断流。
- 高峰期复测：在不同时段重复同一任务，比较延迟和失败类型。
- 备用入口：至少准备一个替代 base url，避免主入口异常时整个工作流停摆。
和中转榜数据怎么配合
第一步，先看中转榜实时排行榜：https://www.zhongzhuanbang.com/zh-CN/rankings/，把可用率、平均延迟和当前状态异常的服务商先排除。第二步，阅读检测方法和风险观察，比如今天的中转站检测清单：https://www.zhongzhuanbang.com/zh-CN/articles/daily-relay-detection-checklist-2026-06-27/。第三步，再用 GitHub 开源清单跑你自己的真实任务。
如果测试结果和榜单不一致，不要急着下结论。榜单反映的是监控样本，GitHub 清单反映的是你的账户、地区、模型、任务形态和使用时段。两者交叉看，才更接近真实使用体验。
适合哪些人使用
这套清单最适合三类人：正在给 Claude Code 找中转站的开发者；想给 Codex、Cursor 或自动化 Agent 配备用入口的团队；以及希望被更透明评测的中转站服务商。
如果你只是偶尔聊天，可以只做基础连通和费用扣减检查。如果你要把中转站放进生产脚本、批量内容任务或团队开发流程，就应该完整跑完长任务、流式输出、错误恢复和备用入口测试。
下一步怎么做
打开 RelayRank Checklist：https://github.com/wuyabinde223/relayrank-checklist，先从 README 的快速开始跑一遍，再把 docs/checklist.md 里的项目逐项填完。完成后回到中转榜的方法说明页 https://www.zhongzhuanbang.com/zh-CN/methodology/ 和风险观察页 https://www.zhongzhuanbang.com/zh-CN/categories/relayrank-risk-observation/ 对照判断。
一个更稳的选型习惯是：榜单初筛，文章理解风险，GitHub 清单复测，最后小额充值验证。这样不容易被低价、单次成功或营销话术带偏。