ProxyPassReverse 本身不会导致死循环，死循环根源是后端返回含原始URL（如localhost、127.0.0.1）的Location头，代理未全覆盖重写，致请求反复转发；需为所有可能内网Host配置ProxyPassReverse，并优先让后端生成公网URL。
ProxyPassReverse 本身不会导致死循环跳转，死循环的根源在于后端应用返回的 Location、Set-Cookie 等响应头中含原始（未代理）的 URL，而前端代理又反复重写、转发，形成闭环。多级代理（如 Nginx → Apache → Tomcat）下这个问题更易暴露，本质是响应头重写不完整或顺序错乱。
一、典型死循环场景还原
假设请求路径为：https://api.example.com/v2/orders
→ Apache（一级代理）→ http://10.0.1.10:8080/v2/orders
→ Tomcat（二级代理/后端）内部重定向到 /v2/orders/123，但返回 Location: http://localhost:8080/v2/orders/123
Apache 的 ProxyPassReverse 若只配置了：
ProxyPass /v2/ http://10.0.1.10:8080/v2/ ProxyPassReverse /v2/ http://10.0.1.10:8080/v2/
它只会改写响应头中匹配 http://10.0.1.10:8080/v2/ 的 Location，对 http://localhost:8080/... 完全无感——浏览器拿到这个地址后再次发请求给 Apache，Apache 又转发给 Tomcat，Tomcat 再次重定向……无限循环。
二、关键解决动作：精准覆盖所有可能的原始 Host
必须让 ProxyPassReverse 覆盖后端可能返回的所有非法 Host 值，包括：
localhost127.0.0.1-
10.0.1.10（后端真实 IP） -
tomcat.internal（内网域名） - 甚至
http://开头的绝对路径
示例完整配置：
ProxyPass /v2/ http://10.0.1.10:8080/v2/ # 逐条覆盖后端可能写死的 Host ProxyPassReverse /v2/ http://localhost:8080/v2/ ProxyPassReverse /v2/ http://127.0.0.1:8080/v2/ ProxyPassReverse /v2/ http://10.0.1.10:8080/v2/ ProxyPassReverse /v2/ https://localhost:8443/v2/ ProxyPassReverse /v2/ http://tomcat.internal:8080/v2/ # 如果后端用相对路径重定向，可加此行兜底（非标准但有效） ProxyPassReverseCookieDomain localhost example.com ProxyPassReverseCookiePath /v2/ /v2/
三、更可靠的做法：让后端不返回原始 Host
比在 Apache 层补漏更治本的是约束后端行为：
-
Tomcat 中设置
proxyName和proxyPort（配合secure="true"）：<connector port="8080" protocol="HTTP/1.1" proxyname="api.example.com" proxyport="443" secure="true" scheme="https"></connector>
这样 Spring MVC 或 Servlet 生成的重定向 URL 就会是
https://api.example.com/v2/orders/123，Apache 无需改写。 -
Spring Boot 应用启用正向代理感知：
server: forward-headers-strategy: native # 或 cloud（适配 X-Forwarded-*）
四、调试与验证方法
- 用
curl -v查看真实Location响应头内容，确认来源； - 在 Apache 日志中开启
LogLevel debug rewrite:trace3，观察ProxyPassReverse是否命中； - 临时用
curl -H "Host: api.example.com"直连后端，确认其返回的Location是否已合规。
不复杂但容易忽略。
