假设有两台服务器 A、B 位于负载均衡器后面，例如，它们可能是两个 docker 容器。如果服务器 A 向 some-site.com 发出 HTTP GET 请求，则响应可能会由负载均衡器传送到服务器 B。根据我的理解，外部只有一个可见的 IP 地址，负载均衡器是一个网络层设备，它会随机将收到的 IP 数据包发送到它正在平衡的服务器之一。我想我在这里遗漏了一些基本的东西，比如负载均衡器的工作原理可能像 NAT 路由器？
答案1
从理论上讲，这对于某些（通常是较旧的）负载平衡器来说是可能的，但会代表配置损坏并且无法工作。
对于 IP，每个数据包都有一个源 IP。其余 IP、源端口和目标端口。源端口可能是缺失的环节。它与目标端口不同，这意味着可以判断请求的方向。例如，对于 http 请求，如果数据包具有外部源地址和源端口 > 1024，则它是传入请求，但如果源 IP 是外部的并且源端口是 80，则它是传出请求。
值得注意的是，对于 http(s)，大多数负载均衡器实际上会终止连接，然后建立与最终服务器的第二个连接。（对于 https，此模型还可以通过处理 https 加密来减少负载）。负载均衡器后面的应用程序将连接视为来自负载均衡器，并知道原始发送者的 IP 地址，因为负载均衡器添加了包含原始 IP 地址的 X-Forwarded-For 标头。此解决方案比在 IP 级别处理数据包更具可扩展性，因为负载均衡器后面的服务器不需要直接连接到它。
我还评论说，虽然连接可以随机分布，但更常见的是根据其他指标（例如以前的请求、请求的资源）来分配请求，并且连接通常会被跟踪，因此除非服务器出现故障，否则来自客户端的请求都会发送到同一个后端服务器。
答案2
通常，在讨论 A 和 B 上的服务负载平衡时，这就是传入通过反向代理建立连接。非常简单，结果是 IP 流，因此服务器可以响应请求。
也可以配置传出连接（从 A 到 whatever.example.com）需要经过一致的服务地址。通常是“正向”（而非反向）代理，就像 Web 浏览器的 HTTP 代理，但适用于服务器应用程序。这是对传入请求的负载平衡器的补充。
据我了解，外部只有一个可见的 IP 地址
这部分是传统 IPv4 的假设。使用 IPv6，拥有负载均衡器服务地址是合理的，例如2001:db8::443代理到后端2001:db8::a和2001:db8::b。如果路由和防火墙策略允许，每个都可以访问互联网。在这种情况下，使用 v6，无需 NAT 即可直接访问。