.NET Core 2 Web API生产环境调用WCF出现地址解析错误

我遇到过不少类似的跨环境WCF调用失败的情况，开发环境正常但生产环境报错，大概率是环境差异导致的配置、网络或者权限问题。咱们可以从以下几个方向逐步排查：

1. 先确认生产环境网络连通性 #

这是最常见的原因——生产服务器可能和WCF服务所在机器不在同一个网络段，或者防火墙/安全组拦截了请求：

• 在Web API所在的生产服务器上，打开命令提示符运行 telnet 192.168.100.33 3433，如果提示“无法打开连接”，说明网络不通，得联系运维团队检查防火墙规则、服务器安全组或者路由配置。
• 用PowerShell的话可以跑 Test-NetConnection 192.168.100.33 -Port 3433，看输出里的TcpTestSucceeded是不是True，如果是False，直接定位到网络问题。

2. 验证WCF服务端本身是否正常运行 #

有时候不是Web API的问题，是WCF服务在生产环境根本没正确启动：

• 登录到WCF服务所在的服务器，在本地浏览器访问 http://localhost:3433/Test.svc，如果能正常打开服务说明页面，证明服务是正常的；如果打不开，检查IIS站点绑定是否正确（端口3433有没有绑定到对应站点），或者WCF服务的web.config有没有配置错误（比如endpoint地址、binding设置）。
• 检查WCF服务的web.config里的<endpoint>节点，确认address属性和你调用的地址一致，binding是对应HTTP类型的（比如basicHttpBinding），并且已经启用了元数据交换（方便测试）。

3. 排查IIS与Kestrel的出站请求限制 #

因为生产环境是IIS托管Kestrel，反向代理可能会限制对外请求：

• 如果IIS配置了ARR（应用请求路由），检查ARR的出站规则，确保没有阻止到http://192.168.100.33:3433的请求。
• 可以在Web API代码里加一段日志，记录发起WCF请求时的实际地址和配置参数，确认代码里用的地址确实是生产环境的WCF地址，而不是硬编码的开发环境地址。
• 检查Kestrel的配置（比如appsettings.json里的Kestrel节点），有没有设置限制出站连接的参数，不过这个概率相对小一些。

4. 核对.NET Core WCF客户端的配置 #

开发环境的配置可能没同步到生产环境：

• 检查Web API的appsettings.json（或者其他配置文件）里的WCF端点地址，确保生产环境的配置是http://192.168.100.33:3433/Test.svc，而不是开发环境的本地地址。
• 如果是通过代码创建WCF通道，确认代码是从配置读取地址，而不是硬写死的开发环境地址。比如：

  var endpointAddress = Configuration["WcfSettings:TestServiceEndpoint"];
  var binding = new BasicHttpBinding();
  var client = new TestServiceClient(binding, new EndpointAddress(endpointAddress));
  

• 检查客户端绑定的超时时间，生产环境网络可能更慢，超时时间设置太短也会导致请求失败。

5. 检查权限与身份验证 #

如果WCF服务启用了身份验证，生产环境的应用池身份可能没权限访问：

• 如果WCF用的是Windows身份验证，检查Web API的IIS应用池身份是否有访问WCF服务的权限。可以临时把应用池身份改成有权限的域账号或者本地管理员测试（测试完记得改回）。
• 在WCF客户端代码里，确认是否设置了正确的凭据，比如：

  var client = new TestServiceClient();
  client.ClientCredentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password", "domain");
  

按照这个顺序排查，基本能定位到问题所在——毕竟开发环境正常，说明代码逻辑是对的，就是生产环境的某个配置或者网络环节出了问题。

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