NGINX limit_req는 정의한 키의 평균 처리율과 초과 요청 버스트를 제어합니다. 기본 동작에서 제한된 초과 요청은 지연될 수 있고, burst를 넘으면 종료됩니다. nodelay는 burst 안의 초과 요청을 지연 없이 처리하도록 바꾸지만 burst 한도를 넘은 요청은 여전히 거부됩니다.
limit_req_status의 기본 거부 상태는 503이며 다른 코드로 바꿀 수 있습니다. 따라서 503 하나만 보고 upstream 장애라고 단정하지 말고 $limit_req_status, NGINX 제한 로그, upstream 상태를 함께 확인해야 합니다.
rate는 평균 속도이고 burst는 초과 요청 여유입니다
NGINX 공식 모듈은 zone별 키에 대해 leaky-bucket 방식으로 요청 처리율을 제한합니다. 예를 들어 rate=1r/s와 burst=5를 설정하면 평균 허용률은 초당 1건이고, 짧은 시간에 몰린 추가 요청은 최대 다섯 건까지 한도 안에서 처리될 수 있습니다. burst가 순간 요청을 무제한 허용하는 것은 아닙니다. rate를 넘는 요청을 얼마나 기다리게 할지, 한도를 넘을 때 어떻게 처리할지 같이 보아야 합니다.
같은 1초 요청 묶음에서 delay와 nodelay를 비교합니다
| 가상 입력 | 설정 | 제한 모듈에서 기대할 관찰 | 다음 확인 |
|---|---|---|---|
| 짧은 급증, 추가 요청 3건 | 기본 지연 | 한도 내 초과 요청이 지연되어 처리될 수 있음 | $limit_req_status와 지연 로그 |
| 같은 급증 | burst=5 nodelay | burst 안 요청은 지연 대기 없이 처리될 수 있음 | 실제 전송 시각과 PASSED/초과 상태 |
| 추가 요청이 5건 초과 | 두 설정 공통 | burst 한도를 넘어 요청이 거부될 수 있음 | REJECTED 결과와 설정된 limit_req_status |
| upstream 응답 503 | 제한 모듈은 거부하지 않음 | 응답 코드만으로 제한으로 분류할 수 없음 | upstream 주소·상태·error log |
NGINX 모듈 문서의 예시는 기본 rate와 burst에서 초과 요청을 지연 처리하고, nodelay를 붙이면 지연하지 않는다고 설명합니다. limit_req_status는 거부 응답 코드를 지정하는 설정이며 문서의 기본값은 503입니다. 429를 쓰도록 변경했을 수도 있으므로 상태 코드 표만 보고 기본 설정을 추정하지 마세요.
상태 코드와 제한 변수는 별도 증거입니다
NGINX는 제한 결과를 $limit_req_status 변수로 PASSED, DELAYED, REJECTED 등으로 구분할 수 있습니다. 로그 형식에 이 값이 포함되어 있는지 확인하면 상태 코드만 보는 것보다 제한 동작을 분류하기 쉽습니다. 다만 실제 운영 로그의 필드 구성과 NGINX 버전은 다를 수 있습니다. 제한 변수가 REJECTED가 아니어도 다른 proxy 정책이나 애플리케이션이 요청을 거절했을 수 있습니다.
가상 503 건을 분류하는 확인 순서
- 같은 요청 시각·경로의 NGINX access log와 error log를 맞춥니다.
- 실제 적용된
limit_req_zone키·rate·공유 메모리 zone을 확인합니다. - 해당 location의 burst, nodelay 또는 delay, 상속된 limit_req 설정을 확인합니다.
limit_req_status의 실제 값을 보고 기본 503이라고 가정하지 않습니다.- 로그에
$limit_req_status가 있다면 PASSED·DELAYED·REJECTED를 구분합니다. - 같은 시각의 upstream 연결·응답 오류와 비교해 애플리케이션 측 503을 별도로 분류합니다.
- 원인 분류 전 제한 수치나 상태 코드를 운영에 변경하지 않습니다.
한 개의 503 응답은 원인 코드가 아닙니다
503은 설정에 따라 rate-limit 거부 코드가 될 수 있지만 upstream이나 다른 계층도 503을 반환할 수 있습니다. 반대로 운영자가 제한 거부 코드를 429로 바꿔 두었다면 제한 로그가 있어도 응답이 503은 아닐 수 있습니다. 상태, 제한 변수, 설정 적용 위치, upstream 증거를 한 타임라인에 놓고 원인을 좁히세요.
복습: 503이면 무조건 upstream인가요?
문제: NGINX가 503을 반환했지만 access log에 $limit_req_status=REJECTED가 있고 이 location의 limit_req_status는 기본값입니다. 무엇을 추론할 수 있나요?
정답: 이 응답은 rate-limit 거부와 일치할 수 있으며, upstream 장애라고 단정할 수 없습니다. 실제 적용 설정과 같은 시각의 upstream 로그도 확인해 다른 503과 구분합니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
교육용 NGINX에서 rate=1r/s, burst=5이고 nodelay가 켜져 있습니다. 짧은 급증에서 burst를 넘은 요청 일부가 503으로 거부됐고 $limit_req_status=REJECTED입니다. upstream 장애로 확정할 수 있나요?
정답과 해설 확인
아닙니다. 제한 결과가 거부로 기록됐으므로 rate-limit 경로와 일치하지만, 나머지 응답과 upstream 상태는 별도로 조사해야 합니다.nodelay는 burst 안 요청의 대기를 바꾸지 burst 용량을 늘리지 않습니다. 기본 거부 코드는 503이지만 운영 설정은 변경될 수 있으므로 변수·설정을 함께 확인합니다.