把自己已有的 key 接进来

最后更新：2026-09-22

目标：你手上有别家的 key，想让它和平台自带的额度走同一个入口——程序里只留一个地址、一把 key。

整个过程是填三个格子。真正花时间的是填完之后「为什么没通」。所以下面分成两半：先填，再验。

先确认这把 key 本身是好的

这一步经常被跳过，然后浪费半小时。在你动平台的配置之前，先用这把 key 直打一次上游：

curl -s https://上游地址/v1/chat/completions \
  -H "Authorization: Bearer 你的key" \
  -H "Content-Type: application/json" \
  -d '{"model":"某个模型名","messages":[{"role":"user","content":"hi"}],"max_tokens":16}'

返回里有回复，说明 key 和模型名都对——问题一定出在平台这一侧的配置。返回报错，先在那边解决，别在平台里绕。

填三个格子

在控制台里打开对应 CLI 的设置（每个工具一张卡片，点齿轮），有三个字段：

填完点「应用」。平台会把这三样写进这个工具自己的配置和平台配置里，下次启动该工具时自动用上。

然后一定要验，别只看「有没有报错」

点完「应用」不会立刻发请求，所以这时候「没报错」什么都说明不了。发一条最小的请求：

curl -s 网关地址/chat/completions \
  -H "Authorization: Bearer 你的key" \
  -H "Content-Type: application/json" \
  -d '{"model":"你的模型名","messages":[{"role":"user","content":"hi"}],"max_tokens":16}'

拿到回复才算通。如果拿到的是错误，先分清是哪一类——下面的四条覆盖了绝大多数情况。

卡点一：key 根本没送出去

很多工具从环境变量读 key，而不是从你刚填的地方。如果你电脑上早就有一个同名的旧变量，你新填的这把可能从头到尾没被用过。

症状是「认证失败」，但你会以为是 key 错了。

怎么确认：

这类问题特别隐蔽，因为界面里显示的是你填的值，进程里用的却是另一个。有真实案例：系统里留着一把几十个字符的旧变量，界面里换了好几把新 key 都不生效，最后发现是那把旧的把新的顶掉了。

卡点二：地址对了，模型不在这边

同一个平台经常有不止一个入口，各自挂着不同的模型池。名字长得像的那个未必是你以为的那个。

症状是「模型不可用」，但那个模型其实是好的——只是不在你打的那个入口后面。

怎么确认：直接列一下那个入口有哪些模型，看你的模型名在不在里面：

curl -s 网关地址/models | grep 你的模型名

不在，就换成挂着它的那个入口。这一步能省掉大量猜测，因为它把「模型不存在」和「你打错了地方」分开了。

卡点三：模型名字写错

模型名是区分大小写的，差一个字符就是不存在的模型。从文档里复制，不要手打。

有些平台给模型起了别名（比如按档位分的名字）。别名只在提供它的入口有效，换一个入口就查不到。

卡点四：工具装好了，但一跑就退

有些命令行工具对运行环境有版本要求。如果你电脑上装过多个版本，切换工具（比如 nvm）换到旧版本后，这个工具就会拒绝启动。

症状通常是它自己把要求打出来，比如「需要 Node 版本 X，当前是 Y」。照它说的切到满足要求的版本即可——注意别只看默认的那个版本号，要看你打开工具的那一刻实际用的是哪个。

一条通用排错法

上面四条看着不同，其实是同一件事的两个方向：

先分清是哪一类，再往下查。多数「配置不生效」的困惑，都是把第二类当第一类在查——一直在改 key，而问题在模型名上。

下一步