我们将 Palo Alto 的 VM 防火墙与 ELB 的 sandwich topology 一起使用，但无法获得正确的 X-Forwarded-Proto 以使其一直返回到 Web 服务器。 HTTPS 终止发生在外部负载均衡器上，然后作为 HTTP 通过堆栈的其余部分运行。使用单个负载均衡器，无论是 HTTP 还是 HTTPS，检索正确的 X-Forwarded-Proto 标头都没有问题。但是，在三明治拓扑中，无论如何我们都会将 HTTP 作为 X-Forwarde-Proto。
我们需要标头的主要问题是将所有请求重定向到 HTTPS，这可能可以在 PAN 防火墙上完成，但这也被证明是难以捉摸的。
【问题讨论】：
标签： amazon-web-services aws-load-balancer web-application-firewall
这是预期的行为，很可能是设计使然——如果 ALB 传递了X-Forwarded-Proto，它可能是伪造的，并且它们没有内置任何允许异常的能力......所以它总是被覆盖。
您可以改为在内部使用网络负载均衡器。由于它们在第 4 层运行，因此它们不会操纵标头。
或者，如果面向外部的平衡器是 ALB，您可以在那里创建一个规则，将所有 HTTP 请求重定向到 HTTPS，在平衡器内。
通过重定向操作，负载均衡器可以将传入请求从一个 URL 重定向到另一个 URL。这包括将 HTTP 请求重定向到 HTTPS 请求的功能，这使您能够满足安全浏览的合规性目标，为您的网站获得更好的搜索排名和较高的 SSL/TLS 分数。
关于 ALB 重定向的一个小问题是，您必须将目标端口明确指定为 443，否则平衡器将保留原始端口并将重定向写入 https://example.com:80/，这当然不起作用。
【讨论】：
这可能不是您要寻找的答案，但如果您在传输层使用基于 TCP 的网络负载平衡器而不是在应用层使用 HTTP/S 侦听器，则此架构将起作用。
传输负载均衡器在将请求代理到目标时根本不会考虑协议，整个 HTTPS 将保持完整。应用程序负载均衡器将解释其策略并按设计覆盖X-Forwarded-Proto。
【讨论】：