Cloudflare Tunnel 변경 로그(Changelog)

원문 보기 위키 갱신 2026.10.07

Cloudflare Tunnel의 최신 릴리스 노트와 기능 변경 사항을 시간순으로 정리한 페이지예요. RSS를 구독해 최신 변경 사항을 바로 받아볼 수도 있어요.

출처: 문서

본문

2026-10-02

Quick Tunnels를 이메일 인증으로 보호하기

이제 Quick Tunnel에 접근할 수 있는 사용자를 제한할 수 있어요. cloudflared의 새 --allowed-mail 플래그를 사용해 방문자가 로컬 서비스에 도달하기 전에 이메일로 전송되는 일회용 PIN으로 인증하도록 요구할 수 있어요.

cloudflared tunnel --url http://localhost:8080 --allowed-mail alice@example.com

Protected Quick Tunnel demo

이전에는 trycloudflare.com URL을 가진 사람은 누구나 그 뒤의 서비스에 접근할 수 있었어요. 보호된 Quick Tunnels를 사용하면 Cloudflare 계정을 만들거나 도메인을 구성하지 않고도 특정 인원과 로컬 개발 서버, 웹훅 수신기, 데모를 공유할 수 있어요.

허용할 수 있는 대상:

단일 이메일 주소: --allowed-mail alice@example.com
여러 이메일 주소(플래그를 반복하거나 쉼표로 구분된 목록 사용): --allowed-mail 'alice@example.com,bob@example.com'
도메인의 모든 주소: --allowed-mail '*@example.com'

방문자는 Cloudflare 계정이 필요 없어요. cloudflared 프로세스를 중지하면 모든 사람의 접근이 종료돼요.

시작하려면 cloudflared를 최신 버전으로 업데이트하고 이메일로 접근 제한 문서를 참고해요.

2026-09-29

네트워크 로그에서 Mesh, Workers VPC, Cloudflare Tunnel 레플리카 식별하기

이제 커넥터 이메일 주소나 Mesh IP 범위를 대조하지 않고도 노트북 사용자와 Mesh 노드 또는 Workers에서 실행되는 AI 에이전트를 구분할 수 있고, 각 세션을 받은 정확한 Cloudflare Tunnel과 cloudflared 레플리카를 확인할 수 있어요.

Gateway 네트워크 로그와 Zero Trust Network Session Logs가 이제 두 가지 새로운 트래픽 종류를 식별해요:

Mesh — Cloudflare Mesh 노드에서 보내거나 노드로 전달된 트래픽. 이전에는 Mesh 노드가 헤드리스 모드로 클라이언트를 실행하기 때문에 Cloudflare One Client를 실행하는 기기와 같은 방식으로 기록됐어요.
Workers VPC — Workers VPC 바인딩을 통해 Worker가 보낸 트래픽. 이전에는 Workers VPC 세션이 Network Session Logs에 기록되지 않았어요.

Viewing Mesh and Workers VPC traffic in Gateway network logs

Gateway 네트워크 로그

대시보드에서 이 값을 보려면 Zero Trust > Insights & Logs > Logs > Network logs로 이동해 Columns를 선택하고 Traffic Source와 Traffic Destination을 켜요. 두 값은 로그 항목을 열 때 Network query details에도 나타나요.

Network Session Logs

Logpush를 통해 제공되는 zero_trust_network_sessions 데이터셋에는 다음 필드가 있어요:

Field	Description
`OnrampType`	How the session entered Cloudflare One. Values: `CF1_CLIENT`, `MESH`, `WORKERS_VPC`, `MAGIC`, `OTHER`.
`Offramp`	Where the session was routed. Sessions routed to a Mesh node report `MESH`.
`SourceName`	Name of the Worker that started the session. Only populated for Workers VPC sessions.
`SourceID`	Stable identifier of the Worker that started the session. Only populated for Workers VPC sessions.
`DestinationReplicaID`	The replica that served the session, such as a specific replica of a Mesh node or a `cloudflared` replica of a Cloudflare Tunnel.

예를 들어 OnrampType = 'WORKERS_VPC' AND Offramp = 'MESH'는 Worker가 Mesh 노드 뒤의 서비스에 도달한 모든 세션을 반환하고, SourceName은 어떤 Worker였는지 알려줘요.

Worker 재배포하기

SourceName과 SourceID는 2026년 9월 29일 이후 배포된 Worker에만 채워져요. 기존 Worker에 포함하려면 재배포해요 — 예를 들어 npx wrangler deploy 명령으로요. 코드 변경은 필요 없어요.

어떤 터널과 레플리카가 세션을 받았는지 확인하기

DestinationReplicaID로 특정 세션에 대해 어느 Cloudflare Tunnel과 어느 cloudflared 레플리카가 트래픽을 받았는지 확인할 수 있어요. 고가용성을 위해 여러 레플리카를 실행할 때 기존 DestinationTunnelID 필드와 결합해 세션을 정확한 터널 레플리카 — 또는 Mesh 노드 레플리카 — 까지 추적할 수 있어요. 레플리카 ID는 대시보드에 표시된 Connector ID와 일치하므로 cloudflared tail --connector-id로 해당 레플리카의 로그를 스트리밍할 수 있어요.

이 변경 전에 기록된 세션은 백필(backfill)되지 않아요. 사용 가능한 모든 필드는 Zero Trust Network Session Logs를 참고해요.

2026-09-18

cloudflared가 2027년에 32비트 Windows 및 Intel 기반 macOS 빌드를 지원 중단할 예정

2027년부터 Cloudflare는 cloudflared의 32비트 Windows 및 Intel 기반 macOS 빌드를 지원 중단할 예정이에요. 지원 중단이 적용되면 Cloudflare는 두 아키텍처에 대해 새 cloudflared 릴리스를 더 이상 게시하지 않아요.

32비트 시스템을 지원하는 마지막 Windows 릴리스인 Windows 10은 2025년 10월에 지원이 종료됐어요. Apple도 Intel 기반 Mac 컴퓨터를 지원 중단했어요. 2025년 9월에 출시된 macOS 26 Tahoe는 Intel 기반 Mac을 지원하는 마지막 macOS 릴리스였어요. 2026년 9월에 출시된 macOS 27은 더 이상 지원하지 않아요.

현재 지원되는 아키텍처에 개발을 집중하면 cloudflared가 운영 체제 지원과 맞춰지고 지원 플랫폼에서 계속 업데이트를 받을 수 있어요. 사용 가능한 다운로드와 지원 플랫폼은 Cloudflare Tunnel 다운로드 문서를 참고해요.

2026-09-02

여러 Cloudflare Tunnel 및 Cloudflare Mesh 경로를 한 번에 만들기

이제 Routes 페이지에서 한 번에 하나씩 경로를 제출하는 대신 단일 작업으로 여러 Cloudflare Tunnel 및 Cloudflare Mesh 경로를 만들 수 있어요.

Creating multiple Cloudflare Tunnel and Cloudflare Mesh routes at once from the Routes page

경로를 만들 때 이제 다음이 가능해요:

여러 대상을 한 번에 추가 — 쉼표로 구분된 CIDR 범위나 호스트 이름 목록을 입력해 같은 유형과 커넥터의 여러 경로를 함께 만들어요.
여러 경로를 큐에 쌓기 — Add another를 선택해 다른 유형이나 커넥터를 포함한 추가 경로를 준비한 뒤 한 번에 모두 만들어요.
실패한 것만 재시도 — 배치에서 일부 경로가 실패하면(예: 잘못된 CIDR) 성공적으로 만들어진 경로는 자동으로 양식에서 제거되므로 실패한 것만 고쳐 다시 제출하면 돼요.

동일한 Routes UI는 이미 Cloudflare WAN 정적 경로의 대량 생성을 지원하므로 여러 WAN 대상을 추가하거나 여러 WAN 경로를 큐에 쌓아 함께 만들 수도 있어요.

Routes로 이동 ↗

설정 단계는 경로 추가를 참고해요.

2026-08-18

대시보드에서 Cloudflare Tunnel의 오리진 애플리케이션 설정 구성하기

이제 Cloudflare Tunnel의 게시된 애플리케이션 경로를 추가하거나 편집할 때 Cloudflare 대시보드에서 오리진 애플리케이션 설정을 직접 구성할 수 있어요. 이 설정은 cloudflared가 오리진 서버에 연결하는 방식을 제어하며, 이전에는 Cloudflare One 대시보드나 로컬 구성 파일에서만 사용할 수 있었어요.

Configure origin application settings in the Cloudflare dashboard

게시된 애플리케이션을 편집할 때 Additional application settings를 펼쳐 세 가지 범주로 구성된 매개변수를 설정할 수 있어요:

HTTP — 사용자 지정 HTTP Host 헤더를 설정하거나 청크 인코딩을 비활성화해요.
TLS — 오리진 서버 이름, CA 풀, TLS 타임아웃을 구성하고, TLS 검증을 비활성화하고, SNI를 호스트에 일치시키거나 오리진으로의 HTTP/2를 활성화해요.
Connection — 연결 타임아웃, keep-alive 타임아웃, keep-alive 연결, TCP keep-alive 간격, 프록시 유형을 조정하거나 Happy Eyeballs를 비활성화해요.

Tunnels로 이동 ↗

전체 오리진 매개변수 목록은 Origin parameters를 참고해요.

2026-08-11

호스트 이름 라우팅이 일반 공급(GA)되며, 초기 확인 IP용 새 공용 IP 범위 제공

호스트 이름 라우팅 ↗︎이 이제 일반 공급(GA)됐어요. 정적 IP 목록과 경로를 관리하는 대신 여러 Cloudflare One 커넥터에 걸쳐 호스트 이름으로 트래픽을 라우팅할 수 있어요:

Cloudflare Tunnel: 프라이빗 호스트 이름(예: wiki.internal.local)을 터널 뒤의 프라이빗 애플리케이션으로 라우팅하거나, 공개 호스트 이름(예: bank.example.com)을 특정 터널을 통해 이그레스하고 전용 출구 노드에 트래픽을 앵커링해요.
Cloudflare Mesh: 프라이빗 또는 공개 호스트 이름의 트래픽을 Mesh 노드로 끌어들여요.

GA와 함께 초기 확인 IP(토큰 IP라고도 함)에 사용되는 기본 IPv4 범위가 Carrier-Grade NAT(CGNAT) 범위에서 Cloudflare 소유의 공용 범위로 변경돼요:

IPv4: 172.64.128.0/20
IPv6: 2606:4700:0cf1:4000::/64

이것이 기본 범위예요. 기존 네트워크와 충돌한다면 IPv4용 사용자 지정 초기 확인 IP 범위를 구성할 수 있어요.

변경 이유: Chrome 142 ↗︎부터 Local Network Access(LNA) 제한이 CGNAT 주소(100.64.0.0/10)에 대한 백그라운드 요청을 차단하는데, 여기에는 이전 초기 확인 IP 기본값(100.80.0.0/16)이 포함됐어요. LNA는 Chromium 엔진 수준에서 구현되므로 Google Chrome뿐 아니라 모든 Chromium 기반 브라우저(예: Microsoft Edge, Brave, Opera)에 영향을 줘요. 이는 이 브라우저 사용자의 호스트 이름 기반 Gateway 기능을 조용히 깨뜨릴 수 있으며 Chrome Enterprise 정책 우회가 필요했어요. 새 기본 범위는 공용 Cloudflare 주소 공간이므로 이 제한의 영향을 받지 않아요.

영향을 받는 것: 초기 확인 IP는 DNS 쿼리를 그 뒤를 따르는 네트워크 연결과 연결하는 여러 기능에서 사용돼요:

Cloudflare Tunnel의 프라이빗 및 공개 호스트 이름 라우팅
Cloudflare Mesh의 호스트 이름 경로
비-HTTPS 포트의 Access 프라이빗 애플리케이션
이그레스 정책 호스트 선택기 (Domain, Host, Application, Content Categories)

계정의 현재 범위를 확인하거나 사용자 지정 범위를 구성하려면 Networking > IP addresses > Address space > Custom IPs에서 언제든 할 수 있고, Initial Resolved IP Subnet API를 사용할 수도 있어요.

Custom IPs로 이동 ↗

전체 지침은 초기 확인 IP 구성을 참고해요. IPv6 범위(2606:4700:0cf1:4000::/64)는 변하지 않으며 이 제한의 영향을 받지 않아요.

기본 IPv4 범위와 모든 Cloudflare One IPv6 범위는 Cloudflare One Client를 통해 자동으로 라우팅되며 별도의 Split Tunnel 구성이 필요하지 않아요. 자세한 내용은 자동 관리 범위를 참고해요.

계정이 여전히 레거시 CGNAT 기반 범위를 사용하는 동안 Chrome Enterprise 정책 우회(예: LocalNetworkAccessRestrictionsTemporaryOptOut)에 의존했다면 다음 단계는 Google Chrome restricts access to private hostnames를 참고해요.

2026-08-10

대시보드에서 Cloudflare Tunnel 실시간 로그 스트리밍

실시간 Tunnel 로그 스트리밍이 이제 Networking > Tunnels 아래 Cloudflare 대시보드에서 사용 가능해요. 이전에는 Cloudflare One 대시보드에서만 가능했던 것과 동일한 실시간 디버깅 기능으로, 고가용성 배포를 위한 다중 커넥터 집계 스트리밍을 포함해요.

Stream live logs from a tunnel in the Cloudflare dashboard

터널 상세 보기의 새 Live logs 탭에서 다음을 할 수 있어요:

단일 또는 여러 커넥터에서 로그 스트리밍 — 여러 cloudflared 레플리카가 있는 고가용성 배포에서 모든 커넥터의 로그가 호스트 이름별로 그룹화된 단일 스트림으로 병합되어 각 로그 항목이 어떤 호스트 머신에서 만들어졌는지 쉽게 식별할 수 있어요.
로그 수준, 이벤트 유형, HTTP 메서드로 필터링 — 어떤 로그 수준에서든 관심 있는 이벤트(HTTP, TCP, UDP 또는 cloudflared 내부)로만 스트림을 좁힐 수 있어요.

Tunnels로 이동 ↗

자세한 내용은 Tunnel observability와 Tunnel log streams를 참고해요.

2026-07-09

Zero Trust Networks 경로 엔드포인트와 Cloudflare Tunnel connections 필드가 2026년 10월 5일에 제거됩니다

2026년 10월 5일에 Zero Trust Networks API와 Cloudflare Tunnel API 전반에 두 가지 변경이 적용돼요: CIDR로 인코딩된 경로 엔드포인트가 제거되고, 터널 목록 및 조회 응답에 더 이상 connections 필드가 포함되지 않아요. API, cloudflared, Terraform 또는 다른 통합을 통해 프라이빗 네트워크 경로를 관리하거나 터널 연결 세부 정보를 읽는다면 다음 섹션의 변경 사항을 검토하고 제거 날짜 전에 마이그레이션해요.

경로 엔드포인트(Route endpoints)

CIDR로 인코딩된 경로 엔드포인트는 이미 존재하는 표준의 route_id 기반 엔드포인트를 위해 지원 중단돼요. 두 엔드포인트 세트 모두 Cloudflare Tunnel 또는 Cloudflare Mesh를 통해 프라이빗 네트워크를 라우팅해요 (API는 여전히 Mesh 노드를 warp_connector라고 부름) — 요청 형태만 변경돼요.

지원 중단 엔드포인트(2026년 10월 5일 제거):

터널 경로 만들기(CIDR 엔드포인트): POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
터널 경로 업데이트(CIDR 엔드포인트): PATCH /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
터널 경로 삭제(CIDR 엔드포인트): DELETE /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}

대체 엔드포인트:

터널 경로 만들기: POST /accounts/{account_id}/teamnet/routes
터널 경로 업데이트: PATCH /accounts/{account_id}/teamnet/routes/{route_id}
터널 경로 삭제: DELETE /accounts/{account_id}/teamnet/routes/{route_id}

무엇이 바뀌나요

	Deprecated (CIDR-encoded path)	Replacement
Route identifier	URL-encoded CIDR in the path (`/network/{ip_network_encoded}`)	`route_id` in the path (`network` moves to the request body on create)
Create	`POST .../teamnet/routes/network/{ip_network_encoded}`	`POST .../teamnet/routes` with `network` and `tunnel_id` in the body
Update	`PATCH .../teamnet/routes/network/{ip_network_encoded}`	`PATCH .../teamnet/routes/{route_id}`
Delete	`DELETE .../teamnet/routes/network/{ip_network_encoded}`	`DELETE .../teamnet/routes/{route_id}`

필요한 조치(Action required)

List tunnel routes를 호출해 각 경로의 route_id를 가져오거나, 대체 엔드포인트로 경로를 처음 만들 때 응답에서 읽어요.
CIDR로 인코딩된 엔드포인트를 직접 호출하는 스크립트, 백엔드 서비스 또는 CI/CD 파이프라인을 업데이트해요.
cloudflared tunnel route ip add | delete 명령으로 경로를 관리한다면 cloudflared를 최신 버전 ↗︎으로 업그레이드해요.
Terraform으로 경로를 관리한다면 cloudflare_zero_trust_tunnel_cloudflared_route ↗︎ 리소스와 Cloudflare Terraform provider ↗︎의 최신 버전을 사용하고 있는지 확인해요.

# Before: create a route by URL-encoding the CIDR into the path
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/network/172.16.0.0%2F16 \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer ***" \
     -d '{"tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: create a route with the network in the request body
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer ***" \
     -d '{"network": "172.16.0.0/16", "tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: update or delete a route using its route_id
curl -X PATCH https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer ***" \
     -d '{"comment": "Updated comment for this route."}'

curl -X DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H "Authorization: Bearer ***"

Cloudflare Tunnel 및 Cloudflare Mesh 연결

같은 날부터 Cloudflare Tunnel과 Cloudflare Mesh 노드(cfd_tunnel 및 warp_connector API 리소스)의 목록 및 조회 응답에서 connections 배열이 제거돼요. 터널 또는 노드 객체에서 필드를 읽는 대신 전용 connections 엔드포인트를 쿼리해요.

영향을 받는 항목:

GET /accounts/{account_id}/cfd_tunnel — result의 각 항목에서 connections 제거
GET /accounts/{account_id}/cfd_tunnel/{tunnel_id} — result에서 connections 제거
GET /accounts/{account_id}/warp_connector — result의 각 항목에서 connections 제거
GET /accounts/{account_id}/warp_connector/{tunnel_id} — result에서 connections 제거

필요한 조치(Action required)

목록 또는 조회 응답에서 파싱하는 대신 터널별 connections 엔드포인트에서 연결 세부 정보를 가져와요. Cloudflare Tunnel의 경우 GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/connections를 호출해요. Cloudflare Mesh의 경우 GET /accounts/{account_id}/warp_connector/{tunnel_id}/connections를 호출해요.

# Before: read connections off the tunnel object
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \
     -H "Authorization: Bearer ***"

# After: query connections directly
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections \
     -H "Authorization: Bearer ***"

터널 목록 또는 조회 응답에서 connections를 파싱하는 모든 대시보드, 모니터링 스크립트 또는 자동화를 업데이트해요. cloudflared와 Cloudflare Terraform provider는 이 필드를 읽지 않으므로 이 부분에 대해서는 양쪽 모두 변경이 필요 없어요.

변경 이유

더 작고 빠른 응답. 연결이 많은 Cloudflare Tunnel과 Cloudflare Mesh 노드가 더 이상 매번 목록 및 조회 호출을 늘리지 않아요 — 연결 세부 정보는 필요할 때만 가져와요.
경로 식별의 단일 방식. route_id로 통합하면 CIDR 범위를 경로에 URL 인코딩할 필요가 없어지고 Zero Trust Networks API의 다른 모든 리소스가 주소 지정되는 방식과 일치해요.
API 전반의 일관성. 두 변경 모두 리소스 식별자와 중첩 상세 엔드포인트에 대한 Cloudflare의 표준 REST 규칙에 맞춰요.

자세한 내용은 Zero Trust Networks API, Cloudflare Tunnel API, Routes 문서를 참고해요.

2026-06-19

대시보드의 한 페이지에서 모든 경로 관리하기

Cloudflare 대시보드의 Routes 페이지가 이제 모든 커넥터의 경로 — Cloudflare Mesh 및 Cloudflare Tunnel 경로와 Cloudflare WAN 및 Magic Transit 정적 경로 — 를 제품별 별도 경로 보기 대신 단일 표로 보여줘요.

The unified Routes page in the Cloudflare dashboard, showing routes across connectors in a single table

통합 Routes 페이지에서 다음을 할 수 있어요:

대화형 지도로 네트워크 시각화 — 여러 커넥터가 같은 접두사를 제공하는 동일 비용 다중 경로(ECMP) 경로를 포함해 목적지가 커넥터로 흘러가는 방식을 보여줘요. 노드를 선택하면 그 뒤의 경로만 표로 필터링돼요.
모든 경로를 한 표에서 확인 — 목적지, 유형, 커넥터, 우선순위, 소스를 보고 필터링하거나 정렬해 필요한 것을 찾아요.
페이지를 벗어나지 않고 지원되는 유형의 경로 생성·편집·삭제 — Cloudflare WAN 또는 Magic Transit 정적 경로를 추가할 때 이제 IP를 입력하는 대신 커넥터 이름으로 다음 홉을 선택해요.
전용 탭에서 가상 네트워크 관리
경로 테스트 — 변경을 확정하기 전에 목적지가 어떤 커넥터와 다음 홉으로 확인되는지 확인해요.

찾으려면 대시보드 사이드바에서 Networking > Routes로 이동해요.

Routes로 이동 ↗

기존 경로, API, 구성은 변하지 않아요 — 이것은 모두 한 곳에 모으는 대시보드 경험이에요. 경로 추가와 가상 네트워크 관리 방법을 알아봐요.

2026-05-27

Cloudflare Tunnel이 이제 시작 시 연결성 사전 검사를 실행

cloudflared 버전 2026.5.2 ↗︎부터 Cloudflare Tunnel이 연결성 사전 검사 워크플로 전체를 바이너리 안에서 직접 자동화해요. 이전에는 고객이 환경을 검증하기 위해 dig와 netcat을 설치하고 그 명령을 직접 실행해야 했어요. 이제 cloudflared가 시작 시 기본으로 이를 처리하고, 무언가 차단되면 실행 가능한 해결 방법을 제시해요.

cloudflared connectivity pre-checks output

매번 cloudflared tunnel run(및 cloudflared tunnel diag)에서 바이너리는 이제 기본적으로 다음을 검사해요:

DNS 해석 — region1.v2.argotunnel.com과 region2.v2.argotunnel.com이 유효한 Cloudflare IP로 해석되는지.
전송 연결 — 포트 7844에서의 아웃바운드 UDP (QUIC)와 TCP (HTTP/2).
관리 API — 소프트웨어 업데이트를 위한 api.cloudflare.com으로의 아웃바운드 TCP/443.

결과는 세 가지 상태가 있는 스캔 가능한 CLI 표로 출력돼요:

✅ Pass — 검사가 성공했어요.
⚠️ Warn — 차단하지 않는 문제예요. 예를 들어 관리 API에 접근할 수 없어 자동 업데이트는 동작하지 않지만 터널은 여전히 올라와요.
❌ Fail — 차단하는 문제로, 구체적인 해결 힌트(예: Allow outbound UDP on port 7844)가 함께 표시돼요.

DNS를 해석할 수 없거나 포트 7844에서 UDP와 TCP 둘 다 실패하면 cloudflared는 불투명한 failed to dial 오류로 반복하는 대신 실패와 함께 일찍 종료해요.

사전 검사는 이제 매번 시작할 때 자동으로 실행되므로 하룻밤 사이의 방화벽 정책 변경 같은 회귀도 잡아내요 — 트러블슈팅 가이드를 다시 실행할 필요가 없어요.

새 동작을 얻으려면 cloudflared를 버전 2026.5.2 이상으로 업그레이드해요. 자세한 내용은 연결성 사전 검사 문서를 참고해요.

2026-05-21

Cloudflare Tunnel 및 Cloudflare Mesh에 대한 세분화된 권한

이제 Cloudflare 권한을 개별 Cloudflare Tunnel 인스턴스와 Cloudflare Mesh 노드로 범위를 좁힐 수 있어요. 관리자는 프라이빗 네트워킹에 대한 계정 전체 제어 권한을 부여하지 않고도 특정 Tunnel이나 Mesh 노드에 대한 접근을 위임할 수 있어요.

새로운 점

구성원 추가 또는 권한 정책 생성 시 리소스 선택기에 이제 Cloudflare Tunnel 인스턴스와 Cloudflare Mesh 노드가 범위 지정 가능한 리소스 유형으로 나열돼요. 다음을 할 수 있어요:

지원 운영자에게 단일 Cloudflare Tunnel 인스턴스에 대한 읽기 전용 역할을 부여해 로그 스트리밍과 진단을 하게 하되, 다른 Tunnel이나 파괴적 작업은 노출하지 않아요.
애플리케이션 팀에게 특정 Cloudflare Mesh 노드에 대한 쓰기 역할을 부여하되, 나머지 프라이빗 네트워크에는 접근을 주지 않아요.
단일 정책을 한 번에 여러 Tunnel 및 Mesh 노드로 범위를 지정해요.

동작 방식

세분화된 권한은 기존 계정 수준 역할과 병행하는 별도의 계층이며 이를 대체하지 않아요.

기존 계정 수준 역할은 계속 동작해요. Cloudflare Access 또는 Cloudflare Zero Trust가 있는 구성원은 계정의 모든 Tunnel과 Mesh 노드에 대한 쓰기 접근을 유지해요. 이는 기존 자동화와 토큰에 대한 이전 버전과의 호환성을 보장해요.
세분화된 권한은 추가적(additive)이에요. 특정 Tunnel 또는 Mesh 노드에 대한 모든 API 요청에 대해 사용자가 계정 수준 역할 또는 해당 리소스에 대한 세분화된 권한 중 하나라도 있으면 접근이 허용돼요.
리소스 열거는 인증 인식(authorization-aware)이에요. 목록 엔드포인트(GET /accounts/{id}/cfd_tunnel, GET /accounts/{id}/warp_connector)는 사용자가 최소한 읽기 접근을 가진 리소스만 반환해요.

시작하기

Cloudflare Tunnel용 세분화된 권한 구성.
Cloudflare One에서 Cloudflare Tunnel 및 Cloudflare Mesh용 세분화된 권한 구성.
Cloudflare 역할 참조의 리소스 범위 역할 검토.

2026-03-20

Cloudflare Tunnel의 여러 레플리카에서 동시에 로그 스트리밍

Cloudflare One 대시보드에서 특정 Cloudflare Tunnel의 개요 페이지가 이제 해당 터널의 모든 레플리카를 표시하고 여러 레플리카에서 동시에 로그를 스트리밍하는 것을 지원해요.

View replicas and stream logs from multiple connectors

이전에는 한 번에 한 레플리카에서만 로그를 스트리밍할 수 있었어요. 이 업데이트로:

터널 개요의 레플리카 — 선택한 터널의 모든 활성 레플리카가 이제 해당 터널 개요 페이지의 Connectors 아래에 나타나요. 레플리카를 선택해 로그를 스트리밍할 수 있어요.
다중 커넥터 로그 스트리밍 — 여러 레플리카에서 동시에 로그를 스트리밍해 디버깅이나 사고 대응 중 인프라 전반의 이벤트를 더 쉽게 연관시킬 수 있어요. 시도하려면 Cloudflare One ↗︎에 로그인하고 Networks > Connectors > Cloudflare Tunnels로 이동해요. 모니터링할 터널 옆의 View logs를 선택해요.

자세한 내용은 Tunnel log streams와 Deploy replicas를 참고해요.

2026-03-19

Wrangler로 Cloudflare Tunnels 관리

이제 Cloudflare Developer Platform의 CLI인 Wrangler에서 직접 Cloudflare Tunnels를 관리할 수 있어요. 새 wrangler tunnel 명령으로 터미널을 떠나지 않고 터널을 만들고, 실행하고, 관리할 수 있어요.

Wrangler tunnel commands demo

사용 가능한 명령:

wrangler tunnel create — 새 원격 관리 터널 만들기.
wrangler tunnel list — 계정의 모든 터널 나열.
wrangler tunnel info — 특정 터널에 대한 세부 정보 표시.
wrangler tunnel delete — 터널 삭제.
wrangler tunnel run — cloudflared 데몬으로 터널 실행.
wrangler tunnel quick-start — Quick Tunnels로 계정 없이 무료 임시 터널 시작.

Wrangler는 cloudflared 바이너리의 다운로드와 관리를 자동으로 처리해요. 처음 사용 시 로컬 캐시 디렉터리에 cloudflared를 다운로드하라는 메시지가 표시돼요.

이 명령들은 현재 실험적이며 예고 없이 변경될 수 있어요.

시작하려면 Wrangler tunnel commands 문서를 참고해요.

2026-02-20

메인 Cloudflare 대시보드에서 Cloudflare Tunnel 직접 관리

Cloudflare Tunnel이 이제 메인 Cloudflare 대시보드의 Networking > Tunnels ↗︎에서 사용 가능해, 오리진 서버 보안에 Tunnel을 사용하는 개발자에게 최고 수준의 Tunnel 관리를 제공해요.

Manage Tunnels in the Core Dashboard

이 새 경험은 공개 애플리케이션용 Tunnel을 관리하는 데 필요한 모든 것을 제공해요:

완전한 Tunnel 수명주기 관리: 한 곳에서 모든 Tunnel을 생성, 구성, 삭제, 모니터링해요.
네이티브 통합: DNS 레코드와 Workers VPC를 구성할 때 이름으로 Tunnel을 확인해요 — UUID를 복사해 붙여 넣을 필요가 없어요.
실시간 가시성: 대시보드에서 직접 레플리카와 Tunnel 상태를 모니터링해요.
라우팅 맵: 공개 애플리케이션, 프라이빗 호스트 이름, 프라이빗 CIDR, Workers VPC 서비스를 포함한 Tunnel의 모든 인그레스 경로를 단일 대화형 인터페이스에서 관리해요.

사용 사례에 맞는 대시보드 선택

Core Dashboard: Networking > Tunnels ↗︎로 이동해 다음에 Tunnel을 관리해요:

CDN, WAF, Load Balancing, DDoS 보호로 오리진 서버와 공개 애플리케이션 보안
Workers VPC를 통해 Workers를 프라이빗 서비스에 연결

Cloudflare One Dashboard: Zero Trust > Networks > Connectors ↗︎로 이동해 다음에 Tunnel을 관리해요:

Zero Trust 접근 정책으로 공개 애플리케이션 보안
사용자를 프라이빗 애플리케이션에 연결
프라이빗 Mesh 네트워크 구축

두 대시보드 모두 완전한 Tunnel 관리 기능을 제공해요 — 기본 워크플로에 따라 선택해요.

시작하기

Tunnel이 처음이라면 Cloudflare Tunnel 시작하기를 배우거나 SSH 서버 보안 또는 Kubernetes에서 Tunnel 실행 같은 고급 사용 사례를 탐색해요.

2026-01-15

간단한 ping으로 WARP Connector 연결 검증

[s]소프트웨어 정의 프라이빗 네트워크의 일부로 WARP Connector를 배포할 때 연결을 더 쉽게 검증할 수 있게 했어요.

이제 설치 직후 WARP Connector 호스트를 LAN IP 주소로 직접 ping할 수 있어요. 이는 다운스트림 서비스에 대한 접근을 테스트하기 전에 네트워크 내에서 Connector가 온라인 상태이고 도달 가능한지 확인하는 빠르고 익숙한 방법이에요.

버전 2025.10.186.0부터 WARP Connector는 자신의 LAN IP로 주소가 지정된 트래픽에 응답해 Connector 도달 가능성을 즉시 확인할 수 있게 해요.

WARP Connector 배포와 Cloudflare One으로 프라이빗 네트워크 연결 구축에 대해 자세히 알아봐요.

2025-11-11

cloudflared proxy-dns 명령이 2026년 2월 2일부터 제거됩니다

2026년 2월 2일부터 cloudflared proxy-dns 명령이 모든 새 cloudflared 릴리스에서 제거돼요.

이 변경은 보안을 강화하고 기본 DNS 라이브러리의 잠재적 취약점을 해결하기 위한 것이에요. 이 취약점은 proxy-dns 명령에만 한정되며 핵심 Cloudflare Tunnel 서비스 같은 다른 cloudflared 기능에는 영향을 주지 않아요.

클라이언트 측 DNS-over-HTTPS(DoH) 프록시를 실행하는 proxy-dns 명령은 수년간 공식 문서화되지 않은 기능이었어요. 이 기능은 적극적으로 개발되는 제품에서 완전하고 안전하게 지원돼요.

이 날짜 이전에 릴리스된 cloudflared 버전은 영향을 받지 않으며 계속 작동해요. 다만 어떤 cloudflared 릴리스에 대한 공식 지원 정책은 릴리스 날짜로부터 1년이라는 점에 유의해요.

마이그레이션 경로

이 비공식 기능 사용자는 2026년 2월 2일 이전에 다음 공식 지원 솔루션 중 하나로 마이그레이션해 안전한 DNS-over-HTTPS 혜택을 계속 누리길 강력히 권장해요.

엔드 유저 기기

사용자 기기에서 DNS-over-HTTPS를 활성화하는 권장 방법은 Cloudflare WARP client예요. WARP 클라이언트는 기기의 모든 DNS 트래픽을 자동으로 보호하고 프록시하며, 조직의 Zero Trust 정책 및 포스처 검사와 통합해요.

서버, 라우터, IoT 기기

매 기기에 클라이언트를 설치할 수 없는 시나리오(서버, 라우터, IoT 기기 등)에서는 WARP Connector 사용을 권장해요.

머신에서 cloudflared proxy-dns를 실행하는 대신 프라이빗 네트워크의 단일 Linux 호스트에 WARP Connector를 설치할 수 있어요. 이 커넥터는 게이트웨이 역할을 하며 전체 서브넷의 모든 DNS 및 네트워크 트래픽을 필터링 및 로깅을 위해 Cloudflare로 안전하게 라우팅해요.

2025-09-18

IP가 아닌 호스트 이름으로 프라이빗 또는 공개 앱을 연결하고 보호 — Cloudflare Tunnel 호스트 이름 라우팅

이제 Cloudflare Tunnel로 프라이빗 트래픽을 호스트 이름이나 도메인 기준으로 라우팅할 수 있어 IP 기반 라우팅의 한계를 넘어서요. 이 새 기능은 모든 Cloudflare One 고객에게 무료예요.

이전에는 Tunnel 경로를 IP 주소나 CIDR 범위로만 정의할 수 있었어요. 이는 동적이거나 임시적인 IP 주소를 가진 현대적 애플리케이션에 과제를 만들어 관리자가 복잡하고 깨지기 쉬운 IP 목록을 유지하도록 했어요.

Hostname-based routing in Cloudflare Tunnel

새로운 점:

호스트 이름 및 도메인 라우팅: 개별 호스트 이름(예: payroll.acme.local) 또는 전체 도메인(예: *.acme.local)에 대한 경로를 만들고 트래픽을 특정 Tunnel로 보내요.
간소화된 Zero Trust 정책: 안정적인 호스트 이름으로 Cloudflare Access와 Gateway에 탄력적인 정책을 구축해 프라이빗 애플리케이션에 리소스별 인가를 훨씬 쉽게 적용할 수 있어요.
정밀한 이그레스(Egress) 제어: 공개 호스트 이름(예: bank.example.com)의 트래픽을 특정 Tunnel을 통해 라우팅해 전용 소스 IP를 강제하고, 서드파티 서비스의 IP 허용 목록 문제를 해결해요.
더 이상 IP 목록 불필요: 이 기능은 Tunnel 연결을 위해 동적 IP 목록을 유지하는 우회 방법을 쓸모없게 만들어요.

Zero Trust 대시보드의 Tunnels 섹션에서 첫 프라이빗 호스트 이름 또는 공개 호스트 이름 경로로 시작해요.

블로그 포스트 ↗︎에서 자세히 알아봐요.

2025-09-02

Cloudflare Tunnel 및 Networks API가 2025년 12월 1일부터 기본적으로 삭제된 리소스를 더 이상 반환하지 않습니다

2025년 12월 1일부터 Cloudflare Tunnel API와 Zero Trust Networks API의 목록 엔드포인트가 기본적으로 삭제된 터널, 경로, 서브넷, 가상 네트워크를 더 이상 반환하지 않아요. 이 변경은 달리 지정하지 않는 한 활성 리소스만 반환하도록 API 동작을 더 직관적으로 만들어요.

이미 명시적으로 is_deleted=false를 설정했거나 활성 리소스만 나열하면 필요한 조치가 없어요.

이 변경은 다음 API 엔드포인트에 영향을 줘요:

모든 터널 나열: GET /accounts/{account_id}/tunnels
Cloudflare Tunnels 나열: GET /accounts/{account_id}/cfd_tunnel
WARP Connector 터널 나열: GET /accounts/{account_id}/warp_connector
터널 경로 나열: GET /accounts/{account_id}/teamnet/routes
서브넷 나열: GET /accounts/{account_id}/zerotrust/subnets
가상 네트워크 나열: GET /accounts/{account_id}/teamnet/virtual_networks

무엇이 바뀌나요?

is_deleted 쿼리 매개변수의 기본 동작이 업데이트될 거예요.

Scenario	Previous behavior (before December 1, 2025)	New behavior (from December 1, 2025)
`is_deleted` parameter is omitted	Returns active & deleted tunnels, routes, subnets and virtual networks	Returns only active tunnels, routes, subnets and virtual networks

필요한 조치(Action required)

삭제된(또는 모든) 리소스를 검색해야 한다면 2025년 12월 1일 전에 API 호출에 is_deleted 매개변수를 명시적으로 포함하도록 업데이트해요.

삭제된 리소스만 목록으로 얻으려면 이제 요청에 is_deleted=true 쿼리 매개변수를 명시적으로 추가해야 해요:

# Example: Get ONLY deleted Tunnels
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tunnels?is_deleted=true" \
     -H "Authorization: Bearer ***"

# Example: Get ONLY deleted Virtual Networks
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/virtual_networks?is_deleted=true" \
     -H "Authorization: Bearer ***"

이 변경 후 활성 및 삭제된 리소스를 모두 포함한 전체 목록을 검색하려면 두 번의 별도 API 호출이 필요해요: 하나는 활성 항목(매개변수를 생략하거나 is_deleted=false 사용), 다른 하나는 삭제된 항목(is_deleted=true)용이에요.

변경 이유

이 업데이트는 사용자 피드백을 기반으로 하며 다음을 목표로 해요:

더 직관적인 기본값 만들기: 목록 작업이 기본적으로 활성 리소스만 반환하는 일반적인 API 설계 원칙에 맞춰요.
예상치 못한 결과 줄이기: 예상치 못하게 반환된 삭제된 리소스에서 사용자가 실수로 작업하는 것을 방지해요.
성능 향상: 대부분의 사용자에게 기본 쿼리 결과가 더 작고 관련성이 높아져요.

자세한 내용은 Cloudflare Tunnel API와 Zero Trust Networks API 문서를 방문해요.

2025-07-15

Cloudflare Tunnel의 더 빠르고 안정적인 UDP 트래픽

Cloudflare Tunnel에서 실행되는 실시간 애플리케이션이 이제 더 빠르고 안정적이에요. cloudflared가 UDP 트래픽을 프록시하는 방식을 다른 트래픽과 격리하도록 완전히 재설계했어요. 프라이빗 DNS 같은 지연 민감 애플리케이션이 같은 Tunnel의 무거운 TCP 트래픽(예: 파일 전송)으로 더 이상 느려지지 않도록 보장해요.

이것은 Cloudflare Tunnel의 기초적인 개선으로 모든 고객에게 자동으로 제공돼요. 구성할 설정이 없어요 — 여러분의 UDP 트래픽은 이미 더 빠르고 안정적으로 흐르고 있어요.

새로운 점:

더 빠른 UDP 성능: 새 UDP 세션 설정의 지연 시간을 크게 줄여 프라이빗 DNS 같은 애플리케이션이 훨씬 더 응답성이 좋아졌어요.
혼합 트래픽에 대한 더 큰 안정성: UDP 패킷이 더 이상 무거운 TCP 트래픽의 영향을 받지 않아 실시간 서비스의 타임아웃과 연결 끊김을 방지해요.

Cloudflare Tunnel을 통해 TCP 또는 UDP 애플리케이션과 프라이빗 네트워크를 실행하는 방법을 자세히 알아봐요.

2024-12-19

진단 로그로 터널 트러블슈팅

최신 cloudflared 빌드 2024.12.2 ↗︎가 cloudflared 인스턴스를 트러블슈팅하는 데 필요한 모든 진단 로그를 수집하는 기능을 도입해요.

진단 보고서는 로컬 머신에서 실행 중인 단일 cloudflared 인스턴스의 데이터를 수집해 cloudflared-diag 파일로 출력해요.

자세한 내용은 진단 로그를 참고해요.

더 알아보기 (Learn more)

변경 로그에서 최신 기능과 지원 중단 예정 사항을 확인할 수 있어요. RSS를 구독하면 Cloudflare Tunnel의 새 소식을 곧바로 받아볼 수 있어요.