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