记录下负载均衡+tomcat遇到的获取到错误scheme的坑

部署给客户的tomcat下的程序获取到的scheme始终是错误的

负载均衡使用的阿里slb,tomcat部署在阿里云centos7服务器上

浏览器到slb为https,slb到tomcat为http,已在slb上勾选传递 X-Forwarded-Proto,tomcat上也已配置对protocolHeader

程序启动后获取到的scheme始终为http,抓包检查slb到tomcat的数据,也确实传递有 X-Forwarded-Proto: https

后来偶然发现通过slb获取到的scheme错误,而通过ssh做本地端口转发,相同数据包,走本地端口转发时,tomcat上能够获取到正确的scheme。本地端口转发时tomcat获取到的客户端ip为127.0.0.1,slb时tomcat获取到的ip为100.x.x.x。

动态调试tomcat,发现是internalProxies导致的,查询相关文档(https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/valves/RemoteIpValve.html)。发现需要配置 internalProxies。

默认情况下internalProxies为10/8, 192.168/16, 169.254/16, 127/8, 172.16/12, and ::1

internalProxies控制可信ip范围, 在该范围中的ip才会使用header中传递的X-Forwarded-Proto等数据

JRebel 2018.1使用反代失败解决

授权地址增加了GUID检测

使用 http://xxx.com:8888/jrebelusername 这样的地址无法激活了
需要修改为 http://xxx.com:8888/88414687-3b91-4286-89ba-2dc813b107ce 这样的地址

如:http://192.168.123.12:8888/88414687-3b91-4286-89ba-2dc813b107ce

后面的那串为GUID,随便找个GUID在线生成器生成个就行了

从老版本升级到该版本的不受影响,激活后一定手动要切换到离线模式,可离线180天,可随时重点下,180天周期会重新刷新