Nginx uwsgi（104：ピアによる接続のリセット）が、アップストリームから応答ヘッダーを読み取り中
環境はNginx + uwsgiです。
特定のGETリクエストでNginxから502 bad gatewayエラーを取得します。 URLの長さに関係しているようです。特定のケースでは、GETパラメーターの長いリストでした。 GETパラメーターを短くし、502エラーはありません。
Nginx/error.logから
[error] 22113#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.100, server: server.domain.com, request: "GET <long_url_here>"
Uwsgiエラーログに情報がありません。
これに多くの時間を費やした後、私は最終的にそれを見つけました。 Nginxへの多くの参照とピアによる接続のリセットがあります。それらのほとんどはPHPに関連しているようです。 Nginxとuwsgiに固有の答えが見つかりませんでした。
最終的に、fastcgiへの参照と502 bad gateway error（ https://support.plesk.com/hc/en-us/articles/213903705 ）が見つかりました。そのため、 buffer-size として存在するuwsgi構成のバッファーサイズ制限を探すことになりました。デフォルト値は4096です。ドキュメントから、次のように書かれています。
大量のヘッダーを含む大きなリクエストを受信する場合は、この値を最大64k（65535）まで増やすことができます。
Uwsgiを設定するには多くの方法がありますが、たまたま.iniファイルを使用しています。だから私の.iniファイルで試しました：
buffer-size=65535
これにより問題が修正されました。好みに合わせて調整できます。最大値から始めて、許容値になるまで戻るか、最大値のままにしてください。
物事のuwsgi側にエラーがなかったため、これを追跡するのはイライラしました。
同じnginxエラーが発生していましたが、uwsgiログにも情報がありませんでした。問題は、 http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html ：
HTTPリクエストにボディがある場合（POSTフォームによって生成されたリクエストなど）、アプリケーションでそれを読み取る（消費する）必要があります。これを行わない場合、通信ソケットは怠areな場合は、自動的にデータを読み取るポストバッファリングオプションを使用できます。ラックアプリケーションの場合、これは自動的に有効になります。
もちろん、これはあなたの場合には問題ではありませんが、同じnginxエラーを受け取っている他の人にとっては役に立つかもしれません。
おかげで、PHPサーバー。値。
ほとんどの場合、(104: Connection reset by peer) while reading response header from upstreamのようなメッセージを受信すると、この種のエラーの上流側のせいにすることができます。
説明したように、接続はnginx自体ではなく、アップストリームピアによってリセットされました。クライアントとしてのNginxは、それを正しくするためにほとんど何もできません。
Buffer-sizeを変更することが魔法の役目を果たすかどうか疑っています。基本的に、コマンドは応答ヘッダーがキャッシュされるバッファーサイズを変更します。これは、応答ヘッダーが大きすぎる場合に有効になります。その場合、upstream sent too big header while reading response header from upstreamというメッセージを受け取りますが、これはconnection reset by peerとはまったく異なります。
この種のエラーはランダムにトリガーされるため、アップストリームと通信するときにnginxがkeepaliveを使用するかどうかを確認することをお勧めします。この場合、nginxは接続が切断されたことを知らなかったため、同じ接続を使用してリクエストを転送するのに対し、アイドルタイムアウト時にアップストリームサーバーによって接続がリセットされる可能性があります。
私が知る限り、それを修正するエレガントなソリューションはありません。再試行するか、keepalive_timeout値をnginxのアップストリーム接続プールに設定して、問題を回避することができます。
参照：
Apache HttpClient Interim Error：NoHttpResponseException
http://tengine.taobao.org/document/http_upstream_keepalive_timeout.html
--post-buffering 32768ここで提案された（そして落胆した）ように私のために働いた NGINX +ピアによるuWSGI接続のリセット
現時点でさらに調査する時間はありませんが（迅速なプロトタイピングモード:)、このハックを見つけるのに多くの時間がかかったので、ここに投稿する価値があります。