我对 Netscaler 不熟悉，所以请持保留态度。

我假设您今天使用 NAT 来转换请求的源地址，因此实际服务器今天看到的不是真实的请求地址，而是由 Netscaler 转换的一些单个 NAT 地址。我还假设他的切换会删除该源地址 NAT，让您的服务器看到真实的请求地址。

在某些情况下，您希望对请求地址进行 NAT，例如，如果出于冗余目的，您希望将服务器同时连接到两个或多个 SLB 设备（谁将 ECMP VIP，即两个 SLB 都是热的：热的，但不是以任何方式相互连接）。然后，当您的服务器回复请求时，它需要通过原始查询来自的同一接口进行回复。

在 Linux 机器上，您可以轻松解决此问题，而无需依赖 SLB 的源代码。

在 Windows 服务器上，除非您对每个请求进行 NAT，否则您实际上没有任何方法将请求返回给发送它的 SLB。如果SLB1 NATs源到192.0.2.1，SLB2 NATs源到192.0.2.2，那么只需在windows中设置静态路由，192.0.2.1/32指向SLB1，192.0.2.2/32指向SLB2。这样你总是将数据包返回给发送请求的 SLB。

其影响取决于您的服务器相对于 LB 和客户端的位置。

如果客户端在 LB 前面而服务器在后面，这样返回流量（服务器到客户端）已经通过 LB，那么应该不会有任何影响。

如果客户端和服务器都在 LB 的“前面”，那么您必须将源地址 NAT 转换为 LB 上的 IP，以便返回流量到达 LB。在这种情况下，如果应用程序需要查看客户端 IP，您可以让 LB 将其插入 HTTP 标头（当然假设为 HTTP），例如 HTTP_FORWARDED_FOR。如果它不是 HTTP，那么我不知道有什么方法可以让它在没有 NAT 的情况下工作。

这确实是一个设计决策，您已经得到了一些很好的答案。有很多原因可以同时做，但这里有一些可以同时做的原因。

如果您有多个处于某种主动/主动状态的负载平衡器，您可能希望将其禁用，以便负载平衡器后面的服务器响应正确的负载平衡器。如果他们将流量发送回错误的负载均衡器，这可能会产生问题（同样基于设计）。

但是，如果您的服务器正在执行日志记录或需要在任何响应中使用实际源地址，则需要将其打开。