IIS 10+Server 2016环境下负载均衡WCF服务单节点无响应求助

这种情况我之前在负载均衡WCF集群的场景里碰到过，结合你给出的细节——仅返回静态字符串的方法却出现服务器无响应、追踪日志只有TransportReceive、移除HAProxy池就恢复——核心问题大概率出在连接资源耗尽或者负载均衡与WCF的连接配置不匹配上，咱们一步步拆解：

先解读追踪日志的关键信息 #

正常请求的4条追踪记录是完整的请求处理链路：TCP接收请求→WCF服务层接收→服务层返回响应→TCP发送响应。而故障服务器只有TransportReceive，说明：

• TCP层面已经收到了HAProxy转发的请求
• WCF Runtime没有继续处理这个请求（既没进入服务方法，也没返回错误）

这种情况几乎都是服务器没有可用资源来分配新请求导致的，因为你的方法只是返回静态字符串，不可能在业务逻辑里卡住。

具体排查方向与解决步骤 #

1. 检查WCF的节流与绑定配置 #

WCF默认的并发连接限制很低，在负载均衡场景下很容易被打满：

• 打开你的WCF服务配置文件，确认是否配置了<serviceThrottling>节点，建议调整到适合集群的数值：

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <!-- 根据你的负载情况调整，以下是参考值 -->
          <serviceThrottling maxConcurrentCalls="1000" 
                             maxConcurrentInstances="2000" 
                             maxConcurrentSessions="1000"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <bindings>
      <!-- 以basicHttpBinding为例，其他绑定类似 -->
      <basicHttpBinding>
        <binding maxConnections="1000" 
                 receiveTimeout="00:10:00" 
                 sendTimeout="00:10:00">
          <readerQuotas maxStringContentLength="65536"/>
        </binding>
      </basicHttpBinding>
    </bindings>
  </system.serviceModel>
  

• 重点关注maxConnections（控制并发连接数）和节流参数，默认值可能只有几十到几百，远不足以应对HAProxy的批量请求。

2. 检查HAProxy的连接与负载策略 #

HAProxy的长连接配置如果和后端WCF不匹配，会导致半开连接积累：

• 查看HAProxy配置文件，确认是否启用了option http-keep-alive（默认开启），同时检查超时设置：

  timeout connect 5s
  timeout client 30s
  timeout server 30s
  timeout http-keep-alive 1m
  

  确保timeout http-keep-alive不超过WCF绑定的receiveTimeout，否则HAProxy保持的长连接会在WCF端超时失效，但HAProxy还会继续用这个连接发请求，导致无效请求积累。
• 检查负载均衡策略，如果用的是source（源IP哈希），可能某类请求会持续打到同一台服务器，导致单台过载；建议换成roundrobin或者leastconn（最少连接数）策略，更适合WCF集群。
• 确认HAProxy的健康检查配置，比如是否配置了server <name> <ip>:<port> check，如果健康检查的频率太低，服务器卡住后HAProxy还会继续发请求，加重负载。

3. 检查服务器的TCP连接状态（故障发生时立刻执行） #

当服务器出现故障时，立刻在涉事VM上执行以下命令，查看连接资源是否耗尽：

• PowerShell命令：

  Get-NetTCPConnection -RemoteAddress <你的HAProxy服务器IP> | Group-Object -Property State
  

• 或者CMD命令：

  netstat -ano | findstr <HAProxy_IP>
  

如果看到大量ESTABLISHED或者TIME_WAIT状态的连接，说明TCP连接池被占满了。此时可以调整Windows的TCP参数：

• 修改注册表（需重启服务器）：
  • TcpTimedWaitDelay：设置为30（单位：秒，默认240），让TIME_WAIT状态的连接更快释放
  • MaxUserPort：设置为65535（默认49152），增加可用的客户端端口数

4. 检查IIS应用程序池配置 #

IIS的应用程序池限制也可能导致请求无法处理：

• 打开IIS管理器，找到WCF服务对应的应用程序池，右键→高级设置：
  • 调整“队列长度”（默认1000），可以适当调大到2000
  • 如果服务器是多核心，将“最大工作进程数”设置为大于1（即启用Web Garden），分散请求压力
  • 确认“闲置超时”设置，避免应用程序池无故回收（但你的情况是移除池就恢复，这个可能性较低）

总结最可能的根本原因 #

你遇到的问题几乎可以确定是HAProxy的长连接与WCF/IIS的连接参数不匹配，导致单台服务器的连接资源被耗尽：

• HAProxy持续通过长连接发请求，而WCF的并发连接限制过低，或者TCP连接无法及时释放
• 当连接资源耗尽时，新请求只能到达TCP层（产生TransportReceive日志），但WCF无法分配资源处理后续步骤
• 移除负载池后，HAProxy不再发请求，服务器的连接逐渐释放，因此恢复正常；重新加入后，连接又被快速占满，再次故障

内容的提问来源于stack exchange，提问作者Wjdavis5