我们在公司网络中的非面向互联网的服务器上有两个应用程序。一个应用程序（客户端应用）通过 API 从另一个应用程序（服务器应用）获取数据。
客户端应用程序使用 PHP 库 Jyggen''Curl 来调用 API。周五，用户开始报告客户端应用的错误。当我检查错误日志时，我可以看到 Curl 请求间歇性地失败并出现错误：
连接到服务器应用程序失败：80;无错误
我能够通过自己单击客户端应用程序中的不同页面来重现这一点 - 最终 API 调用将失败，PHP 库将引发异常。错误今天仍在继续，我也能够使用 curl 从命令行重现它.exe - 我必须执行命令 10-15 次才能得到错误，但它最终发生了。
用户也可以在浏览器（以及 API）中直接访问服务器应用程序，我们在那里没有遇到任何问题。
就客户端应用程序的使用而言，Curl 错误似乎发生在一天中最繁忙的时期（英国时间上午 9 点至下午 3 点）。这两个应用都在 IIS 上运行，并允许足够的最大并发用户数。
我目前的两个理论是：
- 网络问题 - 企业IT看不到任何问题
- 卷曲问题 - 关于一次可以发出多少个卷曲请求，我是否不知道？在过去的几个月里，我们的用户数量一直在稳步增长，所以也许我们才刚刚达到它开始引起问题的临界点？如果相关的话，我们不会使用curl_multi。
接下来要检查的任何提示/想法将不胜感激。
更新
我今天早上设法在浏览器中重现了该错误。我检查了 IIS 日志，当时我是唯一使用客户端应用程序的人（没有其他人使用它超过 10 分钟）。因此，我建议客户端应用程序上的流量不是一个因素。
（为什么人们坚持将完全合理的API包装在过于复杂的OO中？
这不是一个真正的编程问题 - 它是关于故障查找，很可能是一些与基础设施相关的问题。
如果客户端连接失败，则连接被拒绝或超时。您应该有足够的信息来确定哪些适用于此处。
如果连接被拒绝，则不会有明显的延迟。您需要查看拒绝连接的原因（在没有代理或IPS的情况下，这将是IIS实例）并找到原因。
如果连接超时，则问题可能是网络上丢弃的数据包，或远程服务器上的问题。增加连接超时将有助于后者。开始收集客户端连接所需的时间，并查看是否存在任何模式（检查与其他事件（如备份）的相关性）。如果没有任何明显的模式/增加时间无济于事，那么这就是数据包丢失问题。