# GitLab 匿名请求限额骤降，谁的脚本会先断掉？

**Summary:** GitLab 将于 10 月 19 日把匿名流量限制从每分钟 500 次请求收紧到每小时 60 次。我会利用十月份两次限流演练，提前找出那些未认证的调用者，以免共享 IP 掩盖了真正的问题源头。

- Canonical: https://markhuang.ai/zh/news/gitlab-60-request-limit-anonymous-scripts
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-17
- Section: News
- Tags: GitLab, 速率限制, API 自动化, 认证, DevOps
- Source: [GitLab Blog](https://about.gitlab.com/blog/rate-limit-change-2026/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![多条自动化请求流汇聚到一个狭窄的网络闸口，而经过认证的请求则通过专用通道](https://cdn.markhuang.ai/news/gitlab-60-request-limit-anonymous-scripts/hero.webp)

*匿名请求可能来自许多机器，但对外却表现为同一个身份。当配额绑定到 IP 地址时，它们都得在同一个闸口排队。*

[GitLab 宣布 GitLab.com 的速率限制将于 2026 年 10 月 19 日调整](https://about.gitlab.com/blog/rate-limit-change-2026/)。匿名流量将被限制为每个 IP 地址每小时 60 次请求，远低于目前每分钟 500 次请求的通用限制。同一天，免费账户也将切换到基于套餐的限制，高级版和旗舰版则会在 2027 年 1 月跟进。

在我看来，这更像是一次身份审计，而非单纯的容量调整。我手头的任何自动化脚本都该走认证。更棘手的问题在于，还有哪些东西共享了同一个公网 IP？因为一个被遗忘的脚本就可能耗尽同一办公网关、云 NAT 或代理背后所有未认证进程的配额。

## 六十次请求可能属于整个网络

单位的变化说明了一切。GitLab [当前文档](https://docs.gitlab.com/user/gitlab_com/rate_limits/)规定，未认证请求为每个 IP 每分钟 500 次。而新配额是每小时 60 次。一个每分钟运行一次的轮询脚本，自己就能用光整个 IP 的匿名配额。

[GitHub 提供了一个明显的参照：未认证的 REST API 请求也是每小时 60 次](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api)，同样绑定到源 IP。这让 GitLab 所谓“匿名配额符合行业标准”的说法显得可信。但团队仍需找出并修复那些假定配额池大得多的调用者。

IP 边界才是关键。GitLab 的支持指南警告，位于同一 NAT 或办公地址后的人和自动化进程会共享这个配额。开发者查询公开项目数据、访问状态页，再加上一个定时库存脚本，在内部看来毫不相干，但在 GitLab 眼中却是同一个匿名调用者。因此，第一个失败的客户端可能恰恰是那个请求量最少的。

## 限流演练就是生产环境测试

GitLab 将在两个预览窗口启用新的免费账户和匿名限制：10 月 7 日和 14 日，UTC 时间 15:00 至 19:00。公司称之为“限流演练”，之后会再次关闭限制，直到 10 月 19 日永久生效。

我会把这八小时的预览当作一次故障演练。记录每一个 `429 Too Many Requests` 响应、调用任务、其认证状态以及出口 IP。检查客户端是否遵守 `Retry-After` 头。留意那些变慢了、或者悄悄少跑了一部分的任务——不只是那些直接报错的。

> **Info:**
>
> 测试什么时候算过？我手头的每个调用者都有了明确身份，每个有意保持匿名的调用者都划定了预算，而且 `429` 响应只会带来可控延迟，而不是重试风暴——满足这些条件才算。仅凭仪表盘一片绿色，我几乎得不到任何有用信息。

对 GitLab 公布的响应头要谨慎解读。套餐限制文档提到响应中包含剩余配额和重置时间信息，但也提到某些端点级别的限制并不会反映在这些响应头里。一个请求返回的 `RateLimit-Remaining` 值看着健康，不代表下一次请求就能躲开别的限流规则。

## 认证是用凭证风险换配额风险

GitLab 为认证流量提供了宽松得多的套餐限制：免费版每小时 5,000 次请求，高级版 15,000 次，旗舰版 25,000 次。突发上限分别为每分钟 100、1,250 和 2,000 次请求。小时限制优先；如果某个端点自身的限制更低，就以端点限制为准。

给脚本加上令牌是最直接的解决方案，但我不会为了消除 `429` 错误就把个人访问令牌随意散落在 cron 任务里。GitLab 列出了个人、项目、OAuth、部署和 CI/CD 作业凭证等不同场景的选项。我会给每个任务分配刚好够用的最小身份，并记录它的归属人、权限范围、轮换周期和吊销路径。

认证改变了故障模式。匿名自动化担心的是配额太小、跟人共享；认证自动化要担心的，反而是权限给大了。一个只读公开元数据的脚本，不该因为图方便拿了个宽泛的令牌，就顺带获得了写入权限。

## 退避保护的是服务，不是工作负载

GitLab 建议采用批处理、缓存、分页和指数退避。这些都是合理的客户端行为。`429` 响应包含 `Retry-After` 头，客户端应该等待，而不是反复冲击同一个端点。

然而，重试逻辑无法凭空创造容量。如果一个匿名状态收集器每小时需要 120 次请求，再礼貌的退避也只是把失败分散到更长时间里。工作负载要么去认证，要么减少调用次数，要么另寻出路。GitLab 表示，确实无法认证的集成应联系公司，但其手册也明确说明，已公布的限制不提供绕过途径。

商业层面也还有一件事没落地。GitLab 说正在设计一种机制，让用户可以购买超出标准套餐的额外容量，细节会在 2026 年晚些时候公布。还有一个用于对比用量和套餐限制的产品视图，也计划今年晚些时候上线。在 GitLab 公布合同条款和价格之前，我不会围绕这两项功能来制定运营计划。

## 10 月 7 日前我会做什么

我会从网络边缘开始，而不是 GitLab 设置页面。列出办公室、Runner、无服务器任务和云网络使用的公网 IP。在任务定义和脚本中搜索那些调用 `gitlab.com` 但缺少授权头或合适 Git 凭据的请求。然后按调用者和业务目的对结果分组。

自有自动化应分配合适的机器身份。重复读取应尽可能使用缓存或条件请求。每个客户端都应记录状态、相关的速率限制头，以及足以追溯流量激增的调用上下文，同时避免记录密钥。告警应能区分有意限流和 GitLab 服务中断。

我会刻意保留一些匿名调用者。公开徽章、外部监控器，以及由我无法控制的人员运行的软件，可能有正当理由在不使用令牌的情况下访问公开数据。这些情况需要独立的预算和降级方案，不应与可以认证的内部任务混用同一套重试策略。

新限制作为平台防护措施是站得住脚的，尤其在自动化流量不断增长的背景下。我会利用十月份的限流演练，找出那些仍在依赖共享匿名身份的系统。然后为该认证的地方分配合适的凭证，只在真正需要时保留匿名访问。