mod_proxy_balancer不处理大文件上传中断——它仅调度请求，不缓冲、不重试、不感知状态；中断应对需协同客户端连接、Apache到后端转发及后端容错三层配置。
mod_proxy_balancer 本身不处理大文件上传中断问题——它只是负载均衡调度器，负责把请求分发到后端节点，既不缓冲请求体、不重试上传、也不感知上传状态或网络断连。上传中断的根源和应对，全在它上下游的配置与协作中。
上传中断不是 balancer 的责任，而是整个代理链的协同问题
mod_proxy_balancer 的核心行为是：接收客户端连接 → 选择后端 worker（如 http://node1:8080）→ 建立新连接 → 转发请求头 → 等待并透传整个请求体。它默认继承 mod_proxy_http 的行为，即缓冲完整 POST 请求体后再转发。这意味着：
- 上传中途断开（如用户关浏览器、WiFi掉线），Apache 可能已收了一半数据但尚未发给后端；
- 后端收不到完整 body，可能返回 400/500，或卡在读取中；
-
balancer不会自动重试、续传、或通知其他节点接管；它只管“这次请求发给了谁”，不管“发没发完”。
真正影响上传中断体验的三个关键层
1. 客户端到 Apache 的连接稳定性
- 启用
KeepAlive Off或调高Timeout（如Timeout 600），避免因空闲超时断连； - 配合
mod_headers检查Content-Length，对超大文件提前拦截（如RewriteCond %{HTTP:Content-Length} >104857600→RewriteRule ^ - [R=413]）； - 若用 HTTPS，确认 SSL/TLS 握手和会话复用配置合理，减少握手失败导致的假中断。
2. Apache 到后端的转发可靠性
- 对上传路径（如
/upload）显式关闭连接复用与缓冲：<Proxy "balancer://uploads"> BalancerMember http://10.0.1.10:8080 retry=60 BalancerMember http://10.0.1.11:8080 retry=60 ProxySet keepalive=off disablereuse=on timeout=600 </Proxy> ProxyPass "/upload" "balancer://uploads/upload" nocanon
-
disablereuse=on：每次上传都建新连接，避免旧连接残留状态干扰； -
keepalive=off：禁用长连接，防止上传未完成时连接被意外复用； -
timeout=600：确保后端有足够时间处理大文件写入。
-
3. 后端服务自身的容错能力
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 后端必须支持分片上传 + 断点续传协议（如 TUS、S3 multipart upload），不能依赖单次完整 POST；
- 上传接口应返回明确状态码（如
200表示分片接收成功，204表示已存在，409表示冲突），让前端可安全重试； - 日志中记录每个上传 ID 的已接收分片范围，便于中断后查询进度。
不推荐依赖 balancer 的“故障转移”来解决上传中断
即使你配置了多个后端节点，balancer 的 failonstatus=500 或 retry=30 也只对请求发起阶段生效。一旦请求体开始传输，balancer 就不再介入——它不会在传输中检测到断连就切换节点，也不会把已收一半的数据转给另一个 worker。
上传中断后，客户端需主动重发（最好带 Upload-ID 和 Offset 头），由后端判断是否续传。balancer 只需保证这个重试请求能稳定路由到同一节点（可用 stickysession=ROUTEID 绑定会话），或由后端集群共享上传状态（如存 Redis）。
不复杂但容易忽略。
