Apache mod_proxy_balancer 本身不引发重定向死循环，但配置不当会导致后端302跳转暴露内网地址或形成循环；解决关键是配对ProxyPass/ProxyPassReverse、后端使用独立内网域名、透传X-Forwarded-Proto头，并用curl -v验证Location响应头是否为公网地址。
apache mod_proxy_balancer 本身不直接引发重定向死循环或 302 错误，但若配置不当，会让后端返回的 302 跳转暴露内网地址、重复指向代理自身，甚至触发无限跳转。解决的关键不是“禁用重定向”，而是**控制 location 响应头的生成与改写逻辑，并切断代理与后端域名的解析冲突**。
避免后端返回内网地址导致的 302 错误
后端（如 Spring Boot、Tomcat）常根据 Host 或硬编码生成 Location 头，例如 Location: http://127.0.0.1:8080/login。浏览器无法访问该地址，表现为跳转失败或空白页。
- 必须配对使用
ProxyPass和ProxyPassReverse，且路径、协议、主机、端口完全一致（含末尾斜杠） - 对负载均衡集群，每条
ProxyPass都要对应一条专属ProxyPassReverse，不能省略或复用
例如：ProxyPass /api/ balancer://api-cluster/ProxyPassReverse /api/ balancer://api-cluster/ - 确保后端启用代理头支持：Spring Boot 加
server.forward-headers-strategy=framework；Tomcat 配置RemoteIpValve
切断重定向死循环的根源
死循环常见于对外域名和后端服务使用相同域名（如都叫 app.example.com），Apache 把后端返回的 Location: https://app.example.com/logout 又转发给自己，形成闭环。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 后端必须使用独立内网标识：如
app.internal、192.168.1.100:8080，绝不能复用公网域名 - DNS 层严格隔离：
app.example.com解析到 Apache 服务器；app.internal仅内网 DNS 可解析 - 在 Apache 中排除维护路径，防止兜底页被错误代理：
ProxyPass /maintenance.html !ProxyPass /errors/ !
增强重定向可控性的补充措施
仅靠 ProxyPassReverse 不足以覆盖所有场景，尤其当后端拼接绝对 URL 或协议不一致时。
- 显式传递协议信息：
RequestHeader set X-Forwarded-Proto "https" env=HTTPS
让后端知道当前是 HTTPS 请求，避免生成http://地址 - 禁止后端依赖原始 Host 生成跳转：开启
ProxyPreserveHost Off（默认已关，无需额外写），或配合ProxySet keepalive=On减少连接重建干扰 - 调试时临时禁用自动改写，确认原始响应：
ProxyPassReverse / !+ 查看curl -I输出的 Location 值
验证是否真正生效
不要只看配置是否加载，要验证真实响应头：
- 用
curl -v https://example.com/login触发一次跳转，观察返回的Location:是否为公网可访问地址（如https://example.com/dashboard） - 检查 Apache 错误日志是否有
proxy: No protocol handler was valid等提示，说明模块未启用或目标地址协议不匹配 - 确认
mod_proxy、mod_proxy_http、mod_proxy_balancer全部启用：apache2ctl -M | grep proxy（Debian）或httpd -M | grep proxy（RHEL）
