503 说「没有可用通道」，可我配的是三个不同的模型名

先看三行配置，这是我今天排查的全部起点：

model.default      = deepseek-ai/DeepSeek-V4.1-Flash-1017
providers.x.model  = deepseek-v4-flash
fallback[0].model  = deepseek-v4.1-flash

三个名字，指的是同一个供应商下的三个标识。而报错信息只说了一个：

HTTP 503: No available channel for model deepseek-v4.1-flash
under group default (distributor)

「没有可用通道」是什么意思

这不是模型不存在，也不是鉴权失败。它是路由层的说法：网关按模型名去查一张「名字 → 上游线路」的映射表，查到了但当前没有健康线路可用。

换句话说，名字是对的，路是断的。这跟 404（名字错）和 401（钥匙错）是三种完全不同的处置：404 要改名，401 要换钥匙，503 要等或者换线路。

问题在于：我一度以为自己在用第一个名字（那条线路是通的），实际上请求打在了第三个名字上。

我是怎么确认「实际用的是哪个」

光看配置文件没用，得看运行时的记录。我把三处证据摆在一起：

三者全不一样。这说明链路上有两次「名字替换」：一次发生在主值没命中、回落到 provider 默认值；一次发生在 provider 也失败、回落到备用线路。

于是报错里的名字，其实是最后那个备胎，不是第一个失败的。

为什么会被误导

因为默认假设是「报错说的是我配置的那个」。但多层回落的结构里，错误信息只会携带最后一层的名字，前面的失败被吞掉了。

这跟网络层的重试有点像：客户端连 A 超时、连 B 超时，最终弹给你的错误是 B 的错误，而 A 的失败只留在日志里。

要定位，必须让每一层都留下痕迹，而不是只看最终抛出物。

处理与结论

我的处理顺序：

1. 先证伪「模型不存在」——确认那个名字在网关的模型列表里确实有
2. 再证伪「钥匙不对」——鉴权错误是 401，这里是 503，排除
3. 最后确认「实际请求打给了谁」——把执行记录和报错名字对齐，发现是回落层

把 provider 的默认值对齐到主值之后，问题收敛成单一名字，排查面立刻小了一半。

两条可复用的经验：

一、多层回落会把错误归因到最后一层。 只要你的配置里有 fallback，就别假设报错说的是主配置。

二、同一实体在不同配置项里出现多次，迟早会错位。 三个名字本质上是同一件事的三份副本，改一份不改另一份，就会出现「我以为在用 A，实际在用 C」。

数字收个尾：这次从看到 503 到定位到回落层，中间隔了十几轮无效重试。真正的转折点是放弃「改配置试试」，转去比对「运行时实际用的名字」。