nginx限流需分清limit_req（控请求数）、limit_conn（控并发连接数）、limit_rate（控响应速度）三者机制不同、生效时机与配置位置各异，混用易导致请求失败。

直接说结论：Nginx限流不是“开个开关”就完事，必须分清是控请求数（limit_req）、控并发连接数（limit_conn），还是控响应下载速度（limit_rate）——三者机制不同、生效时机不同、配置位置也不同，混用会相互干扰甚至导致请求失败。

怎么配 limit_req 才不卡住用户？

这是最常用也最容易翻车的限流方式，核心是令牌桶算法：每秒按 rate 填充令牌，请求来时取一个；没令牌就排队（burst）或直接拒（加 nodelay）。

• burst 不是“允许超速”，而是“最多能缓存几个等处理”，比如 burst=10 意味着第 11 个超速请求才会被拒绝，但前 10 个仍要排队等令牌释放
• 不加 nodelay 时，排队请求会被延迟转发，用户感知就是“卡顿”甚至超时；加了 nodelay 就变成“有令牌立刻放行，没令牌立刻 503”，更接近硬限流
• rate 单位支持 r/s（每秒）和 r/m（每分钟），但注意 1r/m ≠ “每分钟只让过 1 个”，而是“平均每 60 秒 1 个”，实际可能集中在某几秒爆发
• 测试时别用 curl 单次发多个请求，要用 ab -c10 -n100 或 wrk 模拟真实并发，否则看不出 burst 效果

limit_conn 为什么有时完全不起作用？

这个模块限制的是 TCP 连接数，不是 HTTP 请求。它只在 Nginx 完成 request header 解析、准备把请求交给 upstream 时才计数，所以静态文件（如图片、CSS）走 Nginx 自身服务时，limit_conn 是不生效的。

• 必须搭配 limit_conn_zone 使用，且 key 推荐用 $binary_remote_addr（比 $remote_addr 节省内存）
• limit_conn addr 10 表示“每个 IP 最多 10 个并发连接”，但若后端响应慢（比如数据库卡住），这些连接会长时间占用，新请求就会被挂起甚至超时
• 如果同时配了 limit_rate（比如限速 1k），而连接又卡在慢响应上，会导致后续请求因连接数满而直接失败，现象是大量 503 或连接超时，而不是限速提示
• 日志里查不到连接拒绝记录，默认不打日志；要看到效果得加 limit_conn_log_level error;

limit_rate 和 limit_rate_after 怎么配合防“薅羊毛”？

这两个指令专治大文件下载场景，比如视频、安装包。单纯 limit_rate 50k 会让所有请求从头开始就慢，体验差；加 limit_rate_after 就能“先快后慢”。

• limit_rate_after 1m 表示前 1MB 不限速，之后才启用 limit_rate 限速，适合让用户快速预览开头
• 该指令只对 response body 生效，header 部分不受影响；也不影响 upstream 的处理速度，只是 Nginx 向客户端吐数据变慢
• 注意单位：limit_rate 100k 是每秒约 100KB，不是 100KiB；实测中受系统缓冲区、TCP 窗口大小影响，实际速率会有浮动
• 不能放在 http 块顶层，必须在 server 或 location 里，且对 proxy_pass 流量也生效（即限的是 Nginx 到 client 的下行带宽）

真正难的不是写对这几行配置，而是搞清你到底想拦什么：是防爬虫高频刷接口（limit_req），还是防慢速攻击耗尽连接（limit_conn），或是控制带宽成本（limit_rate）。三者叠加时，务必验证它们的生效顺序和冲突点——比如 limit_conn 拒绝了连接，limit_req 根本就没机会运行。