Apache充当反向代理时，经常会遇到这样一个现象：前端入口是https://ippipp.com，后端应用运行在http://192.168.1.50:8080。用户点击一个需要登录的页面，浏览器却跳转到了http://192.168.1.50:8080/login，然后直接报连接超时。检查后端服务本身并没有问题，问题出在重定向响应里的Location头。后端返回302时，把内部地址原封不动地写进了Location，Apache如果没有额外配置，不会把这个地址改成对外可访问的地址。
要理解为什么会出现这种情况，先要清楚代理服务器和重定向的工作时序。浏览器请求的是Apache对外暴露的域名，Apache通过ProxyPass把请求转发给后端应用。后端应用处理请求时，如果需要重定向，会根据自身监听的地址、端口以及应用配置生成一个绝对URL，放进Location响应头。这个URL通常是后端自己认为的可访问地址，例如http://192.168.1.50:8080/login。Apache转发响应时，如果不做任何干预，就会把这个内部地址原封不动地返回给浏览器。浏览器随后去连接该地址，公网用户自然无法访问。
Location头未修正时的典型表现
这个问题在登录跳转、表单提交成功后的页面跳转、OAuth回调等场景中特别常见。例如用户访问https://ippipp.com/app，后端应用发现请求未携带有效会话，于是返回一个302状态码，并设置Location: http://192.168.1.50:8080/login。浏览器收到响应后，会直接请求这个内网地址，结果要么是DNS解析失败，要么是连接超时。用户看到的现象就是登录页面打不开，或者提交表单后页面一直转圈。
值得注意的是，即便Apache配置了ProxyPreserveHost On，也不一定能解决所有Location头问题。有些后端框架会强制使用配置项中写死的绝对地址，而不是根据请求的Host头动态生成。还有一些应用会直接读取服务器本地IP、监听端口或反向代理配置不传递原始主机名。因此，最稳妥的做法是在Apache代理层对响应头进行显式重写，而不是指望后端应用完全适配代理环境。
下面这段响应报文展示了一个未修正的Location头。可以看到Location中仍然是内部IP和端口，公网客户端拿到这个地址后无法继续访问。
HTTP/1.1 302 Found Location: http://192.168.1.50:8080/login Content-Length: 0
使用ProxyPassReverse自动修正Location头
Apache的mod_proxy模块提供了ProxyPassReverse指令，专门用来处理反向代理后响应头中的URL重写。它的作用是建立一个“内部URL到外部URL”的映射规则。当后端返回的Location、Content-Location等响应头中出现内部URL时，Apache会根据这条规则自动替换为外部可访问的URL。这个替换过程发生在响应从后端返回、即将发送给客户端之前。
基本配置如下。假设外部访问路径是/app，后端服务地址是http://192.168.1.50:8080/，需要在与ProxyPass相同的位置添加ProxyPassReverse。
<VirtualHost *:443>
ServerName ippipp.com
ProxyPass /app http://192.168.1.50:8080/
ProxyPassReverse /app http://192.168.1.50:8080/
ProxyPassReverseCookieDomain 192.168.1.50 ippipp.com
ProxyPassReverseCookiePath / /app
</VirtualHost>
这里的ProxyPassReverse /app http://192.168.1.50:8080/表示：如果后端响应的Location头以http://192.168.1.50:8080/开头，Apache会把它替换为https://ippipp.com/app/。例如后端返回http://192.168.1.50:8080/login，修正后就变成了https://ippipp.com/app/login。需要注意的是，路径匹配和尾部斜杠会影响替换结果。如果ProxyPass写的是/app，而ProxyPassReverse写成了/app/，或者后端返回的Location中包含多个连续的斜杠，替换结果可能出现路径重复或缺失。
除了Location头，ProxyPassReverseCookieDomain和ProxyPassReverseCookiePath也很重要。很多后端应用在返回重定向时，还会设置Cookie的Domain和Path属性。如果这些属性仍然指向内网地址或根路径，浏览器可能无法正确携带会话Cookie，导致跳转后又被判定为未登录。上面的配置中，ProxyPassReverseCookieDomain把Cookie中的192.168.1.50替换为ippipp.com，ProxyPassReverseCookiePath把/替换为/app，从而保持Cookie在代理路径下正常工作。
使用Header edit做更灵活的Location重写
ProxyPassReverse适合大多数标准场景，但它有一个前提：内部URL必须与ProxyPass中配置的后端地址匹配。如果后端在Location中返回的不是同一个地址，例如应用内部又跳转到了另一个内网域名，或者返回的Location包含非标准端口、动态子域名，ProxyPassReverse可能无法覆盖。此时可以启用mod_headers模块，使用Header edit指令对Location响应头进行正则替换。
下面是一个使用Header edit的配置示例。它先加载headers_module模块，然后在虚拟主机中通过正则表达式匹配内部地址，并将其替换为外部地址。
LoadModule headers_module modules/mod_headers.so
<VirtualHost *:443>
ServerName ippipp.com
ProxyPass /app http://192.168.1.50:8080/
ProxyPassReverse /app http://192.168.1.50:8080/
# 兜底重写 Location，替换内网地址为公网地址
Header edit Location "^(http|https)://192\.168\.1\.50(:[0-9]+)?/" "https://ippipp.com/app/"
</VirtualHost>
这段配置中的Header edit Location会检查响应头Location，如果它匹配正则表达式^(http|https)://192\.168\.1\.50(:[0-9]+)?/，就把匹配到的内部地址部分替换为https://ippipp.com/app/。正则里的\.用于转义点号，(:[0-9]+)?表示端口部分是可选的，这样可以同时兼容http://192.168.1.50:8080/login和http://192.168.1.50/login这类地址。
与ProxyPassReverse相比，Header edit的优势在于可以自由定义匹配规则。例如后端返回的Location是http://backend.internal:8080/sso/callback，但ProxyPassReverse只配置了http://192.168.1.50:8080/，这时就可以用Header edit单独增加一条替换规则。又比如需要把HTTP协议升级为HTTPS，或者把内网域名统一改写成外部域名，都可以通过正则表达式的捕获组来实现更精确的控制。需要特别注意的是，多条Header edit规则会按顺序执行，后面的规则会作用在前面规则已经修改过的内容上，因此配置时要注意规则之间的依赖关系。
验证修正结果与常见排查思路
配置完成后，最直接的验证方式是用curl命令查看响应头。例如执行下面的命令，观察Location字段是否已经变成外部地址。
curl -I https://ippipp.com/app/login
如果一切正常，响应头中的Location应该类似下面这样，不再出现内部IP和端口。
HTTP/1.1 302 Found Location: https://ippipp.com/app/login Content-Length: 0
如果Location仍然是内网地址，需要逐步排查。首先确认mod_proxy和mod_headers模块是否已经启用，虚拟主机配置是否生效。可以通过apachectl -M查看已加载模块，或者检查配置文件语法是否正确。其次检查ProxyPassReverse中的内部URL是否与后端实际返回的Location前缀完全一致，包括协议、主机名、端口和路径。尾部斜杠不匹配是常见原因之一。如果使用了Header edit，则需要检查正则表达式是否正确匹配，可以用正则测试工具单独验证。
另外，浏览器缓存也会干扰测试结果。浏览器可能缓存了之前的重定向响应，导致即使Apache已经修正，仍然会跳转到旧地址。因此建议优先使用curl工具进行验证。如果后端返回相对路径的Location，例如Location: /login，Apache通常不会自动添加外部主机名，这属于另外一种需要单独处理的情况。对于绝大多数返回绝对URL的后端应用，按照本文介绍的ProxyPassReverse配合Header edit的方式，可以稳定地完成Location头修正，从而消除反向代理环境中的重定向错乱问题。
Apache反向代理Location头ProxyPassReverse修改时间：2026-08-24 12:45:45