414 Request-URI Too Large 해결

Problem

서버가 414 Request-URI Too Large(또는 414 URI Too Long)로 요청을 거부합니다. 대개 긴 쿼리 문자열이 붙은 특정 URL이나, 꼬리를 물고 커진 리다이렉트에서 터지고, 같은 사이트의 짧은 URL은 멀쩡히 됩니다.

Symptoms

• 사이트 나머지는 열리는데 특정 페이지만 414 Request-URI Too Large / 414 URI Too Long을 반환합니다.
• 실패하는 URL의 쿼리 문자열이 매우 깁니다 — 인코딩된 상태, 토큰, 또는 반복되는 파라미터 다수.
• 리다이렉트 후, 특히 URL을 계속 키우는 로그인·“돌아가기” 흐름 뒤에 나타납니다.
• 쿼리 문자열을 줄이면 같은 요청이 성공합니다.
• 오리진은 받아줬을 요청을 CDN·리버스 프록시가 반환하기도 합니다.

What This Error Actually Means

414는 RFC 9110 §15.5.15에서 정의되며, 예전 이름 “Request-URI Too Long”에서 “URI Too Long”으로 개칭됐습니다. 요청 최상단의 요청 라인 — GET /아주/긴/경로?...= HTTP/1.1 — 이 서버가 파싱하려는 길이보다 길었다는 뜻입니다. 명세가 정한 최대치는 없고, 서버마다 자기 한도를 고릅니다.

사람들이 걸려 넘어지는 포인트는 URI가 어디에 있느냐입니다. URI는 요청 라인에 있지, 헤더나 본문에 있지 않습니다 — 이것이 414를 두 이웃과 구분합니다. 413은 본문이 너무 큼, 431은 헤더가 너무 큼, 414는 URL이 너무 김. 실패 모양은 같고, 요청의 세 부위만 다릅니다.

서버 한도는 생각보다 낮습니다. nginx에선 요청 라인이 large_client_header_buffers의 버퍼 하나에 들어가야 하고 — 기본값 4 8k, 즉 8 KB — 이를 넘치면 414를 반환합니다(반면 단일 헤더가 넘치면 400을 줍니다). Apache는 LimitRequestLine 기본값이 8190 바이트입니다. 이 한도는 일부러 존재합니다. 제한 없는 요청 라인은 파싱·메모리 소진 위험이라, 한도를 올리는 것은 첫 해결책이 아니라 최후의 수단이어야 합니다.

Top 3 Causes

1. 쿼리 문자열 팽창 - GET 요청이 POST 본문에 있어야 할 데이터를 실어 나릅니다: 직렬화된 폼 상태, base64 blob, 완전한 JWT나 토큰, 또는 수십 개의 필터·트래킹 파라미터. 상태가 더 밀어넣어질수록 URL이 조용히 한도를 넘깁니다.
2. 파라미터를 덧붙이는 리다이렉트 루프 - 인증·“돌아가기” 흐름이 매 홉마다 리턴 URL을 중첩합니다 — ?returnUrl=...%3FreturnUrl%3D... — URL이 한도를 넘길 때까지. 전형적인 “로그인 시 갑자기 414” 패턴이며, 수용할 크기가 아니라 리다이렉트 로직의 버그입니다.
3. 필요보다 낮게 잡힌 한도 - 애플리케이션이 정당하게 긴 URL을 만드는데(일부 SSO·리포팅 도구가 그렇습니다), 서버·프레임워크·앞단 엣지 프록시가 오리진보다 작은 요청 라인 한도를 강제합니다.

Diagnose with DechoNet

• HTTP 점검으로 서버가 그 URL에 반환하는 정확한 상태를 보고, Location 헤더로 리다이렉트 체인을 따라가세요 — 매 홉마다 파라미터를 덧붙여 결국 414를 터뜨리는 흐름을 잡는 가장 빠른 방법입니다.
• DNS 조회로 의도한 호스트에 닿고 있는지 확인해, 오래된 엔드포인트나 잘못된 환경에서 나온 414를 쫓지 않도록 하세요.

Resolution Checklist

• 실패하는 정확한 URL로 재현한 뒤 길이를 재세요. 수십 KB라면 그게 결정적 단서입니다.
• 쿼리 문자열에 뭐가 들었는지 보세요. 인코딩된 상태, 토큰, 같은 파라미터의 다중 반복은 POST 본문이나 서버측 참조로 옮겨야 할 데이터입니다.
• 리다이렉트 체인을 따라가세요. 매 홉이 returnUrl / next / redirect 파라미터를 이전 것 위에 덧붙이면 루프입니다 — 중첩을 멈추도록 리다이렉트 로직을 고치세요.
• URL이 설계상 정말 길어야 할 때만 한도를 의도적으로 올리세요: nginx large_client_header_buffers, Apache LimitRequestLine, 그리고 앞단 CDN·리버스 프록시. 무한대가 아니라 앱의 실제 필요에 맞추세요.
• HTTP 점검을 다시 돌려 요청이 끝까지 성공하는지 확인하세요.

When to Escalate

• 앞단에 CDN·리버스 프록시가 있고 자체(더 낮은) 요청 라인 한도를 강제하면, 오리진은 받아줬을 요청에도 414가 엣지에서 나옵니다. 오리진만이 아니라 엣지의 한도를 확인하세요.
• 지나치게 긴 리턴 URL을 만드는 쪽이 IdP나 서드파티 서비스라면 해결은 그쪽에 있습니다 — URL이 전체 상태 대신 짧은 참조를 실어야 하고, 그건 내가 통제하지 못할 수 있습니다.