调中转站时最常见的两种卡壳：一是 base_url 填成官网地址或漏了版本段，请求直接打偏；二是接口通着但返回 503，分不清是站点侧还是自己侧的问题。这篇给一套照着走的填法规则和排查顺序，让你两分钟内定位到是改配置还是找客服。
调中转站时最常卡在两个地方：一是 base_url 填成官网首页、控制台地址或文档地址，请求直接打偏；二是接口明明通着，却时不时返回 503，分不清是站点侧的问题还是自己这端的问题。这篇只讲这两件事，给一套照着走的填写规则和排查顺序。
目标很实际：两分钟内判断出该改配置、该换线路，还是该直接找客服。下面每节都只给判断标准和可执行动作，具体价格、可用性数字这类会变的东西，一律到站内对应页面核对当时的数字。
base_url 到底指哪一段
base_url 只是请求地址的前缀，SDK 会自己在后面拼上具体路径，比如聊天补全、模型列表这些。所以多写一段或少写一段，结果通常不是报错就是 404。先把「前缀」这个定位记住，后面所有填错都能解释。
- 含版本段
- 文档写的是到 /v1 这类版本段为止，你就要把这段一起填进去
- 到域名为止
- 文档只给域名，版本段由 SDK 或调用方自己拼，你就不要多填
- 常见误填
- 把官网首页、控制台登录页、接口文档页当成 base_url，这几类地址都不是 API 前缀
- 打开站点后台或接口文档，找标着「API 地址 / Base URL」的那一行，以它为准
- 确认这一行有没有版本段，有就一起复制，没有就别自己加
- 粘贴后检查结尾有没有多余斜杠，以及有没有把路径重复拼两遍
- 换站点时整个替换，不要只改域名留下旧路径
三条填写规则，先对照再动手
抄别人截图里的地址是最容易踩的坑：截图可能来自另一个线路、另一个版本，甚至连 Key 都不是同一套。规则只有一条核心——以站点自己标出来的那一行为准，其余都是辅助验证。
| 情形 | 该怎么做 | 验证方式 |
|---|---|---|
| 第一次接入 | 从后台复制 API 地址整行 | 发一个最简请求，能返回模型列表即通 |
| 从 A 站换到 B 站 | base_url 和 Key 一起换 | 换一半通常会报鉴权失败或模型不存在 |
| 站点有多个入口 | 按你网络能通的那个填 | 同一 Key 分别试，记录哪个通、哪个不通 |
| 换了本地网络或代理 | 先重测再决定改不改地址 | 用站内工具量一次延迟和可用性 |
如果你只是想看当前各站点的接入信息汇总，可以到 /sites 核对，那里通常会标每个站点给的是哪种形式的地址，比在聊天记录里翻旧截图可靠。
503 出现时，先分清是谁的问题
503 的含义是服务暂时不可用，但它既可能来自中转站自身，也可能来自它背后的上游。不要一看到就改 base_url，先花一分钟做三个判断，方向基本就定了。
- 缩范围换一个最简请求、换一个模型名，看是不是只有某个模型报 503；只有单个模型挂，多半是模型侧而不是地址侧。
- 换变量同一 Key 换线路、换客户端各试一次；全失败基本在站点侧，只是部分失败则更可能在你本地网络或代理。
- 看频率偶发说明上游在排队，等一会儿再试；持续报就说明该模型或该分组当前不可用，考虑切分组或换模型。
- 偶发 503：先重试一到两次，别急着改配置
- 单个模型持续 503：切到同站其他模型验证，能通就先用着
- 全模型全线路 503：直接看站点公告，改配置没用
- 换网络就正常：问题在你本地链路或代理，不在地址
排障顺序：从自己这端往外查
排障最忌两头同时改。固定一个顺序：先确认自己发出去的请求长什么样，再确认网络通不通，最后才把证据交给客服。下面这个顺序照着走，基本不会来回折腾。
- 核对完整请求地址把 base_url 和 SDK 拼出来的实际路径拼一次，确认没有双斜杠、没有重复版本段、没有多出斜杠结尾。
- 量一次网络用站内 /tools/speed-test 做一次测速与可用性探测，先排除本地网络和代理干扰，再谈站点问题。
- 整理证据再问把状态码、请求地址、模型名、发生时间点整理成一条消息发给客服，比只问「怎么 503 了」有效得多。
# 最小验证：只发一次最简请求，看返回体和状态码
curl -sS -o /tmp/resp.txt -w '%{http_code}\n' \
-H "Authorization: Bearer $API_KEY" \
"$BASE_URL/models"
cat /tmp/resp.txt上面这段的价值在于把「地址 + Key」两个变量固定住，一次只验证一件事。返回状态码和响应体都留档，交给客服时对方能直接定位，不用来回追问。想横向对比不同站点当前的可用性表现，可以到 /rankings 看当时的统计。
这些情况别按上面的思路硬套
上面这套顺序默认「你的配置可能有问题，站点本身大体正常」。如果前提不成立，照着改反而浪费时间。遇到下面几类情况，先换判断口径。
- 所有模型、所有线路同时挂：属于站点整体故障，改地址没用，先看公告再决定等还是换
- 报错文案里带账单或额度字样：按充值口径处理，不是地址问题
- 自建或企业网关：base_url 由你自己的路由决定，按内网文档填，别套公网规则
- 公司统一走代理出口：先在代理侧确认放行规则，再怀疑地址和 Key
地址填错是确定性问题，重试就能复现；503 是可用性问题，会自己变好也会自己变坏，两者的处理方式不该一样。下一步如果你正卡在某个站点的 503 上，先去站点目录核对它的接入方式和当前状态，再按上面的顺序走一遍，能省掉大部分来回试错。→
常见问题
中转站给的地址后面要不要加 /v1？
看它文档的写法。多数站点会明确给一段带版本号的地址，照抄即可；只有给到域名级别的，才需要你自己补上版本段。判断办法是拿这条地址加常见接口路径拼一次，能通就说明拼对了，通不了就先问客服要标准写法。
接口昨天还好，今天一直 503，是我配置坏了吗？
先在不动配置的前提下，换一个模型名和另一个分组各发一次请求。如果换了就通，说明是原来那条通路上游出了问题；如果全都 503，基本是站点侧波动，按站内监控页看当时的服务状态，再决定等还是换站点。
同时用好几家中转站，怎么避免地址填混？
按站点建独立的环境变量或配置文件，命名里带上站点简称，不要共用一个变量来回改。切换时连 Key 一起换，并在本地留一份「站点—地址—常用模型」的对照表，出问题时能一眼看出是哪一项对不上。
