limit_rate + limit_rate_after 是唯一开箱可用的单ip带宽限制方案，但按连接限速而非ip总带宽，多连接可绕过；nginx无ip级带宽聚合能力，二者须同作用域配置，限速单位为字节/秒，实测有±15%浮动。

直接说结论：limit_rate + limit_rate_after 是唯一开箱可用的单IP带宽限制方案，但它是按连接限速，不是按IP总带宽限速——客户端开多个连接就能绕过。

为什么不能真正“按IP限带宽”

Nginx 没有模块能聚合同一 IP 的所有连接并统一分配带宽。它只在每个 TCP 连接建立后，独立应用 limit_rate。这意味着：

• 一个 IP 开 4 个下载线程 → 总速 ≈ 4 × limit_rate
• limit_conn_zone 管连接数，limit_rate 管单连接流速，二者不联动
• 没有 limit_bandwidth_per_ip 这种指令，所有“IP级带宽限速”都是伪需求或需外部调度

limit_rate 和 limit_rate_after 必须成对写

单独写 limit_rate 200k 会生效，但无法实现“先快后慢”的体验；加了 limit_rate_after 才能模拟真实下载场景：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• limit_rate_after 5m 表示前 5MB 不限速（header + 视频头/安装包校验段秒开）
• limit_rate 200k 从第 5MB+ 开始生效，单位是字节/秒（不是 bit）
• 必须同时出现在同一作用域（server 或 location），否则 limit_rate_after 被忽略
• 对 proxy_pass 流量也生效，限的是 Nginx → client 的下行，不是 upstream → Nginx 的上行

单位换算和实测浮动要心里有数

你写的数字 ≠ 实际网卡速率，因为受系统 socket buffer、TCP window、客户端接收能力影响：

• 想限 1Mbps 下行 → 计算：1,000,000 ÷ 8 = 125,000 字节/秒 → 向上取整写 limit_rate 125k
• 500k = 500 × 1024 = 512,000 字节/秒 ≈ 498 KiB/s，不是 500 kbit/s
• 实测速率通常有 ±15% 浮动，别拿 iPerf 对标；压测时用 curl -r 0-10485760 http://x/x.zip > /dev/null 更准
• CDN 场景下，$binary_remote_addr 拿到的是 CDN 节点 IP，limit_rate 仍按该 IP 生效，无法穿透

真正难处理的从来不是配置语法，而是并发连接绕过限速这个事实——它没法被 limit_conn 拦住，因为那是另一个维度的事。要么接受“单连限速”，要么用 iptables + tc 做系统层整形，但 reload 会中断连接，且无法 per-HTTP-session 精细控制。