WEB应用

惊现Haproxy重复添加X-Forwarded-For问题(附官方解决办法)

最近在配置Haproxy代理的时候发现一个很有意思的事情:Haproxy在代理http请求会无脑加一个X-Forwarded-For(后文简称XFF),而不是将自身的IP地址加到已存在的XFF列表之后,WTF!还有这种神操作? 确认无误之后,我到Haproxy的github开了一个issue反馈了这个BUG(issue地址),最终了解到了Haproxy就是这样设计的,并得到了解决方案,而且这个issue的回复很有意思,特来博客分享下。 刚开始,我的issue提到Haproxy没有将自身IP地址append到已有的XFF列表之后,而是无脑又加了一个,这应该是个BUG: 官方开发GG回复让我升级到最新稳定版,我说升级了也是一样的,结果人家又回复我说Haproxy本来就是这样设计的: 我接着回复说Haproxy这样设计会导致很多开源程序获取真实IP异常,比如Twisted和packetbeat,但是官方说Haproxy 的设计100%符合HTTP协议标准balabala....既然都这样说了,我能说啥呢?只好用官方给的建议选项if none来拒绝Haproxy添加XFF,先解决我程序获取源IP错误的问题。 本以为这样就结束了,结果高潮来了! 一位很酷的法国大胡子发起了热心支援: 他的大概意思是说,既然Haproxy 100% 符合HTTP标准,那为啥没有遵循 XFF 的标准约定,将自身的IP地址添加到已存在的XFF列表末尾??也提到了多个XFF会导致很多程序无法读取,比如tomcat-8.5。为啥不加一个选项来选择使用多个XFF还是使用一个XFF等等balabala一顿说... 接着官方在HTTP标准上发起反驳解释(一大堆内容,此处不表),并在最后说明这样做是为了提高Haproxy性能,如果先判断是否存在XFF在高并发情况下性能大概下降2-3倍(非特指Haproxy)。 当然,官方最终还是给了一个解决办法,能够让Haproxy也像Nginx那样将自己的IP地址加到已有XFF之后,只需在Haproxy新增如下配置即可: 虽然官方给的答复可以解决问题,不过法国大胡子最后回复的一段话我觉得说得非常好: 大致意思是,我已经知道如何通过配置来解决,但是为啥 option forwardfor 这个选项没有和大部分人预期那样来设计与开发,而且搞得巨复杂? 然后直接给出他认为更好的开发设计,比如用 option forwardfor force 替代: 实现强制覆盖XFF,又比如用 option forwardfor append 来替代: 实现将自身IP地址加到已有的XFF之后。很明显,这样的设计才更有可读性,更好理解!他在最后还提到了,Apache/Nginx/Tomcat/Jetty/F5等等都是将自身IP地址添加到XFF之后,难道你Haproxy认为这些软件的使用率还不够高??喷得大快人心,再次赞一下法国大胡子! 总之,真的是很有意思的一个issue,同时也解决了问题,发现同样问题的朋友可以参考解决!
阅读全文