直接用curl实测下载速度最可靠，重点观察%{speed_download}字段；分段下载可验证limit_rate_after是否生效；多线程会叠加限速效果，需配合limit_conn限制单ip总带宽。
直接用 curl 实测下载速度最可靠，不依赖日志、不看配置是否“写对”，只看真实发给客户端的数据速率。
用 curl 命令实测下载速度
在另一台机器（或本机）执行以下命令，重点观察 %{speed_download} 字段：
curl -o /dev/null -s -w '下载速度: %{speed_download} KB/s\n' http://your-domain.com/file.zip
注意：
– -o /dev/null 避免保存文件干扰测试
– -s 静默模式，只输出自定义结果
– %{speed_download} 单位是 KB/s（千字节每秒），和 Nginx 的 limit_rate 200k 中的 k 含义一致（即 1024 字节）
– 若结果稳定在 190–210 KB/s 左右，说明限速已生效（±15% 浮动属正常）
验证 limit_rate_after 是否起作用
用 curl 分段下载，确认前 N 字节是否“秒发”：
curl -r 0-1048575 -o /dev/null -s -w '前1MB耗时: %{time_total}s\n' http://your-domain.com/file.zip
这个命令只取前 1MB（1048576 字节）。如果 limit_rate_after 1m 生效，该请求通常在 0.1–0.3 秒内完成；而取后面一段（如 -r 2097152-3145727）则明显变慢，就说明限速在指定位置后启动了。
检查并发绕过问题
客户端开多个线程下载会叠加限速效果，这是正常行为，不是失效：
- 单线程：实测 ≈
limit_rate值 - 3 线程并发下载同一文件：
curl并行跑三次，总速 ≈limit_rate × 3 - 若想限制单 IP 总带宽，必须额外配
limit_conn，仅靠limit_rate不行
排除常见干扰项
以下情况会导致实测不准，需提前确认：
-
sendfile on：Linux 下可能首包突增、跳过限速。建议临时关掉：
sendfile off;，或搭配tcp_nodelay on; -
gzip 开启：
limit_rate限制的是压缩后的字节数，不是原始文件大小。测试时用未压缩文件（如 .bin、.zip）更准 -
HTTP/2 多路复用：一个连接承载多个请求，
limit_rate仍按连接限速，但感知不如 HTTP/1.1 明显。可加http2_max_requests 1;或改用 HTTP/1.1 测试 -
Range 请求（断点续传）：每个 range 是独立子请求，
limit_rate_after对每个 range 单独计数，会影响分段测试结果
