我想在haproxy 1.4之前joinstunnel来处理HTTPSstream量。 我还需要stunnel添加X-Forwarded-For头。 这可以通过haproxy网站上的“stunnel-4.xx-xforwarded-for.diff” 补丁来实现。
但是，描述中提到：
请注意，此修补程序不保持活着，…
我的问题是：这对我来说意味着什么？ 我不确定，
这是关于HTTP保持活动状态的，它允许多个资源请求通过单个TCP会话（并且使用SSL，一个SSL会话）。 这对于SSL站点的性能非常重要，因为如果没有保持活动，每个请求的资源都需要SSL握手。
所以，这里所关心的是从客户端一直到后端服务器的一个大的保持活动的会话。 对性能来说这是一个重要的事情，对于现代的HTTP服务器来说当然也是一样，但是这个补丁说它不支持它。 让我们来看看为什么..
保持活动会话只是一个接一个的请求 – 一旦服务器完成对一个请求的响应，服务器就不发送FIN数据包来结束TCP会话; 客户端可以简单地发送另一批头文件。
要了解该补丁正在做什么，下面是一个保持活动对话的例子：
客户：
GET / HTTP/1.1 Connection: keep-alive Host: domain.com ...
服务器：
HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Server: Apache Content-Length: 34 .... (other headers) <html><head>content!</head></html>
这就是非保持连接会停止的地方。 但是，保持活力允许客户只是开火另一个：
GET /images/some/image.on.the.page.jpg HTTP/1.1 Connection: keep-alive Host: domain.com ...
对于代理中的客户端ID，某些反向代理可以在每个客户端请求中的X-Forwarded-For头中添加。 这告诉上游服务器请求来自哪里（而不是从反向代理的IP发起的每个请求），以便logging和其他应用程序的需要。
X-Forwarded-For头部需要注入通过保活连接发送的每个客户端资源请求，因为每次发送完整头部; 处理X-Forwarded-For报头并将其翻译为“真实”请求IP是在每个请求而不是每个TCP-keep-alive-session基础上完成的。 嘿，也许有一些很棒的反向代理软件，它们使用单个保持活动会话来处理来自多个客户端的请求。
这是这个补丁失败的地方。
该站点上的修补程序将监视TCP会话的缓冲区，以查看stream中第一个HTTP标头集合的末尾，并在第一个标头集合结束后将新标头插入stream中。 完成之后，它会认为已完成X-Forwarded-For作业，并停止扫描新的标题集。 这种方法没有意识到通过后续请求进入的所有未来头文件。
不能真的责怪他们; stunnel没有真正build立处理和翻译其内容的stream。
这对你的系统会产生这样的效果：保持活动stream的第一个请求将得到适当注入的X-Forwarded-For头，并且所有的后续请求都能正常工作 – 但是它们不会头。
除非有另一个头注入补丁可以处理每个连接的多个客户端请求（或者在Stack Overflow的朋友的帮助下得到这个补丁），您可能需要查看您的SSL终止的其他选项。
STunnel 4.45使用HAProxy 1.15中的一些新function（代理协议）修正了这个问题
它还修复了以前的补丁和Keep Alive的问题
与我在另一个线程中发布的内容类似，从1.5-dev12开始，HAProxy在两侧都支持本地SSL。 因此，使用X-Forwarded-For，HTTP保持活动状态以及向服务器报告通过SSL进行连接的标题如下所示：
listen front bind :80 bind :443 ssl crt /etc/haproxy/haproxy.pem mode http option http-server-close option forwardfor reqadd X-Forwarded-Proto:\ https if { is_ssl } server srv1 1.1.1.1:80 check ... ...
这比修补通道要容易得多，而且比放弃保持活力要好得多。
从Shane扩展出来的优秀答案，你可以在HAproxy之前使用Nginx作为SSL终结者。 它能够正确处理客户端和nginx之间的保持活动状态，这是对延迟最敏感的一方，并为每个客户端请求创build一个到后端的新连接，并在每个请求中发送X-FORWARDED-FOR。