KeepAlive是Apache中容易被忽视但又非常关键的一项配置。它允许同一个TCP连接处理多个HTTP请求，避免了频繁的三次握手和连接创建开销，能明显提升页面加载速度。但KeepAliveTimeout的取值却让不少运维人员纠结：设短了，客户端还没发起第二个请求连接就断了，复用形同虚设；设长了，空闲连接占着进程不放，高并发时新的请求反而进不来。这篇文章就来把这个参数彻底讲清楚，并给出可直接落地的配置建议。
KeepAliveTimeout到底在控制什么
要理解这个参数，得先看Apache处理请求的过程。当KeepAlive开启时，客户端完成一次请求后，Apache不会立刻关闭TCP连接，而是保持等待状态，等客户端在同一条连接上发送下一个HTTP请求。KeepAliveTimeout定义的就是这个等待的时长，一旦超时还没有收到新请求，Apache就主动关闭连接并释放资源。
这里的关键在于：等待期间，这条连接是被某个处理进程或线程占用的。以prefork模式为例，每个子进程同一时间只能处理一个连接。如果KeepAliveTimeout设置为15秒，而客户端在完成请求后去浏览页面了，这条连接的进程就要白白空等15秒。假设服务器有256个进程，每个连接平均空占10秒，高并发场景下可用进程会被大量空闲连接迅速耗尽，表现为页面打不开、请求排队，而CPU和带宽其实一点都不忙，这种进程饥饿现象就是KeepAliveTimeout过长最典型的故障表现。
反过来看，如果设置得太短，比如1秒，客户端两次请求之间的间隔（用户点击下一页、浏览器解析HTML后再加载图片和脚本）稍微长一点，连接就已被关闭，浏览器必须重新建立TCP连接，复用率大幅下降，KeepAlive几乎失去意义。
不同MPM模式下的影响差异与推荐配置
Apache主要有prefork、worker和event三种MPM模式，KeepAliveTimeout的影响程度差异很大。prefork模式下每个进程只服务一个连接，空闲连接的代价最高，因此建议KeepAliveTimeout设置得相对保守，一般3到5秒即可满足大多数网页的二次请求复用。如果是纯API服务，请求间隔通常在毫秒级，甚至可以降到2秒左右。
worker和event模式下，一个进程派生多个线程，单个空闲连接只占用一个线程而非整个进程，资源压力相对小一些，KeepAliveTimeout可以适当放宽到5到10秒。尤其是event模式，借助专门的连接监听线程，空闲连接在等待期间几乎不占用工作线程，超时时间可以设得更长而不影响吞吐能力。
具体配置写在httpd.conf或对应的虚拟主机配置中：
# 开启KeepAlive（2.4版本默认已开启） KeepAlive On # 单个连接上最多允许的请求数，0表示不限制 # 建议设置一个合理上限，防止个别客户端长期占用连接 MaxKeepAliveRequests 100 # 保活超时时间，单位为秒 # prefork模式建议3-5秒，worker模式建议5-10秒 KeepAliveTimeout 5
需要注意，KeepAliveTimeout通常不需要按虚拟主机单独设置，它默认继承主配置。另外这个参数的最小单位就是秒，如果你确实需要亚秒级的精细控制，应考虑在前面加一层反向代理来管理长连接，而不是在Apache上强行凑合。
关联参数必须协同调整
KeepAliveTimeout从来不是孤立起作用的，它和MaxRequestWorkers（旧版本叫MaxClients）共同决定了连接资源的天花板。一个简单的估算思路是：服务器能同时维持的连接数不能超过MaxRequestWorkers。假设MaxRequestWorkers为150，每个页面访问平均产生5个请求，每个连接空闲等待5秒，那么当一秒钟有超过30个新访客时连接池就会趋于饱和，后续请求开始排队。
所以在调大KeepAliveTimeout之前，先确认进程和线程的上限是否足够。prefork模式每个进程大约消耗2到3MB内存（取决于加载的模块），256个进程大概需要700MB起步。如果你把KeepAliveTimeout从5秒调到15秒，等效于连接占用时间扩大三倍，此时必须同步评估MaxRequestWorkers是否需要提升，否则极易触发连接耗尽。
此外，MaxKeepAliveRequests建议不要设为0，给它一个50到200之间的值，可以避免个别异常客户端把一条连接永久霸占。还要提醒一点：如果Apache前面有Nginx或其他反向代理，代理与后端之间的KeepAlive由代理的upstream配置管理，与客户端到代理这一段的KeepAliveTimeout是两回事，不要混淆。
如何验证你的设置是否合理
配置改完不等于结束，一定要用压测工具验证效果。使用ab模拟带KeepAlive的并发请求：
# -k参数启用KeepAlive，模拟连接复用 # 200并发，共10000个请求 ab -k -c 200 -n 10000 http://127.0.0.1:80/ # 观察输出中的关键指标： # Requests per second：吞吐量 # Time per request：单个请求平均耗时 # Non-2xx responses：异常响应数量
对比KeepAliveTimeout取2秒、5秒、10秒三组压测数据，观察吞吐量和错误率的变化。如果缩短超时后吞吐量不降反升，说明之前的空闲连接确实在拖累进程利用率。同时结合server-status页面实时观察连接状态，重点看W状态（正在处理）和K状态（保活等待）的比例。若K状态的连接长期占到七八成以上，说明KeepAliveTimeout偏长，大量线程在空等。
最后给出一个通用的起点配置：普通动态网站（PHP应用、内容站点）使用prefork模式时KeepAliveTimeout设5秒、MaxKeepAliveRequests设100；静态资源为主的站点使用event或worker模式可以放宽到10秒；纯后端API服务建议3秒以内。从这个基线出发，再结合实际压测数据微调，远比照搬网上抄来的参数靠谱得多。
Apache KeepAliveKeepAliveTimeout超时时间配置修改时间：2026-09-03 19:19:16