Apache通过mod_proxy_uwsgi连接uWSGI是一种成熟、安全且低开销的Python应用部署方式，适合已运行Apache的生产环境，复用其权限控制、SSL终止和静态文件服务，需启用mod_proxy与mod_proxy_uwsgi、禁用ProxyRequests，并配置ProxyPass使用uwsgi://协议及合理ProxySet参数协同调优。
Apache 通过 mod_proxy_uwsgi 连接 uWSGI 是一种成熟、安全且低开销的 Python 应用部署方式，特别适合已运行 Apache 的生产环境。它不依赖额外反代（如 Nginx），直接复用 Apache 的权限控制、SSL 终止和静态文件服务能力。但连接池参数本身不能“动态调整”，需在配置加载时设定合理值，并配合 uWSGI 和 Apache 的并发模型协同优化。
确认模块启用与基础代理配置
确保 Apache 已加载必要模块：
-
mod_proxy和mod_proxy_uwsgi必须启用（Debian/Ubuntu 执行a2enmod proxy proxy_uwsgi；RHEL/CentOS 检查LoadModule行） - 禁用正向代理：
ProxyRequests Off（必须，否则配置无效或存在安全风险） - 基础代理示例（放在
<virtualhost></virtualhost>内）：ProxyPass / uwsgi://127.0.0.1:8000/ProxyPassReverse / uwsgi://127.0.0.1:8000/ -
uwsgi://协议前缀不可替换为http://或省略，否则请求会走 HTTP 代理逻辑并失败
uWSGI 端需匹配监听模式与并发策略
mod_proxy_uwsgi 要求 uWSGI 启动时使用 --socket（而非 --http 或 --scgi），且协议必须为 uwsgi（二进制格式）。关键配置建议：
- 监听地址推荐
--socket 127.0.0.1:8000（避免 Unix socket 权限问题，也便于网络隔离） - 启用
--master+ 合理--processes N（N 通常设为 CPU 核数 × 1~2） - 添加
--vacuum（退出时清理 socket 文件）和--die-on-term（兼容 systemd/upstart） - 若应用 I/O 密集，可启用
--async 2+--workers 1+--plugin asyncio（需 uWSGI ≥ 2.0.20）
Apache 连接池参数：ProxySet 控制实际生效项
ProxySet 是静态指令，仅在 Apache 重载后生效，但它能有效影响 uWSGI 连接行为。以下参数在 <proxy></proxy> 块中设置才起作用：
立即学习“Python免费学习笔记（深入）”；
-
min=2：每个子进程/线程维持至少 2 个空闲连接（适用于 keepalive 场景，uWSGI 默认支持） -
max=50：单个 Apache 子进程最多建立 50 个到 uWSGI 的并发连接（注意：不是全局上限，而是 per-MPM 实例） -
acquire=3000：从连接池获取连接超时 3 秒，避免请求长时间阻塞 -
retry=60：uWSGI 服务临时不可达时，标记该后端 60 秒内不转发新请求 - 务必验证：修改后执行
apachectl graceful，再用curl -v http://your-site/观察响应头是否含Connection: keep-alive，并用ss -tnp | grep :8000查看活跃连接数是否落在预期范围内
协同调优：避免 MPM 与连接池错配
Apache 的并发模型（MPM）直接影响 ProxySet max 的实际效果：
- 使用
mpm_event（推荐）：支持高并发异步处理，max值可设为 30–100，配合ThreadsPerChild≥ 25 - 若仍用
mpm_prefork：max实际受限于MaxRequestWorkers，此时应设较低值（如 10–20），否则易触发 503 - uWSGI 的
--processes与 Apache 的MaxRequestWorkers不必相等，但总连接需求（平均并发 × 平均连接保持时间）应 ≤ uWSGI 处理能力 × 安全余量（建议 70%） - 静态资源交由 Apache 直接服务，用
<location> ProxyPass ! </location>显式排除，减少 uWSGI 负担
