テクノロジー · 実用ガイド
Nginx の「upstream prematurely closed connection」：timeout を延ばす前に backend の時間軸を合わせる
Nginx は upstream に到達しましたが、期待した応答が完了する前に peer が接続を終了しました。正確な段階と upstream を保存し、同じ request を process exit や restart と照合してから、一つだけ変更します。
Nginx は upstream に到達しましたが、期待した応答が完了する前に peer が接続を終了しました。正確な段階と upstream を保存し、同じ request を process exit や restart と照合してから、一つだけ変更します。
response header 版は Nginx が upstream header を読んでいる途中で接続が終わったことを示します。 proxy_read_timeout は応答全体ではなく連続する read 間の無通信時間です。
1. 両方の時計で同じ失敗を保存する
error line、request ID、method、URI、status、upstream address、接続・header・response time、header 中か body 中かを保存します。rotation 前に access log も残します。
backend では同じ trace、worker PID、container、最初と最後の log、exit code・signal、restart、deploy、OOM を保存し、時計の差を補正します。
2. close・read timeout・connect を分ける
connection refused は HTTP 前、read timeout は read 間に byte が届かない状態、premature close は NGINX が応答を待つ間に peer が終了した状態です。長い timeout は終了 process を戻しません。
NGINX の network から同じ scheme、Host、request class で正確な upstream を直接試します。一回の成功では recycle、古い pooled socket、悪い一台を除外できません。
3. upstream process または socket 所有者を特定する
upstream address ごとに集計し、worker timeout、crash、OOM、deploy drain、recycle、size limit、protocol mismatch、keepalive と照合します。reuse では短い connect time と idle-close policy を比較します。
全 502 を buffer 問題と呼びません。NGINX は段階を示せますが、終了理由は process manager と application log が必要です。restart 前に両側を保存します。
4. 証明した境界だけを変更する
crash、memory、exception を application で直し、deploy 時に drain、keepalive を整合、HTTP/HTTPS を修正し、時間軸が示す場合だけ長い処理と worker timeout を変えます。
backend が生きて read 間で正当に止まる場合だけ proxy_read_timeout を延ばします。capacity 測定なしに worker timeout を延ばさず、POST/PATCH の副作用を管理せず retry しません。
5. 安全に再現し終了基準を要求する
特定 backend と NGINX 経由で同じ request class を再現し、正常、遅い経路、deploy/recycle、reuse を試し、status、body、exactly-once side effect を確認します。
代表負荷で 502、worker exit、latency、retry safety を判定します。失敗を遅らせるだけ、重複 write、悪い member を隠す場合は戻します。
