所以我一直在想这个问题已经有一个星期了。 这里是跑下来：
我在PHP中使用CURL从API中提取数据。 随着对API调用的响应变得越来越大（一次超过15k条logging），我注意到任何需要5分钟或更长时间（几秒钟内）的API调用都无法在我的CentOS和Suse服务器上返回。 所以，我通过CURL从CLItesting了API调用，并得到了同样的问题。 奇怪的是，如果我通过OS X运行CURL命令，命令运行良好，并在大约7分钟后返回。
这里是通过CURL运行的命令（creds censored）：
curl -m 0 -k --trace-ascii trace.txt --trace-time -X GET -H "tenant-code: 1cmPx7tqVDVTdN1GSelwycFUmICmASnLCmNQsV72" -H "Authorization: Basic JxHAsXeUiHMRkS8Msiu6pWb3PvY20p6am3QvXCY3knXTAntlxTBS3EyEDgly" -H "Content-Type: application/json" -H "Cache-Control: no-cache" 'https://api.endpoint.com/API/v1/system/users/search?groupid=555' > dump.txt 这里是CURL为每个平台输出的版本：
CentOS（这是我真的需要这个工作） –
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Suse-
curl 7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
OS X-
curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1 SecureTransport zlib/1.2.5 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
这些是我从Centos得到的错误代码：
curl: (56) SSL read: errno -5961
我找不到在文档中引用的代码。 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/sslerr.html
我从Suse得到一个稍微不同的错误：
curl: (52) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
错误104使我相信服务器正在停止/重置连接，但服务器端日志不显示它被丢弃，OS X可以毫无问题地提取数据。 我甚至试图欺骗用户代理，以确保这不是问题。
所以，在这一点上，我假设SSL包SecureTransport正在做一些OpenSSL和NSS没有做的事情。 问题是什么，如果不是，问题是什么？
在MacOSX机器上运行curl命令，但不要redirect输出，让它stream到你的shell窗口。 看看是否有任何缓冲，IE浏览器，你是否从一开始就得到输出，一点点，或者你5分钟没有得到任何东西，然后大量的数据一次？
在超时的机器上再次运行curl命令，并比较其行为。 如果您的输出被API服务器上的某个后台进程缓冲，则在完成查询之前可能无法获得结果。 您的客户端应用程序，客户端操作系统，服务器的操作系统，服务器的REST API以及它们之间的SSL可能具有非零的超时值，如果该计时器在5分钟内没有看到任何数据stream，可能会closures你的连接，而没有说明为什么。 我发现在基于HTTP的服务中发生了这种情况。 在perl中我习惯性的放一个$|=1; 在代码的顶部禁用服务器端的输出缓冲。
第三方设备（如Cisco ASA）也有可能使NAT规则超时并触发问题。 AMANDA备份尝试从ASA外部客户端读取时遇到此问题。 如果客户端花费很长时间通过ASA将大小估计返回给AMANDA服务器，则ASA将丢弃其dynamicNAT规则，并且备份失败。 这个build议值得研究，如果工作的MacOSX在它和API服务器之间没有防火墙，但是失败的Mac OS X有一个。
如果MacOSX的超时值设置为0（永远等待），Linux默认为60或90秒的限制，那么我不会感到惊讶。