Nginx不支持自动感知带宽的动态限速，仅提供limit_rate与limit_rate_after组合的静态限速；因其事件驱动架构不采集网卡吞吐、不运行拥塞控制，所有限速均为预设规则下的确定性行为，实测速率受系统缓冲和TCP窗口影响存在±15%浮动。
直接说结论：Nginx 本身不支持“自动根据当前带宽动态限速”，所谓“智能带宽适配”必须靠外部监控+脚本重载配置实现；真正能用的、开箱即用的，只有 limit_rate + limit_rate_after 这组静态限速指令。
为什么不能自动感知带宽？
Nginx 是一个事件驱动的反向代理/Web 服务器，它不采集网卡实时吞吐、不运行拥塞控制算法、也不与 TCP 栈联动做速率反馈。所有限速行为都是预设规则下的确定性响应——limit_rate 100k 就是每连接恒定约 100KB/s，不管此刻服务器带宽是 10Mbps 还是 1Gbps。
- 所谓“自适应限速”方案（如基于
tc+iptables+ Prometheus + 自定义脚本）本质是周期性读取/proc/net/dev或ethtool输出，再调用nginx -s reload切换不同limit_rate值，延迟高、有抖动、且 reload 会中断长连接 -
limit_rate的单位是字节/秒（不是 bit），且受系统 socket buffer、TCP window size、客户端接收能力影响，实测速率常有 ±15% 浮动，无法精确对齐物理带宽 - 没有模块能 hook 到每个 response 的实时发送速率并动态调整——Nginx 的设计哲学就是“配置即策略”，非运行时调控
limit_rate 和 limit_rate_after 怎么配才像“自动”？
虽然不能真自动，但通过组合这两个指令，可以模拟出接近用户体验友好的“先快后慢”效果，尤其适合大文件下载场景：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
limit_rate_after必须和limit_rate同时出现，否则无效；它只作用于 response body，header 不受限制 - 典型配置：
limit_rate_after 2m; limit_rate 500k;表示前 2MB 立即发，之后才压到 500KB/s，用户能秒开视频头或安装包校验段 - 注意单位：
500k= 500 × 1024 字节/秒 ≈ 488 KiB/s，不是 500 kbit/s；若要限 1Mbps 下行，得算成limit_rate 125k（1,000,000 ÷ 8 ÷ 1024 ≈ 122.07 → 向上取整） - 该配置必须放在
server或location块内，不能写在http顶层；对proxy_pass流量也生效——限的是 Nginx 到 client 的下行，不是 upstream 到 Nginx 的上行
容易被忽略的三个硬限制
即使配置写对了，以下三点仍会导致限速“失效”或“误判”：
- 多个并发连接绕过单连接限速：
limit_rate 100k对每个连接独立生效；客户端开 4 个线程下载，总速就变成 ≈400KB/s —— 要堵死这个口，得叠加limit_conn，例如limit_conn one 1;（需先定义limit_conn_zone $binary_remote_addr zone=one:10m;） - 静态文件走 Nginx 内置服务时，
limit_rate生效；但若走proxy_pass到后端（如 Python/Node.js），则限速发生在 Nginx 吐给 client 那一环，不影响后端处理速度，后端仍可能被打满 -
sendfile on开启时，Linux kernel 直接从磁盘 DMA 到 socket buffer，limit_rate可能因 bypass 用户态缓冲而表现不稳定；可加sendfile_max_chunk 512k;强制分块，让限速更可控
真正难的不是敲出那两行配置，而是想清楚：你到底想控的是单个下载连接的体验（用 limit_rate），还是防多线程薅带宽（必须配 limit_conn），又或者想保后端不被压垮（该上 limit_req 控请求频次）。三者混用时，生效顺序是 limit_conn → limit_req → limit_rate，但它们互不感知——比如 limit_conn 拒掉连接后，limit_rate 根本没机会执行。
