很多人拿到中转站给的密钥后，第一反应是往客户端里一贴，结果报错说模型不存在或者还是连到官方去了。问题通常不在密钥，而在两个地方没配对：地址写成了官方域名，模型名随手抄了个记忆里的拼法。这篇按接入顺序把改哪两处、去哪确认模型名、客户端和代码两种填法、怎么验证流量真走了中转站讲一遍，照着做能少绕几圈。
拿到中转站给的密钥之后，很多人的第一反应是往客户端里一贴就完事，结果要么提示模型不存在，要么调用记录里空空如也。排到后面才发现，问题多半不在密钥本身，而在两个地方没配对：接口地址还指着官方域名，模型名则随手抄了个记忆里的拼法。这两处不对，密钥再对也白搭。
下面按实际接入的顺序走一遍：先搞清楚到底要改哪两处，再去中转站自己的清单里确认模型名，然后分别看客户端和代码两种填法，最后用几个动作验证你的请求确实落在了中转站这边、而不是绕回官方去了。每一步都给了可执行的检查和验证方式，照着做能少绕几圈。
真正要改的就两处：地址和密钥
把整件事想简单一点：你需要动的只有接口地址和密钥这两个字段，其余的温度、最大输出长度、超时这些参数，基本沿用你原来那套就行，不用为了换个站专门去调。地址指的是程序或客户端里原本指向官方域名的那个字符串，换成中转站提供给你的域名。
- 地址后面要不要带版本路径，各家写法不一样，别凭感觉拼，去中转站的接入说明里核对原样写法
- 密钥用中转站自己发的那一串，官方密钥在中转站这边通常无效，两套密钥不要混着用
- 环境变量名如果沿用了官方那套，容易在不经意间读到旧的官方密钥，接入后顺手检查一遍
- 同一个项目里如果同时接了两个站，建议把地址和密钥成对命名，避免复制粘贴时错配
模型名别背，去中转站自己的清单里抄
模型名是最容易出错的一环。同一个底层模型，不同中转站起的名可能带前缀、带版本后缀、带渠道标识，你在别处见过的写法在这里未必被认得，复制粘贴比手打稳得多。打开中转站的控制台或模型列表页，把你要用的那一行原样复制，包括大小写和中间的横杠。
- 先跑通链路拿一个你已经确认在中转站清单里存在的模型名发一次请求，确认地址、密钥、模型名三者对得上
- 再换目标模型链路通了以后，把模型名替换成你真正要用的那个，再发一次。如果报错，这时基本能判断是名字写错还是站点不支持，不会和地址问题混在一起
- 记录可用名单把你实际验证通过的模型名记在项目配置里，下次换人或换环境不用重新试一遍
| 报错现象 | 优先怀疑 | 下一步动作 |
|---|---|---|
| 提示模型不存在 | 模型名拼写或站点未上架 | 回中转站模型列表页逐字对照 |
| 提示鉴权失败 | 密钥用错或地址没换 | 检查是否仍指向官方域名、密钥是否成对 |
| 提示找不到路径 | 地址多写或少写了版本段 | 按中转站接入说明里的地址原样填 |
| 请求成功但后台无记录 | 流量没到中转站 | 核对地址字段是否生效、是否被环境变量覆盖 |
客户端和代码两种填法，差在哪
客户端一般是图形界面里几个输入框：一个填服务地址，一个填密钥，再有个地方选或填模型名。填完先点连接测试，别急着开新对话。代码这边，若用官方 SDK，通常改的是构造客户端时传的基础地址和密钥，请求路径不用你手拼，SDK 会自己接上。
curl -sS <中转站基础地址>/chat/completions \n -H "Authorization: Bearer <中转站密钥>" \n -H "Content-Type: application/json" \n -d '{"model":"<从中转站清单复制的模型名>","messages":[{"role":"user","content":"hi"}]}'- 图形客户端
- 界面填地址和密钥，务必用连接测试按钮先验一次，再开新会话
- 官方 SDK
- 改构造客户端时的基础地址与密钥，路径交给 SDK，别自己拼
- 直接发请求
- 好处是能看到原始返回，坏处是请求头要自己写全，适合排错时用
顺序建议是：先用最简单的一次性请求，把地址和密钥这两件事确认没问题，再把它搬进你的项目配置里。别一边换地址一边改业务代码，出了问题你分不清是哪边引起的。想省事先看别人踩过哪些坑，到 /guides 里的接入类文章翻一翻，能省掉几次无效排查。
怎么确认请求真走了中转站
链路跑通不等于流量走对了站。最直接的一招是看计费或调用记录：向中转站发一次请求，去它后台看这次调用有没有落进去。落进去了，说明流量确实到了它这边；如果后台一片空白但请求却成功了，那大概率你还在直连官方。
- 故意用错密钥发一次，观察报错来自哪里：文案仍像官方那边的鉴权提示，说明地址根本没换成功
- 看返回里的模型字段和用量字段，与你在别处见到的习惯不一致通常意味着中转层做了改写，属于正常现象
- 换个网络环境再试一次，排除本地代理或 hosts 把请求劫持回官方
- 连续发两三次请求，确认后台记录条数与发送次数对得上，而不是间歇性落库
验证通过之后再谈流式和并发，别把两件事搅在一起排查。如果站点本身的可信度、稳定性你还没底，可以先到 /sites 看看各家检测记录，再到 /tools/speed-test 跑一下实际连通情况，最后结合 /price-watch 里当时的数字决定长期用哪家，数字以页面当天显示为准。
下一步地址和密钥配对、模型名从清单里抄、再用后台记录确认流量落点，这三步做完接入就算稳了。想把这些判断标准一次看全，去站内接入指南对照着核一遍。→常见问题
Base URL 到底要不要带后面的版本路径？
看中转站给的说明，两种写法都有人用，不能凭经验猜。稳妥做法是先用它文档里给的完整示例跑通一次，再往你的客户端或代码里搬。如果报的是地址找不到这一类错，八成就是这一段拼错了，把它和文档里的原文逐字符对一遍就行。
为什么密钥换了还是连不上？
先分清是连不上还是连上了但被拒。连不上多半是地址写错或网络不通，被拒基本是密钥问题或模型名不被支持。有个省事的判断法：用明显错误的密钥发一次请求，看报错里提到的是哪一方的身份校验，就能知道请求到底发到了哪。
怎么知道请求有没有真的走中转站？
看中转站后台的调用记录最直接，发一次请求后去那边刷新，看有没有新增一条。没有记录，说明请求压根没到它这儿。另一个办法是留意返回里的模型标识和用量口径，和中转站的说明对得上就基本没问题。
