GitLab.com 从 2026 年 10 月 19 日起按订阅层级重新设定速率限制。免费账户和未认证请求先执行新规，付费层级在 2027 年 1 月起跟进。影响范围覆盖 API 请求、网页请求和已认证的 HTTPS 方式 Git 操作，超限后返回 429 状态码。自动化脚本和爬取类工具受影响最大，自建 GitLab 实例不受影响。
新规则的具体数值
限制按每用户加每个顶层群组应用，用户取自己可达的最高层级。
- 免费层每小时 5000 次，突发上限每分钟 100 次。
- 付费层每小时 15000 次，突发上限每分钟 1250 次。
- 旗舰层每小时 25000 次，突发上限每分钟 2000 次。
- 未认证请求按 IP 每小时 60 次，所有层级一致。
突发上限和小时配额之间有换算关系。按突发上限持续打，免费层约 50 分钟耗尽小时配额，付费和旗舰层约 12 分钟耗尽。短时间高并发的批处理任务，即使总量不大也会撞上限。
未认证的 HTTPS 方式 Git 操作不适用新规，仍按现有的每 IP 限制执行。
过渡期安排
官方安排了两个灰度窗口，10 月 7 日和 10 月 14 日的 15 点到 19 点，只影响免费与未认证流量，提前让用户感受限流后的行为。已登录的付费层级请求不受影响，因为它们的限制要到次年 1 月才变。
谁会被卡住
自己写脚本调 API 的团队首当其冲。不带凭据的请求以前有较宽松的额度，新规按 IP 收到每小时 60 次，对付费账户跑未带凭据的自动化也一样。构建流水线里频繁调 API 拉取项目信息的场景，容易在高峰期触限。
迁移步骤
- 盘点现有调用，按来源分成已认证与未认证两类，给所有自动化脚本配上个人访问令牌、OAuth 令牌或流水线令牌。
- 改造请求模式，能批量的走批量接口，能缓存的加缓存，列表请求改分页翻取，去掉紧循环轮询。
- 加失败处理，读响应头里的剩余次数和重试等待时间，按指数退避重试，不要立即重发。
- 配额明显不够的，评估升级层级，容量超标准套餐的采购通道 2026 年内开放。
响应头里的信息足够自己做限流器，RateLimit 系列字段会给出剩余次数、重置时间和重试等待秒数，项目、群组、用户三类接口不返回信息性速率头，这几处要额外注意。
对比现行额度能看出收紧的幅度。目前未认证流量按 IP 每分钟 500 次，已认证接口按用户每分钟 2000 次，未认证的 HTTPS 方式 Git 操作每 IP 每分钟 15000 次。新规则把这套通用额度换成按层级区分的配额体系，已认证侧的额度变化最明显，未认证侧的收紧从每分钟五百次降到每小时六十次。未认证 Git 操作不在这次重定范围里，暂时维持原样。
为什么现在改
官方没有披露滥用流量的具体占比，给出的背景是平台承载数百万个项目，预计本年度的负载会增长数倍。限流的目标是防止单个工作负载拖慢整站，官方同时表示大多数用户已经在新的限制范围内。这类表述的通常含义是长尾滥用集中在少数调用方身上，但绝大多数正常使用者的请求模式不需要调整。
公开项目的一个现实问题
调用方不登录也能读公开项目，这部分以前几乎不设防。新规按 IP 限到每小时 60 次之后，靠公开接口做数据同步的工具会被影响。官方给出的出路是给调用方加认证，或者把项目转私有，再或者升级套餐。
常见问题
- 自建实例受影响吗。不受影响，新规只覆盖 gitlab.com。
- 超限会丢数据吗。不会，请求被拒绝，稍后重试即可，官方明确自己数据的访问和导出始终保留。
- 怎么提前验证。用灰度窗口测试，或者在测试环境模拟 429 处理逻辑。
- 按团队成员算还是按账号算。按用户加顶层群组，用户取可达的最高层级。