我读过，即在Rackspace上，不应该对敏感信息使用 SSL 终止（在页面上搜索“不应使用 SSL 终止”）。首先，为什么会这样。其次，如果您不能相信数据已安全传输，那么拥有 SSL 到底有什么价值？
我对第一个问题的猜测是，如果有人X-Forwarded-For知道服务器的直接 IP，就可以添加带有 HTTPS URL 的标头，完全绕过负载均衡器，并进入端口 80。我可以通过 iptables 克服这个问题（仅允许来自负载均衡器的端口 80），对吗？
注意：我的服务器与负载均衡器位于同一专用网络中（关于“安全问题是什么？”那篇 Rackspace 文章中的注释）。
他们告诉您的是，如果您选择让您端的 SSL 端点位于负载均衡器中（而不是负载均衡器路由到的服务器），那么您应该意识到，无论数据有多安全在去往负载均衡器的路上比一旦它离开负载均衡器就畅通无阻。在私有数据中心，将 SSL 处理卸载到负载平衡器或专用硬件，然后让内部管道（以前包裹在 SSL 中的管道）继续到常规网络服务器进行服务并不少见。
他们给出的警告是，如果您的云服务器与您的负载均衡器不在同一个数据中心，那么如果您在负载均衡器中解包 ssl 会话，那么从它们到网络服务器的流量将是透明的并通过公共网络路由。
至于你对 X-forwarded-for 的猜测，你误解了它们的意思。他们说，如果您的 Web 服务想要确保客户端使用 SSL，但您正在剥离负载均衡器上的 SSL 包装器，那么他们可以让负载均衡器为您的 Web 服务器贴上一个额外的标头，以便您知道客户端DID 使用 SSL 即使您的网络服务器会说没有使用 SSL。
希望能帮到你
您提到的 rackspace 文档有点不清楚，但我相信其意图是：
您希望敏感信息尽可能多地使用 SSL。（从客户端一直到你的数据库）
如果您在负载均衡器层启用 SSL 终止，则安全性会停在那里。（敏感数据将以明文形式在您的负载均衡器层和您的应用程序层之间传输。）
我相信这是文档中的意图。您应该避免任何未加密的敏感数据传输。
是的，您可能在同一个“专用网络”中，但您的客户将通过端到端的加密流量得到更好的服务。
祝你好运。