브라우저에서는 잘 열리는데 왜 API나 크론잡은 Error 1003이 뜨나요?

브라우저와 스크립트가 Cloudflare에 접근하는 방식이 다르기 때문입니다. 브라우저는 호스트명을 해석해 Cloudflare 엣지 IP에 연결하고 `Host: yourdomain.com`을 보냅니다 — 그래서 Cloudflare가 어느 존을 원하는지 압니다. IP를 하드코딩한 스크립트는 같은 엣지에 연결하지만 호스트로 IP를 보내는데, Cloudflare는 맨 IP를 매핑할 존이 없습니다. 엣지 IP 하나가 수백만 사이트를 앞단에서 받으므로, 진짜 호스트명이 없으면 라우팅할 곳이 없어 1003이 납니다. 클라이언트를 호스트명으로 바꾸면 됩니다.

Error 1003은 제 IP가 차단된 건가요? 밴당한 건가요?

아닙니다. 1003은 평판이나 방화벽 결정과 무관합니다 — 순전히 엣지를 *어떻게* 지정했느냐(호스트명 대신 IP)의 문제입니다. 실제 IP 밴은 Error 1006/1007/1008로, 커스텀 WAF·방화벽 차단은 1020으로, 레이트 리밋은 1015로 나타납니다. 1003은 IP 자체와 무관하므로 네트워크를 바꾸거나 VPN을 켜도 달라지지 않습니다. 호스트명을 쓰면 매번 해결됩니다.

오리진을 직접 테스트하려고 IP를 넣었습니다. 제대로 테스트하려면?

Cloudflare 엣지 IP에 맨 IP를 호스트로 보내면 항상 1003이 납니다 — 그건 오리진 테스트가 아니라 Cloudflare 라우팅 테스트입니다. 실제 경로를 테스트하려면 호스트명을 쓰세요: `curl -I https://yourdomain.com`. Cloudflare 뒤의 *오리진*을 테스트하려면 `curl --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com`으로 호스트명을 오리진의 진짜 IP로 해석시켜 올바른 Host 헤더와 SNI가 함께 가게 하세요. URL에 Cloudflare IP를 넣어 테스트하지 마세요.

조회수: 100

Error 1003 Direct IP Access Not Allowed (Cloudflare)

Error 1003은 요청이 호스트명이 아니라 IP로 Cloudflare에 닿았다는 뜻입니다. 클라이언트·DNS 프록시·오리진 노출을 점검하세요. 무료 HTTP 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

문제

Cloudflare 오류 페이지가 뜹니다: Error 1003, Direct IP access not allowed, HTTP 403과 함께요. 먼저 이해할 점 — 이 오류는 당신 서버에서 오지 않습니다. Cloudflare 엣지에서 오고, 딱 한 가지 이유로 발생합니다: 무언가가 호스트명이 아니라 맨 숫자 주소로 Cloudflare IP를 지정했습니다. Cloudflare 엣지는 공유 인프라입니다. anycast IP 하나가 수백만 개의 서로 다른 사이트를 앞단에서 받고, Cloudflare는 요청의 Host 헤더로 어느 사이트를 원하는지 알아냅니다. 쓸 만한 호스트명 없이 맨 IP를 보내면 라우팅할 존이 없습니다. 그래서 1003으로 막습니다. 해결은 거의 오리진이 아니라, 맨 IP가 쓰인 그곳에 있습니다.

증상

Cloudflare 경고 화면이 Error 1003 / Direct IP access not allowed로, HTTP 403으로 반환됩니다.
같은 사이트가 정상 도메인으로는 브라우저에서 완벽하게 열립니다 — IP로 지정한 경로만 실패합니다.
사람 트래픽은 멀쩡한데 스크립트·모니터·웹훅·API 클라이언트에서 나타납니다.
네트워크·IP·VPN을 바꿔도 달라지지 않습니다. 오류가 IP 평판과 무관하기 때문입니다.

주요 원인 3가지

클라이언트가 호스트명 대신 IP를 하드코딩 - 압도적으로 흔한 원인. API 클라이언트, 가동 모니터, 크론잡, CI 단계, 웹훅이 숫자 IP로 설정됨 — 이제 Cloudflare로 해석되는 옛 오리진 IP이기도 하고, dig 결과에서 복사한 Cloudflare 엣지 IP이기도 합니다. 연결해서 IP를 호스트로 보내면 Cloudflare가 라우팅할 대상이 없습니다. 브라우저는 항상 호스트명을 지니므로 이걸 안 겪습니다.
누군가 IP로 직접 접속 - 북마크, 복사된 링크, 또는 주소창에 https://104.x.x.x/를 친 사람. 연결이 IP를 호스트로 한 채 Cloudflare 엣지에 닿고, 1003이 곧장 돌아옵니다. 무해하지만 지원 티켓을 만듭니다.
서버 대 서버 연동이 잘못된 주소를 고정 - “속도를 위해 IP로” 오리진을 호출하도록 설정된 플러그인·헬스체크·내부 서비스가 (레코드가 프록시되므로) Cloudflare IP를 치고 실패합니다. 정확한 경계에 주목하세요: 1003은 당신이 접촉한 IP가 Cloudflare 소유일 때만 발생합니다. 진짜 오리진 IP를 직접 치면 — 예컨대 레코드가 DNS-only면 — Cloudflare를 아예 우회하므로 1003이 전혀 안 나고, 오리진(또는 오리진 자체 오류)에 닿습니다. 1003은 엣지가 “당신이 나를 숫자로 지정했다”고 말하는 특정 상황입니다.

DechoNet으로 진단

호스트명으로 HTTP 진단을 하면 사이트의 실제 응답이 돌아와야 합니다. 호스트명은 되는데 IP만 실패하면, 사이트는 정상이고 맨 IP가 문제 전부임을 확인한 것입니다 — 이제 그걸 쓰는 범인을 찾으세요.
DNS 진단은 호스트명이 무엇으로 해석되는지 보여줍니다. 프록시된 레코드는 Cloudflare anycast 대역(예: 104.16.0.0/13, 172.64.0.0/13)을 반환합니다. 클라이언트가 그중 하나를 하드코딩했다면 그게 1003의 근원입니다 — 주소는 “당신 서버”처럼 보이는데 Cloudflare로 응답하는 이유이기도 합니다.

해결 체크리스트

IP를 쓴 곳을 찾으세요. 실패하는 숫자 주소를 앱 설정·모니터링·웹훅·CI·크론에서 검색하세요. 해결책은 거기에 있습니다.
어디서든 IP를 호스트명으로 바꾸세요 — API 베이스 URL, 모니터 대상, 웹훅 엔드포인트, 북마크. Cloudflare는 Host로 라우팅합니다. 진짜를 주세요.
서버 대 서버 호출이 꼭 IP를 고정해야 한다면(드물고 대개 실수), 진짜 호스트명의 올바른 Host 헤더와 SNI를 보내고, Cloudflare 엣지 IP가 아니라 오리진의 IP를 고정하세요. 더 나은 방법: 호스트명을 해석시켜 anycast가 건강한 엣지를 고르게 하세요.
curl -I https://yourdomain.com(정상) 대 curl -I https://CLOUDFLARE_IP(1003)로 확인하세요. 두 명령의 대비가 진단을 증명합니다.
오리진으로의 직접 IP 접근을 실제로 막고 싶다면 — 건강한 기본값 — 오리진 방화벽을 Cloudflare 공개 IP 대역으로 잠그고 Authenticated Origin Pulls를 켜세요. 그러면 IP 단위 탐침이 설계상 서버에 닿지 못합니다.

에스컬레이션 시점

하드코딩된 IP를 전부 없앴는데도 정상 트래픽이 여전히 1003에 걸리면, 정확한 요청을 캡처하세요 — Host 헤더가 단서입니다. 비어 있거나 IP값인 호스트가 결정적 증거이며, 잘못 설정된 클라이언트를 곧장 가리킵니다.
수정할 수 없는 서드파티 연동이 IP로 연결을 고집한다면, 그건 벤더가 고칠 버그입니다. 그들의 지름길을 위해 오리진 IP를 노출하지 말고 호스트명과 --resolve 패턴을 주세요.
다른 Cloudflare 오류를 예상한 자리에서 1003이 보이면 — WAF 차단(1020), 레이트 리밋(1015), IP 밴(1006–1008) — 엉뚱한 걸 진단 중입니다. 1003은 언제나 “엣지를 IP로 지정했다”뿐입니다. 나머지는 당신이 누구냐에 대한 정책 결정이지, 어떻게 연결했느냐가 아닙니다.