Nginx防爬虫实战：手把手教你配置IP访问频率限制（附常见问题排查）

最近在维护一个内容型网站时，我发现服务器时不时会出现响应变慢甚至短暂无响应的情况。查看服务器监控，CPU和内存占用并不高，但网络连接数却异常飙升。打开Nginx的访问日志，一眼就看到了问题所在：有几个IP地址在短时间内疯狂请求同一个API接口，频率高得吓人，有的甚至达到了每秒上百次。这明显是自动化脚本在“扫荡”数据，如果不加以限制，不仅浪费服务器资源，还可能影响正常用户的访问体验。

对于中小型网站的运维人员来说，这种场景应该不陌生。我们可能没有大厂那种复杂的分布式限流系统，但利用Nginx自带的limit_req模块，完全可以构建一道有效的防线，将那些过于“热情”的爬虫或恶意请求挡在门外。这篇文章，我就结合自己的踩坑经验，从最基础的配置讲起，带你一步步搭建起IP访问频率限制，并分享几个实际排查中容易遇到的问题和解决方法。

1. 理解Nginx限流模块：不只是简单的“开关”

在开始动手配置之前，我们得先搞清楚Nginx是怎么实现限流的。很多人以为限流就是个简单的“每秒最多多少次”的开关，其实背后的机制要精巧得多。Nginx主要提供了两个模块来处理连接和请求的限制：ngx_http_limit_conn_module（限制并发连接数）和ngx_http_limit_req_module（限制请求处理速率）。我们今天重点要用的是后者。

limit_req模块实现的是经典的漏桶算法（Leaky Bucket）。你可以想象一个底部有洞的水桶，无论上方水流（请求）多么湍急、不均匀，从桶底流出的水（被处理的请求）速率都是均匀、恒定的。如果进水的速度超过了出水口的能力，水桶就会慢慢蓄满，后续的水就会溢出（请求被拒绝）。这个比喻能帮你理解几个核心概念：

  • rate（速率）：就是桶底出水口的恒定流速，比如 10r/s（每秒10个请求）。
  • zone（存储区）：相当于记录每个IP当前桶里有多少“水”的内存空间。Nginx需要在内存中跟踪每个客户端的请求状态。
  • burst（突发容量）：可以理解为在水桶上方加的一个小缓冲区。当瞬间有大量请求涌入时，这个缓冲区能暂时容纳超出rate的请求，而不是立即拒绝，让处理显得更“平滑”。

为什么不用更简单的计数器呢？因为漏桶算法能很好地应对突发流量，避免对正常的、短暂的流量高峰进行“误杀”。比如，一个用户快速刷新几下页面，产生了几次连续的请求，如果使用严格的计数器，可能第二次请求就被拒绝了，体验很差。而漏桶算法允许一定的突发（通过burst），只要长期平均速率不超过限制即可。

这里有一个简单的对比，帮助你理解不同算法的区别：

算法类型核心思想优点缺点适用场景
固定窗口计数器在固定时间窗口（如1秒）内计数，超限则拒绝。实现简单，内存消耗低。临界时间点问题：在窗口切换的瞬间，可能承受两倍于阈值的请求。对精度要求不高的简单场景。
滑动窗口计数器记录最近一段时间内每个小时间片的请求，动态计算。比固定窗口更平滑，精度高。实现相对复杂，需要存储更多时间片数据。需要精确控制速率的API网关。
漏桶算法 (Nginx limit_req)以恒定速率处理请求，超出速率的请求排队或丢弃。输出流量绝对平滑，能处理一定突发。无法应对突发流量（除非设burst），请求可能有延迟。保护下游服务，确保其处理速率稳定。
令牌桶算法系统以恒定速率生成令牌，请求需获取令牌才能被处理。既能限制平均速率，又能允许一定程度的突发。实现比漏桶稍复杂。需要限制平均速率但允许突发的场景，如网络流量整形。

Nginx的limit_req模块在标准漏桶算法上，通过burst和nodelay参数做了实用化的改进，使其更贴合Web服务器的实际需求。

提示：limit_conn模块限制的是并发连接数，即同一时刻来自同一IP的活跃TCP连接数。它常用于防止单个客户端打开过多连接耗尽服务器资源，与limit_req限制请求速率的目标不同，两者可以配合使用。

2. 基础配置实战：从零搭建你的第一道防线

理论说得再多，不如动手配一遍。我们从一个最常见的场景开始：为网站所有页面设置一个全局的、基础的请求频率限制。

配置的核心是两条指令：limit_req_zone 和 limit_req。前者在http块中定义限制规则和存储空间，后者在server或location块中应用这些规则。

首先，打开你的Nginx配置文件（通常是 /etc/nginx/nginx.conf 或 /usr/local/nginx/conf/nginx.conf），在 http { 块内添加如下内容：

http {
    # 其他现有配置...

    # 定义限制区域，命名为 per_ip，分配10MB内存，限制平均速率为每秒5个请求
    limit_req_zone $binary_remote_addr zone=per_ip:10m rate=5r/s;

    # 可选：自定义被限制时的返回状态码，默认是503
    limit_req_status 429; # 使用429 Too Many Requests 更符合语义

    server {
        listen 80;
        server_name yourdomain.com;

        location / {
            # 应用名为 per_ip 的限制规则
            # burst=10 表示允许10个请求的突发缓冲
            # nodelay 表示对超过 (rate + burst) 的请求立即返回429，不延迟处理
            limit_req zone=per_ip burst=10 nodelay;

            # 你的其他代理或root配置
            proxy_pass http://backend_server;
            # 或 root /var/www/html;
        }
    }
}

让我拆解一下这几行配置的含义：

  1. limit_req_zone $binary_remote_addr zone=per_ip:10m rate=5r/s;

    • $binary_remote_addr：这是关键变量，它代表了客户端的IP地址（二进制格式，比字符串节省空间）。Nginx就是通过这个变量来区分不同客户端的。
    • zone=per_ip:10m：我们在共享内存中开辟一个名为 per_ip 的区域，大小为10MB。根据经验，1MB大约可以存储1.6万个IP的状态信息，10MB对于大多数中小网站来说足够了。
    • rate=5r/s：限制每个IP的平均请求速率为每秒5次。你也可以用 r/m（每分钟），例如 rate=300r/m。

  2. limit_req zone=per_ip burst=10 nodelay;

    • zone=per_ip：引用上面定义的规则。
    • burst=10：这是突发缓冲容量。假设一个IP在某一瞬间（比如0.1秒内）同时发来了15个请求。前5个（rate）会立即被处理，接下来的10个（burst）会被放入队列等待处理（如果没设nodelay），而第16个及以后的请求会立刻被拒绝（返回429）。如果没有burst，那么第6个请求就会被拒。
    • nodelay：这个参数需要和burst一起理解。如果不设置nodelay，那么超出rate但仍在burst范围内的请求，会被延迟处理，以严格遵守平均速率。例如，rate=5r/s，来了10个请求，前5个立刻处理，后5个会在接下来的1秒内（每秒5个）被处理完。如果设置了nodelay，那么只要请求数不超过 rate + burst（本例是5+10=15），所有请求都会立即被处理，但会消耗掉burst的额度。消耗的burst额度会以rate指定的速度慢慢恢复。nodelay适用于希望快速响应正常用户突发请求，同时又能严厉惩罚恶意高频请求的场景。

配置完成后，保存文件，记得测试配置语法并重载Nginx：

sudo nginx -t  # 测试配置文件语法
sudo nginx -s reload  # 或 systemctl reload nginx

现在，你可以用 ab（Apache Benchmark）或 wrk 工具简单测试一下效果：

# 从同一台机器测试，注意这会把自己IP限制住
ab -n 100 -c 20 http://yourdomain.com/

观察返回结果，应该会有一部分请求收到 429 状态码。查看Nginx错误日志（/var/log/nginx/error.log），也能看到类似 limiting requests, excess:5.xxx by zone "per_ip" 的条目，说明限流规则生效了。

3. 精细化控制：应对复杂场景的高级配置策略

全局统一的限流策略虽然简单，但往往不够用。一个电商网站，对首页的访问频率和对下单接口的访问频率要求能一样吗？搜索引擎爬虫和恶意爬虫能一视同仁吗？这就需要更精细化的配置。

3.1 针对不同路径（Location）设置不同限流策略

这是最常见的需求。我们可以为静态资源、API接口、管理后台等设置不同的限制。

http {
    limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=api:10m rate=2r/s;
    limit_req_zone $binary_remote_addr zone=admin:10m rate=1r/s;

    server {
        listen 80;
        server_name yourdomain.com;

        # 静态资源，限制宽松一些
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            limit_req zone=general burst=20 nodelay;
            expires 7d; # 设置缓存
            access_log off; # 可选：关闭日志减少压力
            # ... 其他静态文件配置
        }

        # 核心API接口，限制严格
        location /api/v1/ {
            limit_req zone=api burst=5 nodelay;
            limit_req_status 429;
            # 建议记录被限制的日志，便于分析
            error_log /var/log/nginx/api_limit.log warn;
            proxy_pass http://api_backend;
        }

        # 管理后台，限制非常严格
        location /admin/ {
            limit_req zone=admin burst=3;
            # 这里没设nodelay，超出速率的请求会被延迟，适合管理操作
            auth_basic "Admin Area";
            auth_basic_user_file /etc/nginx/.htpasswd;
            proxy_pass http://admin_backend;
        }

        # 网站其他页面
        location / {
            limit_req zone=general burst=15 nodelay;
            proxy_pass http://web_backend;
        }
    }
}

3.2 设置白名单，避免“误伤”关键IP

把公司办公室IP、监控系统IP、自己家的IP或者可信的合作伙伴IP加入白名单，让它们不受限流规则影响，至关重要。Nginx本身没有直接的limit_req_whitelist指令（某些扩展如Tengine有），但我们可以通过 geo 和 map 指令组合实现。

http {
    # 第一步：使用geo模块定义白名单IP段，$limited变量对白名单IP返回0，其他返回1
    geo $limited {
        default 1; # 默认值，表示受限
        # 白名单IP或网段
        192.168.1.0/24 0; # 办公室内网
        10.0.0.100 0;     # 监控服务器
        123.456.78.90 0;   # 你家IP（示例，请替换）
        # 可以继续添加
    }

    # 第二步：使用map模块，将白名单IP的限流key映射为空字符串
    # Nginx对空字符串的key不会进行限流计数
    map $limited $limit_key {
        1 $binary_remote_addr; # 受限IP，使用其IP作为限流key
        0 "";                   # 白名单IP，key为空，不限流
    }

    # 第三步：定义限流zone时，使用map后的$limit_key变量
    limit_req_zone $limit_key zone=protected:10m rate=5r/s;

    server {
        location / {
            limit_req zone=protected burst=10 nodelay;
            # ... 其他配置
        }
    }
}

这个配置的精妙之处在于，对于白名单IP（$limited为0），$limit_key是空字符串。当limit_req_zone的key为空时，Nginx不会为这个请求创建计数条目，因此也就不会触发限流。这是一个非常经典且实用的技巧。

3.3 基于请求属性组合限流（简单指纹）

更高级的防御可以结合更多维度。例如，有些恶意请求会更换IP，但User-Agent很固定。我们可以尝试将IP和User-Agent结合起来作为限流的key，增加攻击成本。

http {
    # 将IP和User-Agent的MD5哈希值组合作为key
    # 注意：$http_user_agent可能被伪造，但这能增加一点门槛
    limit_req_zone $binary_remote_addr$http_user_agent zone=combo:10m rate=10r/s;

    # 或者，只对特定的可疑User-Agent（如一些爬虫框架）进行更严格的限制
    map $http_user_agent $is_aggresive_crawler {
        default 0;
        "~*python-requests|scrapy|curl|wget|Go-http-client" 1; # 示例，请根据实际情况调整
    }

    limit_req_zone $binary_remote_addr zone=normal:10m rate=20r/s;
    limit_req_zone $binary_remote_addr zone=strict:10m rate=2r/s;

    server {
        location / {
            # 根据User-Agent选择不同的限流zone
            if ($is_aggresive_crawler) {
                set $limit_zone strict;
            }
            if ($is_aggresive_crawler = 0) {
                set $limit_zone normal;
            }
            limit_req zone=$limit_zone burst=5 nodelay;
            # ... 其他配置
        }
    }
}

注意：使用 if 指令在 location 中需要格外小心，因为它可能会破坏请求处理的某些阶段。上述用法在设置变量时通常是安全的，但在处理重写或返回时容易出问题。对于生产环境，更推荐使用 map 指令直接映射出最终的 zone 名称，或者使用 limit_req_dry_run 指令（Nginx 1.19.3+）进行调试。

4. 问题排查与性能优化：让限流规则稳定可靠

配置上线后，事情还没完。你可能会遇到一些意想不到的问题，比如误拦截了正常用户，或者限流规则没生效。下面是一些常见的排查思路和优化建议。

4.1 常见问题排查

问题一：为什么我的限流规则好像没生效？

  1. 检查配置作用域：确认 limit_req 指令是放在你期望的 server 或 location 块里。一个常见的错误是放在了 http 块但被 server 块内的其他规则覆盖或忽略了。
  2. 检查变量：确保 limit_req_zone 里用的 key 变量（如 $binary_remote_addr）能正确获取到值。如果网站前面有CDN或负载均衡器，客户端的真实IP可能藏在 X-Forwarded-For 或 X-Real-IP 这样的HTTP头里。这时你需要用 $http_x_forwarded_for 或 $http_x_real_ip 来提取，但要注意安全性和格式处理。
    # 示例：从X-Forwarded-For中取第一个IP作为客户端IP（需评估信任你的代理链）
map $http_x_forwarded_for $real_client_ip {
    ~^([^,]+) $1;
    default $binary_remote_addr;
}
limit_req_zone $real_client_ip zone=per_ip:10m rate=5r/s;
  3. 查看错误日志：Nginx的error日志（级别设为 warn 或 info）会记录限流触发的详细信息。使用 tail -f /var/log/nginx/error.log 观察请求时是否有相关日志输出。
  4. 测试方法：用工具模拟高频请求，并检查返回状态码。确保你测试的请求路径确实经过了配置限流的 location。

问题二：正常用户被误拦截了怎么办？

  1. 检查 burst 和 nodelay：burst 设置是否太小？对于有少量突发请求的正常页面浏览（如快速点击多个标签），一个适中的 burst（比如10-20）配合 nodelay 可以改善体验。
  2. 检查 rate 值：全局 rate 是否设得太严格？对于内容站，rate=1r/s可能就太低了。可以从一个较宽松的值开始（如 10r/s），根据监控逐步调整。
  3. 区分流量：这是最重要的。使用前面提到的白名单机制，把已知的正常流量源（如公司IP、搜索引擎IP段）排除。对于API，考虑引入用户认证，对认证用户和匿名用户采用不同的限流策略。
  4. 分析日志：收集被返回429状态码的请求日志，分析其IP、User-Agent、访问路径。看看是真正的恶意爬虫，还是某个搜索引擎的友好爬虫，或者是某个行为特殊的合法用户（例如，用户在页面卡住时疯狂刷新）。

问题三：zone 内存大小 (10m) 应该设多少？

  • 1MB内存大约能记录1.6万个独立IP的状态（64位系统下）。计算公式可以近似为：存储IP数 ≈ 内存大小(MB) * 16000。
  • 你需要估算同时可能有多少个独立IP访问你的服务。对于中小网站，10m（约16万IP）通常绰绰有余。如果担心不够，可以适当增大，比如 50m。监控Nginx的内存使用情况即可。
  • 可以使用 ngx_http_limit_req_module 模块提供的状态信息（如果编译时带有 --with-http_stub_status_module 或 --with-http_api_module）来查看zone的使用情况，但通常直接看内存占用更直观。

4.2 性能优化与监控

限流本身会消耗一定的CPU和内存资源，尤其是在高并发下。以下几点有助于优化：

  • Key的选择：$binary_remote_addr（二进制IP）比 $remote_addr（字符串IP）更节省空间，性能更好。
  • Zone的分配：不要过度分配内存。根据预估的独立客户端数量设置合理的zone大小。
  • 日志级别：将 limit_req_log_level 设置为 error 而不是默认的 warn，可以减少日志量，除非你在调试阶段。
    http {
    limit_req_log_level error;
    # ... 其他配置
}
  • 状态监控：除了看Nginx错误日志，还应该将429状态码纳入你的业务监控（如Prometheus + Grafana）。建立一个仪表盘，观察429状态码的速率和来源IP分布，这能帮你及时发现新的攻击模式或调整不合理的限流阈值。

最后，任何限流策略在上线前，一定要在测试环境充分验证。可以用不同的IP段模拟正常用户和恶意爬虫的访问模式，观察限流效果和对正常服务的影响。配置的调整也是一个持续的过程，需要结合实际的访问日志和监控数据不断迭代。

Logo
天工造物局

北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台

更多推荐

graphify 视频音视频转写全流程解析：从 detect 结果到知识图谱文档的 Step 2.5

graphify 的核心能力是把任意语料（代码、文档、PDF、图片）转化为可查询的知识图谱，而视频与音频文件无法被直接阅读，必须先把它们转写成文本。本文围绕 `graphify` 运行手册中的转写参考文档 [transcribe.md](https://link.gitcode.com/i/d3285781588e0f1b84886dfdbc4fe7f6)，完整讲解 "Step 2.5 - Tra

avatar 天工造物局

ML-For-Beginners 终章：经典机器学习在金融、医疗、零售等八大行业中的真实落地场景

本篇技术指南基于开源课程仓库 ML-For-Beginners 的收尾课程《Postscript: Machine learning in the real world》（对应仓库目录 [9-Real-World/1-Applications](https://link.gitcode.com/i/6b23002df80861c20abf34d7db63ef41)）编写。该课此前 11 周的教学带

avatar 天工造物局

graphify 知识图谱查询实战：query / path / explain 与可审计的答案闭环

本指南以 graphify 的 Trae 版查询技能参考（[graphify/skills/trae/references/query.md](https://link.gitcode.com/i/72a7875d46ec6d3706d31791f3cdcbe0)）为主体，系统讲解如何针对**已构建好的知识图谱**执行三类查询：语义相关节点遍历（query）、两概念间最短路径（path）、单节点关

avatar 天工造物局