短.be速率限制 (Rate Limiting) 是对 API 或服务的请求数量在一定时间窗口内设置上限的机制。例如「每分钟最多 60 个请求」「每天最多 1,000 个请求」，超出上限的请求会收到 HTTP 429 (Too Many Requests) 响应。这个状态码由 RFC 6585 定义，用于告知客户端在一定时间内发送了过多请求。
速率限制有三个主要目的：第一是保护服务器 (防止大量请求导致服务宕机)，第二是确保公平性 (防止个别用户独占资源)，第三是成本控制 (管理云服务的按量计费)。
在短链接服务中，速率限制应用于多个场景：URL 缩短 API 的请求次数限制 (防止垃圾链接的批量生成)、短链接访问次数限制 (缓解 DDoS 攻击)、管理后台的登录尝试次数限制 (防止暴力破解) 等。
速率限制的算法主要有四种：固定窗口 (每分钟重置计数器)、滑动窗口 (持续计算最近一分钟内的请求数)、令牌桶 (以固定速率补充令牌，每次请求消耗一个令牌)、漏桶 (以固定速率处理请求，超出部分排队等待)。
开发者在使用 API 时应对速率限制做好应对：检查响应头，根据剩余请求数调整请求频率。表示剩余量的响应头名称因服务而异，X-RateLimit-Limit、X-RateLimit-Remaining 这类名称是长期形成的惯例；标准的 RateLimit 响应头仍在制定中，截至 2026 年 8 月还处于 Internet-Draft 阶段。收到 429 响应时，如果带有 Retry-After 头，就按它指示的时间等待后重试；如果没有该头，或者等待后重试仍然返回 429，则逐步延长等待时间，即指数退避。两者是不同的手段，按 Retry-After 等待本身并不等于指数退避。