limit_rate_after 是 Nginx 1.19.10 引入的指令，用于在响应传输达到指定字节数后才开始应用 limit_rate 限速；低于该版本（如 1.18.x）不支持，配置会报“unknown directive”错误。
Limit-Rate-After 是什么，Nginx 版本要求有多高？
Limit-Rate-After 是 Nginx 1.19.10 引入的指令，用于在响应传输达到指定字节数后才开始应用 limit_rate 限速。它不是所有版本都支持——低于 1.19.10 的 Nginx（包括主流 LTS 版本如 1.18.x）压根不识别该指令，配置会直接报错：unknown directive "limit_rate_after"。
验证方法很简单：
nginx -v
若输出是 nginx version: nginx/1.18.0 或更早，必须升级；1.19.10+ 才能继续往下配。
如何正确配置 Limit-Rate-After 和 limit_rate 协同工作？
这两个指令必须成对出现，且只在 location 或 server 块中生效，不能写在 http 全局块里。典型用法是：前 10MB 不限速，之后限制为 512KB/s。
示例配置：
location /downloads/ {
alias /var/www/files/;
limit_rate_after 10m;
limit_rate 512k;
}
注意点：
-
limit_rate_after的单位支持k、m、g（大小写敏感，M无效），但不能写成10MB或带空格 -
limit_rate值为 0 表示不限速；设为1则实际限速约 1 字节/秒（几乎卡死） - 如果文件本身小于
limit_rate_after值（比如只下 5MB），则全程不限速 - 该机制作用于单个 HTTP 响应流，不跨请求累积（即每次下载独立计数）
为什么加了 Limit-Rate-After 却没生效？常见失效原因
最常踩的坑不是语法错，而是和其它模块冲突或隐式覆盖：
- 启用了
gzip或gunzip：压缩会改变响应体字节数，导致limit_rate_after计算基准错乱；建议在限速 location 中显式关闭：gzip off; - 使用了
proxy_pass：该指令仅对 Nginx 自身生成或本地文件响应有效；上游代理返回的内容不受limit_rate_after控制 - 被
limit_conn或limit_req拦截：限速逻辑在连接/请求限流之后执行，若请求已被拒绝，根本走不到这里 - 客户端断连重试：TCP 断开后新请求从头开始计数，不会“接着上次的 9.9MB 继续”
替代方案：旧版 Nginx 怎么模拟类似行为？
如果你卡在 1.18.x 无法升级，limit_rate_after 确实不可用，但可借助两个变通方式逼近效果：
- 用
map+$sent_http_content_length做粗略分流（仅适用于已知固定大小文件，且需提前知道文件尺寸） - 用 Lua 模块（OpenResty）在
body_filter_by_lua_block中动态统计已发送字节数，手动控制后续 chunk 的 sleep 时长——但这会显著增加 CPU 开销，且需维护额外逻辑
真正稳定、低侵入的做法还是升级 Nginx；1.19.10 已是 2021 年发布的版本，主流发行版源基本都已收录，编译或包管理升级都很直接。
别忽略单位大小写和 gzip 干扰——这两个点，八成的“配置写了没反应”都栽在这儿。
