Flask接口限流防CC攻击防护配置

Flask默认的开发服务器和多数同步部署方式对客户端请求频率几乎不设防，单个IP可以在短时间内发起大量请求，轻则消耗服务器资源，重则直接导致正常用户无法访问。接口限流的核心不是“拦截所有高频请求”，而是识别异常流量模式，在保障正常用户体验的前提下，把恶意请求挡在业务逻辑之前。针对CC攻击，Flask本身没有内置限流模块，但可以通过扩展和中间件实现多层防护。

做接口限流首先要确定“以什么维度计数”。最常用的是客户端IP，但在存在反向代理的情况下，必须正确获取真实IP，否则所有请求都会被识别成代理服务器地址，导致限流误伤或完全失效。获取真实IP需要信任代理层传递的X-Forwarded-For头，同时要防止客户端伪造该头。建议在Nginx层统一处理真实IP，再通过X-Real-IP或自定义头传给Flask。限流计数存储可以选内存、Redis或Memcached。单进程部署时内存计数器最简单，但多进程或多实例部署必须使用Redis这类集中式存储，否则各进程各自计数，限流形同虚设。

Flask-Limiter是目前Flask生态中最成熟的限流扩展，底层基于limits库，支持多种存储后端。安装后基础配置如下：

from flask import Flask
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address

app = Flask(__name__)

limiter = Limiter(
    key_func=get_remote_address,
    default_limits=["200 per day", "50 per hour"],
    storage_uri="redis://localhost:6379/0",
    strategy="fixed-window"
)

这里的key_func决定了限流维度，get_remote_address会从请求的remote_addr取值，如果前面有代理，需要替换成从X-Forwarded-For中提取真实IP的函数。default_limits是全局默认限制，可以写多个规则，单位支持秒、分、时、天，也支持更细的写法如“5 per second”。storage_uri指向Redis时，所有计数器集中存储，多进程部署不会出现计数漂移。strategy可选fixed-window或moving-window，fixed-window实现简单但存在边界突发问题，moving-window更平滑但消耗更多存储和计算资源，高并发接口建议用moving-window。

全局默认限制只能做粗粒度防护，实际业务中不同接口的敏感度和资源消耗差异很大。登录接口、短信发送接口、文件上传接口需要更严格的限制，而普通查询接口可以放宽。Flask-Limiter支持装饰器方式对单个路由设置限流：

@app.route("/login", methods=["POST"])
@limiter.limit("5 per minute")
def login():
    # 登录逻辑
    pass

如果限流规则需要根据用户身份或业务参数动态变化，可以使用limit_value参数传入可调用对象。例如对VIP用户放宽限制，对普通用户收紧：

def get_limit_for_user():
    user = get_current_user()
    if user and user.is_vip:
        return "100 per minute"
    return "20 per minute"

@app.route("/api/action")
@limiter.limit(get_limit_for_user)
def api_action():
    pass

动态规则让限流从“一刀切”变成可运营的策略，但要注意可调用对象本身不能有高延迟操作，否则每个请求都会在限流判断阶段被拖慢。

CC攻击的特点是请求量大、请求路径集中、往往绕过静态资源缓存直接打动态接口。单纯设置“每分钟N次”的固定阈值不够灵活，攻击者可以用大量代理IP分散请求，每个IP都不触发阈值，但整体流量仍然压垮服务。应对CC攻击需要组合策略：第一层是IP级限流，阈值设置得相对宽松，避免误伤正常用户；第二层是接口级限流，对高消耗接口设置独立阈值；第三层是全局并发或总请求速率限制，防止攻击者用海量IP稀释单IP计数。

Flask-Limiter支持对同一接口叠加多个限流规则，例如同时限制单IP和全局：

@app.route("/api/search")
@limiter.limit("10 per minute", key_func=get_remote_address)
@limiter.limit("1000 per minute", key_func=lambda: "global")
def search():
    pass

这种组合方式下，单个IP超过10次每分钟会被拦截，同时全局超过1000次每分钟也会触发限流，即使攻击者使用大量不同IP也无法突破全局阈值。全局限流的key_func返回固定字符串，意味着所有请求共享同一个计数器。

默认情况下Flask-Limiter触发限流会返回429状态码和一段简单的错误文本。对用户来说，直接返回429可能不够友好，对API调用方来说，缺少明确的限流信息会增加调试成本。建议自定义限流响应，在响应头中加入剩余配额和重置时间：

from flask import jsonify

@app.errorhandler(429)
def ratelimit_handler(e):
    return jsonify({
        "code": 429,
        "message": "请求过于频繁，请稍后再试",
        "retry_after": e.description
    }), 429

Flask-Limiter在触发限流时会把重试等待时间放在异常的description中，自定义处理器可以读取这个值，通过Retry-After响应头或JSON字段返回给客户端。对于Web页面，可以返回一个带有倒计时提示的HTML页面，而不是冷冰冰的JSON。

把限流全部放在Flask层有一个明显缺点：恶意请求已经到达了应用进程，消耗了Python解释器的资源。更优的做法是在Nginx层先做第一道限流，把明显异常的流量直接拒绝在应用之外。Nginx的limit_req模块基于漏桶算法，配置简单且性能极高：

http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=2r/s;

    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
            proxy_pass http://flask_backend;
        }

        location /login {
            limit_req zone=login_limit burst=5 nodelay;
            proxy_pass http://flask_backend;
        }
    }
}

limit_req_zone定义了限流区域和速率，rate=10r/s表示每秒允许10个请求。burst参数允许突发流量，nodelay表示突发请求立即处理而不是排队等待。这种配置下，正常用户偶尔的突发请求不会被误伤，但持续高频的请求会被直接返回503。Nginx层限流的优势在于不占用应用资源，单台Nginx可以轻松处理数万并发连接，是抵御CC攻击的第一道有效屏障。

使用Redis作为限流计数器存储时，键的设计直接影响内存占用和清理效率。Flask-Limiter默认会为每个限流规则和每个key创建独立的Redis键，键名包含规则标识和时间窗口信息。在高并发场景下，如果限流维度很多，Redis中的键数量会快速增长。建议在Redis配置中设置合理的maxmemory和淘汰策略，避免限流计数器占满内存。同时，限流计数器的过期时间必须与时间窗口匹配，否则会出现计数不重置的问题。Flask-Limiter会自动设置键的过期时间，但使用自定义存储或手动实现计数器时，务必确保每个时间窗口结束后计数器能够自动清零。

限流策略不能只有“限制”而没有“放行”。内部服务调用、健康检查、管理后台等场景需要绕过限流。Flask-Limiter支持通过装饰器或条件函数实现白名单：

def is_whitelisted():
    ip = get_real_ip()
    return ip in WHITELIST_IPS

@app.route("/api/internal")
@limiter.limit("1000 per minute", exempt_when=is_whitelisted)
def internal_api():
    pass

exempt_when接收一个返回布尔值的函数，当返回True时跳过限流。黑名单则相反，对已知恶意IP直接拒绝，不进入限流计数逻辑。黑名单可以放在Nginx层通过deny指令实现，也可以在Flask中间件中检查。对于动态更新的黑名单，建议存储在Redis中，Flask请求进入时先查询黑名单，命中则直接返回403，避免恶意请求继续消耗限流计数器和业务逻辑资源。

限流配置上线后不是一劳永逸的。阈值设置过高会导致防护失效，设置过低会误伤正常用户。需要监控限流触发次数、被限流的IP分布、限流触发的接口分布等指标。Flask-Limiter提供了事件钩子，可以在限流触发时记录日志或发送告警：

from flask_limiter import Limiter

limiter = Limiter(key_func=get_remote_address)

@limiter.request_filter
def log_ratelimit():
    # 记录限流触发事件
    app.logger.warning("Rate limit triggered for IP: %s", get_real_ip())

通过对限流日志的分析，可以发现攻击模式的变化，例如攻击者是否在切换IP段、是否在调整攻击目标接口。基于这些数据可以动态调整阈值和策略，而不是等用户投诉后才被动响应。对于生产环境，建议将限流事件接入统一的监控系统，设置触发频率告警，当限流次数在短时间内异常升高时，可能意味着正在遭受CC攻击，需要人工介入。

很多开发者在配置限流时只关注“限制”本身，忽略了真实IP获取的准确性。如果Nginx没有正确配置X-Forwarded-For的传递和信任，Flask中的remote_addr可能永远是127.0.0.1，导致所有用户共享同一个计数器，正常用户会被大量误伤。另一个常见问题是把限流阈值设置得过于严格，比如登录接口限制“3次每分钟”，用户输错两次密码后第三次就被锁死，体验极差。合理的做法是区分“尝试频率”和“锁定策略”，限流只控制请求频率，账户锁定由业务逻辑处理。此外，限流计数器本身也有性能开销，尤其是在使用moving-window策略时，每次请求都需要操作多个Redis键，高并发下可能成为新的瓶颈。对于超高并发接口，优先考虑Nginx层限流，Flask层限流作为补充。

Flask接口限流防CC攻击的配置不是单一工具能完成的，需要Nginx前置限流、Flask-Limiter应用层限流、Redis集中存储、白名单黑名单、监控告警共同配合。核心思路是分层防护，把异常流量在尽可能靠近入口的位置拦截掉，同时保证正常用户的请求不受影响。限流阈值的设定需要结合业务实际流量模型，通过监控数据持续调整，而不是照搬某个固定数值。