7 个 AI 网关过完一遍 2026 现状：恢复速度快 60 倍，也可能变成云端跳板

【开源测评】第 2 期。上一期（第 1 期）我们把 7 个开源 WAF 过了一遍。这一期过的是另一个正在快速变成"必需品"的组件：AI 网关（LLM Gateway）。它到底是优化项还是基础设施？它救你多少、又能害你多少？这篇给答案。

先问一个问题。

当你的模型供应商挂了，你恢复服务需要多久？

这不是假设。2026 年真实生产环境里有这样三份记录：

没有网关自动 fallback 时的真实事故恢复时间是 38–128 分钟——注意，这个区间代表的全是"人工介入的延迟"，不是技术恢复时间。

而配置了提供商 fallback 的网关，MTTR 降到 15–45 秒。

压缩约 60 倍。

这就是网关模式最强的实证论点。不是降延迟，不是成本追踪——是恢复速度。

但同一个组件有第二张脸

网关是那个让自动 fallback 成为可能的组件。也正因为如此，它自己挂了，fallback 就一起消失了。

而 2026 年，最广泛部署的那个开源网关，经历了一整年的安全灾难。

LiteLLM 的 2026：一份时间线

逐条看几个关键漏洞，因为每一个都值得你拿去对照自己的部署：

① 预认证 SQL 注入（CVE-2026-42208）——最狠的那个

代理把 Authorization: Bearer 头的值直接拼进 SQL 查询，没做参数化绑定。

后果：攻击者只要在伪造令牌里插一个单引号（比如 sk-litellm'），就能在认证之前逃逸出原查询。任何能访问该端口的 HTTP 客户端都能利用。

拿到什么：后端 PostgreSQL 里的主 API 密钥、litellm_credentials、litellm_config——也就是你的云厂商凭证。

影响版本 1.81.16–1.83.6，修复于 1.83.7。Sysdig 在漏洞被收录后 36 小时就检测到首次利用尝试——而且攻击者不是盲扫：他们针对上述三张核心表定向窃取，载荷甚至匹配了数据库模式的大小写，流量出自同一 AS 内的两个 IP。

② PyPI 供应链投毒

litellm 的 1.82.7 和 1.82.8 两个版本在 PyPI 上带凭证窃取载荷，约 40 分钟后被移除。

40 分钟窗口。 在这个窗口里做了一次安装或重建镜像的人——你们全在名单上。

③ 两请求从普通用户升到管理员（CVSS 9.9）

• CVE-2026-47101：创建虚拟 API key 时，用户可以提交 allowed_routes 字段指定该 key 能访问哪些路径。LiteLLM 存储这个值时没有校验——任何一个 internal_user 都能建一个 allowed_routes: ["/*"] 的 key，直接通到管理员端点。
• CVE-2026-47102：/user/update 和 /user/bulk_update没有字段级授权检查——任何已认证用户都能往自己的账户记录里 POST 一个 user_role: "proxy_admin"。

两个请求，从无特权升到网关管理员。

④ 然后把它变成 RCE（CVE-2026-40217）

LiteLLM 的 Custom Code Guardrail 功能允许管理员提供 Python 代码来过滤模型输入输出。它用 Python 内置的 exec() 执行这段代码，而且没有关掉 __builtins__。

于是有管理员权限的人可以提交一段护栏代码，弹一个反弹 shell、读环境变量里的密钥、或者把代理配置整个外泄出去。

⑤ 一个组合链，实际严重性等于满分

• CVE-2026-48710（Starlette 的 Host 头校验缺陷，外号 BadHost）：Starlette 用 Host 头重建 request.url，而路由算法走原始路径——一个注入字符就能让认证中间件评估错误的路径，从而被绕过。
• CVE-2026-42271：MCP 测试端点的命令注入（CVSS 8.7，本来需要有效 API key）。

两者一组合，认证门槛完全消失——研究者评估实际严重性等同于 CVSS 10.0（理论最高分）。CISA 在 6 月 8 日把它加进了 KEV 目录。

还有更直接的：公网上那些没关门的实例

Wiz 扫描了 3074 个公网可达的 LiteLLM 实例，其中 294 个接受默认主密钥或者根本没启用认证。

约每十个里就有一个是敞开的。

为什么说它是"云端跳板"

这是本篇最该记住的一句话：

AI 网关保存的不只是模型调用记录。它往往还连接着云身份、内部工具、数据库和代码仓库。

想一想你为了让网关跑起来，都给了它什么：

• 各家模型厂商的 API key
• MCP 服务器凭证（能读文件、读仓库、查数据库、跑工作流）
• 可能是云厂商的 IAM 凭证
• 一个存着以上所有的数据库

网关集中管理 API key，同时也集中了这些 key 的攻击面。

一个网关被打穿，不是泄露一个厂商密钥，是把你的整条 AI 供应链连同它背后的云身份一起交出去。

而且——这正是 CVE-2026-59822（MCP 认证绕过）的杀伤路径：一个无意义的 Bearer 令牌也能建立有效会话，然后去调用网关已经连好的文件、仓库、数据库、工作流工具。这个漏洞已在蜜罐中观察到利用，CISA 也已收录。

7 个方案过一遍 2026 现状

我的判断口径（沿用第 1 期的原则——没实测就不说实测）：

• 要开源自托管：先看 Bifrost（性能与 MCP 治理都齐），Helicone 适合"我只想先看清楚调用"；
• 要用 LiteLLM：可以，但必须认清它的两个前提——性能天花板（500 RPS 附近就该考虑分片或换实现）和必须持续跟版本（2026 年它的修复节奏是以周计的）；
• 要商业托管：Portkey（治理最全）或 Cloudflare（零运维、但数据要能出境）；
• 已用 Kong：直接上 Kong AI Gateway，别为了一个 AI 插件引入整套新平台。

什么时候该上，什么时候别上

这条我放在选型表之后，因为它比选哪个更重要。

该上的信号（同时满足至少两个）：

• 多个模型厂商
• 多个团队共用
• 反复出现流量尖峰
• 需要集中预算管控
• 发生过厂商故障
• 模型目录频繁变动
• 有"绝不能把凭证放进客户端"的要求

别上的信号：

不要因为架构图里画了一个网关，就加一个网关。

单厂商的内部原型，用短时效凭证 + 基本日志 + 客户端超时，可能更简单也更安全。

因为网关不是免费的：它额外引入一个网络跳、一个故障域、一份策略漂移，和一个你需要长期运营的组件。

量级参考：传说中"约每月 100 万次请求"是平台投入开始划算的门槛——但这不是规矩：5 万次昂贵的 Agent 请求，可能比 1000 万次廉价分类调用更值得加控制。

延迟：别信"<1ms"，要看你落在哪一段

厂商宣传的单体开销数字（11 微秒、<5ms）都是自托管内核的处理时间，不是你要部署的端到端往返。

真实分布是这样的：

而且延迟数学在 Agent 管道里才真正变危险：

多 Agent 场景是顺序链式调用的。**5 次顺序调用，经过一个 40ms 开销的 Python 网关，就是 200ms 的累计"网关税"。**换成 Go 或 Rust 网关，同样的 5 次调用开销可以忽略。

单请求基准测试看不到这个。 这是架构选择在管道层面的下游后果。

上线之后才会发现的 5 个坑

这一节是纯运维向，全部来自真实生产事故。

① 单实例部署，在评估期很常见，在生产不可原谅。

网关一旦在链路上，它就需要和你的数据库一样的可用性待遇。两位工程师的教训：自托管网关在一次部署中崩溃，把整个聊天机器人一起带走了。

② 别把网关放在和应用不同的云区域。

每一次调用增加的那点延迟，累积起来比人们预期的快得多。 要放就放同区域，或者用它的边缘部署。

③ 流式 + fallback = 咬人最狠的那个组合。

这是一旦输出开始，请求就已经"提交"给该厂商了。针对缓冲响应工作良好的 fallback 路由，换到流式就挂——用户界面会变成一段漫长的停顿，然后突然刷出一整面墙的字。

连接中途失败时，网关应该报告"部分响应"，除非应用明确接受重复，否则不要静默重跑生成。

④ 熔断器会误伤健康厂商。

按 provider + model 组合分别设熔断器是对的，但一个在健康厂商上误触发的熔断器，会把全部流量推给一个可能没有容量接住的备用。

⑤ 有些故障不会自己宣告。

• 网关丢掉 Redis 连接 → 静默停止缓存**，不报明显错误**。
• 网关层数据库饱和 → 从应用的角度看就像 LLM 延迟。

所以：把网关当基础设施建模，不是当中间件。 健康检查、按组合分别熔断、可观测的 fallback 状态——三样都要。

可抄的安全加固清单

这一节是这一期真正的"抄作业"部分。

别用成这样

• 别把网关当"买个软件"。 它是关键路径上的基础设施——需要副本、健康检查、被演练过的切换路径，和季度复查（路由规则是否还匹配当前模型能力、密钥是否还轮换得动、fallback 厂商是否还在合同内）。
• 别只看单体开销数字。 厂商的"<1ms"是内核处理时间；要测的是你实际部署的那一跳，从应用端测，不是引厂商的最佳值。
• 别把 fallback 当普通重试。 模型调用慢且贵，盲目重试会同时放大成本和你最差的那部分延迟。fallback 要按请求设计（顺序 fallback 省成本，并行对冲保尾延迟但双倍花费）。
• 别让护栏成为"没有故障策略的依赖"。 护栏挂了怎么办是一个有意识的选择（fail-open 还是 fail-close）——要有界的时间预算、二级检查、明确的决策记录。
• 别在一个网关里混所有工作负载。受监管负载、面向公众的 Agent、内部实验、高并发批处理，可能需要不同的网关策略或不同部署。 集中化应该减少重复劳动，而不是造出一个超大的信任边界。
• 别记成"上了网关就安全了"。 网关是安全的执行点，也是攻击的高价值靶心——它同时把凭证和权限集中到了一处。

一句话总结这一期：**AI 网关把故障恢复从 2 小时压到 45 秒，代价是你在关键路径上多了一个"集中了所有凭证"的组件。**前者的收益是确定的、可量化的；后者的风险也是——2026 年，最流行的那个开源实现在 PyPI 上被投毒过 40 分钟，被 CISA 收录过 KEV，公网上还有约十分之一的实例没关门。

所以结论不是"别上网关"，而是：如果你上了，就按基础设施的标准养它。

下期预告：10/8 周报自动任务跑起来，10/14【漏洞雷达 #4】。今天最后留一个问题给所有已经或准备上网关的团队：你的网关跑了哪个版本、用了哪个密钥、暴露在哪个网段——这三个答案，你现在能立刻说出来吗？

网关不是优化项，是关键路径。开源测评，第 2 期。每周二/五见。