服务器被恶意爬虫或高频请求拖慢，通常不一定要先上复杂网关或额外防护组件。对大多数站点来说，先把 Nginx 自带的 ngx_http_limit_req_module 用起来，就能较低成本地挡住一批明显异常的请求，并把服务压力控制在可接受范围内。
这篇文章按实际部署顺序来讲：先确认环境和配置文件位置，再给出一段可直接套用的限频配置，接着解释几个最关键的参数，最后补充测试方法和常见优化方向。看完后，你可以判断自己该把限流设到多严、哪些参数该优先调。
为什么要在 Nginx 层做访问限频
当站点遇到恶意爬虫、接口被刷，或者短时间内出现异常高频访问时，最先被打满的往往不是业务逻辑，而是入口层连接、转发和后端资源。把限频放在 Nginx 层处理，有几个直接好处：
- 拦截更靠前，能更早减少无效请求进入应用层。
- 配置简单，性能开销小，适合作为基础防护手段。
- 可以按客户端标识控制速率，便于针对常见流量模型做限制。
本文使用的核心模块是 ngx_http_limit_req_module，它的作用可以理解为给请求入口加一个速率阀门。
先确认 Nginx 已安装并找到配置文件
如果服务器还没有安装 Nginx，可以先执行下面两条命令：
sudo apt update
sudo apt install nginx配置文件通常有两个常见位置：
- 主配置文件：
/etc/nginx/nginx.conf - 更常编辑的虚拟主机配置：
/etc/nginx/sites-a vailable/default
如果你准备直接改默认站点配置，可以打开对应文件：
sudo nano /etc/nginx/sites-a vailable/default这里有一个关键点需要先记住：limit_req_zone 要定义在 http 块内；而 limit_req 一般放在 server 或 location 里实际启用。
一套可直接使用的 Nginx 限频配置
下面这段配置可以作为基础模板使用：
http {
# 其他配置...
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
server {
listen 80;
server_name example.com;
location / {
limit_req zone=mylimit burst=5 nodelay;
# 其他location配置...
}
}
}这段配置的逻辑并不复杂：
- 先用
limit_req_zone定义一个限流区域和速率规则。 - 再在具体的
location中通过limit_req引用它。 - 请求没有超出限制时正常通过，超过限制时会被 Nginx 拦截。
`limit_req_zone` 在做什么
这一行配置：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;可以拆成三部分理解：
$binary_remote_addr：用客户端 IP 作为请求识别标识。zone=mylimit:10m：定义一个名为mylimit的共享内存区域，大小为10m。rate=1r/s：设置速率上限为每秒1个请求。
如果你的业务更适合按分钟控制，也可以把速率改成 60r/m，表示每分钟最多 60 个请求。
`burst` 和 `nodelay` 应该怎么理解
实际生效的是这一行：
limit_req zone=mylimit burst=5 nodelay;它的意思是：
zone=mylimit：引用前面定义好的限流区域。burst=5：允许瞬时突发5个请求。nodelay：这些突发请求不排队、不延迟，直接放行。
在这个配置下，超过基础速率的少量突发流量还有缓冲空间，但一旦超过 burst=5 的额度，请求就会被拒绝，通常返回 503。这也是为什么调参数时不能只看防护强度，还要考虑正常用户的短时点击、页面资源并发加载和接口突发访问。
测试配置并让规则生效
改完配置后，不要直接重启，先测试语法：
sudo nginx -t
sudo systemctl reload nginxsudo nginx -t 用来检查配置是否有语法错误，确认通过后，再执行 sudo systemctl reload nginx 平滑加载新配置。这样做的好处是能尽量避免因为配置写错导致服务中断。
生效后，可以根据站点实际压力调整两个最常用的参数：
rate：控制长期平均速率。burst：控制可容忍的短时突发量。
如果你发现正常用户也经常被误伤，通常优先检查是否把 rate 设得过低，或者 burst 设得过小。
进一步优化：差异化限流与日志记录
基础按 IP 限流能解决很多问题，但在接口服务、开放平台或多租户场景里，往往还需要更细的控制。
基于 API Key 做更细的限制
如果需要针对不同调用方做差异化限流，比如同一出口 IP 下有多个合法客户端，单纯依赖 $binary_remote_addr 就不够了。这时可以考虑配合 ngx_http_auth_request_module 和外部认证服务，根据 API Key 或身份信息做更细粒度的策略控制。
建议开启限流日志
限流规则上线后，最好不要只看服务有没有变稳，还要知道谁被拦了、拦了多少、是否误伤正常请求。为此可以增加 limit_req_log_level 指令，把限流相关事件写入日志，便于后续监控和排查问题。
对于大多数中小型站点，这套方案已经足够作为第一层防护。它上手快、成本低，关键在于参数不要照抄，要根据访问模式去调，最终在防攻击能力和正常用户体验之间找到合适平衡。
