URL이 길 때 500이 난다는 사실만으로 Nginx 메모리 부족을 단정할 수 없습니다. 요청을 받는 쪽과 업스트림 응답을 읽는 쪽의 버퍼는 역할이 다릅니다. 먼저 실제 상태 코드, 같은 시각의 error log, 업스트림까지 요청이 도달했는지를 맞춥니다.
1 KB 제한을 둔 별도 서버의 관찰값
일반 사용자로 임시 Nginx 1.24.0을 127.0.0.1의 별도 포트에서 실행했습니다. large_client_header_buffers 2 1k 조건에서 1,800자 경로는 414, 1,800자 단일 요청 헤더는 400이었습니다. 별도 location의 proxy_buffer_size 1k에 대해 모의 업스트림이 1,800자 응답 헤더를 보내면 502였습니다. 각 경우는 한 번씩 작은 요청으로 검사했고 공개 WordPress에는 보내지 않았습니다.
요청 헤더 지시문은 요청 줄과 단일 헤더가 한 버퍼에 들어가야 하는 조건을 설명합니다. 버퍼 개수만 늘려도 긴 요청 줄이 허용된다고 생각하면 안 됩니다. 프록시 버퍼는 업스트림 응답을 읽는 경계입니다.
증상에 맞는 최소 변경 선택
414라면 클라이언트가 URL에 거대한 상태나 토큰을 넣는 이유와 서비스의 허용 길이를 먼저 검토합니다. 400이라면 쿠키·단일 헤더의 실제 크기를 확인합니다. 502와 upstream response header 오류가 함께 있으면 앱이 만드는 Set-Cookie나 중복 헤더를 먼저 살핍니다. 500이라면 앱 로그와 오류 페이지 변환 설정을 확인해 원래 오류가 가려졌는지 조사합니다.
버퍼 조정이 필요하다면 측정한 정상 요청 범위와 동시 접속 수를 근거로 크기를 정합니다. 작은 서버에 128 KB·256 KB를 일괄 적용하는 방식은 사용하지 않습니다. 변경 전 설정을 보관하고 문법 검사, 명시적 reload, 같은 요청과 정상 요청의 재확인을 순서대로 수행합니다. HTTP/2·CDN·WAF 경로는 이번 HTTP/1.1 루프백 결과와 별도로 검증해야 합니다.