HTTP 463 (ALB): XFF IP 30개 초과

문제

AWS Application Load Balancer를 통한 요청이 463으로 돌아오는데, 애플리케이션 로그엔 그 요청이 도착한 흔적이 없습니다. 그게 단서입니다: ALB가 타깃 그룹이 보기도 전에 요청을 거부한 것이죠. 463은 당신 코드도 아니고 장애도 아닙니다 — X-Forwarded-For 헤더가 IP 30개를 초과해 담고 도착했다는 이유로 로드밸런서가 요청을 거부한 것입니다. ALB는 그렇게 긴 XFF 리스트를 malformed 요청으로 취급해 엣지에서 멈춰 세웁니다. 그래서 문제는 “내 서버가 뭐가 잘못됐나”가 아닙니다 — 서버는 요청을 받지도 못했습니다. 문제는 ALB에 도달하는 forwarded-for 체인이 왜 30개 넘게 깊은가입니다.

증상

• 클라이언트는 HTTP 463을 받고, 타깃의 접근 로그엔 일치하는 항목이 없습니다 — 요청이 타깃에 닿지 않았으니까요.
• 클라이언트마다 결과가 다릅니다: 같은 엔드포인트가 어떤 네트워크에선 되고 다른 네트워크에선 463을 냅니다 — 각 요청이 지난 프록시 수에 따라서요.
• ALB 앞에 홉을 추가한 뒤(새 CDN·WAF·리버스 프록시), 또는 트래픽을 당신 스택으로 두 번 보내는 라우팅 변경 뒤에 나타납니다.
• ALB로 곧장 보낸 평문 요청은 됩니다. 실패는 도착 시점에 이미 긴 X-Forwarded-For 헤더를 지닌 요청에서만 나타납니다.

이 에러의 실제 의미

463은 Application Load Balancer가 스스로 생성하는 상태 코드 중 하나로, 460(클라이언트가 유휴 타임아웃 전에 연결을 닫음)·464(클라이언트와 타깃 간 프로토콜 버전 비호환)과 나란히 있습니다. AWS의 463 정의는 좁습니다: 로드밸런서가 IP 30개를 초과해 담은 X-Forwarded-For 요청 헤더를 받았고, 이를 malformed 요청과 비슷하게 취급한다는 것입니다.

메커니즘은 이렇습니다. X-Forwarded-For는 클라이언트가 공급하는 append-only 헤더입니다: 요청을 처리하는 각 프록시가 자기가 연결을 받은 주소를 덧붙이고, ALB는 기본적으로 그 뒤에 즉각 클라이언트의 IP를 추가합니다. 30개 상한은 ALB가 받는 것에 걸립니다. 헤더가 이미 IP 30개 넘게 나열한 채 나타나면 — 긴 프록시 체인을 지났거나, 당신 인프라를 두 번 돌았거나, 클라이언트가 손수 만들었거나 — ALB는 전달 대신 463으로 거부합니다. 30은 하드 한도이고 조정 불가입니다. 그리고 누구나 X-Forwarded-For에 원하는 걸 넣어 보낼 수 있으므로, 463은 때로 클라이언트가 헤더를 의도적으로 부풀린다는 첫 신호이기도 합니다.

주요 원인 3가지

1. ALB 앞의 진짜 긴 프록시 체인 - CDN → WAF → 리버스 프록시 → ALB, 각자 주소를 덧붙이고 원래 클라이언트도 이미 X-Forwarded-For를 보낸 경우. 깊지만 정상적인 체인 — 특히 멀티 CDN 구성이나 재프록시하는 서비스 메시 — 은 스스로 30개를 넘길 수 있습니다. 아무도 당신을 “공격”하는 게 아니라, 토폴로지가 홉을 너무 많이 전달할 뿐입니다.
2. 당신 스택을 두 번 도는 요청 루프 - 라우팅 실수로 트래픽이 같은 인그레스 경로를 한 번 넘게 지나갑니다 — 또 다른 ALB로 되돌아가는 프록시 앞의 ALB, 또는 같은 엣지로 재진입하는 리다이렉트. 매 통과마다 덧붙는 주소가 대략 두 배가 되어, 여유 있게 30 미만이던 체인이 선을 넘습니다.
3. 일부러 X-Forwarded-For를 부풀리는 클라이언트 - X-Forwarded-For는 신뢰할 수 없는 클라이언트 입력입니다. 스크래퍼·스캐너, 또는 당신 스택이 헤더를 어떻게 다루는지 떠보는 누군가가 이미 IP 30개 넘게 나열한 요청을 보내 463을 즉시 유발할 수 있습니다. ALB엔 무해하지만, 로깅·레이트리밋·접근 규칙에서 XFF를 신뢰한다면 부풀린 헤더는 주목할 가치가 있습니다 — 누군가 그 표면을 시험하고 있다는 뜻이니까요.

DechoNet으로 진단

• HTTP 점검은 당신 네트워크 바깥에서 정상적인 짧은 X-Forwarded-For로 엔드포인트에 깨끗한 요청을 보내고, 돌아오는 상태와 헤더를 보여 줍니다. DechoNet이 건강한 200을 받는데 당신 클라이언트는 463을 받는다면, 문제가 깔끔하게 격리됩니다: ALB와 타깃은 멀쩡하고, 463은 전적으로 당신 요청 경로가 붙이는 부푼 XFF 헤더 때문입니다. “서버가 죽었다”를 한 방에 배제합니다.
• IP 점검은 당신 트래픽이 나가는 실제 공인 IP를 보여 주므로, forwarded-for 체인에 쌓이는 주소들과 대조해 어느 홉이 무엇을 덧붙이는지 가려낼 수 있습니다 — 그 추가 주소가 당신 프록시 것인지 클라이언트 것인지 애매할 때 유용합니다.

해결 체크리스트

• 재현하고 주소 개수를 세세요. 일부러 긴 헤더로 요청을 보내고 — curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, ...(31개)" https://YOUR_ALB/ — 463이 나는지 확인하세요. 그런 다음 실제 실패 요청의 XFF를 들여다보며 IP가 몇 개인지, 어디서 왔는지 파악하세요.
• 가장 바깥 홉에서 X-Forwarded-For를 정리하세요. CDN이나 앞단 프록시(Cloudflare·Akamai·엣지 nginx)에서, 자기 것을 덧붙이기 전에 들어온 헤더를 잘라 내거나 초기화해 ALB에 도달하는 체인을 깨끗하게 시작하세요. AWS 자신이 권장하는 해법이며, 30개 상한을 실제로 다루는 유일한 방법입니다.
• ALB의 XFF 처리를 의도적으로 설정하세요. routing.http.xff_header_processing.mode — append·preserve·remove — 를 타깃이 헤더를 소비하는 방식에 맞추세요. 한도를 올리진 못하지만, remove(타깃이 XFF 불필요) 또는 preserve(신뢰 상류가 이미 올바로 설정)를 고르면 ALB에서 헤더가 더 커지는 걸 막습니다.
• 루프를 찾아 끊으세요. 자기 인그레스로 되돌아가는 홉이 있는지 요청 경로를 추적하세요. 같은 엣지를 두 번 지나는 요청이 정상 체인을 조용히 30 너머로 두 배 불리는 가장 흔한 원인입니다.
• 원시 XFF를 보안 결정에 신뢰하지 마세요. 레이트리밋이나 허용/차단 규칙이 X-Forwarded-For를 직접 읽는다면, 클라이언트가 공급한 전체 리스트가 아니라 당신의 신뢰 프록시가 덧붙인 주소만(오른쪽부터) 쓰세요 — 안 그러면 부푼 헤더가 463을 유발하면서 당신 로직까지 오염시킵니다.

언제 에스컬레이션할까

• DechoNet의 깨끗한 요청도 463을 반환하면, ALB가 스스로 초과분을 붙이고 있거나 신뢰 상류가 매 요청마다 긴 XFF를 주입하도록 잘못 설정된 것입니다 — 클라이언트별 이상이 아니라 엣지 담당자에게 넘길 인프라 설정 문제입니다.
• 463이 부푼 헤더를 쏟아붓는 특정 소스와 함께 움직인다면 단순 설정 수정이 아니라 남용 표면 문제로 다루세요: 요청 모양이 의도적이며, 지속 가능한 해법은 엣지에서 XFF를 정규화하고 하류에서 신뢰하지 않는 것입니다.
• 정상 홉 수를 30 미만으로 못 줄이겠다면 — 진짜 멀티 CDN이나 메시 토폴로지 — 헤더 계약 자체를 플랫폼 팀과 다시 설계해야 합니다; forwarded-for를 신뢰 가능한 단일 홉 정체 헤더로 축약하거나 대체하는 건 로드밸런서 설정이 아니라 아키텍처 결정입니다.