不推荐用 mod_ratelimit 针对 .zip、.mp4 等后缀限速，因其不识别文件类型，仅对 apache 原生输出的响应体流式节流；需确保文件由 apache 直接服务且未被 php、代理等接管，否则无效。
不推荐用 mod_ratelimit 针对特定文件后缀（如 .zip、.mp4）做下载限速。它本身不识别文件类型或后缀，只对 Apache 直接输出的响应体做流式节流，无法按 MIME 类型、扩展名或请求头动态判断是否该限速——哪怕你把 <files></files> 套上 SetOutputFilter RATE_LIMIT，也大概率无效。
真正生效的前提是：Apache 必须自己读取文件并输出内容（比如静态文件由 mod_mpm_event + mod_unixd 直接发送），且未被其他模块（如 mod_proxy、mod_php、mod_fastcgi）接管响应流程。一旦文件经 PHP 脚本 readfile() 输出、或由 Nginx 反向代理中转、或走 X-Sendfile，mod_ratelimit 就完全不介入。
如果你仍需在 Apache 环境下实现「仅对 .zip/.rar 等大文件限速」，必须绕过 mod_ratelimit 的局限，采用组合策略：
1. 用 <files></files> + <location></location> 双重匹配，提高命中率
只靠 <files></files> 不可靠（它作用于磁盘路径，且不继承输出过滤器）；应配合 <location></location> 匹配 URI 路径，并用 FilesMatch 显式限定后缀：
<location><filesmatch>
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 200
</filesmatch></location>
⚠️ 注意：<filesmatch></filesmatch> 必须嵌套在 <location></location> 或 <directory></directory> 内才有效；rate-limit 200 表示 200 KB/s（不是字节/秒），不能写 200k 或 0.2m，小数会被截断为 0。
2. 确保文件由 Apache 原生服务，而非脚本中转
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- ✅ 有效场景：
/downloads/file.zip是真实磁盘文件，且未被Alias指向外部路径，也未被RewriteRule重写到 PHP 脚本。 - ❌ 无效场景：
-
RewriteRule ^/downloads/(.*)$ /download.php?file=$1 [L]→ 限速失效（PHP 控制输出） -
Alias /downloads /mnt/storage→ 若/mnt/storage权限不足或跨文件系统，可能触发sendfile失败，回退到低效读取，加剧 CPU 占用 - 启用了
EnableSendfile Off但没关EnableMMAP Off，仍可能绕过过滤器
-
3. 替代方案更可靠（推荐）
若目标明确是「按后缀限速下载」，以下方式更可控、更少副作用：
-
使用
mod_headers+mod_setenvif先标记请求，再交由mod_ratelimit：SetEnvIf Request_URI "\.(zip|rar|iso)$" need-ratelimit <if> SetOutputFilter RATE_LIMIT SetEnv rate-limit 150 </if>这比
<filesmatch></filesmatch>更灵活，支持正则，且作用于请求阶段。 对高并发下载场景，搭配
mod_evasive或mod_qos限制单 IP 并发连接数，避免多线程工具（如迅雷）绕过单流限速。生产环境建议改用 Nginx：其
limit_rate支持location ~ \.(zip|rar)$ { limit_rate 200k; }，语义清晰、无流式卡顿、CPU 开销低。
本质上，mod_ratelimit 是个简单粗暴的“漏斗”，适合整条路径的粗粒度限速（如 /downloads），不适合基于后缀的精细化控制。强行用于文件后缀，容易出现首字节延迟长、后续突发、日志无报错但实际不限速等问题。
