我想将tunnel放在haproxy 1.4之前，以处理HTTPS流量。我还需要一个隧道来添加X-Forwarded-For标头。这可以通过 haproxy网站上的“ stunnel-4.xx-xforwarded-for.diff” 补丁来实现。
但是，描述中提到：
请注意，此修补程序不适用于keep-alive，...
我的问题是：这对我实际上意味着什么？我不确定
Answers:
这是关于HTTP保持活动状态的，它允许多个资源请求通过单个TCP会话（对于SSL，则是单个SSL会话）。这对于SSL网站的性能非常重要，因为如果没有保持活动状态，则每个请求的资源都需要SSL握手。
因此，这里的关注点是从客户端一直到后端服务器的一个大型keep-alive会话。对于性能而言，这是重要的事情，对于现代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），以确保日志记录和其他应用程序的需求。
X-Forwarded-For需要将标头注入通过保持活动连接发送的每个客户端资源请求中，因为每次都发送完整标头。X-Forwarded-For标头的处理以及将其转换为“真实”请求IP是基于每个请求而不是每个TCP-keep-alive会话进行的。嘿，也许那里有一些很棒的反向代理软件，它使用单个keep-alive会话来服务来自多个客户端的请求。
这是此修补程序失败的地方。
该站点上的修补程序监视TCP会话的缓冲区以查找流中第一组HTTP标头的结尾，并在第一组标头结束后将新标头注入流中。完成此操作后，它将认为X-Forwarded-For作业已完成，并停止扫描新的标头集的末尾。此方法不了解通过后续请求进入的所有将来的标头。
真的不能怪他们。stunnel并不是真正为处理和转换其流的内容而构建的。
这将对您的系统造成影响，即保持活动流的第一个请求将X-Forwarded-For正确注入标头，并且所有后续请求都可以正常工作-但它们将没有标头。
除非那里有另一个标头注入补丁，每个补丁可以处理多个客户端请求（或者在Stack Overflow的朋友的帮助下对其进行调整），否则您可能需要查看其他SSL终止选项。
STunnel 4.45使用HAProxy 1.15随附的一些新功能（代理协议）正确修复了此问题
它还修复了以前的补丁和Keep Alive问题。
与我在另一个线程中发布的内容类似，HAProxy从1.5-dev12开始在两侧均支持本机SSL。因此，拥有X-Forwarded-For，HTTP keep-alive以及一个标头，该标头告诉服务器该连接是通过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 ...
...
它比修补隧道更容易，比必须丢弃keep-alive更好。
扩展Shane的出色答案，您可以在HAproxy之前使用Nginx作为SSL终结器。它正确处理客户端和nginx之间的保持活动状态，这是对延迟最敏感的一面，并为每个客户端请求建立到后端的新连接，并在每个客户端请求中发送X-FORWARDED-FOR。