核心是平衡体验、资源与公平性，采用limit_rate_after与limit_rate组合实现“前快后稳”限速，按路径/MIME/后缀精准作用，并配合limit_conn防单IP多线程占满带宽。
在生产环境做视频点播和文件下载限速，核心不是压低速度，而是平衡体验、资源与公平性——既要让用户秒开视频头或安装包校验段，又要防单 IP 多线程占满带宽，还得避免小资源（如图标、JS）被误伤。
只对大文件生效：用 limit_rate_after + limit_rate 组合
这是最实用、最无副作用的限速方式。它不一刀切，而是“前快后稳”：
- 前 N 字节不限速，快速加载关键数据：比如视频首帧、PDF 第一页、ZIP 文件校验头
- 超出后恒定限速，平抑带宽峰值，保护服务器出口和后端 IO
- 必须成对使用：单独写 limit_rate_after 无效；单位是字节，5m = 5 × 1024 × 1024 字节
推荐配置（放在 server 或 location 块中）：
limit_rate_after 10m;<br>limit_rate 1m;
含义：每个连接前 10MB 秒发，之后稳定在 ≈1MB/s（即 8Mbps）。对 500MB 视频或 ISO 镜像非常友好。
精准作用于下载路径或文件类型
绝不建议在 http 块全局设限速，否则首页 JS、CSS、小图标全变慢。应明确限定范围：
- 按目录匹配（高性能，推荐）：
location ^~ /video/ { limit_rate_after 2m; limit_rate 800k; } - 按 MIME 类型匹配（更准，适合隐藏后缀或动态生成）：
map $sent_http_content_type $dl_speed { ~^video/ 1m; ~^application/zip 512k; default 0; }，再在 location 中写limit_rate $dl_speed; - 按后缀正则（需确保
mime.types已加载）：location ~ \.(mp4|avi|mkv|zip|iso|tar\.gz)$ { limit_rate_after 5m; limit_rate 600k; }
防止单 IP 蹭满带宽：加 limit_conn 控并发连接数
limit_rate 是每连接限速，不是每 IP 总带宽限制。用户开 4 个下载线程，总速就是限速值 × 4 —— 这常被误判为“配置失效”。
真正控总量，要组合 limit_conn：
- 先定义计数区：
limit_conn_zone $binary_remote_addr zone=perip:10m; - 再在下载 location 中启用：
limit_conn perip 3;（同一 IP 最多 3 个并发下载连接） - 注意：该限制只对 TCP 连接计数，静态资源直出时生效；若走 proxy_pass，需确认后端响应及时释放连接
代理大文件时：关缓冲 or 限临时文件大小
当 Nginx 作为反向代理吐出大文件（如从 Node.js 或 Java 后端流式返回 MP4），默认开启 proxy_buffering on 会写临时文件到磁盘，可能撑爆空间：
- 若后端支持流式传输且你可控，直接关缓冲：
proxy_buffering off;，Nginx 边收边发，省磁盘、低延迟 - 若必须缓冲（如需重试或日志审计），则严格限制单个临时文件：
proxy_max_temp_file_size 500m;（设略大于业务最大文件） - 同时建议加
tcp_nodelay on;，缓解sendfile on下首包突增绕过限速的问题
可选：按用户身份或参数动态调速
适合 VIP 加速、测试环境降速等场景，用 map 实现：
- 在
http块定义：map $arg_lvl $rate { default "300k"; "vip" "2m"; "test" "128k"; } - 在下载 location 中引用：
limit_rate $rate; - 访问
/video/demo.mp4?lvl=vip即按 2MB/s 下载；注意需配合鉴权，勿暴露控制逻辑
不复杂但容易忽略：限速效果必须实测验证。用 curl -o /dev/null -s -w '%{speed_download}\n' URL 测单连接真实速率；开多个终端并行下载，观察是否被 limit_conn 拦截；小文件（
