Apache mod_proxy本身不追求极致并发，但通过选用AJP/uWSGI协议、启用event MPM、合理配置连接池与超时、协同后端调优，可稳定支撑数千级并发；关键在于连接复用得当、超时合理、故障不扩散。
apache mod_proxy 本身不追求极致并发数，但通过协议选择、连接复用、mpm调优和后端协同，可稳定支撑数千级并发请求。关键不是堆参数，而是让每个连接更“聪明”——复用得当、超时合理、故障不扩散。
选对协议：AJP 或 uWSGI 代替 HTTP 代理
HTTP 协议解析开销大，尤其在高并发下 CPU 明显升高。对 Java 后端优先用 mod_proxy_ajp，对 Python（uWSGI）用 mod_proxy_uwsgi：
- AJP 是二进制协议，免去 HTTP 头解析，透传真实客户端 IP 更精准，Tomcat 端线程利用率更高
- uWSGI 协议同样跳过 HTTP 解包，配合 uWSGI 的异步 worker，延迟更低、内存更省
- 避免混用：Tomcat 开了 AJP 就别配
ProxyPass / http://...；uWSGI 启动用了--socket就别配http://地址
启用 event MPM 并精调连接生命周期
prefork 模型在高并发下易耗尽进程，event MPM 支持异步 I/O 和长连接复用，是 Apache 2.4+ 推荐默认：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 确认启用：
httpd -V | grep MPM应显示event；若为 prefork，需修改/etc/httpd/conf.modules.d/00-mpm.conf - 调高并发上限：
MaxRequestWorkers 1500（根据内存调整，每进程约 10–15MB） - KeepAliveTimeout 设为 15–30 秒：太短导致频繁建连，太长空闲连接堆积
- MaxKeepAliveRequests 设为 50–100：平衡复用收益与单连接风险，避免一个慢请求拖垮整条连接
连接池 + 后端协同：不只 Apache 单方面调参
连接池参数必须与后端服务能力匹配，否则不是资源浪费就是连接打满：
- 对 Tomcat：
ProxySet keepalive=on min=5 max=20 smax=10 ttl=60，同时 Tomcat 的maxThreads建议设为 ApacheMaxRequestWorkers的 1.2–1.5 倍 - 对 uWSGI：
ProxySet min=2 max=50 acquire=3000 retry=60，uWSGI 端需配--processes 4 --threads 2或异步模式 - 全局超时要留余量：
ProxyTimeout 30（设为后端 P95 响应时间的 2–3 倍），并同步调Timeout 60和KeepAliveTimeout 20
增强韧性：防抖动、防误踢、防雪崩
复杂网络或后端波动时，静态配置容易放大故障：
- 健康检查加权组合：
ProxySet hcinterval=15 hcfail=2 hcsuccess=3 ping=5，核心路径用 HEAD，数据库依赖型加 POST 深度探测 - 失败隔离：
retry=60防止瞬断误判，搭配fallbackroute实现机房级降级 - 容错头处理：
ProxyBadHeader Ignore防止非标响应头（如重复 Set-Cookie）导致整请求失败 - 真实 IP 透传不能少：
RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}e"，否则限流、日志、白名单全失效
