总体反馈
首先感谢这个项目——轻量化的订阅管理理念非常契合个人开发者 / 小团队的实际需求。不做格式转换、全文请求记录、单一管理员 + API Key 额度控制的设计，相比 NewAPI / One-API 这类重型方案干净很多。在实际部署使用过程中，有两个点希望能改进。
一、故障转移（Failover）未正确触发 — Bug
场景：
同一模型名（模型别名）配置了多个渠道，按 priority 排序：
- priority 1 → minimax 渠道
- priority 2 → glm 渠道
问题：
当 minimax 渠道返回 429（Too Many Requests / 限流） 时，网关没有自动 fallback 到 priority 2 的 glm 渠道，而是直接把 429 错误返回给客户端。
期望行为：
当上游返回 429（以及 5xx 等可重试错误）时，网关应自动按 priority 降级，将请求重试到下一个可用渠道，直到拿到成功响应或所有渠道都失败后再把错误透传给客户端。
复现步骤：
- 配置两个渠道映射到同一模型别名，priority 分别为 1 和 2
- 将 priority 1 渠道（如 minimax）的额度耗尽 / 触发上游限流，使其返回 429
- 通过网关发送请求
- 客户端直接收到 429，而非从 priority 2 渠道获得的正常响应
建议：
- 明确哪些上游状态码（429、500、502、503、504 等）会触发 failover
- 在渠道级别允许配置"是否参与 failover"和"冷却时间"，避免被限流的渠道短时间内被反复命中
- failover 日志在控制台请求记录中可见，方便排查
二、路由侧增加「最大连接数」限制 — Feature Request
需求：
希望在渠道/路由级别支持配置 最大并发连接数（max connections / concurrency limit）。当某个渠道的并发连接数达到上限时，自动将后续请求路由到 priority 更低的下一个渠道，而不是排队等待或直接拒绝。
典型场景：
- minimax 渠道有 QPS / 并发数限制，达到上限后继续打到它只会 429
- 与上面的 failover 配合：连接数满了 → 自动降级路由；429 了 → 故障转移。两者互补，形成完整的「压力分担 + 故障兜底」链路
期望配置形态（供参考）：
channels:
- name: minimax
priority: 1
max_connections: 10
- name: glm
priority: 2
max_connections: 5
当 minimax 达到 10 个并发时，新请求自动流向 glm；两者都满时再按 failover 策略处理（排队 / 拒绝 / 返回明确错误）。
环境信息
- 部署方式：Docker（
ghcr.io/gojam11/llmrelayservice:main）
- 上游：minimax + glm
感谢作者考虑以上建议，期待项目越来越好。
总体反馈
首先感谢这个项目——轻量化的订阅管理理念非常契合个人开发者 / 小团队的实际需求。不做格式转换、全文请求记录、单一管理员 + API Key 额度控制的设计，相比 NewAPI / One-API 这类重型方案干净很多。在实际部署使用过程中，有两个点希望能改进。
一、故障转移（Failover）未正确触发 — Bug
场景：
同一模型名（模型别名）配置了多个渠道，按
priority排序：问题：
当 minimax 渠道返回 429（Too Many Requests / 限流） 时，网关没有自动 fallback 到 priority 2 的 glm 渠道，而是直接把 429 错误返回给客户端。
期望行为：
当上游返回 429（以及 5xx 等可重试错误）时，网关应自动按 priority 降级，将请求重试到下一个可用渠道，直到拿到成功响应或所有渠道都失败后再把错误透传给客户端。
复现步骤：
建议：
二、路由侧增加「最大连接数」限制 — Feature Request
需求：
希望在渠道/路由级别支持配置 最大并发连接数（max connections / concurrency limit）。当某个渠道的并发连接数达到上限时，自动将后续请求路由到 priority 更低的下一个渠道，而不是排队等待或直接拒绝。
典型场景：
期望配置形态（供参考）：
当 minimax 达到 10 个并发时，新请求自动流向 glm；两者都满时再按 failover 策略处理（排队 / 拒绝 / 返回明确错误）。
环境信息
ghcr.io/gojam11/llmrelayservice:main）感谢作者考虑以上建议，期待项目越来越好。