Cloudflare 521·522·524 오류 해결: 원본 서버 확인 방법

AI Editter

Cloudflare 522 오류가 떠도 서버 프로세스가 반드시 꺼진 것은 아닙니다. 원본 서버는 살아 있지만 Cloudflare에서 오는 연결만 방화벽이 막을 수 있습니다. 반대로 524라면 원본과 연결한 뒤 응답 또는 쓰기 작업을 기다리는 단계에서 제한을 넘긴 상황을 조사해야 합니다. 521·522·524를 구분하고, 같은 요청을 CDN 경유와 원본 직접 연결로 비교하면 점검 범위를 크게 줄일 수 있습니다.

오류 코드별로 첫 확인 위치가 다르다

각 코드는 521, 522, 524 공식 설명을 기준으로 정리했습니다. TLS 핸드셰이크나 인증서 검증 문제는 525·526 등 다른 코드로 나타날 수 있어 같은 절차로 단정하면 안 됩니다.

1. 오류 화면에서 시각·URL·Ray ID를 남긴다

사용자가 보는 오류 페이지의 UTC 시각, 전체 URL, Ray ID, 어느 지역에서 재현되는지 기록합니다. 민감한 쿼리 문자열은 공유할 때 가립니다. 전체 사이트가 실패하는지 특정 API만 실패하는지도 구분하세요. 홈은 정상인데 CSV 내보내기만 실패한다면 연결 자체보다 그 작업의 처리 시간을 먼저 봅니다.

Cloudflare 대시보드의 해당 도메인에서 DNS 레코드가 의도한 원본을 가리키는지 확인합니다. A 레코드만 고치고 오래된 AAAA 레코드를 남기거나, 이전 로드밸런서 주소가 남은 경우를 놓치기 쉽습니다. DNS 조회에서 Cloudflare IP가 보이는 것은 프록시 사용 시 정상이며, 원본 주소 확인은 대시보드의 레코드 값에서 합니다.

2. Host와 SNI를 유지한 채 원본을 비교한다

아래는 자신이 관리하는 서버에서 실행할 진단 예시입니다. 문서용 IP 203.0.113.10과 도메인은 실제 값으로 바꿉니다. IP 주소만 브라우저에 입력하면 가상 호스트와 인증서 이름이 달라져 비교가 잘못될 수 있습니다.

curl -sS -o /dev/null --connect-timeout 5 --max-time 20 \
  -w 'cdn code=%{http_code} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://app.example.com/health

curl -sS -o /dev/null --connect-timeout 5 --max-time 20 \
  --resolve app.example.com:443:203.0.113.10 \
  -w 'origin code=%{http_code} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://app.example.com/health

원본이 Cloudflare IP만 허용한다면 외부 PC의 직접 연결 실패는 예상된 결과입니다. 그때는 허용된 관리 경로나 서버 내부에서 검사해야 합니다. Origin CA 인증서처럼 일반 클라이언트가 기본 신뢰하지 않는 인증서를 사용하면 직접 연결의 인증서 검증도 실패할 수 있습니다. 이를 서버 다운으로 판단하거나 서비스의 TLS 검증을 끄지 마세요.

가벼운 health 경로가 정상이어도 문제 API가 정상이라는 뜻은 아닙니다. 로그인·데이터 범위가 필요한 요청은 테스트 계정과 읽기 전용 조건으로 별도 비교합니다. 위 예시의 20초 제한은 빠른 연결 점검용이며, 524 발생까지 기다리는 재현 시험과는 목적이 다릅니다.

3. 522라면 보안 그룹부터 애플리케이션 앞까지 연결한다

서버의 80·443 리스너, 클라우드 보안 그룹, OS 방화벽, 호스팅 업체의 차단을 차례로 확인합니다. Cloudflare IP 허용 목록을 쓰는 환경이라면 공식 IP 범위와 현재 규칙을 비교합니다. 임시로 모든 방화벽을 해제하는 대신 누락된 범위와 실제 차단 로그를 대조하세요.

특정 배포 직후부터 실패한다면 포트 변경이나 원본 IP 변경을 먼저 봅니다. 트래픽이 몰릴 때만 실패하면 연결 대기열, 파일 디스크립터, CPU·메모리, 웹 서버 워커 포화를 같은 시각으로 묶어 봐야 합니다. 외부에서는 timeout인데 access log가 전혀 없다면 HTTP 요청이 웹 서버까지 도달하기 전 구간의 자료가 필요합니다.

4. 524는 느린 작업을 쪼개서 확인한다

2026년 10월 확인한 Cloudflare 문서의 기본 Proxy Read Timeout은 125초입니다. 쓰기 시간 초과도 524를 만들 수 있으므로 모든 524를 같은 시간 기준으로 해석하지 마세요. 큰 업로드는 요청 쓰기 구간을, 대용량 보고서는 DB 조회·파일 생성·외부 API 시간을 나눠 측정합니다.

오래 걸리는 작업은 접수 응답을 먼저 보내고 작업 상태와 다운로드 URL을 별도 조회하도록 설계할 수 있습니다. 프록시를 끄는 DNS-only 전환은 원본 노출과 보호 범위를 바꾸므로 일반적인 첫 해결책으로 삼지 않습니다. 먼저 원본의 병목과 작업 방식을 고쳐야 합니다.

지원 요청에도 쓸 수 있는 점검 결과

다음처럼 한 건의 기록을 만들면 운영팀이나 호스팅 지원팀이 이어서 조사하기 쉽습니다. “10:15 UTC, /export, 524, Ray ID ○○, health 정상, 원본 export 응답 지연, 같은 시각 DB 잠금 대기 확인.” 오류 코드와 스크린샷만 전달하는 것보다 장애 구간을 명확히 보여 줍니다. 수정 후에는 문제가 생겼던 데이터 크기와 동시 요청 조건에서 다시 확인하세요.

원본이 Nginx이고 로그에 upstream 오류가 남는다면 Nginx 502·504 로그 해석과 연결해 앱까지의 구간을 확인할 수 있습니다.