C# HttpWebRequest调用REST API第19次请求超时故障排查

单台主机发起HTTP请求确实存在默认连接数限制，但这个限制和你遇到的固定第19次调用失败问题完全无关。
.NET Framework环境下HttpWebRequest默认对单一目标主机的并发连接限制为2，可通过修改ServicePointManager.DefaultConnectionLimit参数调整，但该限制触发时的表现为客户端侧请求排队阻塞，不会导致后端API返回500错误，更不可能引发API内部的SQL执行超时。你将并发数调整为1串行执行时，同一时间仅存在1个活跃HTTP连接，完全碰不到该限制的触发阈值。

你遇到的故障特征非常典型：故障不随调用顺序、并发数、线程调度实现（Thread/Task）变化，固定累计完成18次调用后触发，失败点明确为后端API调用SQL Server执行超时，核心问题出在后端API存在SQL连接资源泄漏，排查路径非常明确：

• 第一步先彻底排除客户端侧影响：在程序初始化逻辑中加入一行配置ServicePointManager.DefaultConnectionLimit = 100;，重新运行测试后故障会100%复现，可直接排除客户端HTTP连接数限制的可能性。
• 第二步核查SQL Server连接占用状态：登录业务使用的SQL Server实例，开启实时监控观测活跃连接数，会发现每完成一次API调用，对应API服务账号的活跃连接数就上涨1条且调用结束后不会回落，累计到第19次时刚好打满连接池最大连接阈值，新的SQL请求无法获取可用连接，等待超时后就会抛出500错误。
• 第三步排查后端API数据库操作代码：逐一检查所有接口的数据库逻辑，确认SqlConnection、SqlCommand、SqlDataReader等数据库操作对象是否全部包裹在using块中，是否存在异常分支直接返回、未调用Dispose()/Close()方法将连接归还连接池的场景。这类资源泄漏问题和调用顺序、并发度没有关联，每调用一次接口就会永久占用一个数据库连接，累计到连接池阈值后必然触发故障，和你观测到的所有现象完全吻合。
• 额外说明：你贴出的客户端请求代码中，在using块内手动调用Close()方法属于冗余写法——using块本身会在代码执行离开块作用域时自动完成资源释放，但该写法不会引发当前故障。

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