——按 IP、UID 还是 Token？

一、为什么 API 限流越来越重要？

在现代互联网应用中，API 已经成为业务系统最重要的入口。用户登录、查询订单、发送验证码、支付、修改资料……几乎所有业务操作，最终都会转换成一次 API 请求。例如用户登录对应 POST /api/login，获取订单对应 GET /api/order/list，发送验证码对应 POST /api/sendSms。

如果 API 没有限制访问频率，就意味着任何人都可以无限调用接口。攻击者可能利用这一点：不断尝试用户名密码进行暴力破解；无限请求短信验证码导致短信资源被刷；高频调用查询接口爬取大量业务数据；大量请求消耗服务器资源造成服务不可用。因此，API 限流（Rate Limiting）已经成为企业 API 安全防护中的基础能力。

很多开发人员知道要做限流，但是经常会遇到一个问题：API 限流到底应该按照什么维度限制？按 IP？按用户 UID？还是按照 Token？实际上，单独依赖任何一种方式都存在问题，真正安全的 API 限流通常需要结合多种维度。

二、什么是 API 限流？

简单来说，API 限流就是限制某个对象在单位时间内可以访问接口的次数。例如一分钟内用户 A 最多请求登录接口 10 次，某个 IP 地址最多请求接口 100 次，某个 Token 最多调用查询接口 500 次。超过限制后，系统返回 HTTP 429 Too Many Requests，表示请求太频繁，请稍后再试。

正常请求返回：

HTTP/1.1 200 OK

超过限制则返回：

HTTP/1.1 429 Too Many Requests

三、为什么只按照 IP 限流不够？

很多系统最开始设计限流时，会采用同一个 IP 一分钟只能访问多少次的策略。例如 IP 192.168.1.100 限制 60 秒最多访问 100 次。这种方式简单，但是存在明显问题。

第一，NAT 环境导致误伤。 现在很多企业、学校、家庭网络都是多个用户共享一个公网 IP，例如公司出口公网 IP 120.xxx.xxx.xxx，员工 A、B、C、D 全部通过这个 IP 访问系统。如果限制一个 IP 一分钟 100 次请求，可能导致正常员工一起办公时被误认为攻击。

第二，攻击者可以通过代理绕过。 攻击者不会一直使用一个 IP，而是不断切换 1.1.1.1、2.2.2.2、3.3.3.3、4.4.4.4 等代理 IP。如果系统只限制 IP，攻击者可以轻松绕过。

第三，移动网络 IP 经常变化。 手机用户使用 4G/5G 网络时 IP 不断变化，如果按照 IP 限制，可能导致限制效果不好，正常用户体验下降。所以 IP 限流适合作为第一层防护，但不能作为唯一方案。

四、按照 UID 限流有什么问题？

UID（用户 ID）限流就是按照登录用户进行限制。例如用户 ID 10001 限制一分钟最多查询订单 50 次。这种方式比 IP 更精准，即使多人共享 IP 也不会互相影响。但是 UID 限流也存在问题。

第一，未登录接口无法使用 UID。 例如登录接口 POST /api/login，用户还没有登录，系统哪里知道 UID？攻击者用账号 admin 配合不同密码 123456、123457、123458 等不断尝试，这种场景只能依赖 IP、设备指纹、Cookie 或风险评分。

第二，攻击者可以批量注册账号。 例如短信验证码接口 POST /api/sendCode 限制每个 UID 每天 5 次，攻击者注册 1000 个账号 user001、user002、user003 等，每个账号发送 5 次验证码，最终 1000 × 5 = 5000 次短信请求，UID 限制直接失效。

五、Token 限流是否更安全？

Token 限流就是按照访问凭证限制。例如 Authorization: Bearer eyJxxxx 限制同一个 Token 每秒 10 次请求。这种方式适合 API 开放平台、微服务、第三方接口调用。例如企业开放 API，第三方应用 A 的 Token 为 abc123456，限制 10000 次/天。

但是 Token 限流也不是万能的。问题在于 Token 泄露怎么办？如果攻击者获取了 Access Token abcdef123456，那么攻击者可以正常携带 Token 请求。因此 Token 限流必须结合 Token 有效期、IP 异常检测、设备信息、风险控制等措施。

六、企业最佳实践：不要选择一个维度，而是组合限流

实际企业系统中，更推荐多维度联合限流。例如登录接口 POST /login 的限制策略：IP 一分钟最多 100 次，账号一分钟最多 5 次，设备一分钟最多 20 次，异常行为触发验证码。这样攻击者需要同时绕过多个限制。

七、常见限流算法有哪些？

1. 固定窗口算法

这是最简单的算法。例如 10:00-10:01 允许 100 次请求。缺点是边界容易被突破，攻击者可以在 10:00:59 发送 100 次请求，然后在 10:01:00 再次发送 100 次请求，短时间内 200 次请求通过。

2. 滑动窗口算法

解决固定窗口问题。系统记录最近一分钟请求数量，例如 10:00:30 - 10:01:30 统计请求数量，精度更高。

3. 令牌桶算法（企业最常用）

令牌桶可以理解为系统提前放入一些"访问令牌"，每请求一次消耗一个令牌。例如桶容量 100 个令牌，每秒生成 10 个令牌。正常情况快速消耗是允许的，超过则等待或者拒绝。优点是支持突发流量、控制更加平滑、适合互联网业务。

4. 漏桶算法

漏桶类似固定速度处理请求。例如服务器每秒处理 100 个请求，超过则排队或者丢弃。适合需要严格控制流量的系统。

八、渗透测试中如何验证 API 限流？

安全测试人员不仅要发现接口，还需要验证限流是否真的有效。

1. 高频请求测试

例如使用 Burp Intruder 设置 POST /api/login 发送 1000 次请求，观察是否返回 429。如果全部返回 HTTP 200，说明可能没有限制。

2. 修改请求参数绕过

例如限制 uid=10001，测试修改为 uid=10002、uid=10003 等，验证是否只依赖参数。

3. Header 绕过测试

尝试 X-Forwarded-For、X-Real-IP、Client-IP 等 Header，例如设置 X-Forwarded-For: 1.1.1.1，观察是否可以绕过 IP 限制。

4. 多账号绕过测试

例如验证码接口限制手机号每天 5 次，测试多个账号请求是否可以无限发送。

九、开发/测试安全 Checklist

十、总结

API 限流不是简单设置"一个 IP 一分钟多少次"，真正安全的限流需要根据业务场景选择不同策略。

最佳实践是：基础防护用 IP 限流，用户行为用 UID 限流，身份控制用 Token/API Key 限流，高风险业务用设备 + 风控 + 多维度限制。

对于企业应用来说，IP 解决来源问题，UID 解决用户问题，Token 解决身份问题。三者结合，才能真正降低 API 暴力破解、数据爬取、资源滥用、自动化攻击等风险。

限流不是为了限制用户，而是为了保证正常用户可以稳定使用业务，攻击者无法无限消耗系统资源。在 API 安全建设中，限流应该和认证、授权、风控一起设计，而不是上线后发现接口被刷才临时补救。