기술 · 실용 가이드
Nginx “upstream prematurely closed connection”: timeout을 늘리기 전에 백엔드 타임라인을 맞추세요
Nginx는 upstream에 도달했지만 예상 응답이 끝나기 전에 peer가 연결을 종료했습니다. 정확한 단계와 주소를 보존하고 같은 요청을 프로세스 종료·재시작과 연결한 뒤 한 경계만 바꾸고 안전하게 재현합니다.
Nginx는 upstream에 도달했지만 예상 응답이 끝나기 전에 peer가 연결을 종료했습니다. 정확한 단계와 주소를 보존하고 같은 요청을 프로세스 종료·재시작과 연결한 뒤 한 경계만 바꾸고 안전하게 재현합니다.
response header 형태는 Nginx가 upstream header를 읽는 중 연결이 끝났다는 뜻입니다. proxy_read_timeout은 전체 응답이 아니라 연속 read 사이의 무데이터 시간입니다.
1. 두 시계에서 같은 실패를 보존하세요
전체 error line, request ID, method, URI, status, upstream 주소, connect/header/response time과 header 또는 body 단계를 보존합니다. rotation 전에 access log도 저장합니다.
backend에서 같은 trace, worker PID, container/pod, 첫·마지막 log, exit code·signal, restart, deploy와 OOM을 보존하고 시계 차이를 보정합니다.
2. close·read timeout·connect 단계를 분리하세요
connection refused는 HTTP 전에, read timeout은 read 사이 byte 부재일 때, premature close는 NGINX가 응답을 기다리는데 peer가 종료할 때입니다. timeout 증가는 죽은 프로세스를 살리지 못합니다.
NGINX 네트워크에서 같은 scheme, Host와 request class로 정확한 upstream을 직접 시험합니다. 한 번 성공해도 recycle, stale pooled socket, 나쁜 한 서버를 배제하지 못합니다.
3. upstream 프로세스나 socket 소유자를 찾으세요
upstream 주소별로 실패를 묶고 worker timeout, crash, OOM, deploy drain, recycle, size limit, protocol mismatch와 keepalive를 맞춥니다. reused socket은 짧은 connect time과 idle-close 정책을 비교합니다.
모든 502를 buffer 문제로 부르지 마세요. NGINX는 단계를 보여도 종료 이유는 process manager와 application log가 설명합니다. restart 전에 양쪽 증거를 보존합니다.
4. 증명된 경계 하나만 바꾸세요
application crash, memory, exception을 고치고 deploy 때 drain하며 keepalive와 HTTP/HTTPS를 맞추고 타임라인이 뒷받침할 때만 긴 작업과 worker timeout을 조정합니다.
backend가 살아 있고 read 사이 합법적으로 멈출 때만 proxy_read_timeout을 늘립니다. 용량 측정 없이 worker timeout을 늘리거나 중복 부작용을 통제하지 않은 POST/PATCH retry를 켜지 않습니다.
5. 안전하게 재현하고 종료 기준을 요구하세요
식별한 backend와 NGINX 경로에서 같은 요청을 재현하고 정상·느린 경로·deploy/recycle·reuse를 시험해 status, body 완전성과 exactly-once 효과를 확인합니다.
대표 부하에서 502, worker exit, latency와 retry 안전 기준을 확인합니다. 실패만 늦추거나 중복 쓰기, 나쁜 서버를 숨기면 되돌립니다.
