
이 글은 「Cloudflare 완전 정복」 시리즈 5/16회입니다. 지난 4회까지 DNS·CDN·SSL·Pages로 Cloudflare 무료 플랜의 기초를 완성했다면, 오늘부터는 본격적인 홈랩·자가호스팅 영역으로 들어갑니다.
포트포워딩, 왜 더 이상 쓰면 안 되는가
집에 Synology NAS를 두고 외부에서 접속하고 싶다면, 대부분의 가이드는 이렇게 안내합니다. “공유기에서 포트포워딩을 설정하세요.” 5443 포트를 열고, DDNS를 잡고, 방화벽 규칙을 추가하고… 작동은 합니다. 하지만 2026년 기준으로 이 방식은 권장하기 어렵습니다.
- 공인 IP 노출: 포트를 여는 순간, 전 세계 봇이 해당 IP:포트를 스캔합니다. Shodan 같은 검색 엔진에 NAS 관리 화면이 인덱싱되는 건 시간문제입니다.
- ISP 제약: 국내 가정용 인터넷 대부분은 CGNAT(Carrier-Grade NAT) 환경입니다. 공유기에서 포트를 열어도 ISP 단에서 막혀 있어 아예 작동하지 않는 경우가 흔합니다.
- 유동 IP: 가정용 회선의 IP는 수시로 바뀝니다. DDNS로 따라가더라도 전파 지연이 발생하고, 그 사이 접속이 끊깁니다.
- 보안 업데이트 부담: 열린 포트 하나는 곧 공격 표면 하나입니다. NAS 펌웨어, SSL 인증서, 방화벽 규칙을 모두 직접 관리해야 합니다.
Cloudflare Tunnel은 이 모든 문제를 한 번에 해결합니다. 포트를 열지 않고, 공인 IP를 노출하지 않으면서, 집 안의 서비스를 안전하게 인터넷에 공개할 수 있습니다.
클라우드플레어 터널이란 — 아웃바운드만 사용하는 역방향 연결

Cloudflare Tunnel의 핵심 원리는 단 한 문장으로 요약됩니다.
“집 서버가 Cloudflare 엣지로 먼저 연결한다. 외부 요청은 그 연결을 타고 들어온다.”
일반적인 포트포워딩은 인바운드 방식입니다. 외부에서 안으로 들어오는 트래픽을 허용하기 위해 방화벽에 구멍을 뚫어야 합니다. 반면 Cloudflare Tunnel은 아웃바운드 전용입니다.
- cloudflared라는 경량 데몬이 집 서버에서 실행됩니다.
- cloudflared는 Cloudflare의 전 세계 엣지 네트워크로 아웃바운드 QUIC/HTTP2 연결을 맺습니다.
- 외부 사용자가
nas.example.com에 접속하면, Cloudflare 엣지가 이미 열려 있는 터널 연결을 통해 요청을 집 서버로 전달합니다. - 집 서버의 인바운드 포트는 하나도 열리지 않습니다. 공유기·방화벽 설정을 건드릴 필요가 없습니다.
이 구조가 가져다주는 이점은 명확합니다.
- CGNAT 우회: 아웃바운드 연결이므로 ISP의 NAT 뒤에서도 문제없이 작동합니다.
- 공인 IP 비노출: DNS 조회 결과에 Cloudflare의 Anycast IP만 표시됩니다. 집 IP는 어디에도 드러나지 않습니다.
- 자동 TLS: 2회에서 설정한 Cloudflare의 무료 SSL/TLS가 그대로 적용됩니다. 별도의 인증서 관리가 불필요합니다.
- DDoS 방어: 모든 트래픽이 Cloudflare 엣지를 경유하므로, 1회에서 소개한 DDoS 완화 기능이 자동으로 작동합니다.
사전 준비 — 5분이면 충분합니다
Cloudflare Tunnel을 설정하기 전에 다음을 확인하세요.
- Cloudflare 계정: 무료 플랜이면 충분합니다.
- Cloudflare에 등록된 도메인: 2회에서 네임서버를 이전한 도메인이 있어야 합니다. 아직 없다면 2회를 먼저 참고하세요.
- 집 서버: Synology NAS, Mac Studio, 라즈베리파이, 일반 PC — 무엇이든 괜찮습니다. Docker를 지원하면 설치가 더 간편합니다.
- 외부 공개할 서비스: NAS 관리 화면(DSM), 웹 서버, Home Assistant, Jellyfin 등 이미 내부 네트워크에서 작동 중인 서비스.
방법 1 — Cloudflare 대시보드에서 터널 만들기 (GUI)
명령줄이 익숙하지 않다면 대시보드에서 시작하는 것이 가장 쉽습니다.
1단계: Zero Trust 대시보드 진입
one.dash.cloudflare.com에 로그인한 뒤, 왼쪽 메뉴에서 Networks → Tunnels로 이동합니다.
2단계: 터널 생성
Create a tunnel 버튼을 클릭합니다. 터널 타입은 Cloudflared를 선택합니다(Warp Connector는 다른 용도입니다). 터널 이름은 알아보기 쉽게 homelab이나 nas-tunnel 정도로 지정합니다.
3단계: 커넥터 설치
터널을 만들면 대시보드에 운영체제별 설치 명령어가 표시됩니다. 이 명령어에는 터널 인증 토큰이 포함되어 있어, 복사해서 서버에 붙여넣기만 하면 됩니다. Synology NAS라면 Docker 탭의 명령어를 사용합니다(아래 실습 섹션에서 자세히 다룹니다).
4단계: 퍼블릭 호스트네임 매핑
커넥터가 연결되면 Public Hostnames 탭에서 서비스를 매핑합니다.
- Subdomain:
nas(→ nas.example.com이 됩니다) - Domain: Cloudflare에 등록된 도메인 선택
- Service Type:
HTTPS - URL:
localhost:5001(Synology DSM의 기본 HTTPS 포트)
하단의 Additional application settings → TLS → No TLS Verify를 활성화합니다. DSM은 자체 서명 인증서를 사용하므로, cloudflared가 이를 검증하지 않도록 설정해야 합니다.
Save를 누르면 끝입니다. 이제 https://nas.example.com으로 외부에서 DSM에 접속할 수 있습니다.
방법 2 — CLI로 터널 만들기 (개발자 권장)
대시보드 GUI는 편리하지만, 터널 설정을 코드로 관리하고 싶다면 CLI가 낫습니다. 설정 파일을 Git에 넣어두면 서버를 교체하더라도 동일한 환경을 바로 복원할 수 있습니다.
cloudflared 설치
Mac Studio에서는 Homebrew로 설치합니다.
brew install cloudflared
Linux(Debian/Ubuntu 계열)에서는 공식 패키지를 사용합니다.
curl -L https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-archive-keyring.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-archive-keyring.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install -y cloudflared
인증 및 터널 생성
# Cloudflare 계정 인증 (브라우저가 열립니다)
cloudflared tunnel login
# 터널 생성
cloudflared tunnel create homelab
# 생성된 터널 ID 확인
cloudflared tunnel list
tunnel create 명령은 ~/.cloudflared/ 디렉토리에 터널 자격증명 JSON 파일을 생성합니다. 이 파일이 터널의 신원을 증명하므로 안전하게 보관해야 합니다.
설정 파일 작성
~/.cloudflared/config.yml 파일을 만들어 라우팅 규칙을 정의합니다.
# ~/.cloudflared/config.yml
tunnel: homelab
credentials-file: /home/user/.cloudflared/<TUNNEL-ID>.json
ingress:
# Synology DSM
- hostname: nas.example.com
service: https://localhost:5001
originRequest:
noTLSVerify: true
# Jellyfin 미디어 서버
- hostname: media.example.com
service: http://localhost:8096
# Home Assistant
- hostname: home.example.com
service: http://localhost:8123
# 매칭되지 않는 요청은 404
- service: http_status:404
ingress 규칙의 마지막 항목은 반드시 hostname 없이 catch-all로 끝나야 합니다. 이것을 빠뜨리면 cloudflared가 실행을 거부합니다.
DNS 레코드 등록 및 실행
# DNS CNAME 레코드 자동 등록
cloudflared tunnel route dns homelab nas.example.com
cloudflared tunnel route dns homelab media.example.com
cloudflared tunnel route dns homelab home.example.com
# 터널 실행
cloudflared tunnel run homelab
tunnel route dns 명령은 Cloudflare DNS에 <TUNNEL-ID>.cfargotunnel.com을 가리키는 CNAME 레코드를 자동으로 추가합니다. 2회에서 봤던 DNS 관리 화면에 새 레코드가 나타나는 것을 확인할 수 있습니다.
Synology NAS(DS+925) 실전 설치 — Docker 방식

Synology NAS에서 cloudflared를 가장 안정적으로 운영하는 방법은 Docker(Container Manager)입니다. SSH로 NAS에 접속한 뒤 다음 명령을 실행합니다.
Docker Compose 파일 작성
# /volume1/docker/cloudflared/docker-compose.yml
services:
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
restart: unless-stopped
command: tunnel run
environment:
- TUNNEL_TOKEN=<대시보드에서 복사한 터널 토큰>
network_mode: host
network_mode: host를 사용하는 이유가 있습니다. cloudflared가 NAS의 localhost에서 실행 중인 서비스(DSM, Plex, Synology Photos 등)에 직접 접근해야 하기 때문입니다. bridge 모드를 쓰면 localhost:5001이 컨테이너 자신을 가리키게 되어 연결에 실패합니다.
실행 및 확인
# SSH로 NAS 접속
ssh [email protected]
# docker-compose 디렉토리로 이동
cd /volume1/docker/cloudflared
# 컨테이너 실행
sudo docker compose up -d
# 로그 확인 — "Connection registered" 메시지가 나오면 성공
sudo docker compose logs -f cloudflared
정상 연결 시 아래와 비슷한 로그가 출력됩니다.
INF Connection established connIndex=0 connection=xxx location=ICN
INF Connection established connIndex=1 connection=xxx location=NRT
INF Connection established connIndex=2 connection=xxx location=ICN
INF Connection established connIndex=3 connection=xxx location=NRT
cloudflared는 기본적으로 4개의 연결을 Cloudflare 엣지에 맺습니다. ICN은 인천(서울), NRT는 나리타(도쿄) 엣지입니다. 국내에서 접속하면 대부분 ICN 엣지를 통해 라우팅되어 지연 시간이 최소화됩니다.
여러 서비스를 하나의 터널에 묶기
대시보드 방식(토큰 기반)이라면 Public Hostnames 탭에서 서브도메인을 추가하기만 하면 됩니다. 터널 하나로 여러 서비스를 동시에 공개할 수 있습니다.
nas.example.com→https://localhost:5001(DSM)photos.example.com→http://localhost:8180(Synology Photos)drive.example.com→https://localhost:10002(Synology Drive)media.example.com→http://localhost:8096(Jellyfin)
각 서브도메인마다 Cloudflare의 DNS, SSL, 캐시, 보안 기능이 독립적으로 적용됩니다.
Mac Studio 실전 설치 — Homebrew + LaunchAgent
Mac Studio를 개발 서버로 사용한다면, Homebrew로 설치한 cloudflared를 macOS 서비스로 등록합니다.
설치 및 서비스 등록
# cloudflared 설치
brew install cloudflared
# 대시보드에서 생성한 터널 토큰으로 서비스 등록
sudo cloudflared service install <TUNNEL-TOKEN>
# 서비스 상태 확인
sudo launchctl list | grep cloudflared
service install 명령은 /Library/LaunchDaemons/com.cloudflare.cloudflared.plist 파일을 생성하고, 시스템 부팅 시 자동으로 cloudflared를 시작하도록 등록합니다.
Mac Studio에서 로컬 개발 서버 외부 공개
Next.js, Flask, Express 등 로컬 개발 서버를 외부에 공개하고 싶을 때도 유용합니다. 대시보드에서 퍼블릭 호스트네임을 추가합니다.
dev.example.com→http://localhost:3000(Next.js)api.example.com→http://localhost:8000(FastAPI)
포트포워딩 없이 클라이언트나 동료에게 개발 중인 서비스를 공유할 수 있습니다. ngrok의 무료 대안이 됩니다.
Quick Tunnel — 설치 없이 임시 터널 열기
설정을 영구적으로 저장할 필요 없이, 잠깐 테스트하고 싶을 때는 Quick Tunnel이 편리합니다.
# 로컬 8080 포트를 임시 공개 (도메인은 자동 생성)
cloudflared tunnel --url http://localhost:8080
실행하면 https://random-words.trycloudflare.com 형태의 임시 URL이 발급됩니다. Cloudflare 계정이나 도메인이 없어도 작동합니다. 터미널을 닫으면 터널도 사라집니다.
웹훅 테스트, 모바일 기기에서의 로컬 개발 확인, 일시적인 파일 공유 등에 활용할 수 있습니다.
터널 상태 모니터링과 장애 대응
대시보드에서 상태 확인
Zero Trust 대시보드의 Networks → Tunnels에서 각 터널의 상태를 실시간으로 볼 수 있습니다.
- HEALTHY: 4개 연결 모두 정상.
- DEGRADED: 일부 연결이 끊겼지만 서비스는 가능.
- DOWN: 모든 연결이 끊김. cloudflared 프로세스를 확인해야 합니다.
- INACTIVE: 커넥터가 한 번도 연결되지 않음. 토큰이나 네트워크를 확인합니다.
자주 만나는 문제와 해결법
“ERR Unable to establish connection” — 아웃바운드 차단
회사 네트워크나 일부 공공 와이파이에서 QUIC(UDP 7844)이 차단된 경우 발생합니다. cloudflared는 QUIC 실패 시 HTTP/2로 자동 폴백하지만, 이마저도 차단되었다면 네트워크 관리자에게 문의해야 합니다.
# HTTP/2 폴백을 명시적으로 강제
cloudflared tunnel --protocol http2 run homelab
“502 Bad Gateway” — 로컬 서비스 미응답
터널 자체는 정상이지만, 매핑된 로컬 서비스가 꺼져 있거나 포트가 다를 때 나타납니다. curl http://localhost:PORT로 로컬에서 먼저 확인하세요.
“SSL certificate problem” — 자체 서명 인증서
Synology DSM, Portainer 등 자체 서명 인증서를 사용하는 서비스라면 No TLS Verify 옵션을 활성화해야 합니다. CLI 설정에서는 originRequest.noTLSVerify: true입니다.
NAS 재부팅 후 자동 시작 안 됨
Docker Compose에 restart: unless-stopped를 넣었는데도 안 되는 경우, Synology Container Manager에서 해당 프로젝트의 “자동 재시작” 설정을 별도로 확인합니다. DSM 7.2+에서는 Container Manager UI에서 프로젝트 단위로 자동 시작 여부를 제어합니다.
보안 강화 — Cloudflare Access와 함께 쓰기
Tunnel만으로도 포트포워딩보다 훨씬 안전하지만, 누구든 URL만 알면 접속할 수 있다는 점은 동일합니다. 관리 화면처럼 민감한 서비스에는 Cloudflare Access로 인증 레이어를 추가하는 것을 권장합니다.
Cloudflare Access의 자세한 설정은 다음 6회에서 다루겠지만, 터널과 함께 가장 기본적인 설정만 미리 소개합니다.
대시보드에서 액세스 정책 추가
Zero Trust 대시보드 → Access → Applications → Add an application에서 다음을 설정합니다.
- Application domain:
nas.example.com - Policy name:
Allow me - Action:
Allow - Include rule:
Emails — [email protected]
이렇게 하면 nas.example.com에 접속할 때 이메일 인증(OTP) 화면이 먼저 나타납니다. 등록한 이메일로 코드를 받아 입력해야만 DSM에 도달할 수 있습니다. 이 인증은 Cloudflare 엣지에서 처리되므로, 인증에 실패한 요청은 NAS에 도달조차 하지 않습니다.
성능 팁 — 더 빠른 터널을 위해
QUIC 프로토콜 우선
cloudflared는 기본적으로 QUIC을 사용합니다. QUIC은 UDP 기반이라 TCP 핸드셰이크 오버헤드가 없고, 연결 마이그레이션을 지원해 네트워크 전환 시에도 끊김이 줄어듭니다. 특별한 이유가 없다면 기본 설정(QUIC)을 유지하세요.
HTTP/2 Origin 연결
cloudflared와 로컬 서비스 사이의 연결도 HTTP/2를 사용하면 멀티플렉싱 효과를 얻습니다. 로컬 서비스가 HTTP/2를 지원한다면 설정에 추가합니다.
ingress:
- hostname: app.example.com
service: https://localhost:3000
originRequest:
http2Origin: true
noTLSVerify: true
캐시 활용
Cloudflare CDN 캐시가 터널 뒤의 콘텐츠에도 적용됩니다. 정적 파일이 많은 서비스라면 2회에서 설정한 캐시 규칙이 그대로 효과를 발휘합니다. NAS에서 제공하는 이미지나 동영상 썸네일을 캐시하면 NAS의 부하를 줄이고 응답 속도도 개선됩니다.
하나의 터널, 여러 머신 — 분산 홈랩 구성
터널 하나에 커넥터를 여러 대 연결할 수도 있지만, 일반적으로는 머신마다 별도의 터널을 만드는 것이 관리하기 쉽습니다.
# 터널 구성 예시
nas-tunnel → NAS (DSM, Photos, Drive)
mac-tunnel → Mac Studio (개발 서버, API)
pi-tunnel → Raspberry Pi (Home Assistant)
각 터널은 독립적으로 상태를 관리하며, 한 머신이 꺼져도 다른 터널에는 영향이 없습니다. 대시보드에서 터널별 트래픽과 상태를 한눈에 확인할 수 있습니다.

기존 포트포워딩에서 마이그레이션하기
이미 포트포워딩으로 운영 중인 서비스가 있다면, 다음 순서로 전환하세요.
- 터널을 설정하고 테스트: 새 서브도메인(예:
nas-new.example.com)으로 터널을 먼저 만들어 정상 작동을 확인합니다. - DNS 전환: 기존 도메인의 DNS 레코드를 터널의 CNAME으로 변경합니다.
- 포트포워딩 제거: DNS 전파(최대 24시간, Cloudflare Proxy 모드면 즉시)가 완료된 후 공유기의 포트포워딩 규칙을 삭제합니다.
- 방화벽 정리: 열어둔 인바운드 포트를 닫습니다.
이 순서를 지키면 서비스 중단 없이 전환할 수 있습니다.
Cloudflare Tunnel 비용 명세표

| 항목 | Free (무료) | Teams (50석 이하) | Enterprise |
|---|---|---|---|
| Cloudflare Tunnel 생성 | 무제한 | 무제한 | 무제한 |
| 퍼블릭 호스트네임 (서비스 매핑) | 무제한 | 무제한 | 무제한 |
| 트래픽 대역폭 | 무제한 | 무제한 | 무제한 |
| 커넥터 수 (cloudflared 인스턴스) | 무제한 | 무제한 | 무제한 |
| Cloudflare Access (인증) | 50명까지 무료 | 50명까지 무료 | 커스텀 |
| SSL/TLS 인증서 | 무료 (자동) | 무료 | 무료 |
| DDoS 방어 | 포함 | 포함 | 포함 |
| 월 비용 | $0 | $0 (50석 이하) | 별도 문의 |
Cloudflare Tunnel은 완전 무료입니다. 터널 수, 서비스 수, 트래픽 양에 제한이 없습니다. Cloudflare Access도 50명까지 무료이므로, 개인이나 소규모 팀의 홈랩 용도라면 비용이 전혀 발생하지 않습니다.
이것이 포트포워딩 대신 Cloudflare Tunnel을 선택해야 하는 가장 실질적인 이유이기도 합니다. 더 안전하면서 더 저렴(무료)합니다.
포트포워딩 vs Cloudflare Tunnel — 한눈에 비교
| 비교 항목 | 포트포워딩 | Cloudflare Tunnel |
|---|---|---|
| 인바운드 포트 오픈 | 필요 | 불필요 |
| CGNAT 환경 지원 | 불가 | 가능 |
| 공인 IP 노출 | 노출됨 | 비노출 |
| SSL 인증서 관리 | 수동 (Let’s Encrypt 등) | 자동 (Cloudflare) |
| DDoS 방어 | 없음 | 자동 포함 |
| 유동 IP 대응 | DDNS 필요 | 불필요 |
| 인증 레이어 | 직접 구현 | Cloudflare Access 연동 |
| 설정 난이도 | 중간 | 쉬움 |
| 비용 | 무료 | 무료 |
마무리 — 포트를 닫고, 터널을 여세요
Cloudflare Tunnel은 홈랩 운영의 게임 체인저입니다. 공유기 설정을 만질 필요도, 공인 IP를 노출할 필요도, DDNS를 설정할 필요도 없습니다. cloudflared 하나만 실행하면 Cloudflare의 전 세계 엣지 네트워크가 여러분의 집 서버 앞에 서게 됩니다.
오늘 설정을 마쳤다면, 다음 질문은 자연스럽게 떠오릅니다. “터널로 서비스를 공개했는데, 누가 접속하는지 어떻게 통제하지?”
다음 6회에서는 Cloudflare Zero Trust와 Access를 다룹니다. 구글 계정으로 로그인한 사람만 NAS에 접속하게 하거나, 특정 국가의 IP만 허용하거나, 재택근무 직원에게만 사내 서비스를 열어주는 방법까지 — 터널 위에 쌓는 인증·권한 레이어를 완전 정복합니다.
이미지는 Leonardo AI 로 생성되었습니다.
이미지는 Claude AI 로 생성되었습니다.
◀ 이전 4화 (다음 차수는 아직 게시되지 않았습니다)