본문으로 바로가기 본문 바로가기
WIKI 기술 지식 베이스

Cloudflare Tunnel 트러블슈팅(Troubleshooting)

원문 보기 위키 갱신

이 페이지로 Cloudflare Tunnel의 일반적인 문제를 진단하고 해결해요. 많은 문제는 cloudflared를 최신 버전으로 업그레이드하여 해결되니, 깊이 조사하기 전에 Update cloudflared를 먼저 참고해요.

출처: 문서

본문

터널 상태 모니터링, 로그, 메트릭은 Observability를 참고해요.

터널이 Healthy인데 HTTPS 경로가 실패하거나 리다이렉트된다면 HTTPS 오리진 트러블슈팅을 참고해요.

연결 오류(Connection errors)

cloudflared가 Cloudflare 네트워크에 도달할 수 없으면 DNS 해석, QUIC(UDP), 또는 TCP 연결성 문제인지 알려주는 특정 오류 메시지를 로그로 남겨요.

DNS 해석 실패

edge discovery: error looking up Cloudflare edge IPs

ERR edge discovery: error looking up Cloudflare edge IPs: the DNS query failed
    error="lookup _v2-origintunneld._tcp.argotunnel.com on 172.19.64.1:53: no such host"

이 오류는 머신에 구성된 DNS 해석기가 cloudflared가 Cloudflare Tunnel 목적지 IP를 발견하는 데 사용하는 SRV 레코드를 해석할 수 없다는 뜻이에요. 흔한 원인으로는 SRV 레코드를 제거하거나 차단하는 기업용 DNS 해석기, 압축된(compressed) SRV 레코드를 반환하는 DNS 해석기가 있어요.

진단 방법:

cloudflared 호스트 머신에서 실행해요:

dig SRV _v2-origintunneld._tcp.argotunnel.com

SERVFAIL, NXDOMAIN 또는 빈 답변을 받으면 Cloudflare의 공용 해석기로 테스트해요:

dig SRV _v2-origintunneld._tcp.argotunnel.com @1.1.1.1

해결 방법:

  • 1.1.1.1은 결과를 반환하는데 로컬 해석기는 그렇지 않다면, 호스트가 Cloudflare DNS(1.1.1.1) 또는 다른 공용 해석기를 사용하도록 구성해요.
  • 두 해석기 모두 결과를 반환하지 않는다면 방화벽이 아웃바운드 DNS 쿼리(UDP 포트 53)를 차단하고 있을 가능성이 커요. 네트워크 관리자와 협력해 DNS 트래픽을 허용해요.

DNS query failed ... i/o timeout

ERR edge discovery: error looking up Cloudflare edge IPs: the DNS query failed
    error="lookup _v2-origintunneld._tcp.argotunnel.com on 127.0.0.11:53:
    read udp 127.0.0.1:53467->127.0.0.11:53: i/o timeout"

이 변형은 cloudflared의 DNS 쿼리가 차단되거나 완전히 끊긴다는 뜻이에요 — 해석기가 전혀 응답하지 않아요. 내부 DNS 해석기(127.0.0.11)에 도달할 수 없거나 잘못 구성된 컨테이너 환경(Docker, Kubernetes)에서 흔해요.

해결 방법:

  • Docker에서 컨테이너의 DNS 구성(/etc/resolv.conf)을 확인해요. 컨테이너를 실행할 때 --dns 1.1.1.1로 해석기를 덮어쓸 수 있어요.
  • Kubernetes에서 kube-dns 또는 CoreDNS 서비스가 실행 중이고 파드에서 도달 가능한지 확인해요.
  • cloudflared 호스트에서 /etc/resolv.conf에 나열된 해석기가 도달 가능하고 쿼리에 응답하는지 확인해요.

QUIC 핸드셰이크 타임아웃

Failed to dial a quic connection

ERR Failed to dial a quic connection error="failed to dial to edge with quic:
    timeout: handshake did not complete in time" connIndex=0 ip=198.41.192.227
INF Retrying connection in up to 2s connIndex=0 ip=198.41.192.227

이 오류는 cloudflared가 Cloudflare Tunnel 목적지 IP를 해석했지만 UDP 포트 7844에서 QUIC 핸드셰이크를 완료할 수 없다는 뜻이에요. 네트워크나 방화벽이 Cloudflare로의 아웃바운드 UDP 트래픽을 차단하고 있어요.

cloudflared는 지수 백오프(2, 4, 8, 16, 32, 최대 64초)로 재시도해요. 재시도를 모두 소진하면 TCP를 통한 HTTP/2로 폴백해요:

INF Switching to fallback protocol http2 connIndex=0

폴백도 실패하면 TCP 연결 타임아웃 오류가 보일 거예요.

진단 방법:

cloudflared 호스트 머신에서 포트 7844의 연결성을 테스트해요:

nc -uvz -w 3 198.41.192.227 7844

198.41.192.227을 오류 메시지에 표시된 IP로 바꿔요. 포트가 닫혀 있거나 방화벽으로 차단되면 명령이 Connection refused를 반환하거나 타임아웃될 거예요.

해결 방법:

  • 방화벽 또는 보안 그룹에서 포트 7844로의 아웃바운드 UDP 트래픽을 허용해요. 전체 IP 및 포트 목록을 참고해요.
  • UDP를 열 수 없다면 cloudflared가 자동으로 TCP를 통한 HTTP/2로 폴백해요. [--protocol http2 실행 매개변수를 설정해 HTTP/2를 강제할 수도 있지만, 더 나은 성능을 위해 QUIC를 권장해요.

TCP 연결 타임아웃

DialContext error: dial tcp ... i/o timeout

ERR Unable to establish connection with Cloudflare edge
    error="DialContext error: dial tcp 198.41.200.43:7844: i/o timeout" connIndex=0
ERR Serve tunnel error
    error="DialContext error: dial tcp 198.41.200.43:7844: i/o timeout" connIndex=0

이 오류는 cloudflared가 TCP 포트 7844로 Cloudflare에 도달할 수 없다는 뜻이에요. 그 위에 QUIC 핸드셰이크 타임아웃도 함께 보인다면 UDP와 TCP가 모두 차단된 것이므로 터널은 전혀 연결할 수 없어요.

진단 방법:

빠른 테스트로 다음을 실행해요:

curl -v https://region1.v2.argotunnel.com:7844

연결이 끊긴다면 호스트와 Cloudflare 사이에서 트래픽이 버려지고 있는 거예요.

cloudflared가 포트 7844에 연결할 수 있는지 테스트하려면:

nc -vz -w 3 198.41.200.43 7844

198.41.200.43을 오류 메시지에 표시된 IP로 바꿔요. 포트가 닫혀 있거나 방화벽으로 차단되면 명령이 Connection refused를 반환하거나 타임아웃될 거예요.

해결 방법:

  • Cloudflare Tunnel IP 범위로의 아웃바운드 TCP 포트 7844 트래픽을 허용해요.
  • 환경이 포트 7844를 완전히 차단한다면(UDP와 TCP 모두) 터널이 작동할 수 없어요. 네트워크 관리자와 협력해 이 포트에서 아웃바운드 트래픽을 허용해요.

cloudflared service is already installed 메시지가 보여요.

원격 관리 터널을 설치할 때 이 오류가 보이면 이 머신에서 다른 cloudflared 인스턴스가 서비스로 실행 중이 아닌지 확인해요. 특정 머신에서는 오직 하나의 cloudflared 인스턴스만 서비스로 실행될 수 있어요. 대신 기존 터널에 추가 경로를 더해요. 또는 sudo cloudflared service uninstall을 실행해 cloudflared를 제거할 수도 있어요.

An A, AAAA, or CNAME record with that host already exists 메시지가 보여요.

터널의 공개 호스트 이름을 저장할 수 없다면 다른 호스트 이름을 선택하거나 기존 DNS 레코드를 삭제해요. Cloudflare 대시보드 ↗︎에서 도메인의 DNS 레코드를 확인해요.

터널 자격 증명 파일이 없거나 파일이 아닙니다.

터널을 실행할 때 다음 오류가 발생하면 config.yml 파일을 다시 확인하고 credentials-file이 올바른 위치를 가리키는지 확인해요. /root/를 홈 디렉터리로 바꿔야 할 수도 있어요.

cloudflared tunnel run

2021-06-04T06:21:16Z INF Starting tunnel tunnelID=928655cc-7f95-43f2-8539-2aba6cf3592d
Tunnel credentials file '/root/.cloudflared/928655cc-7f95-43f2-8539-2aba6cf3592d.json' doesn't exist or is not a file

터널이 인증에 실패해요.

Cloudflare Tunnel 사용을 시작하려면 Cloudflare 계정의 슈퍼 관리자가 먼저 cloudflared login으로 로그인해야 해요. 클라이언트는 브라우저 창을 띄우고 사용자에게 Cloudflare 계정의 호스트 이름을 선택하도록 요청해요. 선택하면 Cloudflare가 세 가지 구성 요소로 이루어진 인증서를 생성해요:

  • 해당 호스트 이름의 오리진 인증서 공개 키
  • 해당 도메인의 오리진 인증서 프라이빗 키
  • Cloudflare Tunnel에 고유한 토큰

이 세 구성 요소는 이 로그인 흐름에서 한 번 다운로드되는 단일 PEM 파일로 묶여요. 호스트 인증서는 루트 도메인과 한 단계 깊이의 서브도메인에 유효해요. Cloudflare는 이 인증서 파일을 사용해 cloudflared를 인증하고 여러분의 도메인에 대한 DNS 레코드를 Cloudflare에 만드는 것을 허가해요.

세 번째 구성 요소인 토큰은 존 ID(선택한 도메인용)와 login 명령으로 처음 인증한 사용자에게 범위가 지정된 API 토큰으로 구성돼요. 사용자 권한이 변경되면(예: 그 사용자가 계정에서 제거되거나 다른 계정의 관리자가 되는 경우) Cloudflare는 사용자의 API 키를 회전해요. 하지만 cloudflared를 통해 다운로드된 인증서 파일은 이전 API 키를 유지하므로 인증 실패를 일으킬 수 있어요. 사용자는 인증서를 다시 생성하기 위해 cloudflared로 한 번 더 로그인해야 해요. 또는 관리자가 전용 서비스 사용자를 만들어 인증하게 할 수도 있어요.

오류가 보여요: x509: certificate signed by unknown authority.

이는 오리진이 cloudflared가 신뢰하지 않는 인증서를 사용 중이라는 뜻이에요. 예를 들어 서버와 Cloudflare 사이의 프록시에서 SSL/TLS 검사를 사용하는 경우 이 오류가 날 수 있어요. 해결하려면:

  • CA 인증서를 시스템 신뢰 저장소에 추가한 뒤 cloudflared를 재시작해요.
  • caPool을 CA 인증서가 들어 있는 로컬 PEM 파일로 설정해요.
  • 임시 최후 수단으로 noTLSVerify를 true로 설정해요. 인증서 신뢰 체인을 수정한 뒤 꺼두어요.

--origin-ca-pool과 --no-tls-verify 명령줄 플래그는 --url로 단일 오리진을 정의할 때만 적용돼요. 인그레스 규칙의 경우 originRequest 아래에서 이 설정들을 구성해요.

터널을 실행하려고 할 때 오류 1033이 보여요.

1033 오류는 터널이 Cloudflare 네트워크에 연결되어 있지 않다는 뜻이에요. Cloudflare 네트워크가 트래픽을 받을 건강한 cloudflared 인스턴스를 찾을 수 없기 때문이에요.

먼저 Cloudflare 대시보드 ↗︎에서 Networking > Tunnels로 가거나 cloudflared tunnel list를 실행해 터널이 Active로 표시되는지 확인해요. 터널이 Active가 아니라면 다음을 검토하고 터널 상태에 필요한 조치를 취해요:

Status Meaning Recommended Action
Healthy The tunnel is active and serving traffic through four connections to the Cloudflare global network. No action is required. Your tunnel is running correctly.
Inactive The tunnel has been created (via the API or dashboard) but the cloudflared connector has never been run to establish a connection. Install and run cloudflared on your origin server to connect the tunnel to Cloudflare. You can find the installation command in the Cloudflare dashboard under Networking > Tunnels — select your tunnel, then on the Overview tab select Add a replica. For API-based setup, refer to Install and run the tunnel.
Down The tunnel was previously connected but is currently disconnected because the cloudflared process has stopped. 1. Ensure the cloudflared service or process is actively running on your server.
2. Check for server-side issues, such as the machine being powered off, an application crash, or recent network changes.
Degraded The cloudflared connector is running and the tunnel is serving traffic, but at least one individual connection has failed. Further degradation in tunnel availability could risk the tunnel going down and failing to serve traffic. 1. Review your cloudflared logs for connection failures or error messages.
2. Investigate local network and firewall rules to ensure they are not blocking connections to the Cloudflare Tunnel IPs and ports.

자세한 내용은 Cloudflare 1xxx 오류의 종합 목록을 참고해요.

터널을 통해 HTTP 또는 HTTPS 애플리케이션에 연결할 때 502 Bad Gateway 오류가 보여요.

터널 경로에서 Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared와 함께 502 Bad Gateway 오류가 발생하면 터널 자체는 Cloudflare 네트워크에 연결되어 있지만 cloudflared가 인그레스 규칙에 정의된 오리진 서비스에 도달할 수 없다는 뜻이에요. 터널이 Cloudflare에 연결되어 있지 않음을 나타내는 오류 1033과 달리, 502 오류는 cloudflared와 로컬 서비스 사이의 문제를 나타내요.

구체적인 원인을 찾으려면 Tunnel 로그에서 error 수준 메시지를 검토해요. 흔한 원인은 다음과 같아요:

오리진 서비스가 실행 중이 아님

오리진 서비스가 중지되었거나 시작된 적이 없다면 cloudflared 로그에 다음과 같은 오류가 표시돼요:

error="dial tcp [::1]:8080: connect: connection refused"

해결하려면 서비스가 실행 중이고 기대한 포트에서 수신 중인지 확인해요:

curl -v http://localhost:8080

서비스가 실행 중이 아니라면 시작하거나 재시작해요. ss -tlnp | grep <PORT>(Linux) 또는 lsof -iTCP -sTCP:LISTEN -nP | grep <PORT>(macOS)를 실행해 서비스가 수신 중인지 확인할 수 있어요.

오리진 서비스 URL이 잘못된 프로토콜 사용

오리진이 HTTPS를 기대하는데 터널 경로가 http://를 지정하거나 그 반대라면 cloudflared 로그에 다음과 같은 오류가 표시돼요:

error="net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\x15\x03\x01\x00\x02\x02\""

해결하려면 터널 경로의 서비스 URL을 오리진이 기대하는 프로토콜과 일치하도록 업데이트해요. 예를 들어 http://localhost:8080을 https://localhost:8080으로 바꿔요. 로컬 관리 터널을 사용한다면 구성 파일의 인그레스 규칙을 업데이트해요.

오리진 서비스 URL이 잘못된 포트를 가리킴

터널 경로의 포트가 서비스가 수신 중인 포트와 일치하지 않으면 cloudflared가 그 포트에 대해 connection refused 오류를 기록해요. 인그레스 규칙의 서비스 URL을 다시 확인하고 애플리케이션이 바인딩된 포트와 비교해요.

cloudflared가 오리진 인증서를 검증할 수 없음

오리진이 cloudflared가 검증할 수 없는 TLS 인증서를 제시하면 로그에 다음과 같은 오류가 표시돼요:

error="x509: certificate is valid for example.com, not localhost"

이 오류는 인증서가 서비스 호스트 이름을 커버하지 않는다는 뜻이에요. 반면 x509: certificate signed by unknown authority 오류는 cloudflared가 인증 기관을 신뢰하지 않는다는 뜻이에요.

해결하려면 다음 방법 중 하나를 사용해요:

  • 터널 경로에서 originServerName을 오리진 인증서의 호스트 이름으로 설정해요. 로컬 관리 터널을 사용한다면 구성 파일 예시가 다음과 같아요:

    ingress:
  - hostname: app.example.com
    service: https://localhost:443
    originRequest:
      originServerName: app.example.com

  • caPool로 CA 인증서를 제공해요:

    ingress:
  - hostname: app.example.com
    service: https://localhost:443
    originRequest:
      caPool: /path/to/ca-cert.pem

  • 임시 최후 수단으로 noTLSVerify로 TLS 검증을 비활성화해요. 인증서 문제를 해결한 뒤 꺼두어요.

    ingress:
  - hostname: app.example.com
    service: https://localhost:443
    originRequest:
      noTLSVerify: true

게시된 애플리케이션이 ERR_TOO_MANY_REDIRECTS를 반환해요.

이 오류는 오리진이 HTTP 요청을 HTTPS로 리다이렉트하는데 게시된 애플리케이션 경로가 http:// Service URL을 사용할 때 발생할 수 있어요. 각 요청이 HTTP로 오리진에 도달하고 동일한 리다이렉트를 받아요.

올바른 서비스 URL과 오리진 설정을 선택하려면 HTTPS 오리진 트러블슈팅을 참고해요. 리다이렉트 체인이 HTTP와 HTTPS를 번갈아 가며 나타나면 ERR_TOO_MANY_REDIRECTS도 참고해요.

cloudflared access가 websocket: bad handshake 오류를 보여요.

이는 cloudflared access 클라이언트가 cloudflared tunnel 오리진에 도달할 수 없다는 뜻이에요. 진단하려면 cloudflared tunnel 로그를 봐요. 흔한 근본 원인은 cloudflared tunnel이 오리진으로 프록시할 수 없는 경우예요(예: 인그레스가 잘못 구성, 오리진이 다운, 오리진 HTTPS 인증서를 cloudflared tunnel이 검증할 수 없음). cloudflared tunnel에 로그가 없다면 Cloudflare 네트워크가 websocket 트래픽을 여기로 라우팅하지 못한다는 뜻이에요.

이 오류 뒤에는 여러 가능한 근본 원인이 있어요:

  • cloudflared tunnel이 실행되지 않거나 Cloudflare 네트워크에 연결되어 있지 않아요.
  • WebSockets가 활성화되어 있지 않아요.
  • Cloudflare 계정에 Universal SSL이 활성화되어 있지만 SSL/TLS 암호화 모드가 Off (not secure) 로 설정되어 있어요. 해결하려면 Cloudflare 대시보드에서 SSL/TLS > Overview로 가서 SSL/TLS 암호화 모드를 Flexible, Full 또는 Full (strict) 로 설정해요.
  • 요청이 Super Bot Fight Mode로 차단되고 있어요. 해결하려면 봇 파이트 모드 설정에서 Definitely automated을 Allow로 설정해요.
  • SSH 또는 RDP Access 애플리케이션에 Binding Cookie가 활성화되어 있어요. 쿠키를 비활성화하려면 Access controls > Applications로 가서 애플리케이션 설정을 편집해요.
  • 하나 이상의 Workers 경로가 터널 호스트 이름과 겹치는데 Workers가 트래픽을 제대로 처리하지 않아요. 해결하려면 터널 호스트 이름을 포함하는 경로를 정의하지 않아 터널을 Worker 경로에서 제외하거나, Worker가 특정 경로만 처리하고 나머지 요청은 오리진으로 전달하도록 업데이트해요(예: return fetch(req) 사용).

터널 연결이 SSL 오류로 실패해요.

cloudflared가 error="remote error: tls: handshake failure" 오류를 반환하면 해당 호스트 이름이 SSL 인증서로 커버되는지 확인해요. 다중 레벨 서브도메인을 사용한다면 Universal SSL이 한 단계 이상의 서브도메인을 커버하지 않으므로 고급 인증서가 필요할 수 있어요. 이는 브라우저에 ERR_SSL_VERSION_OR_CIPHER_MISMATCH로 표면화될 수 있어요.

터널 연결이 Too many open files 오류로 실패해요.

Cloudflare Tunnel 로그가 socket: too many open files 오류를 반환하면 cloudflared가 머신의 열린 파일 제한을 소진했다는 뜻이에요. 열 수 있는 최대 파일 수(파일 디스크립터)는 프로세스가 열 수 있는 파일 수를 결정하는 운영 체제 설정이에요. 열린 파일 제한을 늘리려면 cloudflared를 실행하는 머신에서 ulimit 설정을 구성해야 해요.

로그에서 failed to sufficiently increase receive buffer size가 보여요.

이 버퍼 크기 증가는 cloudflared ↗︎가 활용하는 quic-go 라이브러리 ↗︎에 의해 보고돼요. 로그 메시지에 대해 quic-go 저장소 ↗︎에서 자세히 배울 수 있어요. 이 로그 메시지는 일반적으로 영향이 없으며 트러블슈팅할 때 안전하게 무시할 수 있어요. 다만 독특한 고대역폭 환경에 cloudflared를 배포했다면 테스트 목적으로 버퍼 크기를 수동으로 덮어쓸 수 있어요.

Linux에서 최대 수신 버퍼 크기를 설정하려면:

  1. /etc/sysctl.d/ 아래에 새 파일을 만들어요:

    sudo vi 98-core-rmem-max.conf

  2. 파일에서 원하는 버퍼 크기를 정의해요:

    net.core.rmem_max=2500000

  3. cloudflared를 실행하는 호스트 머신을 재부팅해요.

  4. 변경 사항이 적용되었는지 확인하려면 grep 명령을 사용해요:

    sudo sysctl -a | grep net.core.rmem_max

    net.core.rmem_max = 2500000

Cloudflare Tunnel이 스트리밍 응답을 실시간으로 스트리밍하는 대신 버퍼링해요.

오리진 서버가 Content-Type: text/event-stream 응답 헤더를 포함하지 않는 한 Cloudflare Tunnel을 통한 프록시 트래픽은 기본적으로 버퍼링돼요. 이 헤더는 cloudflared에게 전체 응답을 버퍼링하는 대신 데이터가 도착할 때 스트리밍하라고 알려줘요.

Cloudflare Tunnel이 Palo Alto Networks Next-Generation Firewall을 통해 연결하지 못해요.

Cloudflare는 최근 Palo Alto Networks Next Generation Firewall(NGFW) App-ID 데이터베이스 버전 9128의 변경을 알게 됐는데, 이 변경이 Cloudflare Tunnel과 Cloudflare One Client 트래픽을 허용하기 위한 요구 사항에 영향을 줘요.

Palo Alto Networks Next Generation Firewall(NGFW)은 App-ID 데이터베이스 버전과 관계없이 Cloudflare Tunnel(cloudflared)과 Cloudflare One Client(WARP with Zero Trust)를 모두 cloudflare-warp로 감지해요. 현재 cloudflared에 대한 별도의 App-ID는 없어요.

이 문제는 Cloudflare One Client와 WARP 클라이언트에 영향을 줄 가능성이 높은데, Palo Alto Networks NGFW가 그들의 트래픽을 cloudflare-warp로 식별하기 때문이에요.

이 섹션은 QUIC(UDP 포트 7844)를 통해 Cloudflare에 연결하는 Cloudflare Tunnel(cloudflared)에 초점을 맞춰요.

App-ID 데이터베이스 버전 9128(2026년 7월 27일 출시)부터 NGFW가 이 트래픽 허용 요구 사항을 변경했어요. App-ID 데이터베이스 버전 9128 이상은 이전에 요구된 App-ID와 그 종속 항목에 더해 quic-base 애플리케이션을 명시적으로 허용할 것을 요구해요.

연결을 복원하려면 App-ID 데이터베이스를 되돌리거나, 필요한 애플리케이션과 UDP 포트를 명시적으로 허용해요.

옵션 1: App-ID 데이터베이스 되돌리기

App-ID 데이터베이스 버전 9127로 되돌리고 Palo Alto Networks가 영구 해결책을 제공할 때까지 자동 App-ID 업데이트를 비활성화해요.

App-ID 데이터베이스를 되돌리면 임시 완화책으로 취급하고 보안 팀과 조율해요. Palo Alto Networks가 영구 해결책을 제공하면 자동 업데이트를 다시 활성화해요.

옵션 2: 명시적 방화벽 정책 구성

UDP 포트 7844용 사용자 지정 서비스 만들기

  1. PAN-OS에서 Objects > Services로 이동해요.

  2. 다음 설정으로 서비스를 만들어요:

    Setting Value
    Name cloudflared_7844_udp
    Description Optional
    Protocol UDP
    Destination Port 7844
    Source Port Leave blank
    Session Timeout Inherit from application

  3. OK를 선택해요.

방화벽 규칙 생성 또는 업데이트

  1. Policies로 이동해요.
  2. universal 또는 interzone 방화벽 규칙을 만들거나 수정해요.
  3. Source 및 Destination 조건을 환경의 관련 트래픽 흐름과 일치하도록 구성해요:
    • Source: 적절한 Source Zone 및/또는 Source Address를 선택해요.
    • Destination: 적절한 Destination Zone 및/또는 Destination Address를 선택해요.
  4. Application 아래에 다음 애플리케이션을 모두 추가해요:
    • cloudflare-warp
    • quic-base
  5. Service/URL Category 아래에 사용자 지정 서비스 cloudflared_7844_udp를 추가해요.
  6. 규칙 Action을 Allow로 설정해요.
  7. 조직의 보안 정책에 따라 로깅을 활성화해요.
  8. 정책 변경을 커밋한 뒤 Cloudflare Tunnel이 방화벽을 통해 연결을 설정하고 유지할 수 있는지 확인해요.

지원팀에 어떻게 연락하나요?

가장 빠른 트러블슈팅을 위해 지원 티켓에 포괄적인 세부 정보가 포함되도록 해요. 제공하는 문맥이 많을수록 문제를 더 빨리 식별하고 해결할 수 있어요.

지원에 연락할 때 효율적인 해결을 위해 티켓에 관련 세부 정보를 최대한 많이 포함해요:

  • 문맥: 시나리오나 사용 사례를 간략히 설명해요(예: 사용자가 어디에 있었고 무엇을 하려 했는지).
  • 재현 단계: 트러블슈팅 중 문제를 재현하기 위해 취한 단계를 설명해요.
  • 타임스탬프: 구체적으로 작성하고 문제 발생 시각과 시간대를 정확히 포함해요.
  • 트러블슈팅 시도: 문제를 해결하기 위해 이미 시도한 트러블슈팅 단계나 변경을 요약해요.
  • Tunnel ID와 터널 이름.
  • cloudflared 버전(cloudflared --version 실행).
  • 터널 설정 방법(로컬 관리 또는 대시보드를 통한 원격 관리).
  • 터널 로그: 로컬 머신의 로그를 포함해요.
  • 터널 진단 로그: 터널 진단 로그를 포함해요.

문제를 더 빨리 해결하려면 상세 티켓을 작성해요

모호한 설명을 피하고 시나리오, 타임스탬프, 문제 트러블슈팅을 위해 취한 단계를 포함해요. 다음 예시를 참고해요:

Acme Corp은 2025년 10월 30일 오후 3시 45분 UTC경 터널 연결 설정을 시도했습니다. DNS 해석과 TCP 연결성 테스트는 통과했지만 cloudflared 데몬 로그에 failed to sufficiently increase receive buffer size 오류가 표시되었습니다. 오후 3시 50분 UTC에 수집된 터널 진단 로그와 DNS 및 네트워크 연결성 사전 검사 출력을 첨부합니다.

디버그 로그 수집

트러블슈팅을 위해 자세한 출력을 캡처하려면:

  • 로컬 관리 터널: --loglevel debug 플래그로 cloudflared를 실행해요:

    cloudflared tunnel --loglevel debug run

    로그를 파일로 유지하려면 --logfile 플래그를 추가해요:

    cloudflared tunnel --loglevel debug --logfile /var/log/cloudflared/cloudflared.log run

  • 원격 관리 터널(대시보드로 생성): 터널의 실행 매개변수에서 로깅을 구성해요. 원격 로그 스트리밍 기능으로 로그를 실시간 스트리밍할 수도 있어요.

지원에 연락할 때 디버그 로그를 첨부해요 — 포함할 정보 전체 목록은 위 체크리스트를 참고해요.

더 알아보기 (Learn more)

대부분의 문제는 cloudflared 업그레이드와 연결성(포트 7844 UDP/TCP, DNS SRV 해석) 점검으로 해결돼요. 502 오류는 Cloudflare 연결이 아니라 cloudflared와 로컬 오리진 사이의 문제를 뜻한다는 점을 기억하세요.