509 Bandwidth Limit Exceeded 원인

Problem

어제까진 멀쩡했습니다. 오늘은 모든 페이지가 509 Bandwidth Limit Exceeded를 반환합니다 — 대개 호스트 브랜딩이 박힌, 꾸밈없는 페이지죠. 코드는 아무것도 안 바뀌었고, 서버는 살아 있고, 같은 서버의 다른 사람 사이트는 정상입니다. 벌어진 일은 시시하고 버그와는 무관합니다: 당신 호스팅 계정이 이번 청구 주기에 플랜이 허용한 것보다 더 많은 데이터를 옮겼고, 호스트가 계량기가 리셋될 때까지 차단한 겁니다.

Symptoms

• 페이지에 “Bandwidth Limit Exceeded”가 cPanel·Plesk 또는 호스트 브랜딩과 함께 뜹니다 — 프레임워크 에러나 스택 트레이스가 아니라.
• 갑자기 나타나서 정적 이미지와 홈페이지까지 도메인의 모든 URL을 한꺼번에 막습니다.
• 같은 공유 서버의 다른 계정은 멀쩡하고, 당신 계정만 차단됩니다.
• 타이밍이 청구 주기 말과 겹치거나, 급증과 겹칩니다 — 떡상한 글, 핫링크된 파일, 당신을 발견한 크롤러.
• 매월 1일에 “저절로 낫고” 몇 주 뒤 다시 돌아오는 일이 잦습니다.

What 509 Actually Means

509는 진짜 HTTP 상태 코드가 아닙니다. RFC 9110에도, 그 이전 어떤 HTTP 규격에도 없고, IANA 핵심 상태 코드 레지스트리는 이 코드를 미할당으로 둡니다. 오래된 Apache 모듈 mod_bandwidth를 통해 세상에 나왔고, 제어판들 — cPanel·Plesk 등 — 이 딱 한 상황을 위한 집안 관례로 받아들였습니다: 이 호스팅 계정이 호스트가 판 월 데이터 전송 허용량을 소진했다.

그 출신이 이 코드의 헷갈리는 점을 전부 설명합니다. 프로토콜 상태가 아니라 제어판 관례라서, 모듈 없는 서버는 이걸 절대 안 냅니다 — nginx는 같은 초과 상황을 503이나 커스텀 에러 페이지로 보여주므로, 509가 안 뜬다고 모든 스택에서 한도 안에 있다는 뜻은 아닙니다. 그리고 계정 수준 요금 신호라서, 모든 URL을 동시에 때리고 이웃은 봐줍니다: 서버도 건강하고, 애플리케이션도 건강하고, 넘어간 건 계량기입니다.

여기서 시간을 아끼는 핵심 구분이 나옵니다. 500이나 503은 로그와 애플리케이션 코드를 파게 만듭니다. 509는 코드가 무관하다고 말해주는 겁니다 — 바이트를 너무 많이 보냈다고. 질문은 “뭐가 고장났나”가 아니라 “뭐가 그만한 데이터를 옮겼고, 그게 정당한가”입니다.

Top Causes

1. 정말로 플랜을 넘어섰다. 실제 트래픽 성장, 런칭, 어딘가 큰 데서 온 링크. 사이트는 제 할 일을 했고 플랜이 이번 달엔 너무 작을 뿐입니다. 우회가 아니라 업그레이드가 정직한 답인 유일한 경우죠.

2. 대용량 파일이 반복해서 서빙됨. 영상, 고해상도 이미지, PDF, 다운로드. 50MB 파일 하나를 수천 번 내려주면 기가바이트 단위입니다. 그게 홈페이지나 자동재생에 있으면 방문자마다 통째로 끌어갑니다.

3. 핫링크 — 남의 페이지가 당신 바이트를 서빙. 누군가 당신 이미지·영상을 당신 URL에서 직접 임베드하면, 그쪽 방문자가 당신 대역폭을 씁니다. 당신 분석에는 트래픽이 안 잡히는데 전송량만 나갑니다.

4. 루프 도는 봇과 스크래퍼. 공격적 크롤러, 오작동하는 미러, 같은 대용량 에셋을 반복 다운로드하는 스크래퍼. 계량기에겐 실수요와 구분이 안 됩니다.

5. 오산정되거나 계량 안 되는 프로세스. HTTP로 복사되는 백업, 프로덕션 미디어를 끌어오는 스테이징 작업, 캐시 없이 매 요청 pull-through하도록 잘못 설정된 CDN. 전송은 실재하지만 방문자가 아닙니다.

Diagnose with DechoNet

• HTTP Check로 오리진이 반환하는 정확한 상태 줄과 응답 헤더를 읽습니다. 이걸로 두 가지를 빠르게 확인합니다: 509가 오리진에서 바로 오는지(호스트 서버 시그니처를 달고 옵니다), 그리고 요청마다 일정한지 — 후자는 일시적 요청별 실패가 아니라 계정 수준 차단의 특징입니다. 헤더 세트와 본문이 애플리케이션 에러가 아니라 호스팅 제어판 할당 페이지와 일치하면, 코드 버그는 배제하고 곧장 대역폭 문제로 넘어갈 수 있습니다.

Resolution Checklist

• 호스팅 제어판을 열어 실제 대역폭 사용 그래프를 읽으세요. 넘어간 자원이 디스크·CPU가 아니라 해당 기간의 전송량/대역폭인지 확인 — 엉뚱한 한도를 고치지 마세요.
• 언제 마지막으로 리셋됐고 얼마나 빨리 올랐는지 보세요. 완만히 꾸준히 차오르면 성장, 갑자기 수직 상승이면 파일 하나·핫링크·봇입니다.
• 무거운 URL을 찾으세요. raw 액세스 로그를 히트 수가 아니라 전송 바이트로 정렬 — 자주 끌린 대용량 에셋 하나가 잔챙이 백만 요청을 이깁니다.
• 핫링크를 죽이세요. Referer 기반 규칙(또는 제어판의 핫링크 보호)을 걸어 남의 사이트가 당신 돈으로 당신 대용량 파일을 못 서빙하게.
• 정적 미디어 앞에 CDN이나 오브젝트 스토리지를 두어 이미지·영상·다운로드가 다시는 계량되는 호스팅 대역폭에서 안 나가게 하세요. 대부분 509에서 가장 큰 지렛대입니다.
• 남용 크롤러를 차단·레이트리밋하고, 백업·스테이징 작업이 공개 HTTP 경로로 대용량 파일을 끌어가지 않는지 확인하세요.
• 원인을 이해한 뒤에만 플랜을 올리세요. 진짜 성장이면 여유가 정직하고, 누수면 한도만 키우는 건 다음 509를 미룰 뿐입니다.

When to Escalate

• 사용 그래프가 설명 안 되는 전송량을 보이면 — 분석·로그로 설명되는 것보다 훨씬 많다면 — 호스트에게 날짜·경로별 바이트 분해를 요청하세요. 오산정, 스팸 파일을 서빙하는 침해된 계정, 폭주 프로세스가 계량기를 부풀릴 수 있고, 전체 그림은 호스트만 봅니다.
• 정적 에셋을 CDN으로 옮기고 핫링크를 죽이고 나쁜 봇을 막았는데도 매 주기 한도에 부딪힌다면, 사이트가 정말 공유 호스팅을 넘어선 겁니다. 그건 또 하나의 설정 수정이 아니라 용량 대화 — 상위 플랜, VPS, 무계량 egress — 입니다.