NGINX의 $status는 요청 처리 마지막에 클라이언트에 보낸 상태이고, $upstream_status는 upstream 서버에서 얻은 상태 코드 또는 코드들의 기록입니다. 재시도 설정이 켜져 있으면 앞선 upstream 실패와 다음 성공이 함께 남을 수 있습니다.
최종 200은 응답이 성공으로 끝났다는 뜻이지, 요청이 중간에 실패하지 않았거나 업무가 한 번만 처리됐다는 증거가 아닙니다. 주소·시도 순서·애플리케이션 요청 식별자를 맞춰야 합니다.
최종 응답과 upstream 시도는 서로 다른 필드입니다
NGINX 로그 모듈에서 $status는 요청 처리의 마지막에 클라이언트로 보낸 응답 상태를 나타냅니다. upstream 모듈의 $upstream_status는 upstream 서버에서 얻은 상태 코드 또는 코드들을 기록하며, $upstream_addr는 해당 upstream 주소 기록과 대응합니다. 그러므로 access log 한 줄에서 $status=200과 $upstream_status=502, 200이 함께 보이는 것은 모순이 아닙니다. 앞선 upstream 응답이 실패한 뒤 다른 upstream에서 성공했을 수 있습니다.
NGINX 공식 문서는 여러 주소·상태가 쉼표나 콜론으로 구분될 수 있다고 설명합니다. 콜론은 서로 다른 upstream group 사이의 연결 맥락일 수 있으므로, 단순히 모든 구분 기호를 시도 횟수로 세면 안 됩니다. 실제 해석은 사용 중인 NGINX 버전, proxy 설정, log_format, upstream group 구성을 확인한 뒤 하십시오. 아래 값은 문서 설명을 위해 만든 예시이며 실제 서비스 로그가 아닙니다.
가상 한 줄 로그를 시간 순서로 풉니다
| 관측 필드 | 가상 값 | 해석 |
|---|---|---|
| 요청 식별 | request_id=demo-17, URI=/report/preview | 앱 로그와 연결할 후보 키. 실제 구성에서 전달·기록되는지 확인 필요 |
| 최종 응답 | $status=200, $request_time=1.42 | 클라이언트에는 성공 코드가 전송됨 |
| upstream 주소 | $upstream_addr=10.0.0.11:8080, 10.0.0.12:8080 | 두 upstream 주소가 기록됨. 설정과 버전에 따라 구분 기호 의미를 확인 |
| upstream 상태 | $upstream_status=502, 200 | 첫 upstream 시도는 오류, 다음 기록은 성공일 가능성. 시각·시도 세부정보로 확인 |
| 앱 처리 결과 | 첫 인스턴스 로그 없음, 두 번째에 request_id=demo-17 기록 | 첫 요청이 도착했지만 로그가 누락됐을 가능성도 배제하지 못함 |
이 표에서는 마지막에 200이 반환됐지만 앞선 502 기록은 조사 대상에서 지워지지 않습니다. 타임아웃 뒤 재시도 과정에서 첫 서버가 실제 업무를 처리하고 응답만 놓쳤다면, 같은 쓰기 요청이 두 번 전달될 위험도 있습니다. RFC 9110은 재시도 가능한 메서드·조건을 다루며, 단지 클라이언트가 같은 URI를 호출했다는 이유만으로 모든 요청을 안전하게 반복할 수 있는 것은 아닙니다. 애플리케이션의 idempotency 설계와 요청 ID를 확인합니다.
최종 200을 확인한 다음에도 할 일
- 로그 포맷에
$status,$upstream_status,$upstream_addr, 요청 ID가 실제 포함되는지 설정·샘플 로그로 확인합니다. - 한 줄의 최종 코드와 upstream 코드 목록을 별도 열로 읽고, 빈 값·복수 값·구분 기호를 버전 문서와 대조합니다.
- 각 주소의 upstream 서버 로그에서 같은 요청 ID, 처리 시각, 오류 메시지가 있는지 확인합니다.
- 애플리케이션 로그와 trace에서 요청이 업무 로직에 도달했는지, 결과가 한 번 또는 여러 번 기록됐는지 확인합니다.
- 재시도 대상 메서드와 오류 조건, 최대 횟수, 요청 본문 재전송 여부를 설정에서 확인합니다. 운영 설정을 이 학습 예시에 맞춰 바꾸지 않습니다.
- 최종 성공과 앞선 실패를 함께 보고하고, 앱 기록이 없다는 이유만으로 upstream이 요청을 받지 않았다고 단정하지 않습니다.
200 하나로는 사용자의 실제 결과를 증명하지 못합니다
상태 코드는 HTTP 응답을 요약합니다. 요청이 애플리케이션에 도달했는지, 데이터 변경이 완료됐는지, 사용자가 응답을 받았는지는 각각 다른 질문입니다. access log가 요청 ID를 기록하지 않으면 proxy·upstream·앱 기록의 정밀 연결은 어려울 수 있습니다. 모르는 관계는 ‘확인되지 않음’으로 남기고, 앞으로 필요한 상관 필드를 수집 설계에서 검토합니다.
복습: 성공 코드 앞에 실패 코드가 있으면?
문제: 교육용 로그의 최종 $status는 200이고 $upstream_status는 502, 200입니다. 요청은 결제 변경 요청이었습니다. 무엇을 결론 내리고 무엇을 추가 확인해야 하나요?
정답: 클라이언트 응답은 성공으로 끝났고 upstream 시도 중 실패 기록이 있었음을 말할 수 있습니다. 업무가 정확히 한 번 적용됐는지는 결론 낼 수 없으므로 요청 ID, upstream·앱 기록, 중복 방지 및 결과 상태를 확인합니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
가상 NGINX 기록에 $status=200, $upstream_status=502, 200, 두 upstream 주소가 적혀 있습니다. 가장 안전한 요약과 추가 확인 자료 한 가지를 답하세요.
정답과 해설 확인
클라이언트 응답은 200이지만 upstream 기록에는 실패 코드 뒤 성공 코드가 함께 있다. 앱 로그 또는 trace의 같은 요청 ID를 확인해 실제 업무 처리 횟수와 결과를 대조합니다.최종 클라이언트 상태와 upstream 시도 결과는 다른 관측값이며, 응답 코드만으로 업무 부작용이나 재시도 안전성을 알 수 없습니다.