换中转站后怎么验证接口通不通

刚把 Base URL 和 Key 换成新中转站，客户端里还是报错，到底是配置写错、模型名不对，还是这个站本身有问题？这篇给一套按顺序走的连通性自检流程：每一步测什么、看到什么算通过、不通过该往哪查，最后附一份换站当天的验收清单。

刚把 Base URL 和 Key 换成新中转站，客户端里还是报错，到底是配置写错、模型名不对，还是这个站本身有问题？这种情况最容易乱：一边改地址一边换 Key 一边试模型名，报错出来根本不知道是谁的锅。先稳住手，按顺序一项一项验，比反复重装客户端有用得多。

下面这套流程从最笨的命令行请求开始，一路走到客户端复验和当天验收清单。每一步只回答一个问题：这一步测什么、看到什么算过、不过该往哪查。途中的价格、额度、支持模型这类会变的东西，一律去站内对应页面按当时的数字核对，不在这里写死。

先别急着换站：一次只改一个变量

换站的时候，你实际上同时改了三样东西：接口地址、密钥、还有要调用的模型名。这三样任意一个写错，报错看起来都差不多。所以第一步不是调客户端，而是把变量拆开——用最原始的方式打一次请求，先把「链路本身通不通」和「客户端配置对不对」分成两个独立的问题。链路不通就查站，客户端不通就查配置，别混在一起猜。

• 先把新 Key 单独放到一个环境变量或临时文件里，别和旧 Key 混在同一个配置文件
• 用 curl 或任意 HTTP 客户端直接打接口地址，完全不经过你的编辑器或桌面客户端
• 确认这一发有正常返回之后，再去改客户端的 Base URL 和 Key，一次只动一处
• 改完立刻再发一次最小请求，通过才继续下一步

第一关：鉴权通不通，报错怎么对号入座

鉴权是最先要过的关，但报错码不能一锅端。401 和 403 是两回事：401 多半是 Key 本身有问题——拼错、前缀少了、复制时带了多余空格，或者旧 Key 还留在环境变量里把新的覆盖了；403 往往是 Key 本身有效但当前没被允许做这件事，比如额度、权限或该站对某些调用方的限制。

404 一般是路径写错，不是 Key 的问题。接口地址多一层、少一层，末尾带不带 /v1，各家写法不一样，这类格式差异站内已经有专文讲过，别在鉴权这一步瞎猜。还有一类错误跟 Key 完全无关：连不上、超时、证书报错，属于网络根本没出去，这时候查代理、查 DNS、查本机网络，别去动 Key。

最省事的做法是改配置之前先看清楚现在到底哪份 Key 生效。环境变量和配置文件打架是换站时最常见的坑，你以为改了界面里的设置，实际跑的还是环境变量里的旧值。

第二关：模型名对不对，别拿官方名硬套

鉴权过了，接下来是模型名。中转站的模型名未必和官方完全一致，有的加前缀，有的用别名，有的会把同一个模型拆成多个入口。拿官方名字直接往上套，很容易收到「model not found」，然后你以为是站坏了，其实是名字根本没对上。

1. 去该站自己的模型列表核对不要凭记忆写，打开这个站提供的模型清单，找到你要用的那一个，原样复制名称。
2. 先用最小请求验一次一句话提示、很短的最大输出，只求返回正常。
3. 报错了就逐字符对重点看大小写、连字符、后缀版本标记这几处，中转站最容易在这些地方和官方不同。
4. 确认是站不支持还是名字写错如果清单里压根没有这个模型，那就是支持范围问题，换个模型再测，别死磕。

这一步顺带提醒一件事：模型版本和清单随时会变，今天能用的名字明天不一定还在。别把名字背下来写进笔记当长期配置，要写就写「去站内模型库核对」这个动作，具体名字到对应的模型库页面按当时的清单查。

第三关：流式、工具调用这些「高级项」单独测

非流式返回正常，不等于流式也正常。很多中转站对 SSE 流式的支持是单独做的一条链路，普通请求通、流式却卡住或者干脆一次把整段吐出来的情况并不少见。所以流式必须单独发一次请求验证：带上 stream 参数，看数据块是不是陆续返回，而不是等半天一次性出来。

• 流式：发一次带 stream 的请求，确认是一个个数据块陆续到达，最后有明确的结束标记
• 工具调用：构造一个必须调工具才能答对的问题，看返回里有没有结构完整的调用字段
• 结构化输出：如果业务依赖固定格式返回，单独跑一次，看格式有没有被吞掉或变形
• 这三项任何一项不通过，先判断是「这个站不支持」还是「参数写法不对」，两者处理方式完全不同

判断「不支持」和「写错」的方法很简单：换成最朴素的参数再试一次。还是不通，基本可以判定这个站这条链路没打通；一改就通，那就是你的调用写法问题。这个区分很重要，它决定你是换个站还是改代码。

第四关：量一次基线，别只看「能返回」

能返回和能用是两回事。换站之后至少要留两个手感：流式的首字时间，以及整段输出跑完大致花多久。别只测一次就下结论，同一个提示词连打几次，看的是波动——单次快慢说明不了问题，但一会儿很快一会儿卡很久，这个波动本身就是信号。

测之前建议先排除本地因素。用站内的测速工具先量一遍自己这台机器到公网的基线，如果本地网络本身就不稳，你测出来的延迟其实是网络问题，不是站的问题。

第五关：并发和报错率，小批量压一下

单次请求通过，只说明链路活着。真正上线之后是并发在跑，会不会一到并发就 429、会不会中途断流、失败的比例高不高，这些得小批量试才知道。做法不复杂：开几路并发，跑几十次短请求，把成功、限流、其他错误分开统计。

1. 定一个小节奏别一上来按生产峰值打，先用几路并发起步，参考站内并发分档的思路设计节奏。
2. 跑一轮短请求请求内容要短，目的是压连接而不是压生成，跑几十次够看出趋势。
3. 统计三类结果成功、429 限流、其他错误各占多少，重点看限流出现的频率是不是异常高。
4. 给错误码归类是限流、是超时、还是服务端 5xx，三类处理方式不同，先分清再决定要不要换站。

限流和 5xx 的语义、以及对应的重试做法，站内已经有专文讲透了，这一轮你只需要回答一个问题：这个站在你能接受的节奏下，会不会频繁触发这些错误。会，就记下来；不会，就进下一步。具体错误码的含义别在本文找，去站内那篇专文对。

第六关：回到你实际用的客户端再验一遍

命令行通了，不代表你在编辑器或桌面客户端里也能用。这类客户端的配置项格式各不相同，有的走界面设置，有的读环境变量，有的两者都读。换站之后最典型的坑就是新旧配置打架：界面上改了，环境变量里还留着旧的 Key 或旧的地址，结果客户端一直用旧的。

• 先发一句最简单的请求，能正常回一句就算过，别拿复杂任务当验收
• 确认客户端读的是哪一份配置：是界面里的，还是环境变量里的
• 把旧 Key 和旧地址从所有可能生效的地方清理干净
• 确认完之后再重新试一次完整流程，不要跳过最小请求这步

不同客户端的具体配置写法，站内有各自对应的配置文，这里只确认一件事：换站之后，客户端这层必须重新验一遍。命令行通过只是必要条件，不是充分条件。

换站当天的验收清单

把上面六步收成一张当天能照着勾的清单。过完这张表，基本可以确认这个新站从鉴权到并发这条链路是通的；没过完就上线，后面出问题你会分不清是站的问题还是配置的问题。

• 鉴权通过，模型名已到该站模型列表核对无误，最小请求返回正常
• 流式单独验证通过；工具调用或结构化输出按业务需要单独验证通过
• 小批量并发跑过一轮，拿到成功率和限流、5xx 的出现情况
• 记下首字和整体耗时的感觉，作为日后对比的基线
• 回到实际客户端再发一次最小请求确认；旧 Key 和旧地址清理干净
• 要看价格、额度是否对得上，去站内对应页面按当时的数字核对

最后这一条单独强调：换站之后顺手核一下价格和额度是常规动作，但这类数字会变，本文不写死任何数值。你到站内价格追踪页面看当时的数字，再决定要不要继续用。