我来帮你拆解清楚这个困扰你的问题——首先得明白，Spring Boot 2.2+引入server.forward-headers-strategy这个配置，核心是为了处理反向代理后的请求头（比如X-Forwarded-Proto，用来告诉应用真实的请求协议是HTTP还是HTTPS），这也是你升级后Hateoas链接协议不对的根源所在。

一、NATIVE和FRAMEWORK模式到底差在哪？ #

咱们直接说本质：

• NATIVE模式：把转发头的处理权交给底层的Servlet容器（比如Tomcat）。容器会自己解析X-Forwarded-*这类请求头，然后修改请求对象里的协议、主机、端口等信息，让Spring框架拿到的就是已经修正后的真实请求信息。但这里有个前提：容器本身得开启了转发头的支持才行。
• FRAMEWORK模式：完全由Spring框架自己来处理转发头，通过内置的ForwardedHeaderFilter过滤器解析X-Forwarded-*头，手动修正请求的相关属性。这种模式不依赖容器的配置，所有逻辑都在Spring层控制，兼容性更强。

二、该选容器处理还是框架处理？分场景看 #

1. 嵌入式Tomcat（Spring Boot内嵌容器） #

两种模式基本都能正常工作：

• 选NATIVE的话更轻量，因为复用了容器原生的处理逻辑，性能上略占优；
• 要是你用的容器原生转发处理有特殊限制，或者需要自定义转发头的规则，那FRAMEWORK模式会更灵活。

2. 外部独立Tomcat（你当前的场景） #

优先选FRAMEWORK模式，除非你已经手动给外部Tomcat配置了转发头处理组件。
你遇到的问题就是典型情况：外部Tomcat默认是没有开启RemoteIpValve（Tomcat用来处理转发头的核心组件）的，所以NATIVE模式下容器根本不会去解析X-Forwarded-Proto头，Spring拿到的还是容器内部的HTTP协议，自然生成的Hateoas链接就是HTTP的；而FRAMEWORK模式下Spring自己处理转发头，能正确识别真实的HTTPS协议，生成的链接就对了。

三、解决你当前问题的具体方案 #

针对你基于外部Tomcat的Spring Boot 2.4.6应用，有两种可选方案：

方案1：用FRAMEWORK模式（推荐） #

直接在配置文件里加一行：

server.forward-headers-strategy=FRAMEWORK

Spring会自动注册ForwardedHeaderFilter来处理转发头，不用动Tomcat的配置，就能解决Hateoas链接协议的问题。

方案2：如果非要用NATIVE模式 #

那得手动给外部Tomcat配置RemoteIpValve：

1. 打开Tomcat的conf/server.xml文件；
2. 在<Host>标签内部添加如下配置：

<Valve className="org.apache.catalina.valves.RemoteIpValve"
       remoteIpHeader="X-Forwarded-For"
       protocolHeader="X-Forwarded-Proto"
       protocolHeaderHttpsValue="https"/>

3. 重启Tomcat后，再把server.forward-headers-strategy设为NATIVE，就能正常生效了。

四、为啥嵌入式Tomcat两种模式都能用？ #

因为Spring Boot在嵌入式Tomcat场景下，当你设置server.forward-headers-strategy=NATIVE时，会自动帮你配置好RemoteIpValve，所以容器能正确处理转发头；但外部Tomcat不会自动做这个配置，所以NATIVE模式就失效了。

内容的提问来源于stack exchange，提问作者Arun Gowda