科技 · 實用指南
Nginx 顯示「upstream prematurely closed connection」？加逾時前先對齊後端時間線
這表示 Nginx 已連到上游，但對端在預期回應完成前結束交換。先保存精確階段與上游位址，把同一請求和程序退出或重啟對齊，再只改一個邊界並安全重播。
這表示 Nginx 已連到上游，但對端在預期回應完成前結束交換。先保存精確階段與上游位址，把同一請求和程序退出或重啟對齊，再只改一個邊界並安全重播。
reading response header 表示連線結束時 Nginx 還在讀取上游標頭。 proxy_read_timeout 計算相鄰讀取間的無資料時間，不是總回應時間。
1. 在兩側時鐘保存同一失敗請求
保存完整錯誤、請求 ID、方法、URI、狀態、上游位址、選中伺服器、連線/標頭/總回應時間，以及失敗在標頭或本文。輪替前保留對應 access log。
後端保留同一 trace、worker PID、容器或 pod、首尾日誌、退出碼或 signal、重啟計數、部署與 OOM 證據。先校準時鐘差。
2. 區分關閉、讀取逾時與連線階段
連線拒絕發生在 HTTP 交換前；read timeout 表示兩次讀取間沒有資料；premature close 表示 NGINX 仍期待資料時對端已關閉。加逾時不能復活已退出程序。
從 NGINX 網路環境以相同 scheme、Host 與請求類別直連。一次成功不能排除間歇回收、失效 pooled socket 或單一壞節點。
3. 找出上游程序或 socket 持有者
依 upstream 位址分組並對齊 worker timeout、崩潰、OOM、部署排空、回收、大小限制、協定錯配或 keepalive。復用 socket 要比較近零連線時間與後端 idle close。
不要把所有 502 當作 buffer 問題。NGINX 只能指出階段，後端程序與應用日誌才能解釋原因；重啟前保存雙方證據。
4. 只修改已證實的邊界
在應用修 crash、記憶體與例外；部署時排空 worker；對齊 keepalive；修正 HTTP/HTTPS；只有時間線支持才調整長工作與 worker timeout。
只有後端仍存活且合法停頓時才增加 proxy_read_timeout。改 worker timeout 前評估容量；未控制重複副作用時不要重試 POST/PATCH。
5. 安全重播並要求退出門檻
對單一後端和 NGINX 重播相同請求，測正常、慢路徑、部署回收與復用連線，確認狀態、本文完整且副作用一次。
在代表負載下要求 502 率、worker 退出、延遲與重試安全達標；若只是延後失敗或重複寫入就回滾。
