最近整理了一篇关于 Spring Boot 应用部署到反向代理之后，访问地址被重定向成内部地址的问题。这个问题表面上像是 Nginx 配置错误，实际常常和应用如何识别外部请求协议、Host、端口以及上下文路径有关。

参考原文：Spring Boot 反向代理重定向问题处理

问题现象

在生产环境里，Spring Boot 服务通常不会直接暴露给用户，而是放在 Nginx、网关、负载均衡或 Ingress 后面。用户访问的是公网域名和 HTTPS 地址，但后端应用实际收到的可能是来自代理的 HTTP 请求。

  • 浏览器访问外部域名后，被 302 到内网 IP、容器名或错误端口。

  • HTTPS 站点跳转后变成 HTTP，导致混合内容、登录失败或回调地址错误。

  • 应用配置了 context-path，访问根路径或上下文路径时出现多一次跳转，Location 地址不符合预期。

核心原因

Spring Boot 或内嵌 Tomcat 在生成重定向地址时，会参考当前请求的 scheme、serverName、serverPort、contextPath 等信息。如果反向代理没有把原始请求信息传给后端，或者后端没有启用对 Forwarded / X-Forwarded-* 头的识别，应用就可能按“代理到后端时看到的地址”生成跳转 URL。

因此这个问题要同时看两端：代理层是否传递了外部请求信息，应用层是否信任并使用这些头。只改一边，往往修不完整。

Nginx 侧建议配置

代理到 Spring Boot 服务时，至少保留 Host、真实 IP、协议和端口。一个常见配置如下：

location / {
    proxy_pass http://127.0.0.1:8080;

    proxy_set_header Host \System.Management.Automation.Internal.Host.InternalHost;
    proxy_set_header X-Real-IP \;
    proxy_set_header X-Forwarded-For \;
    proxy_set_header X-Forwarded-Proto \;
    proxy_set_header X-Forwarded-Host \System.Management.Automation.Internal.Host.InternalHost;
    proxy_set_header X-Forwarded-Port \;
}

如果你的站点统一由 HTTPS 暴露，但 Nginx 到后端是 HTTP，那么 X-Forwarded-Proto 尤其关键。否则后端生成的链接可能会误判为 http。

Spring Boot 侧建议配置

Spring Boot 需要启用对转发头的处理。新版本常用配置是：

server:
  forward-headers-strategy: framework

如果使用的是传统 Servlet 容器策略，也可以根据版本和部署方式选择 native。关键是让应用知道“用户真正访问的外部地址”是什么。

另外，Spring Boot 官方文档提到，Tomcat 在 context root 处理上可能产生重定向；如果代理终止了 SSL，而后端误以为自己处在 HTTP 环境，可以考虑关闭 Tomcat 的 context root 自动重定向：

server:
  tomcat:
    redirect-context-root: false

这个配置不是所有重定向问题的万能解，适合处理与 context root 跳转相关的场景。更通用的第一步仍然是正确配置转发头。

排查思路

  1. 先用浏览器开发者工具或 curl -I 看响应 Location，确认到底跳到了哪个地址。

  2. 检查 Nginx 是否传了 Host、X-Forwarded-Proto、X-Forwarded-Port 等头。

  3. 检查 Spring Boot 是否启用了 forward-headers-strategy。

  4. 如果问题只出现在根路径或 context-path 跳转，再考虑 server.tomcat.redirect-context-root。

  5. 最后确认外部域名、HTTPS 证书、网关路径改写和应用 context-path 是否一致。

实践建议

  • 不要在后端代码里硬编码域名来“修”跳转地址，优先修正代理和转发头。

  • 同一套配置在本地、测试、生产环境要区分，尤其是 HTTP/HTTPS 和端口。

  • 登录回调、OAuth2、文件下载、Swagger、Actuator 等页面最容易暴露这类问题，可以作为回归检查点。

  • 如果前面还有多级代理，要确认每一层都没有丢失或覆盖 X-Forwarded-* 信息。

小结

反向代理后的重定向异常，本质是“外部请求地址”和“后端感知地址”不一致。比较稳妥的处理方式是：代理层传递真实请求信息，Spring Boot 层启用转发头识别，必要时再针对 Tomcat context root 重定向做补充配置。这样既能修复跳转地址，也能减少登录、回调和 HTTPS 场景下的连带问题。