张戈博客

最近在配置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，同时也解决了问题，发现同样问题的朋友可以参考解决！