Cloudflare Error 1033: 터널 오류 해결

문제

Cloudflare 뒤의 사이트가 Error 1033: Cloudflare Tunnel error(오래된 구성은 “Argo Tunnel error”)를 반환합니다. 엣지가 페이지 틀을 서빙했으니 Cloudflare 자체는 도달 가능합니다 — 하지만 요청을 백엔드로 넘기지 못했습니다. 백엔드가 Cloudflare 터널을 통해 연결돼 있는데 지금 응답하는 건강한 cloudflared 커넥터가 없기 때문입니다.

증상

• Cloudflare 오류 페이지가 Error 1033을 “Cloudflare Tunnel error” 및 Ray ID와 함께 표시.
• 서버 재부팅·배포·컨테이너 재시작·자격증명 변경 직후에 시작 — 오리진은 돌아왔는데 터널은 안 돌아옴.
• 로컬에서 확인하면 오리진 웹 서버는 살아 있는데, 호스트명을 통한 모든 요청은 1033을 반환.
• cloudflared tunnel list나 Zero Trust 대시보드가 터널을 비활성·다운·연결 0으로 표시.

이 오류의 진짜 의미

대부분의 Cloudflare 사이트는 일반 오리진을 씁니다: 엣지가 서버 IP의 443·80 포트로 네트워크 연결을 엽니다. Cloudflare 터널은 이걸 뒤집습니다. Cloudflare가 걸어 들어오는 대신, cloudflared라는 경량 데몬이 오리진 옆에서 돌며 Cloudflare 엣지로 걸어 나가 지속 연결을 열어 둡니다. 호스트명 DNS는 <UUID>.cfargotunnel.com 타깃으로의 CNAME이고, 엣지는 요청을 그 아웃바운드 터널로 커넥터에 라우팅하며, 커넥터가 로컬 서비스로 전달합니다. 인바운드 포트도, 노출된 오리진 IP도 없습니다.

Error 1033은 엣지가 터널에 연결된 호스트명 요청을 받아, 내려보낼 건강한 cloudflared 커넥터를 찾았지만 하나도 못 찾았다는 뜻입니다. 터널은 구성상 존재하지만 지금 살아 있는 연결이 없습니다. 이건 직접 오리진에 닿으려다 실패하는 걸 전제하는 520~524와 근본적으로 다른 실패입니다. 여기엔 닿을 직접 오리진이 없습니다 — 터널의 핵심은 커넥터가 손을 뻗는 것인데, 그 커넥터가 사라진 겁니다.

실무 번역: 오리진은 멀쩡할지 몰라도, 오리진으로 트래픽을 나르는 것 — cloudflared — 이 지금 Cloudflare에 연결돼 있지 않습니다.

가장 흔한 원인 3가지

1. cloudflared 프로세스가 실행 중이 아님 - 크래시했거나, 중지됐거나, 기기가 재부팅됐는데 서비스가 부팅 시 시작하도록 설정돼 있지 않은 경우. 단일 최다 원인이고, 1033이 유지보수 후 그토록 확실히 나타나는 이유입니다: 오리진은 돌아오고 터널 데몬은 안 돌아옵니다. 서비스 재활성화 없이 서버를 재시작하는 배포가 바로 이걸 만듭니다.
2. 커넥터가 Cloudflare 엣지에 못 닿음 - cloudflared는 Cloudflare로 아웃바운드 연결합니다(7844 포트에서 QUIC/HTTP2). 방화벽·이그레스 정책·네트워크 변경이 그 아웃바운드 연결을 막으면 데몬은 돌아도 등록을 못 해 — 엣지는 여전히 건강한 커넥터 0을 봅니다. 기기가 웹 브라우징은 되면서도 7844가 필터링되면 터널 수립에 실패할 수 있습니다.
3. 경로나 자격증명이 잘못된(또는 삭제된) 터널을 가리킴 - DNS CNAME이나 터널의 공개 호스트명 인그레스 규칙이 이제 실행 중인 커넥터가 없는 터널 UUID로 매핑된 경우 — 흔히 터널 재생성, 터널 토큰 회전, named/legacy 터널 간 마이그레이션 뒤. 옛 경로는 해석되고, 새 커넥터는 다른 ID로 돌고, 둘이 만나지 못합니다.

DechoNet으로 진단하기

• HTTP 진단은 네트워크 밖에서 호스트명을 가져와 실시간 엣지 응답을 보여줍니다. 1033이 여전히 모두에게 일어나는지(진짜 죽은 커넥터) 아니면 로컬 문제인지 확인해 주고, 터널이 복구되는 순간을 알려줍니다.
• DNS 진단은 호스트명 레코드를 보여줍니다. 터널 호스트명은 Cloudflare를 통해 cfargotunnel.com CNAME 타깃으로 해석돼야 합니다 — 요청이 정말 터널로 라우팅되는지, 낡은 직접 A 레코드가 아닌지 확인합니다.
• SSL 진단은 엣지가 TLS를 정상 종단하는지 확인해, 그 앞의 인증서 문제가 아니라 커넥터를 진단하고 있음을 보장합니다.

해결 체크리스트

• 직접 오리진이 아니라 터널인지 확인: 호스트명은 <UUID>.cfargotunnel.com으로의 Cloudflare 프록시 CNAME이어야 합니다. 오리진 서버를 쫓기 전에 DNS 진단으로 라우팅을 검증하세요.
• 커넥터 기기에서 데몬이 실행 중인지 확인 — systemctl status cloudflared(또는 당신의 서비스 매니저) — 중지됐으면 재시작하세요. 다음 재부팅이 이걸 재현하지 않도록 부팅 시 시작을 설정하세요.
• 터널이 건강한 연결을 보이는지 확인: cloudflared tunnel info <name> 또는 Zero Trust → Networking → Tunnels. 연결 0은 커넥터가 엣지에 등록되지 않았다는 뜻입니다.
• 커넥터에서 Cloudflare로의 아웃바운드 연결(7844 포트)을 확인하세요. 나갈 수 없는 실행 중 데몬은 엣지 입장에서 중지된 데몬과 똑같아 보입니다.
• 최근 터널을 재생성했거나 토큰을 회전했다면, DNS 경로와 인그레스 규칙이 실행 중인 커넥터가 실제로 쓰는 터널 UUID를 가리키는지 다시 확인하세요. 자격증명이 바뀌었으면 커넥터를 재인증하세요.
• HTTP 진단을 다시 돌려 호스트명이 1033 대신 이제 당신의 앱을 서빙하는지 확인하세요.

에스컬레이션 시점

• 방문자라면 당신 쪽에서 넘길 게 없습니다 — 사이트 소유자가 커넥터를 복구해야 합니다. 새로고침·캐시 삭제·네트워크 전환은 도움이 안 됩니다.
• 커넥터가 실행 중이고 7844에 닿을 수 있는데도 터널이 여전히 연결 없음을 보이면, Ray ID와 터널 ID를 담아 Cloudflare 티켓을 여세요 — 엣지측 등록에 그들의 손이 필요할 수 있습니다.
• 1033이 부하 중이나 배포마다 깜빡인다면 Cloudflare 문제가 아니라 프로세스 관리 문제로 에스컬레이션하세요: cloudflared에 제대로 된 서비스 정의, 헬스 체크, 자동 재시작이 필요합니다 — 재부팅과 재배포를 견디도록.