508 Resource Limit Is Reached 원인

Problem

방문자가 사이트를 여는데 페이지 대신 딱딱한 메시지가 뜹니다: 508 Resource Limit Is Reached. 코드는 아무것도 안 바뀌었습니다. 한 시간 전엔 멀쩡했고요. 이건 거의 항상 RFC 상태 코드가 아닙니다 — cPanel/CloudLinux 페이지가, 당신 호스팅 계정이 서버가 배정한 자원 예산을 소진했다고 알려주는 겁니다.

Symptoms

• 페이지에 평범한 WebDAV 오류가 아니라 cPanel 또는 CloudLinux 로고와 함께 “Resource Limit Is Reached”가 뜹니다.
• 트래픽에 따라 오락가락합니다 — 새벽 3시엔 멀쩡, 바쁜 시간엔 죽음.
• 같은 공유 서버의 다른 계정은 정상, 당신 것만 깨집니다.
• WordPress나 PHP 앱이 부하가 걸리면 멈췄다가 508을 내고, 트래픽이 빠지면 복구됩니다.
• 드물게, 순환 참조에 갇힌 앱이나 WebDAV 엔드포인트가 진짜 508 Loop Detected를 냅니다.

What 508 Actually Means

508은 둘이고 서로 아무 관계도 없습니다.

진짜 HTTP 상태는 RFC 5842 §7.2의 508 Loop Detected입니다: 서버가 요청 처리 중 무한 루프를 감지해 작업을 종료한 것 — 교과서적 사례는 자기 자신을 참조하는 바인딩을 Depth: infinity로 도는 WebDAV 요청입니다. 안전밸브죠. 그리고 흔치 않습니다. WebDAV를 돌리거나 일부러 이걸 내뱉는 앱이 아니라면 몇 년이 가도 볼 일이 없습니다.

거의 모두가 도달하는 508은 CloudLinux가 서빙하는 cPanel 오류 페이지이고, 같은 숫자를 완전히 다른 목적으로 재사용합니다. CloudLinux는 호스팅 계정마다 LVE — Lightweight Virtual Environment — 로 감싸고, CPU·물리 메모리·entry process·프로세스 수·디스크 I/O에 단단한 상한을 겁니다. 계정이 상한을 넘으면 새 요청은 큐에 걸리거나 죽고, 방문자는 508 Resource Limit Is Reached를 봅니다. 애플리케이션의 버그가 아닙니다. 공유 머신에서 허용된 소비량의 끝에 당신 계정이 부딪힌 겁니다.

가장 흔한 방아쇠는 entry-process(EP) 한도입니다. entry process는 대략 당신 PHP로 들어온 활성 히트 하나 — 방문자 하나, 봇 하나, 연결을 붙잡은 cron 하나입니다. 한도는 대개 작습니다(호스트가 흔히 20 안팎으로 설정). 느린 요청 몇 개가 DB를 기다리며 앉아 있으면 가용 entry process를 전부 붙잡고, 다음 방문자는 CPU 그래프가 한가한데도 508을 받습니다. 그게 반직관적인 부분입니다: CPU와 메모리가 넉넉해도 508이 뜰 수 있습니다. 넘긴 한도가 마력이 아니라 동시성이었으니까요.

Top Causes

1. 느린 요청이 entry process를 소진 - 무거운 쿼리, 타임아웃 없는 외부 API 호출, 최적화 안 된 페이지가 연결을 붙잡습니다. 각각이 하나의 entry process. EP 한도를 채우면 그 뒤로는 느린 요청이 빠질 때까지 전부 508입니다.

2. 낮은 플랜에 진짜 트래픽 스파이크 - 정상 방문자, 런칭, 떡상한 링크. 사이트는 멀쩡하고 플랜이 그 순간엔 너무 작을 뿐. 여유가 진짜 답인 유일한 경우입니다.

3. 봇·스크레이퍼·공격이 예산을 태움 - 공격적 크롤러, wp-login.php 브루트포스, 댓글 스팸이 계정을 두드려 EP와 CPU를 먹습니다. CloudLinux 입장에선 이게 트래픽과 구분 안 됩니다 — 부하가 반가운지 아닌지와 무관하게 throttle합니다.

4. 진짜 508 Loop Detected - 페이지가 cPanel 자원 메시지가 아니라 밋밋한 508이면, 순환 rewrite, 자기 자신을 참조하는 redirect, 또는 자기 참조 바인딩에 대한 WebDAV Depth: infinity 작업을 찾으세요.

Diagnose with DechoNet

• HTTP 진단으로 오리진이 반환하는 정확한 최종 상태 줄과 응답 헤더를 읽으세요. 두 가지를 빠르게 알려줍니다: 508이 당신 오리진에서 오는지(CloudLinux 자원 페이지는 cPanel/LiteSpeed 서버 시그니처를 답니다) 아니면 그 앞의 무언가에서 오는지, 그리고 오류가 상시인지 부하 때만 뜨는지. 조용할 때 재시도하면 사라지는 자원-한도 508은, 매번 508을 내는 라우팅·루프 문제와 완전히 다르게 보입니다 — 그 갈림이 진단의 첫 분기입니다.

Resolution Checklist

• 페이지 본문을 읽으세요. cPanel “Resource Limit Is Reached”는 용량 문제, 밋밋한 “Loop Detected”는 순환 참조입니다. 엉뚱한 508을 고치지 마세요.
• 자원-한도 페이지라면 CloudLinux Manager를 열거나(또는 호스트에 문의) 어느 한도가 걸렸는지 확인하세요 — EP, CPU, PMEM, NPROC, I/O. 그 한도 이름이 곧 문제입니다.
• entry process가 최대치라면 느린 엔드포인트를 사냥하세요. 인덱스 없는 쿼리 하나, 타임아웃 없는 API 호출 하나가 CPU가 움직이기 한참 전에 EP를 붙잡습니다.
• 캐싱(페이지 캐시, 오브젝트 캐시, 앞단 CDN)을 붙여 일반 방문자가 아예 PHP를 안 건드리게 하세요. 어떤 한도 증설보다 EP·CPU 압력을 더 낮춥니다.
• 나쁜 트래픽을 막으세요 — 남용 크롤러를 rate-limit/방화벽하고 wp-login.php·xmlrpc.php를 잠그세요. 그들의 요청 값을 당신 자원 예산으로 치르는 중입니다.
• 원인을 파악한 뒤에만 한도를 올리거나 상위 플랜으로 옮기세요. 사이트가 정말 공유 호스팅을 벗어나는 중이면 여유가 정직하고, 누수가 원인이면 한도만 높이는 건 다음 508을 미루는 것뿐입니다.
• 진짜 Loop Detected면 rewrite와 redirect에서 순환을 추적하고, 자기 참조 경로에 대한 Depth: infinity WebDAV 작업을 끄세요.

When to Escalate

• LVE 통계를 직접 못 본다면 호스트에 에스컬레이션하세요 — WHM의 CloudLinux Manager가 어느 한도가 얼마나 자주 걸리는지 정확히 보여주고, 그 이력이 추측을 끝냅니다.
• 캐싱과 봇 완화 후에도 508이 이어지고 LVE 그래프가 짧은 EP 스파이크가 아니라 지속적인 CPU·메모리 포화를 보인다면, 계정이 플랜을 벗어난 겁니다. 설정 손질이 아니라 용량 대화입니다.