GitLab.com 将按套餐限流，匿名自动化先迎来每小时 60 次
据 GitLab 的限流调整公告，GitLab.com 将分阶段实施按套餐区分的速率限制。其中，面向 Free 与匿名流量的调整计划于 10 月 19 日开始，匿名请求的上限将降为每个 IP 每小时 60 次。
作者：林岚｜OC 开发者生态编辑
据 GitLab 的限流调整公告，GitLab.com 将分阶段实施按套餐区分的速率限制。其中，面向 Free 与匿名流量的调整计划于 10 月 19 日开始，匿名请求的上限将降为每个 IP 每小时 60 次。
一句话结论：最先需要排查的不是人工浏览，而是那些没有认证、共享出口、反复轮询的自动化脚本。
每小时 60 次看起来不像一个会影响大型工程的数字，恰恰因为很多人没有意识到，自己的一小段脚本可能每天都在匿名访问代码托管平台。查询最新版本、检查文件变化、定时刷新元数据，这些请求各自不多，叠到一个出口上就不一样了。
公告区分了两个时间段：Free 与匿名流量在今年 10 月调整，Premium 和 Ultimate 的相关变化计划从 2027 年 1 月开始。范围是 GitLab.com，不是所有自建 GitLab，也不包括 GitLab Dedicated。把它概括为“GitLab 全面每小时只能访问 60 次”，会同时弄错对象和限额。
共享 IP，会把小脚本变成大流量
匿名请求缺少用户身份，平台只能按 IP 等信息计量。同一个办公室、云端代理或 CI 出口后的多个任务，因此可能共同消耗额度。脚本作者看自己的日志觉得“我才请求几次”，但服务端看到的是同一个出口持续发来请求。
即使访问的是付费组织的公开资源，匿名访问也不自动获得付费身份待遇。认证请求则按公告描述的用户与顶层群组及其套餐规则计算，不能简单拿项目所在公司的套餐替匿名脚本辩解。
遇到 429，不要把它变成重试风暴
这一变化会暴露一些本来就脆弱的实现：收到错误就立即再试、多个进程各自查询同一份数据、没有缓存也不理解剩余额度。限流发生后，这些做法会把一次暂时失败拖成长时间无法恢复。
工程上更合理的处理是识别限流响应，在适用时遵守 Retry-After 等提示，并为重试加上等待和随机分散。能缓存的内容不要每次重新下载；能通过事件获知变化的工作流，可以评估减少轮询。这里的重点是减少无效请求，而不是换出口绕过限制。
如果决定使用认证，也不能顺手给所有脚本塞一个高权限个人令牌。访问权限应与脚本实际需要相符，凭据不应出现在公开仓库、命令日志或发布包中。解决额度问题，不值得制造一个更大的凭据问题。
预演窗口比生效日更值得盯
GitLab 安排了 10 月 7 日和 14 日的预演，时间均为 UTC 15:00 至 19:00。团队可以借此观察真实任务是否出现限流，而不是只靠估计请求次数。跨时区的团队应按 UTC 转换排班，避免把窗口误看成本地下午。
测试不能只看流水线最终是否成功。某个任务靠多次重跑才通过，或者更新检查被静默跳过，也可能隐藏问题。应同时查看错误分布、等待时间和最终数据是否完整。
关键事实
- 生效阶段：Free、匿名流量计划 2026 年 10 月 19 日调整；付费套餐相关阶段在 2027 年 1 月。
- 匿名限额：每 IP 每小时 60 次，不是所有认证用户的统一额度。
- 预演：10 月 7 日、14 日，UTC 15:00—19:00。
- 范围：GitLab.com；不涵盖 Self-Managed 与 Dedicated。
OC 判断
这次调整的实际影响会集中在不起眼的自动化接缝。OC 建议把它当作一次依赖盘点：谁在访问、是否认证、谁共享出口、失败后如何恢复。只为某个报错加重试，可能掩盖设计问题；把请求预算纳入工作流，才是持久修复。
为什么重要
- 对开发者：版本检查和公开项目采集脚本需要提前检查。
- 对平台团队：共享 CI 出口会放大匿名流量的集中程度。
- 对项目用户：自动更新延迟未必是项目停止维护，也可能是取数环节触发了限制。
评论
围绕这篇文章补充信息、提出问题或分享观察。