为了调试nginx错误情况，我需要首先完全理解错误日志消息。我们的nginx会不时写出特定的错误日志消息。
记录消息
“SSL握手中的对等关闭连接（104：通过对等方连接重置），而SSL握手到上游”。
“同行”是什么意思？
我想知道：“peer”是指上游，意味着上游在ssl握手期间关闭了连接，还是引用了客户端，这意味着客户端在负载均衡器和Web服务器时关闭了连接在握手期间内部？
设置
答案 0 :(得分：5)
在这种情况下，Peer指的是上游。仅仅因为如果我们认为对等方是客户端，那就意味着两个SSL握手（客户端 - > nginx，nginx - >上游）同时发生，这没有意义 - 客户端必须建立连接并发送查询，只有这时nginx才能选择合适的上游来连接
答案 1 :(得分：1)
您的问题可能与您将Comodo .bundle文件与您的网站证书连接在一起的订单有关。
您需要在网站证书之后放置捆绑文件。
Click this link for more details
同伴必须是同一个＆＃34;级别＆＃34;作为Nginx，因为你的问题与SSL有关，必须是OpenSSL。
我猜你的操作系统是Ubuntu 12.x而OpenSSL是1.0.1。如果是这样，那么问题很可能与Ubuntu错误有关。
似乎您需要升级到Ubuntu 13.04或禁用TLS 1.1。
Click this link for more details
无论如何，同伴不是上游。
答案 2 :(得分：0)
经过几个小时的调试后，我们终于找到了问题的实际原因。该错误消息是由请求没有域的nginx的客户端产生的，例如， https://11.22.33.44/robots.txt。 Nginx然后将请求转发到IIS服务器，该服务器没有绑定到https的任何默认网站用于ip-alone-requests。
原始问题的结论是，“对等”实际上是指上游（IIS），因为IIS是切断连接的那个。
我们选择解决此问题的解决方案是不在nginx中获取此错误，从而避免客户端以“向下”方式发送所有服务器的曝光 - 模式是配置nginx自行拒绝这些请求。另一种可能的解决方案是确保IIS在这些请求中表现良好。