Gemini API Key 限制强制执行已生效：Routing 团队现在必须检查什么

Google Gemini API 已从 2026 年 6 月 19 日起停止接受未配置限制的标准 API Key。如果你的 routing 层或 gateway 使用未设置显式 API 限制的 Key 代理 Gemini 请求，这些调用现在将返回错误。此次强制执行如期落地——错过截止日期的 operator 今天正面临生产管道中断的问题。

什么发生了变化

Google 在截止日期前数周向所有 Gemini API 用户发送了"Action Required"通知，并在官方 Gemini API 论坛发布了强制执行公告，明确设定了硬性截止时间：从 2026 年 6 月 19 日起，Gemini API 将停止接受使用无限制标准 Key 发出的请求。

"无限制" Key 是指在 Google Cloud Console 或 AI Studio 中创建，但未添加显式 API 级别限制的任何 Key。在 6 月 19 日之前，这些 Key 可以正常用于 Gemini 请求。从今天起，它们将无法使用。

仍然有效的 Key 必须至少应用以下一种限制：

在 API 限制中设置为 Gemini API（或特定 API 子集）。
在应用限制中配置了允许的 referer、IP 范围或 Android/iOS 应用指纹。

修复方式很简单：打开 Google Cloud Console → 凭据，找到所有用于 Gemini 请求的 Key，确保每个 Key 的 API 限制列表不为空，其中必须包含 Gemini API 和/或 Generative Language API。

为何对 Gemini Routing 影响重大

对于通过任何 gateway（无论是自托管代理、共享推理平台还是自定义 routing 层）路由到 Google Gemini 的团队而言，API Key 是存储在 gateway 配置中的共享凭据，而非应用代码中。这意味着：

Gateway 凭据会静默老化。 在项目启动时创建、从未审查过的 Key 几乎肯定没有限制。如果它运行了几个月都没问题，现在它会突然失败，除了 403 或服务中断错误外没有任何其他预警。
每个 Key 的限制不会继承。 如果你的 gateway 轮换 Key 或使用 Key 池，每个 Key 都需要单独配置限制。限制 Key 池中的一个 Key 无法保护其他 Key。
Routing 故障转移可能短暂掩盖问题。 如果你的 routing 策略在 4xx 时回退到其他 provider，Gemini Key 被拒绝的情况可能被静默处理——直到你发现 Gemini 在路由流量中的占比降至零。
限制在凭据层面，而非配额层面。 这不是速率限制问题。增加用量额度无法解决它。Key 本身必须携带限制元数据，才能通过 Google 的认证层。

需要审查的内容

通过 Gemini 路由的 operator 应按以下步骤检查：

第一步——列出所有正在使用的 Gemini 凭据。 在 gateway 的凭据存储中查询所有匹配 AIza* 模式的 Key。这些都是 Google 标准 API Key。

第二步——检查限制状态。 对每个 Key，打开 Google Cloud Console → 凭据 → Key 详情页。在"API 限制"下，值不应为"无"或"不限制 Key"。

第三步——应用限制。 如果某个 Key 未受限制，将其 API 限制设置为包含 Generative Language API（这是 Gemini API 底层使用的 API）。应用限制立即生效，无需重新部署。

第四步——测试。 限制生效后，通过该 Key 发送一个轻量请求（model: gemini-3.5-flash，最小 token 量），确认返回 200 响应。

第五步——轮换。 这次强制执行也是审查 Key 年龄和范围的好时机。建议轮换所有超过 90 天的 Key，并将限制范围缩小到 routing 层实际调用的特定 Gemini API 面（Generative Language 与 Vertex AI 与 AI Studio）。

更广泛的凭据卫生信号

这次强制执行符合所有主要 provider 的普遍趋势：API 凭据的限制只会越来越严，而非越来越宽松。当 Gemini 的 API 发布使原本对公众安全的 Firebase/GCP API Key 突然具备调用付费、消耗配额的模型能力时，Google 开启了这一变革周期。安全研究社区记录了数千个暴露的 Key，按 Google 自己的 Firebase 指引这些 Key 从技术上是公开安全的，但它们在一夜之间成为了活跃的 Gemini 凭据。

6 月 19 日的强制执行关闭了另一侧的缺口：即使是在自己项目内部，仅仅"无限制"的 Key 也不再被接受。

对 routing 团队而言，这带来了操作层面的启示：将 Gemini API Key 限制状态纳入凭据轮换清单，而不是一次性配置步骤。 每个新 Key 创建时就应携带限制，现有 Key 需要定期审计。