proxytimeout专管代理连接总等待时间，timeout覆盖请求头读取、请求体接收、响应头发送三阶段i/o阻塞超时；keepalivetimeout仅控制客户端空闲连接时长，与后端通信无关。
ProxyTimeout 和 Timeout 的分工必须分清
ProxyTimeout 只管代理连接的总等待时间，也就是 Apache 等后端 Java 应用返回响应的整个过程；而 Timeout 是更底层的 I/O 阻塞超时，它覆盖请求头读取、请求体接收、响应头发送三个阶段。两者不互斥，但作用域完全不同。
常见错误是把 Timeout 设得很大（比如 300），以为能“撑住慢后端”，结果反而让慢速攻击（如 Slowloris）有更多时间耗尽 worker 连接槽位。真正该调大的是 ProxyTimeout，且应设为后端 P95 响应时间的 2–3 倍（例如后端 P95 是 8s，就设 ProxyTimeout 25）。
若未显式配置 ProxyTimeout，它会继承 Timeout 的值——这正是很多线上故障的根源：一个本该只影响 CGI 或上传的全局超时，意外拖垮了整个反向代理链路。
KeepAlive 在 mod_proxy 场景下必须显式启用
Apache 默认在 mod_proxy 下是关闭连接复用的。即使全局 KeepAlive On 生效，若 Proxy 配置里没加 keepalive=on，每次请求仍会新建 TCP 连接到后端 Java 服务。
正确写法示例：
ProxyPass /app http://10.0.1.10:8080/app keepalive=on ProxySet keepalive=on max=20 min=5 smax=10 ttl=60
关键点：
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
keepalive=on必须写在ProxyPass行末或单独ProxySet中，漏掉就等于没开 -
max=20是池上限，别盲目设高——Tomcat 默认maxConnections通常为 200，按后端实例数折算，20 是较安全的起点 -
ttl=60控制空闲连接存活时间，要 ≥ 后端的keepAliveTimeout（如 Tomcat 的keepAliveTimeout="30000"）
KeepAliveTimeout 不控制代理连接，只管客户端空闲
KeepAliveTimeout 完全不参与 Apache 到后端 Java 的通信流程。它只决定：一个已处理完请求的客户端连接，在发下一个请求前能空闲多久。
这意味着：
- 它和
ProxyTimeout、Timeout没有数值继承关系 - 设成 30 秒，不会让 Apache 多等后端 30 秒；它只影响前端浏览器是否复用当前 TCP 连接
- 若你用 CDN 或 WAF 前置，这个值实际约束的是 Apache 到 CDN 的那跳连接
典型误配：把 KeepAliveTimeout 设得比后端 Keep-Alive 超时还短（比如后端设了 30 秒，Apache 却只设 5 秒），导致连接频繁重建，却误以为是后端问题。
验证配置是否真生效的硬办法
改完配置不能只靠 apachectl graceful —— KeepAliveTimeout 和 ProxyTimeout 类参数需完整重启才能对所有 worker 进程生效：systemctl restart apache2。
验证方式要分层：
- 看连接复用：
curl -v http://your-domain/ --output /dev/null 2>&1 | grep "Connection #"，连续两次请求若显示相同 connection 编号，说明复用成功 - 看后端连接状态：
ss -tnp | grep :8080 | wc -l，对比开启前后数量变化，稳定在max=20附近才合理 - 模拟超时行为：临时把后端接口 sleep(35)，访问时若返回 504，则
ProxyTimeout 25生效；若直接断连或 500，则可能是Timeout或后端自身超时在起作用
最容易被忽略的是模块加载顺序：reqtimeout_module 若未启用，Timeout 就仍是唯一防线，此时调大它只会放大风险，而非增强容错。
