当一台Apache服务器突然涌入大量请求，带宽被占满、正常用户无法访问时，很多运维人员的第一反应是加机器或者上负载均衡，但其实在Apache自身层面就有一套成熟的解决方案。mod_qos是Apache的质量服务模块，它基于令牌桶算法对连接和请求进行限流，能够有效防御CC攻击、防止个别客户端耗尽服务器资源。本文将从原理讲到实操，带你完整掌握mod_qos的配置方法。
令牌桶算法的工作原理
在动手配置之前，有必要先理解mod_qos限流的底层逻辑。令牌桶算法的核心思想是：系统以固定速率往一个桶里投放令牌，每个请求到达时必须从桶中取走一个令牌才能被处理，如果桶是空的，请求就会被拒绝或延迟处理。桶的容量决定了允许的突发流量上限，而投放速率决定了长期的平均请求处理速度。
举个具体的例子：假设桶的容量是50，令牌投放速率是每秒10个。当一个客户端在前9秒内没有发送任何请求，桶中会积累最多50个令牌（不会超过容量）。此时如果它突然发起60个请求，前50个可以立即通过，剩余10个要么被拒绝要么等待新令牌生成。这就是令牌桶算法允许突发流量但又能限制长期平均速率的特性，相比简单的固定窗口计数器，它更加平滑合理。
mod_qos把这个算法应用到了两个维度：一是连接层面，控制同一时刻的并发连接总数；二是请求层面，控制单位时间内的请求次数。两个维度配合使用，基本可以覆盖绝大多数限流场景。
mod_qos的安装与编译
mod_qos默认不随Apache一起发布，需要单独下载编译。以Linux环境为例，首先确认系统已经安装了Apache的devel包和编译工具，然后从官方地址下载源码包进行编译：
# 安装依赖（以CentOS为例） yum install -y httpd-devel gcc make # 下载并编译mod_qos cd /usr/local/src wget https://sourceforge.net/projects/mod-qos/files/latest/download -O mod_qos.tar.gz tar zxvf mod_qos.tar.gz cd mod_qos-* cd tools && make && cp qslog /usr/local/bin/ cd ../apache2 apxs -i -c -D WITH_MEMCACHE mod_qos.c
编译成功后，apxs会自动把模块文件安装到Apache的modules目录。接着需要修改httpd.conf，在LoadModule区域添加加载指令：
LoadModule qos_module modules/mod_qos.so
如果使用的是Debian或Ubuntu系统，把apxs换成apxs2即可。WITH_MEMCACHE参数是可选的，启用后mod_qos可以借助memcached在多台服务器之间共享限流状态，适合集群部署场景。单机部署可以不加这个参数。配置完成后重启Apache，如果启动没有报错，说明模块已经正常加载。
核心配置指令详解
mod_qos提供了丰富的指令，下面挑出最常用的几个详细说明。首先是控制单IP并发连接的两个指令：QS_SrvMaxConnPerIP限制每个客户端IP的最大并发连接数，QS_SrvMaxConn限制服务器总并发连接数。这两个值需要根据业务实际并发量来设定，比如普通网站把单IP并发设为20左右比较合适。
其次是请求频率控制。QS_ClientEventBlockCount配合QS_ClientEventBlockTime可以统计指定时间窗口内的请求次数，超限的客户端会被加入黑名单一段时间。而QS_SrvRequestRate则是基于令牌桶算法的请求速率控制，单位是每秒请求数，超过速率的请求会收到503响应。
下面给出一段生产环境可直接使用的完整配置示例：
<IfModule mod_qos.c>
# 客户端最低传输速率，低于此值空闲连接将被关闭
QS_ClientMinDataRate 150 1200
# 单IP最大并发连接数
QS_SrvMaxConnPerIP 20
# 服务器最大并发连接数
QS_SrvMaxConn 800
# 每秒最大请求数（令牌桶速率）
QS_SrvMaxRequestRate 500
# 请求频率限制：60秒内超过120次请求则封禁300秒
QS_ClientEventBlockCount 120
QS_ClientEventBlockTime 60
QS_ClientEventBlockExcludeIPs 192.168.1.0/24
# 优先级规则：命中正则的路径享有独立带宽
QS_LocRequestLimitMatch 4000 \/api\/.*
# 返回给被限流客户端的状态码
QS_ErrorPage /var/www/html/busy.html
</IfModule>
其中QS_ClientMinDataRate 150 1200的含义是：客户端数据传输速率低于150字节每秒，且持续超过1200毫秒，Apache就会主动断开这个连接。这条指令专门用来清理慢速攻击建立的僵尸连接，比如Slowloris攻击就是靠大量缓慢发送数据的连接拖垮服务器，这个参数正好对症下药。QS_ClientEventBlockExcludeIPs用来设置白名单，内网监控、健康检查等来源的IP一定要加进去，否则监控探针本身可能触发封禁规则。
QS_ErrorPage指定的页面会在客户端被限流时返回，建议在这个页面中说明访问受限的原因，避免正常用户误触后不明所以。如果不设置，mod_qos默认返回406或503状态码，部分客户端可能会重复快速重试，反而加剧压力。
mod_qos与其他限流方案的对比
市面上常见的Apache限流方案还有mod_limitipconn和mod_evasive，三者各有侧重。mod_limitipconn功能单一，只能限制单IP并发连接数，无法控制请求频率，也没有令牌桶机制，适合需求极简的场景。mod_evasive侧重于攻击检测，命中规则后会临时拉黑IP，但它基于固定窗口计数，突发流量判断不够精准，误杀率相对较高。
mod_qos的优势在于精细和灵活：它同时支持连接层和请求层的双重控制，可以针对不同路径设置不同的限流规则，支持优先级调度保证关键业务在高压下仍能获得资源，还能通过qslog工具输出详细的限流日志用于分析。代价是配置项比较多，学习曲线略陡，初次上手建议先在测试环境调参。
另外提一点，如果流量入口已经有Nginx或者云WAF，限流策略一般放在前置层做，mod_qos更适合作为最后一道防线，防止恶意流量穿透到后端时把Apache打挂。多层配合、各司其职，才是更稳妥的架构设计。