ASP.NET Web API连接超时排查求助：仅特定客户端应用无法连接

1. 故障大概率归属 #

• 客户端环境（防火墙/安全软件）：头号嫌疑。防火墙、企业级安全软件确实会区分程序放行规则——比如默认允许浏览器（Chrome、Edge等）访问外部端口，但自定义开发的.NET应用可能被识别为未授权程序，直接拦截出站请求。这种“区别对待”的情况在企业环境里很常见。
• 客户端应用配置/环境：次之。比如该客户端的.NET应用配置文件里API地址被本地修改（虽然其他客户端正常，但不排除人为改动），或者客户端的.NET运行时版本过低，导致TLS协议不兼容——浏览器会自动适配服务器的TLS版本，但旧版.NET可能硬编码了过时的TLS版本，无法连接服务器。
• 服务器端：基本可以排除。其他客户端正常、该客户端浏览器能访问，说明服务器的IIS、防火墙、API服务都处于正常状态。

2. 无客户端权限下的定位方法 #

服务器侧可执行的排查步骤 #

• 查看IIS日志：在服务器IIS的站点日志中搜索该客户端的IP，如果完全找不到对应请求记录，说明请求根本没到达服务器，100%是客户端侧拦截；如果有请求记录但返回异常（如4xx/5xx状态码），再针对性排查API业务逻辑。
• 验证端口监听状态：用PowerShell执行 Test-NetConnection localhost -Port 你的API端口，确认服务器自身能正常访问API端口；同时引导客户端联系IT同事，从客户端侧执行 Test-NetConnection 你的服务器IP -Port 你的API端口，对比两边的连通结果。
• 检查服务器防火墙黑名单：虽然其他客户端正常，但仍需确认服务器防火墙入站规则中，是否误将该客户端IP加入黑名单。
• 测试TLS兼容性：检查服务器IIS绑定的TLS版本（如是否仅启用TLS 1.2/1.3），再确认你的.NET应用默认使用的TLS版本。若应用使用TLS 1.0/1.1而服务器已禁用这些版本，就会出现浏览器能连但应用连不上的情况。可临时在服务器开启旧版TLS做测试（测试后需关闭），或引导客户端在应用中添加代码 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13; 验证。

引导客户端完成的验证（让用户反馈结果） #

• 检查本地安全软件拦截记录：让客户端查看防火墙、杀毒软件的日志，确认是否存在拦截你的.NET应用出站请求的记录，或是否设置了“仅允许指定程序联网”的规则。
• 用命令行测试连通性：让客户端执行 curl 你的API端点 或PowerShell命令 Invoke-WebRequest 你的API端点，若命令行也失败，说明是客户端侧网络拦截；若命令行成功，则问题出在应用自身。
• 核对应用配置：让客户端对比正常客户端的应用配置文件，确认API地址、端口完全一致，无本地修改。
• 检查.NET版本：让客户端查看自身的.NET运行时版本，与正常客户端对比，版本差异可能导致网络请求逻辑异常。

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