Cloudflare Tunnel 다운로드 속도 100배 높이기 (QUIC → HTTP/2)

12GB 파일 하나를 외부 서버로

집 컴퓨터에 있는 12GB짜리 녹화 MKV 파일 하나를 외부 서버에서 받아야 했다. 계정도, 포트포워딩도, DNS 설정도 필요 없는 Cloudflare quick tunnel(trycloudflare.com)이 이럴 때 제일 간편하다. 로컬에 HTTP 서버를 하나 띄우고 터널로 연결하면 임시 공개 URL이 발급된다.

cloudflared tunnel --url http://127.0.0.1:18923
# https://xxxx-xxxx-xxxx-xxxx.trycloudflare.com 형태의 URL이 발급된다

작업은 Claude Code에게 맡겼다. 한 가지 조건을 걸었는데, quick tunnel은 인증이 없어서 python -m http.server 같은 일반 파일 서버를 물리면 폴더가 통째로 인터넷에 노출된다. 그래서 딱 그 파일 하나만, 랜덤 토큰이 붙은 URL로만 내려주는 전용 서버를 만들어 물렸다. 어떻게 만들었는지는 글 끝에 정리했다.

이상하게 느린 다운로드

URL을 받아 다운로드를 걸었더니 속도가 이상했다. Cloudflare를 타면 원래 빠르지 않나? 12GB인데 이 속도면 하루 종일 걸릴 판이었다.

실제로 재보니 터널을 통과한 다운로드는 50MB를 받는 데 2분이 넘어도 끝나지 않았다. 400KB/s도 안 나온다는 뜻이다. 참고로 Cloudflare edge는 가까운 인천(ICN)에 잘 붙어 있었으니 거리 문제도 아니었다.

구간을 나눠서 측정

경로는 단순하다. 로컬 파일 서버 → cloudflared → Cloudflare edge → 받는 쪽. 어느 구간이 느린지는 나눠서 재보면 바로 드러난다.

# 로컬 서버 직접 (터널 안 탐)
curl -s -r 0-209715199 -o /dev/null -w "%{speed_download}\n" \
  "http://127.0.0.1:18923/<토큰>/file.mkv"

# 터널 경유 (공개 URL)
curl -s -r 0-52428799 -o /dev/null -w "%{speed_download}\n" \
  "https://xxxx.trycloudflare.com/<토큰>/file.mkv"

구간	실측
로컬 서버 직접 (200MB)	2.8GB/s
quick tunnel 경유 (50MB)	<400KB/s (2분+ 미완)

로컬 서버는 2.8GB/s가 나와서 전혀 문제가 없었다. 느린 곳은 터널 구간이었다.

원인은 cloudflared의 기본 프로토콜 QUIC

cloudflared 로그를 보면 답이 나와 있었다.

INF Settings: map[ha-connections:1 protocol:quic url:http://127.0.0.1:18923]
INF Initial protocol quic

cloudflared는 기본으로 QUIC(UDP 7844)을 써서 Cloudflare edge에 붙는다. 그런데 ISP나 중간 네트워크 장비가 UDP 트래픽을 제한하면 QUIC 처리량이 크게 떨어진다. cloudflared 커뮤니티에서는 꽤 알려진 속도 저하 패턴이다. 증상도 딱 이랬다. 연결은 되고 핑도 정상인데 처리량만 바닥을 긴다.

공유기 문제일까, ISP 문제일까

UDP가 문제라고 하면 자연스럽게 공유기 포트포워딩부터 의심하게 되는데, 결론부터 말하면 포트포워딩과는 관계가 없다. cloudflared는 집 컴퓨터에서 Cloudflare edge의 UDP 7844 포트로 나가는 연결을 맺는다. 포트는 고정이고, --protocol http2는 같은 7844 포트를 TCP로 쓴다. 연결이 항상 안에서 밖으로 나가는 아웃바운드라서 공유기에 열어줄 인바운드 포트 자체가 없다. 애초에 인바운드 포트를 하나도 안 여는 것이 Cloudflare Tunnel의 존재 이유다.

공유기나 방화벽이 UDP 7844를 아예 차단했다면 QUIC 연결 자체가 실패해서 cloudflared가 에러를 내거나 http2로 폴백했을 것이다. 그런데 로그상 QUIC 연결은 정상이었고 터널도 동작했다. 오직 처리량만 바닥이었다. 연결은 되는데 속도만 안 나오는 것은 차단이 아니라 속도 제한(트래픽 쉐이핑)의 증상이고, 이건 보통 공유기가 아니라 ISP 구간에서 일어난다. 국내 ISP들이 UDP 트래픽을 강하게 제한하는 것은 꽤 알려진 이야기다. 참고로 우리 집은 KT 인터넷을 쓰고 있다.

공유기 가능성까지 확실히 배제하고 싶다면 폰 핫스팟(LTE/5G)에 물려서 QUIC 터널 속도를 다시 재보면 된다. 핫스팟에서 빠르면 집 회선 쪽으로 좁혀진다. 다만 어느 쪽으로 결론이 나든 우리가 통제할 수 있는 해법은 --protocol http2 플래그 하나로 같다.

해결은 플래그 하나, --protocol http2

전송 프로토콜을 TCP 기반 HTTP/2로 바꿔 터널을 다시 열었다.

cloudflared tunnel --protocol http2 --url http://127.0.0.1:18923

프로토콜	터널 경유 50MB	속도
QUIC (기본값)	2분+ 미완	<400KB/s
HTTP/2	1.5초	35MB/s (~280Mbps)

같은 기계, 같은 파일, 같은 edge인데 약 100배 차이가 났다. 12GB 전송도 몇 분 안에 끝났다.

주의할 점이 두 가지 있다. quick tunnel은 재시작하면 URL이 새로 발급되므로 이미 URL을 공유했다면 다시 보내야 한다. named tunnel을 쓴다면 config.yml에 protocol: http2로 설정해두면 된다.

한 파일만 노출하는 공유 서버

앞에서 말한 단일 파일 서버는 Python 표준 라이브러리 http.server로 만든 100줄짜리 스크립트다. 설계는 단순하다.

서버를 띄울 때 공유할 파일 경로 하나와 랜덤 토큰(secrets.token_urlsafe)을 받는다.
요청 경로가 /<토큰>/파일명과 정확히 일치할 때만 파일을 내려주고, 나머지는 전부 404로 응답한다. 디렉토리 목록도, 다른 파일에 접근할 코드 경로도 애초에 없다.
GET/HEAD만 허용하고 나머지 메서드는 405로 막는다.
Range 요청을 지원해서 대용량 파일도 끊기면 이어받을 수 있고(curl -C -), aria2c -x 8 같은 병렬 다운로드도 된다.

URL에 든 토큰이 사실상 비밀번호 역할을 하므로, URL은 받을 사람에게만 전달하면 된다. 다 받고 나면 서버와 터널을 내리는 것으로 상황 종료.

마치며

“Cloudflare는 빠르다”는 말은 맞다. 하지만 cloudflared가 edge까지 가는 전송 프로토콜(QUIC/UDP)은 별개의 병목이 될 수 있다. CDN의 평판과 터널 데몬의 전송 경로는 다른 문제다. 진단 방법은 이번에도 같았다. 추측하지 말고 구간을 나눠서 측정하기. 로컬 직접과 터널 경유를 나눠 재는 데 1분이면 충분했고, 고치는 건 플래그 하나였다. cloudflared 터널이 이유 없이 느리면 --protocol http2부터 시도해보자.

환경: Omarchy(Arch Linux) 데스크탑(유선, KT 인터넷) · cloudflared 2026.5.2 · quick tunnel(trycloudflare.com), edge ICN · 12GB MKV, 로컬 Python 단일 파일 서버 · 측정일 2026-07-09

Thu, 09 Jul 2026 22:40:00 +0900