网站开发框架DjangoRestFramework的Throttle限流防CC

Django REST Framework（DRF）的Throttle机制本质上是一个基于请求频率的流量控制层，它直接作用于API视图，在请求到达业务逻辑之前完成拦截或放行。很多人把Throttle简单理解为“限制某个IP一分钟访问多少次”，这确实是它的基础功能，但真正要防住CC攻击，必须深入理解它的限流算法、键值生成策略、以及如何与前端缓存和反向代理联动。CC攻击的特点是攻击者通过大量代理IP发起看似正常的请求，专门消耗服务器资源，如果限流键只认IP，攻击者切换IP的成本极低，限流就形同虚设。所以正确的做法是采用复合键策略，把用户ID、会话标识、请求路径甚至自定义的指纹信息组合起来，让攻击者即使换IP也无法轻易绕过。

DRF的限流体系由三个核心类构成：BaseThrottle、SimpleRateThrottle和AnonRateThrottle/UserRateThrottle。BaseThrottle是抽象基类，定义了allow_request方法，返回布尔值决定请求是否被放行。SimpleRateThrottle继承自BaseThrottle，实现了基于缓存后端的速率控制逻辑，它需要一个scope属性来对应settings里配置的速率字符串，比如“100/hour”。AnonRateThrottle和UserRateThrottle是DRF内置的两个具体实现，前者针对未认证用户，后者针对已认证用户。当请求进入DRF视图时，框架会依次调用所有已配置的Throttle类的allow_request方法，任何一个返回False，请求就会被拒绝，返回429 Too Many Requests状态码。这个流程的关键在于，限流判断发生在认证之后、权限判断之前，也就是说你可以拿到request.user，这对于设计精准限流策略至关重要。

SimpleRateThrottle的parse_rate方法会把“100/hour”这样的字符串解析成请求次数和秒数，然后通过get_cache_key方法生成一个唯一的缓存键。这个缓存键的生成逻辑是防CC的核心。默认的UserRateThrottle生成的键格式是“throttle_user_用户ID”，AnonRateThrottle是“throttle_anon_IP地址”。如果你只依赖这些默认实现，攻击者用代理池轮换IP打你的匿名接口，每个IP在窗口期内都能打满限额，限流就完全失效。你需要重写get_cache_key，把更多维度的信息编码进去。比如对于匿名请求，可以把IP和User-Agent拼接起来做哈希，或者更激进一点，把请求路径也加进去，让攻击者即使IP和UA相同，只要换一个URL就要重新计算限额。但要注意，缓存键的粒度太细会导致缓存条目激增，反而拖慢Redis性能，需要在安全性和性能之间找平衡。

下面是一个实际的复合键限流实现，它把IP、User-Agent和请求路径的前缀组合起来，对匿名用户进行更精准的限制：

from rest_framework.throttling import SimpleRateThrottle
import hashlib

class CompositeAnonRateThrottle(SimpleRateThrottle):
    scope = 'anon_composite'

    def get_cache_key(self, request, view):
        if request.user.is_authenticated:
            return None  # 已认证用户不触发此限流
        
        ident = self.get_ident(request)  # 默认取X-Forwarded-For最左端IP或REMOTE_ADDR
        ua = request.META.get('HTTP_USER_AGENT', '')
        path_prefix = request.path.split('/')[1] if len(request.path.split('/')) > 1 else 'root'
        
        raw_key = f"{ident}:{ua}:{path_prefix}"
        hashed_key = hashlib.sha256(raw_key.encode()).hexdigest()
        
        return self.cache_format % {
            'scope': self.scope,
            'ident': hashed_key
        }

这个实现做了三件事：获取客户端真实IP，拼接User-Agent，再取请求路径的第一段作为分组依据。这样做的好处是，同一个IP下不同浏览器的请求不会互相干扰，不同功能模块的API也有独立的限额。攻击者如果只换IP但UA不变，打同一个路径依然会被累计。如果你想更严格，可以把路径前缀改成完整路径，或者加入自定义的请求头指纹。注意这里用了SHA256哈希，避免缓存键过长，也防止原始信息泄露。

DRF默认的SimpleRateThrottle使用的是固定窗口算法，它记录的是从第一次请求开始的时间窗口内的请求次数。这种实现有个严重缺陷：窗口边界处的请求突发。比如限制每分钟100次，攻击者可以在第59秒发100次，下一秒窗口重置再发100次，实际两秒内打了200次。要缓解这个问题，可以改用滑动窗口或令牌桶算法。DRF没有内置滑动窗口，但你可以通过重写throttle_success和throttle_failure方法，结合Redis的Sorted Set来实现。思路是把每次请求的时间戳存入Sorted Set，每次判断时删除窗口外的记录，再统计剩余数量。令牌桶则更平滑，以恒定速率向桶中添加令牌，请求到达时消耗令牌，桶空则拒绝。这两种算法都能有效防止边界突发，但实现复杂度更高，需要权衡你的项目是否真的需要这种级别的平滑控制。

一个成熟的API系统不应该对所有用户一视同仁。付费用户、内部服务、普通访客的限流阈值应该不同。DRF允许你在视图或视图集上配置多个Throttle类，按顺序执行。你可以定义VIPUserRateThrottle、NormalUserRateThrottle和StrictAnonRateThrottle，然后在视图里这样配置：

from rest_framework.views import APIView
from rest_framework.throttling import UserRateThrottle

class MyAPIView(APIView):
    throttle_classes = [VIPUserRateThrottle, NormalUserRateThrottle, StrictAnonRateThrottle]

在VIPUserRateThrottle的allow_request里，先判断用户是否属于VIP分组，如果是就应用高限额，如果不是就返回None让下一个Throttle处理。返回None在DRF的限流逻辑中意味着“不适用”，框架会继续尝试下一个Throttle。这种链式处理让你可以构建非常灵活的分层限流体系。内部服务之间的调用可以用一个固定的服务账号，配置极高的限额甚至白名单，避免内部调用被误伤。

限流系统必须要有白名单能力，否则搜索引擎爬虫、健康检查探针、管理后台的操作都会被误限。你可以在自定义Throttle的allow_request方法开头就检查IP或用户是否在白名单中，直接返回True。白名单可以维护在Django的settings里，也可以存数据库并用缓存加速读取。更高级的做法是动态阈值调整：根据服务器实时负载自动收紧或放宽限流。比如在Django中集成一个中间件，监控每个视图的响应时间和错误率，当系统负载升高时，通过Redis发布阈值变更消息，Throttle类在每次判断时读取最新阈值。这种自适应限流能更智能地应对突发流量，但实现时要注意阈值变更的原子性和缓存一致性。

限流不能只靠后端。在Nginx层就可以用limit_req和limit_conn模块对IP和连接数做第一层限制，把明显异常的流量挡在应用服务器之外。DRF的Throttle应该作为第二层精细控制。前端方面，对于需要高频调用的接口，可以设计一个基于nonce的防重放机制，让每个请求携带一个一次性随机数，服务端用Redis记录已使用的nonce，配合短时间窗口的限流，能有效防止攻击者重放合法请求。另外，DRF的Throttle在返回429响应时，可以通过Retry-After头告诉客户端多久后可以重试，前端应该实现指数退避重试策略，避免在限流恢复瞬间又打出一波请求高峰。

限流策略上线后，如果没有监控，你根本不知道它是在正常工作还是误杀了一大片正常用户。DRF的Throttle在拒绝请求时只会返回429，不会主动记录详细日志。你需要在自定义Throttle的throttle_failure方法中增加日志输出，记录被限流的用户标识、请求路径、时间戳和当前计数。这些日志可以输出到文件，再由ELK或Loki收集分析。关键指标包括：每分钟429响应数量、被限流最多的接口TOP10、被限流用户的分布等。当429比例突然飙升时，可能是CC攻击正在发生，也可能是你的限流阈值设置不合理。告警规则可以设定为：某个接口的429比例连续5分钟超过20%，就触发通知。这样你就能在攻击造成实际影响前介入处理。

第一个误区是把限流阈值设得过高或过低。过高等于没限，过低影响正常用户。正确的做法是先分析线上实际流量，取P99的请求频率作为参考，再乘以一个安全系数。第二个误区是只限匿名不限认证用户。攻击者完全可以注册大量账号来打接口，所以认证用户的限流同样重要。第三个误区是使用Django的本地内存缓存做限流后端。在多进程部署环境下，每个进程维护独立的计数器，限流完全不准。必须使用Redis或Memcached这类集中式缓存。性能方面，每次请求都要读写Redis，高并发下Redis可能成为瓶颈。优化手段包括：使用Redis Pipeline批量操作、对缓存键设置合理的过期时间避免内存膨胀、在Nginx层用Lua脚本做第一层快速拦截减少打到Django的请求量。另外，DRF的Throttle列表是按顺序执行的，把最可能拦截大量请求的Throttle放在前面，能减少后续判断的开销。

限流防CC不是一劳永逸的配置，而是需要持续观察和调整的动态策略。DRF的Throttle体系提供了足够的扩展点，让你可以从简单的IP计数一路演进到基于用户行为指纹的智能限流。关键是理解每个扩展点的作用，根据自身业务特点组合使用，而不是照搬文档里的默认配置。