当我尝试使用curl（或wget，lynx等）从我们的本地networking上的服务器连接到我们的网站（位于CoyotePoint负载平衡器后面的本地服务器上）时，curl会失败。 平安没有这个问题。
当我直接卷到任何负载均衡器后面的服务器（从同一个本地networking），我也没有问题。 无论我的本地服务器是否在负载均衡器后面，都没有关系。
有没有人有任何想法，为什么我不能通过我的本地networking上的负载平衡器访问我的networking服务器？
编辑：附加信息：
来自curl的错误信息：
* Trying [ip address]... connected * Connected to [web address] ([ip address]) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.6.2 zlib/1.2.3 libidn/1.9 libssh2/1.2.4 > Host: [web address] > Accept: */* > * Closing connection #0 * Failure when receiving data from the peer curl: (56) Failure when receiving data from the peer IP地址是正确的外部地址，而不是内部networkingIP。
我正在试图使用url，而不是一个IP地址curl。 该url通过我们的负载均衡器parsing为正确的IP地址以连接到站点（外部）。
据我了解我们的networking（我显然不是这方面的专家），我们所有的服务器和负载均衡器都在同一个networking上。
什么样的负载平衡？ （你在networking层，应用层等负载均衡）; 还定义“不工作”
我打算冒险，猜测你的后端服务器的NAT或路由configuration错误，你的本地子网。 即：您可以击中负载平衡器，负载平衡器将stream量踢向您的一台服务器，但服务器无法将数据包返回给您。
popup打开wireshark并看看你的TCP连接失败/失速的地方。
另外，PING（ICMP）和TCP是完全不同的野兽。
如果我了解您的networking权限，则您的客户端和源服务器都在networkingA上，而负载均衡器VIP在networkingB上？
这意味着LB必须首先将其请求转发给networkingB，然后返回到networkingA.一些负载均衡器可以这样做（见F5和Foundry至less以这种方式设置），但是它是非标准configuration，依赖于供应商通常默认情况下不启用。
不幸的是你的问题有一点含糊不清，要给出具体的答案，如果你能回答以下问题，我们可能会提供更多的帮助。
什么是networking设置？ 例如，networkingA中的所有服务器，包括负载均衡器后面的服务器，负载平衡的VIP都位于单独的networking上。
如果是这种情况，那么我不认为负载平衡器会回复任何关于VIP请求的请求，因为这些请求是进入内部networking的，因为它担心它们不应该使用VIP并且将忽略stream量。
我已经看到这种情况发生在内部networking上的服务器尝试访问同一networking上的另一台服务器的防火墙上，防火墙丢弃了该数据包，因为它不是该接口上列出的范围，而另一台服务器将其忽略为它对外部IP一无所知。 我不是100％确定的，但我希望同样适用于负载均衡器，但我从来没有真正尝试过。
你怎么连接？ 您是否使用了URL或IP地址，如果您使用的是某个URL地址，则在您ping通该地址时返回该地址，则可能需要编辑本地主机文件或该域的DNS
从你的更新，我正确地认为外部地址是通过防火墙上的NAT提供的，因此我相信curl请求如下，
你能否尝试更新服务器主机文件来parsing域名到VIP的内部IP，并再次testing，如果这个工作，你可能想检查你的防火墙是否支持DNS修改（更多信息在这里 ）。
对于在Kemp Load Master负载均衡器后面的SUSE Linux Enterpirse服务器（SLES）上运行的3个Web服务器，我们遇到了类似的问题。 在我们的情况下，默认情况下（自第11版开始），SLES随反向数据包过滤开启。 此function将保持http（s）stream量不stream经负载均衡器。 要closures这个“function”，我不得不编辑/etc/sysctl.conf文件并更改下面一行：
net.ipv4.conf.all.rp_filter = 1
至
net.ipv4.conf.all.rp_filter = 0
然后做一个
sysctl -p
一切看起来都很开心。
听起来就像你有在NAT模式下的负载平衡器。 如果您尝试通过负载均衡器连接到您的Web服务器，则会看到您位于本地子网上，并尝试直接回复您（由于负载平衡器已经对stream量进行了NAT转换，因此会失败）更改负载平衡服务器上的路由：
为了纠正Linux服务器的这个问题，我们需要修改本地networking路由，通过改变一个更高的指标：
route del -net 192.168.1.0 netmask 255.255.255.0 dev eth0 route add -net 192.168.1.0 netmask 255.255.255.0 metric 2000 dev eth0
注意用您的本地子网地址replace192.168.1.0。 然后，我们需要确保本地networking访问使用负载均衡器作为其默认路由：
route add -net 192.168.1.0 netmask 255.255.255.0 gateway 192.168.1.21 metric 0 dev eth0
注意用您的负载均衡器网关replace192.168.1.21
这在Loadbalancer.org手册的第83页单臂（单子网）NAT模式一节中有更详细的解释。