某医院为保证应用的可靠性，部署了负载均衡设备，组建服务器集群，对外提供服务。如下图所示
两台真实服务器地址为133和134，负载均衡虚拟出的地址为1，正常情况下，客户访问服务虚地址，然后由负载均衡设备把客户访问流量分担到两台真实服务器上。
问题现场为，部分终端访问虚IP，业务正常，部分终端不正常，并且终端不固定，可能上午正常，下午就不正常了。
第一步，排查物理服务器是否正常，访问真实地址，两台服务器均正常。
第二步，登录负载均衡设备，检查配置，配置没有问题，但是发现多个用户尝试访问时，只有133的服务器有会话链接记录，134的服务器会话一直为0。怀疑134服务器的配置是否有问题，再次检查负载均衡配置，没有问题。
第三步，在终端上开启抓包，然后不停的访问服务器虚地址，抓取正常和非正常时候的报文进行对比。正常情况下，终端访问虚地址，所有的报文都是应该与虚地址进行交换机，不应该看到真实服务器的地址，实际抓包也是如此；但当出现问题无法访问时，在抓包时看到了服务器的真实地址，由于客户端的TCP握手发起目标地址并非是服务器真实地址，导致此TCP会话不停的重置，最后失败。
直接原因找到了，但是为什么访问虚IP地址，最后会是真实服务器返回的报文。从整个报文的流程上进行分析。
1.终端A访问虚IP，IP包为A to 1；
2.负载均衡将会话负载到134服务器上，服务器收到的IP包为 A to 134
3.服务器回的报文为134 to A，这么看PC收到134的包是正确的，但是会出问题的
解决这个问题的关键就是服务器134回的包要先到负载均衡，由负载均衡用自己的虚IP把134这个地址替换掉，这就是此问题的关键点，服务器134的网关不能设置真实的网关，而需要把网关设置为负载均衡的IP地址。这样，服务器回应的报文就会先到达负载均衡，然后完成IP替换后返回给客户端A，之后一切正常。
负载均衡在网络中部署的方案有多种，不同的方案，又会采用不同的报文处理方式，本方案中是采用二层旁挂的方式，采用的IP地址替换的方法。大家在处理负载均衡问题时，一定要先分析清楚组网结构及采用哪种方案，报文如何传递，才能更快的解决问题。
