你不是一个人。
注册账号、登录控制台、建好 API 密钥、复制粘贴那几行 curl，按下回车——结果游乐场弹出一个 openai_error，或者代码返回 404 model not found，又或者最诡异的一种：控制台里的「请求次数」永远是 0，额度一丝不动。
这不一定是你的代码写错了。很大概率，是你接的那个大模型上游，从这层链路里"掉线"了。
三种最常见的"假在线"现象
openai_error/ 5xx：请求被中转站转发到上游后，上游直接报错。404 / model does not exist：上游根本没有你配置的这个模型名。- 「请求次数 = 0」：你以为发起了请求，但流量根本没进到计费/推理层——通常卡在鉴权或路由这一步。
三者都指向同一件事：链路某一环断了，但前端可能还显示"渠道在线"。
为什么"启用"不等于"可用"
很多人（包括不少站长自己）会默认：中转站后台把渠道开关打开（status=1），就代表"这个模型能用了"。
其实不是。
渠道启用，只代表"这一路被允许参与路由"。它不验证上游 Key 此刻是否还能调通、也不验证你填的模型名上游到底有没有开通。于是会出现一种很扎心的状态：
站点看起来一切正常，模型广场列得满满当当，但每一个真实请求都被上游拒绝——整站"在线却零服务"。
我们见过最典型的例子：某站渠道里填了一串"看起来没问题"的 Key，实际上上游那边的 DeepSeek 从未开通、旧模型也全线下线了。结果就是：用户注册、充值、建密钥，却永远跑不出第一个 token。16 个账号，请求次数全是 0。
3 步上游自检法（建议收藏）
下次遇到调不通，先别怀疑自己，按顺序查这三步：
第 1 步：验 Key——它到底还"活"不"活"
拿渠道里填的那串 Key，直接打上游官方接口（例如官方 /v1/models，或对应 SDK 的 list models）。
- 返回
401 / 403：Key 失效或权限不足。 - 返回
404：端点不对，或 Key 绑定的资源不存在。 - 返回模型列表，但没有你配置的那个模型：模型未开通。
- 返回的模型列表里只有几个已下线的旧模型：上游资源已被回收。
只要 Key 没法"列出它该有的模型"，后续一切都是空中楼阁。
第 2 步：验模型名——差一个字符都不行
上游的模型 id 经常带日期后缀，比如 deepseek-v4-flash-260425。中转站配置的模型名必须和上游逐字符一致，大小写、连字符、日期后缀都不能差。
差一个字符，上游就会判定 model_not_found，然后你的请求就 404 了。这是最高频的"假故障"。
第 3 步：验端点——请求最终落在哪
base_url 必须指向真正能 serving 该模型的入口。很多"一键接入""免 Key 客户端"会把你的请求转给某个第三方，你并不知道最终落到了谁的服务器、是不是官方授权渠道。
能直达官方推理入口的，才算数。
3 秒自检口诀
Key 能列模型？模型名一致？端点直达官方？
三项全绿，才算真通；任一红，就是假在线。
把这句话存进你的排查 SOP，能省掉无数个小时的"我代码哪里写错了"式自我怀疑。
一个坏 Key 的真实代价
一个失效的 Key，足以让整站陷入"看起来在线、实际零服务"。对站长，是白烧的服务器和悄悄流失的用户；对开发者，浪费的不是钱，是信任——你第一次调不通，大概率就走了，再也不会回来验证"是不是我的问题"。
所以如果你在挑一个中转站，请把"它能否列出自己宣称的模型"当成硬指标。敢让你自己验、模型名和官方逐字对齐、端点直达官方的，才值得把核心业务接上去。
Yady 的做法（说人话版）
我们直连火山引擎官方渠道，模型名与官方逐字对齐，base_url 直达官方推理入口；当你心里没底时，可以用上面三步自己验一遍——能验，才是真合规。
如果你刚注册还没跑通第一个请求，先看这份《3 步跑通第一个 API 请求》和《5 分钟上手 Yady》，按图索骥，比盲调高效得多。
调不通的时候，先别急。先问一句：是我的代码，还是上游掉线了？ 这份清单，就是帮你回答后一半问题的。
