很多人卡在第一步：注册完拿到 Key，却不知道该把地址填在哪、模型名写什么、报错 401 和 404 分别该改哪里。这篇按实际操作顺序走一遍注册到调通的全流程，把每一步的验证动作和出错时的排查方向列清楚，照着做能少绕几圈。
第一次用中转站，最容易卡住的地方往往不是不会写代码，而是拿到 Key 之后不知道该把地址填在哪、模型名该写什么、报错了该先改哪一处。很多人注册完兴致冲冲去调用，结果一个 401 或者 404 就把人劝退了，其实多数情况下只是配置里某个字段差了几个字符。
下面按真实操作顺序走一遍：从注册拿 Key，到填地址和模型名，再到跑通第一个请求，最后附上报错时的排查顺序和几个日常习惯。每一步都写了怎么验证，照着做能少绕几圈。想先搞清楚中转站本身是什么、和官方直连差在哪，可以先去看 /relay-api-usage-basics，这篇只讲操作。
第一步：注册、拿 Key、先把余额和额度看清楚
注册流程各家大同小异，邮箱或手机号注册完进控制台，找「令牌」或「API Key」那一页新建一把。要点是：Key 通常在创建后只完整显示一次，当场复制存到密码管理器或本地文件里，别指望关掉页面还能再看到。存好之后再顺手看一眼账户余额和这把 Key 所属的分组，很多莫名其妙的报错其实是余额为零，或者令牌没绑到你以为的那个分组上。
- 新建 Key 后立刻复制存好，多数站点只展示一次，丢了只能重新建
- 确认余额不为零，确认令牌绑定的分组和你要调的模型对得上
- 先只建一把临时 Key 用来跑通，权限别开到最大，跑通后再按环境拆分
- 把 Key 的创建时间和用途记一笔，后面排查「为什么这把不能用」时省事
第二步：填对地址和模型名，这两处错得最多
中转站的调用方式和官方接口基本一致，差别集中在两个字段：一是你要填的 API 地址（base url），二是模型名。地址必须填站点给的那一版完整前缀，多写一段路径、少写一段、结尾斜杠处理不一样，都可能直接 404。客户端里通常有两个地址输入框，一个是完整接口地址，一个是只填到域名层级的前缀，别填反了。拿不准就到 /relay-api-usage-basics 对照示例抄一遍。
模型名的坑更隐蔽。站点模型列表里写的名字可能带自己的前缀、大小写和官方不完全一样，照着官方文档的习惯自己拼一个，大概率报「模型不存在」。正确做法是从站点的模型列表页原样复制，先别改任何字符。另外建议先用列表里最便宜的那个模型跑通一次，再换成你真正要用的，这样能把「配置问题」和「模型本身的问题」分开。
| 出错现象 | 最可能的原因 | 先改哪里 |
|---|---|---|
| 连接失败或直接 404 | 地址前缀多写或少写、协议头不对 | 对照站点文档原样复制 base url |
| 提示模型不存在 | 模型名拼写、大小写、前缀不对 | 从站点模型列表复制，别自己拼 |
| 请求发出去但没反应 | 客户端把流式当非流式处理 | 先关掉流式发一次纯文本请求 |
| 返回正常但内容是空的 | 提示词或参数问题，不是配置问题 | 换一段最简单的短提示词复测 |
第三步：跑通第一个请求，确认是真能用
配置填好后，先用一段十几个字的短提示词发一次非流式请求。返回状态码正常、内容也是一句通顺的话，才算真的通了。这一步别用长提示词或复杂参数，变量越少越容易定位问题。通了之后再发一次流式请求，看输出是不是一段一段出来的，流式断流或者完全没有分块，多半是客户端或中间层的处理方式不对，换个客户端再试一次就能分清。
- 发一次短提示词的非流式请求用十几个字的问题，参数保持默认，确认返回状态正常且内容是通顺的自然语言
- 补一次流式请求同一个模型换成流式，观察输出是否分块到达；若失败先换官方示例客户端复测，排除客户端问题
- 连续发几次看稳定性间隔发三五次，记录响应时间和成功率；忽快忽慢先记下来，别只凭一次结果判断站点好坏
- 换目标模型复测把最便宜的模型换成你实际要用的，再跑一遍上面三步，确认不是只有便宜模型能用
报错时的排查顺序，从外到内一层层剥
报错别乱改，按从外到内的顺序来：先看身份（Key 对不对），再看位置（地址和模型名对不对），然后看额度与频率（余额、并发、限速），最后才怀疑站点本身。这个顺序的好处是每一步都能独立验证，改完一处再复测，不会一次改五个地方最后不知道是哪个起的作用。
- 401/403：先查 Key 有没有复制全、首尾有没有多余空格、令牌是否被禁用或过期
- 404：查地址前缀和模型名，两个都拿站点文档原文逐字符对一遍
- 429 或超时：先看是不是并发打满、余额不足，再换个时间段复测一次
- 以上都排除后，把报错原文和时间点整理好再提工单，比一句「用不了」有效得多
- 需要判断模型真假或稳定性，用 /tools/verify 这类检测入口跑一遍，比凭感觉猜靠谱
这里补一句适用范围：如果你用的是自己搭的转发或公司内网代理，上面的排查顺序要从代理那层开始，先确认代理是否透传了鉴权头和流式响应，再去查 Key 和模型名。直接照搬上面的顺序，可能会在错误的方向上浪费时间。
日常用起来的几个习惯
跑通之后，真正影响体验的是日常怎么管。Key 分环境放是最基本的：测试和线上各一把，别一把 Key 到处粘，出了事既不好定位也不好回收。地址、模型名、计费口径这几个关键信息记在一个固定地方，换客户端、换工具时直接抄，手误能少一大半。
另外要留意站点公告。分组调整、限速变化、模型上下架都会影响你正在用的那把 Key 和那个模型，看到公告先判断影响范围，再决定是改配置还是换站点。价格和可用模型的实时情况，到 /price-watch 核对当时的数字，别拿几个月前的印象做决定；想横向比较几家，可以看 /sites 的站点信息和可信度记录。
下一步把上面三步走完还觉得不稳，就去站点检测工具跑一遍延迟和可用性，再决定要不要换一家。→常见问题
注册完拿到 Key，第一个请求一直 401，可能是什么原因？
按顺序查三处：Key 复制时是不是带上了首尾空格或换行；令牌是不是被禁用、过期或余额已为零；请求头里鉴权字段的格式站点要求哪一种。三处都对还报 401，就把完整请求（隐去 Key）发给客服，让他们从日志侧看。
地址和 Key 都填对了，还是报模型不存在，怎么办？
多半是模型名写法不对。把站点模型列表里的名字原样复制，注意有没有渠道前缀、大小写差异、带不带版本后缀。还有一种情况是这个模型在你的分组里没开通，去控制台看分组和可用模型列表，换个已开通的先用。
能用之后再遇到断流、卡住，先动哪里？
先分清是网络还是服务端：换一个客户端、换一个模型各试一次，两次都断基本是中间层问题，只有某个模型断就是那个模型或渠道的问题。确认后在站点公告和状态页看有没有限速通知，再决定提工单还是换线路。
