Error 530 (Cloudflare) 안의 1xxx 읽기

Problem

Cloudflare가 방문자에게 Error 530 페이지를 내보내고 있습니다. 숫자가 표준 HTTP 5xx처럼 보여서 깨진 서버를 찾아 나서지만 — 서버엔 아무 문제가 없습니다. 530은 오류가 아니기 때문입니다. Cloudflare가 다른 오류 코드를 감싼 껍데기이고, 진짜 코드는 페이지 안, 한 줄 아래, 당신이 그냥 지나쳤을 형식으로 앉아 있습니다.

Symptoms

• 방문자에게 Ray ID가 붙은 Cloudflare Error 530 페이지가 뜹니다.
• “530” 바로 아래에 1xxx 범위의 두 번째 코드가 보입니다 — 대개 1016 Origin DNS Error — 오리진 쪽 문제로 표시됩니다.
• 오리진 서버 자체는 살아 있습니다. SSH 되고, 앱 돌고, 로그 조용합니다. 서버에서 오류를 내는 건 없습니다.
• 코드 배포 후가 아니라 DNS 변경, 호스트 이전, 레코드 만료·삭제 직후에 시작되는 경우가 많습니다.

530이 실제로 뜻하는 것

Cloudflare는 방문자와 오리진 사이에 앉아 있습니다. Cloudflare가 자기 오리진 접근 시도에서 뭔가 깨지면 서버 응답을 돌려줄 수 없으니(응답이 없으니) 오류 페이지를 만듭니다. 그 페이지의 방문자용 HTTP 상태는 530이지만, 구체적 이유는 본문에 1xxx 코드로 채워 넣습니다. 530은 봉투, 1xxx는 편지입니다.

이것이 핵심이고, 놓치면 몇 시간을 날립니다: 530 그 자체로는 진단이 불가능합니다. “Error 530”을 똑같이 보여주는 두 사이트가 완전히 무관한 문제를 가질 수 있습니다. 530은 Cloudflare가 “내 1xxx 조건 중 하나에 걸렸다”고 말하는 것뿐이니까요. 530은 고칠 수 없습니다. 그것이 나르는 1xxx를 고치는 겁니다.

가장 흔한 승객은 단연 1016, Origin DNS Error — Cloudflare가 오리진 호스트명을 IP로 해석하지 못한 것입니다. 이게 무슨 뜻인지 보세요: 요청이 Cloudflare가 서버에 연결을 시도하기도 전에 죽은 것입니다. 걸 주소조차 못 얻었습니다. 그래서 서버가 멀쩡해 보이는 겁니다 — 애초에 아무것도 서버에 닿지 않았으니까요.

다른 1xxx 코드도 530 안에 탑니다: 예외를 던진 Worker(1101), 자원 한도를 넘은 Worker(1102), 교차 사용자 CNAME 차단(1014) 등. 해독 단계는 매번 동일합니다: 530 아래 숫자를 읽고, 그 숫자를 찾아보라. DechoNet엔 흔한 것들의 전용 가이드가 있습니다(1016 오리진 DNS, 1101/1102 Workers, 1014 CNAME) — 이 가이드는 당신을 맞는 곳으로 데려가는 지도입니다.

진짜 오류를 읽는 법

오류 페이지를 열어 두 번째 코드를 찾으세요. Cloudflare가 대놓고 찍어 줍니다:

Error 530
...
Host Error
origin.example.com
1016

그 1016이 당신의 실제 진단입니다. 페이지 본문 없이 모니터링 알림으로 530만 받았다면 curl -sv https://yourdomain.example/로 재현해 응답을 읽으세요 — Cloudflare가 반환 HTML에 코드를 담습니다. 그다음 530이 아니라 1xxx 숫자를 들고 해결로 가세요.

주요 원인 3가지 (흔한 530/1016)

1. 오리진 A 레코드 누락 - Cloudflare DNS에 프록시할 IP를 주는 A/AAAA 레코드가 없어 엣지에서 호스트명 해석이 실패합니다. 그게 오리진 포인터인 줄 모르고 레코드를 지우거나 수정한 뒤에 흔합니다.
2. 죽은 타깃을 가리키는 CNAME - 오리진이 더는 해석되지 않는 외부 호스트명(로드밸런서, SaaS 호스트, 이전 공급자)으로의 CNAME입니다. 호스트를 옮겼고, 옛 타깃의 DNS가 철거됐으며, 이제 CNAME이 아무것도 가리키지 않습니다. Cloudflare가 타깃을 해석하려다 NXDOMAIN을 받고 530/1016을 반환합니다.
3. 해석 불가한 로드밸런서 풀 오리진 - Cloudflare Load Balancing을 쓴다면, 기본·지역·폴백 풀의 오리진 호스트명이 더는 해석되지 않을 때 같은 1016이 납니다 — 존의 DNS 레코드는 멀쩡해 보이는데도요.

DechoNet으로 진단

• 오리진 호스트명 — 프록시된 www 이름이 아니라 Cloudflare가 닿으려는 실제 타깃 — 을 DNS 조회하세요. 오리진이 CNAME이면 그 타깃을 해석하세요. DNS 조회가 오리진 타깃에 A 레코드 없음이나 NXDOMAIN을 돌려주면, Cloudflare의 1016을 밖에서 재현한 것이고, 해결이 서버가 아니라 DNS 레코드임을 안 것입니다.
• 갈림을 확인: 건강한 오리진 서버 + 실패하는 오리진 호스트명 조회가 530/1016의 서명입니다. 문제는 어떤 서버 설정보다 위쪽인 이름 해석입니다.

해결 체크리스트

• 530이 아니라 1xxx 코드를 읽기. 아래 모든 게 어떤 코드냐에 달려 있고, 530만으로는 알 수 없습니다.
• 1016이면: Cloudflare DNS에 오리진용 유효한 A/AAAA 레코드(또는 해석되는 타깃으로의 CNAME)가 있는지 확인. 그 정확한 타깃에 DNS 조회를 돌려 주소가 나오는지 보세요.
• 호스트 이전 후엔 오리진 레코드를 다시 가리키거나 새로 만들기. 타깃 DNS가 삭제된 CNAME이 전형적 1016입니다 — 새 오리진으로 다시 가리키거나, IP를 통제한다면 A 레코드로 전환하세요.
• Cloudflare Load Balancing을 쓴다면 모든 풀 오리진(기본·지역·폴백)이 여전히 해석되는지 검증. 죽은 풀 멤버 하나가 530/1016으로 표출됩니다.
• 1016이 아닌 코드면 그 오류의 가이드로 점프 — 1101/1102를 감싼 530은 Worker 문제, 1014는 교차 사용자 CNAME이고, 해결이 완전히 다릅니다.

언제 에스컬레이션할까

• 오리진 레코드와 그 타깃이 둘 다 깔끔히 해석되는데도 Cloudflare가 530/1016을 계속 반환하면, Ray ID와 함께 Cloudflare 지원으로 올리세요 — 유효한 레코드에서 지속되는 해석 실패는 당신이 아니라 그들이 조사할 몫입니다.
• 감싼 코드가 1101이나 1102면 이건 DNS가 아니라 Cloudflare Workers 문제입니다 — Worker를 소유한 쪽으로 올리고, wrangler tail로 그 뒤의 예외나 자원 한도를 잡으세요.