Spring Boot部署于EKS的Traefik反向代理后忽略X-Forwarded请求头问题

• 先确认请求的实际源IP是否匹配server.tomcat.remoteip.internal-proxies配置
  可以在Spring服务中新增临时测试接口，打印请求的request.getRemoteAddr()返回值，对比该IP是否在你配置的信任代理IP段范围内。EKS环境下经常出现两类IP漏配的情况：一是企业自定义的VPC CIDR段（比如常见的100.64开头的CGNAT段）不在Tomcat默认信任的10/8、172.16/12、192.168/16等网段内；二是如果Traefik前面挂载了AWS NLB/ALB，负载均衡的健康检查或者转发请求的源IP段未加入信任列表。临时将server.tomcat.remoteip.internal-proxies设置为.*测试，如果功能恢复正常即可确认是IP段配置遗漏。
• 核对Tomcat相关头处理参数是否完整
  Spring Boot 2.2/2.4版本除了server.forward-headers-strategy=NATIVE之外，还需要确认以下参数没有被误修改：
  • server.tomcat.remoteip.remote-ip-header：默认值为X-Forwarded-For，确保没有被自定义配置覆盖
  • server.tomcat.remoteip.protocol-header：默认值为X-Forwarded-Proto，该参数控制Tomcat识别HTTPS状态的请求头
  • 如果存在多层代理，还需要补充配置server.tomcat.remoteip.trusted-proxies，加入所有上层代理的IP段
• 排查是否有自定义组件修改请求属性
  检查服务中是否存在自研Filter、Interceptor或者第三方安全组件，在Tomcat处理完X-Forwarded头之后，再次修改了HTTPServletRequest的isSecure、remoteAddr等属性。可以通过测试接口同时打印request.isSecure()和request.getHeader("X-Forwarded-Proto")的值，如果头的值是https但isSecure()返回false，即可确认是请求处理链后续逻辑修改了属性，而非Tomcat未识别头。
• 确认EKS网络插件没有篡改请求
  部分EKS网络插件（如开启了SNAT的AWS VPC CNI、自定义Calico网络策略）可能会修改请求的源IP或者请求头，导致Tomcat识别到的源IP不在信任列表内，可以抓包确认Traefik发出的请求源IP和头，与Spring服务接收到的内容是否完全一致。
• 核对Spring Cloud相关组件的配置
  如果服务引入了Spring Cloud Zuul、Spring Cloud Gateway等网关相关依赖，server.forward-headers-strategy=NATIVE可能不生效，需要将该参数改为FRAMEWORK，或者单独配置对应网关组件的头处理规则。

内容的提问来源于stack exchange，提问作者Robert Keck