引用PROXY“标头”在技术上并非不准确,但可能会有些误导或含糊不清的术语。
从某种意义上说,它是一个“标头”,它到达连接的开头,但它不是 HTTP 请求标头,不像我们熟悉的 X-Forwarded-For,它当然是一个 HTTP 请求标头。
简洁优雅,该协议的版本 1 在 TCP 连接的开头注入一条消息:
PROXY TCP4 192.168.0.1 192.168.0.11 56324 443\r\n
这些字段是协议(基于 IPv4 的 TCP)、源 IP、目标 IP、源端口、目标端口,每个字段之间用一个空格分隔。
在堆栈中使用PROXY 协议时,它是强制性的。连接开始时缺少或格式错误的PROXY 消息是错误情况。 PROXY 消息的存在带来的信任级别高于 X-Forwarded-For 提供的信任级别,X-Forwarded-For 是通过修改传递的(后来的值附加到早期的值上)。 PROXY 协议没有官方允许级联多个值。
如果您需要 ELB 在“内部”传输此值,那么将 ELB 的入口安全组限制为仅接受来自可信源地址的请求至关重要。
完成后,tl;dr:
将 ELB 侦听器配置为 TCP 模式(不是 HTTP)并在 ELB 本身上禁用代理协议将允许将原始的外部 PROXY 消息传输到 ELB 后面的系统。
在 HTTP 模式下使用 ELB 是不可能通过的,因为 ELB 不期望它在请求上,并且后端连接可以被多个前端客户端重用,这不是从根本上与代理协议兼容——它旨在识别传入连接的客户端机器的 IP 源地址和端口(不是 HTTP 请求的源 IP 和端口)......并且如前所述,它不是 HTTP 请求标头。
PROXY 协议背后的想法是通过一组不支持有效负载的组件来识别发起客户端。因此,在这种情况下,ELB 需要遵循该模型。 (当然,中间组件有可能剥离然后重新注入 PROXY 消息,尽管在许多情况下这有点毫无意义,并且 ELB 不处理此配置。)
在 TCP 模式下,ELB 变得与协议无关,并且前端和后端连接之间存在 1:1 的关系,因此消息应该通过并按预期工作。
需要注意的一个可能的警告可能取决于 ELB 如何在 TCP 模式下处理数据包负载。代理协议要求整个PROXY 消息出现在第一个数据包中。 (该协议甚至被设计为保证数据始终适合单个段。)如果 ELB 曾经对其进行分段,则目标将需要具有容错性。这似乎不太可能成为问题,但请注意这种可能性,如果最终目的地间歇性地认为传入流无效。