Cloudflare Tunnel 라우팅(Routing)

원문 보기 위키 갱신 2026.10.07

Cloudflare Tunnel이 트래픽을 사설 네트워크와 서비스로 라우팅하는 방식을 알아봐요. 게시된 애플리케이션, 지원 프로토콜, DNS 레코드, 로드 밸런싱을 다뤄요.

출처: 문서

본문

Cloudflare Tunnel은 Cloudflare 네트워크에서 cloudflared 뒤에서 실행되는 서비스로 트래픽을 라우팅해요. 애플리케이션을 게시하면 공용 호스트 이름을 로컬 서비스에 매핑해요. 예를 들어 app.example.com을 http://localhost:8080에 매핑하고, Cloudflare는 요청을 오리진으로 전달하기 전에 CDN 캐싱, WAF, DDoS 보호를 적용해요.

게시된 애플리케이션(Published applications)

게시된 애플리케이션은 터널 구성에서 정의한 호스트 이름-서비스 매핑이에요. 각 매핑은 특정 공용 호스트 이름의 트래픽을 받을 로컬 서비스를 cloudflared에 알려줘요.

단일 터널에 여러 애플리케이션을 게시할 수 있어요. 각 애플리케이션에 대해 다음을 지정해요:

공용 호스트 이름 — 사용자가 방문하는 도메인 또는 서브도메인(예: app.example.com).
서비스 — 애플리케이션이 실행 중인 로컬 주소 또는 소켓(예: http://localhost:8080).

대시보드에서 라우트를 추가하면 Cloudflare가 호스트 이름을 터널 서브도메인(<UUID>.cfargotunnel.com)으로 가리키는 DNS 레코드를 자동으로 만들어요.

참고

공용 호스트 이름 라우트는 트래픽을 Cloudflare를 통해 프록시해요. Free, Pro, Business 요금제에서는 서비스별 약관 ↗︎에 따라 동영상 및 기타 대용량 파일을 제공하려면 특정 유료 서비스를 사용해야 해요.

자세한 내용은 Cloudflare로 동영상 제공을 참조해요. 대용량 파일을 비공개로 전송하려면 사설 네트워크 라우트를 대신 사용해요.

지원 프로토콜(Supported protocols)

아래 표는 공용 호스트 이름으로 라우팅할 수 있는 서비스 유형을 보여줘요. 비 HTTP 서비스는 최종 사용자가 연결하려면 클라이언트에 cloudflared를 설치해야 해요.

Service type	Description	Example `service` value
HTTP	Proxies incoming HTTPS requests to your local web service over HTTP.	`http://localhost:8000`
HTTPS	Proxies incoming HTTPS requests directly to your local web service. You can disable TLS verification for self-signed certificates.	`https://localhost:8000`
UNIX	Same as HTTP, but uses a Unix socket.	`unix:/home/production/echo.sock`
UNIX + TLS	Same as HTTPS, but uses a Unix socket.	`unix+tls:/home/production/echo.sock`
TCP	Streams TCP over a WebSocket connection. End users run `cloudflared access tcp` to connect. For long-lived connections, use Client-to-Tunnel instead.	`tcp://localhost:2222`
SSH	Streams SSH over a WebSocket connection. End users run `cloudflared access ssh` to connect. For long-lived connections, use Client-to-Tunnel instead.	`ssh://localhost:22`
RDP	Streams RDP over a WebSocket connection. For more information, refer to Connect to RDP with client-side cloudflared.	`rdp://localhost:3389`
SMB	Streams SMB over a WebSocket connection. For more information, refer to Connect to SMB with client-side cloudflared.	`smb://localhost:445`
HTTP_STATUS	Responds to all requests with a fixed HTTP status code.	`http_status:404`
BASTION	Allows `cloudflared` to act as a jump host, providing access to any local address.	`bastion`
HELLO_WORLD	Test server for validating your Cloudflare Tunnel connection (for locally managed tunnels only).	`hello_world`

IPv6 서비스 주소

서비스 값이 IPv6 리터럴일 때는 RFC 3986 ↗︎에서 정의한 대로 주소를 대괄호로 감싸요. 주소 안의 : 문자가 포트 구분자와 혼동되지 않도록 대괄호가 필요해요.

Service type	Example `service` value
HTTP	`http://[2001:db8::1]:8000`
HTTPS	`https://[2001:db8::1]:443`
TCP	`tcp://[2001:db8::1]:2222`
SSH	`ssh://[2001:db8::1]:22`
RDP	`rdp://[2001:db8::1]:3389`

호스트 이름과 IPv4 주소는 대괄호가 필요 없어요. http://localhost:8000과 http://192.0.2.1:8000은 그대로 유효해요.

DNS 레코드

터널을 만들면 Cloudflare가 <UUID>.cfargotunnel.com의 서브도메인을 생성해요. 이 서브도메인을 가리키는 CNAME 레코드를 만들어 호스트 이름에서 터널로 트래픽을 라우팅해요.

cfargotunnel.com 서브도메인은 같은 Cloudflare 계정의 DNS 레코드에 대해서만 트래픽을 프록시해요. 누군가 터널 UUID를 발견해도 다른 계정에 DNS 레코드를 만들어 이 터널을 통해 트래픽을 프록시할 수 없어요.

DNS 레코드 만들기

Cloudflare Tunnel의 DNS 레코드를 만들려면:

Cloudflare 대시보드 ↗︎에 로그인하고 도메인의 DNS Records로 이동해요. Records로 이동 ↗
Add record를 선택해요.
다음 값을 입력해요:
- Type: CNAME
- Name: 애플리케이션의 서브도메인
- Target: <UUID>.cfargotunnel.com
Save를 선택해요.

로컬 관리형 터널에서는 다음 명령으로 터널 서브도메인을 가리키는 CNAME 레코드를 만들어요:

cloudflared tunnel route dns <UUID or NAME> www.app.com

이 명령은 CNAME 레코드를 만들지만 터널이 실행 중이지 않으면 트래픽을 프록시하지 않아요.

참고

cloudflared로 DNS 레코드를 만들려면 cert.pem 파일이 시스템에 설치돼 있어야 해요.

DNS 레코드와 터널은 독립적이에요. 실행 중이지 않은 터널을 가리키는 DNS 레코드를 만들 수 있어요. 터널이 중지되면 DNS 레코드는 삭제되지 않으며, 방문자는 1016 오류를 보게 돼요.

같은 터널 서브도메인을 가리키는 DNS 레코드를 여러 개 만들 수도 있어요. 여러 호스트 이름에서 여러 서비스로 트래픽을 라우팅하려면 각 호스트 이름에 대한 CNAME 항목을 만들어요. 모든 항목은 같은 대상을 공유해요.

로드 밸런싱

공용 로드 밸런서를 사용해 게시된 애플리케이션을 실행하는 서버들에 트래픽을 분산해요. 이는 상태 점검 기반 장애 조치와 지역 간 지능형 트래픽 스티어링을 제공해요.

graph LR
    accTitle: Load balancing traffic to applications behind Cloudflare Tunnel

    A[Internet] --> C{Cloudflare <br> Load Balancer}
    C -- Tunnel 1 --> cf1
    C -- Tunnel 2 --> cf2
    subgraph F[Data center 2]
        cf2[cloudflared]
        S3[App server]
        S4[App server]
        cf2-->S3
        cf2-->S4
    end
    subgraph E[Data center 1]
        cf1[cloudflared]
        S1[App server]
        S2[App server]
        cf1-->S1
        cf1-->S2
    end

레플리카 대 로드 밸런서

같은 터널 UUID에서 여러 cloudflared 레플리카를 실행하면 기본 중복성을 제공해요. 호스트 하나가 실패해도 다른 레플리카가 트래픽을 계속 서빙해요. 다만 로드 밸런서는 같은 터널 UUID의 모든 레플리카를 단일 엔드포인트로 취급해요.

세밀한 트래픽 스티어링과 세션 어피니티가 필요하면 각 호스트를 서로 다른 터널 UUID로 연결해서 로드 밸런서가 각각을 독립적으로 처리할 수 있게 해요.

로드 밸런서 풀에 터널 추가하기

전제 조건

최소 하나의 게시된 애플리케이션 라우트가 있는 Cloudflare Tunnel.

Cloudflare Tunnel 게시 애플리케이션용 로드 밸런서를 만들려면:

Cloudflare 대시보드에서 Load Balancing 페이지로 이동해요. Load Balancing으로 이동 ↗
Create load balancer를 선택한 다음 Public load balancer를 선택해요.
Select website에서 게시된 애플리케이션 라우트의 도메인을 선택해요.
Hostname 페이지에서 로드 밸런서용 호스트 이름을 입력해요(예: lb.example.com).
Pools 페이지에서 Create a pool을 선택하고 설명적인 이름을 입력해요.
다음 값으로 터널 엔드포인트를 추가해요:
- Endpoint Name: 애플리케이션을 실행하는 서버 이름
- Endpoint Address: <UUID>.cfargotunnel.com (Tunnel ID는 Cloudflare 대시보드의 Networking > Tunnels에서 찾아요)
- Header value: 게시된 애플리케이션 라우트의 호스트 이름(예: app.example.com)
- Weight: 1 (엔드포인트가 하나뿐일 때)
참고

단일 오리진 풀은 같은 터널 UUID를 두 번 참조할 수 없어요.
Fallback pool을 선택해요. 라우팅 옵션은 traffic steering policies를 참조해요.
(권장) Monitors 페이지에서 엔드포인트에 모니터를 연결해요. HTTP 또는 HTTPS 애플리케이션에는 HTTPS 모니터를 만들어요:
- Type: HTTPS
- Path: /
- Port: 443
- Expected Code(s): 200
- Header Name: Host
- Value: app.example.com
로드 밸런서를 저장하고 배포해요.

테스트하려면 로드 밸런서 호스트 이름(lb.example.com)으로 애플리케이션에 접근해요.

TCP 터널 오리진 모니터링

TCP 모니터는 터널 엔드포인트에서 지원되지 않아요. 대신 cloudflared 호스트에 상태 점검 엔드포인트를 만들고 HTTPS 모니터를 사용해요. 예를 들어 cloudflared로 고정 HTTP 상태 응답을 반환할 수 있어요:

상태 점검용 게시된 애플리케이션 라우트를 추가해요:
- Hostname: health-check.example.com
- Service Type: HTTP_STATUS
- HTTP Status Code: 200
다음 설정으로 모니터를 만들어요:
- Type: HTTPS
- Path: /
- Port: 443
- Expected Code(s): 200
- Header Name: Host
- Value: health-check.example.com

이 모니터는 cloudflared가 도달 가능한지만 확인해요. 업스트림 서비스가 요청을 수락하는지는 확인하지 않아요.

로컬 연결 선호도

서로 다른 위치의 엔드포인트 간 트래픽 불균형이 눈에 띄면 로드 밸런서 구성을 조정해야 할 수 있어요.

Cloudflare는 Anycast 라우팅 ↗︎을 사용해 최종 사용자 요청을 가장 가까운 데이터 센터로 안내해요. cloudflared는 같은 데이터 센터의 연결을 사용해 요청을 서빙하는 것을 선호하며, 이는 엔드포인트 간 트래픽 분포에 영향을 줄 수 있어요.

같은 터널 UUID에서 cloudflared 레플리카를 실행한다면 트래픽 스티어링을 더 세밀하게 제어하기 위해 별도 터널로 전환하는 것을 고려해요.

Cloudflare 설정

게시된 애플리케이션은 호스트 이름의 Cloudflare 설정을 상속해요. 여기에는 캐시 규칙, WAF 규칙, 및 기타 Rules 구성이 포함돼요. 각 호스트 이름의 설정은 Cloudflare 대시보드 ↗︎에서 변경할 수 있어요.

로드 밸런서를 사용하면 설정은 대신 로드 밸런서 호스트 이름에 적용돼요.

더 알아보기 (Learn more)

라우팅의 핵심은 호스트 이름-서비스 매핑, 지원 프로토콜과 IPv6 주소 형식, DNS CNAME 레코드, 그리고 레플리카·로드 밸런서를 통한 트래픽 분산이에요.