기술 · 실용 가이드
NGINX를 바꿔도 413인가요? body 제한을 집행하는 hop부터 증명하세요
모든 proxy 제한을 키우거나 무제한으로 만들지 마세요. 같은 marked request로 최초 거부 hop을 찾고 실제 설정을 덤프한 뒤 하나의 유한 scope만 바꾸고 경계 아래와 위를 검증하세요.
모든 proxy 제한을 키우거나 무제한으로 만들지 마세요. 같은 marked request로 최초 거부 hop을 찾고 실제 설정을 덤프한 뒤 하나의 유한 scope만 바꾸고 경계 아래와 위를 검증하세요.
HTTP 413은 request path의 어떤 server/proxy hop에서도 올 수 있습니다. NGINX client_max_body_size 기본값은 1m이며 http, server, location에 둘 수 있습니다.
1. 재현 request 고정
목표 limit 주변의 정확한 byte 수를 가진 무해한 body를 만들고 같은 method, auth, content type과 고유 request ID로 정확한 route에 보냅니다. status, headers, response prefix, 시간, client trace를 저장하고 browser 문구로 owner를 판단하지 않습니다.
2. 최초 거부 hop 식별
response headers, TLS endpoint, server signature, request ID를 각 hop의 access/error log와 맞춥니다. 가장 먼저 413을 만든 계층이 거부 owner이며 app에 같은 request가 없으면 body가 도달하지 않은 것입니다.
3. 실제 policy 증명
standalone NGINX는 실제 instance에서 nginx -T를 수집해 URI를 지배하는 http, server, location을 찾습니다. ingress-nginx는 Ingress, annotation, controller version, ConfigMap, generated block을 저장하고 edge와 app cap을 분리합니다.
4. 유한한 한 계층만 변경
memory, buffer, timeout, scanner, storage가 감당할 유한 값을 선택하고 최초 거부 계층의 목표 scope만 바꿉니다. security review 없이 0으로 만들지 않습니다. syntax와 새 worker, Pod, generation을 보존합니다.
5. 경계 양쪽 시험
같은 request로 limit 바로 아래, 가능하면 정확히 limit, 바로 위를 시험합니다. 작은 body는 app에 도달하고 큰 body는 예상 계층에서 거부되어야 합니다. bytes, route, config hash, logs, 결과, rollback과 small request health를 기록합니다.
