포트포워딩을 버리고 Cloudflare Tunnel로 갈아탄 이유

포트포워딩을 버리고 Cloudflare Tunnel로 갈아탄 이유

홈서버가 다운된 후 복구 과정에서 포트포워딩이 가지는 문제점을 알게 되었고 대안을 찾았습니다. Cloudflare Tunnel로 전환하니 포트포워딩 불필요, 공인 IP 비노출, IP 변경 무관, 무료. 설치부터 systemd 등록까지 10분이면 끝납니다.

배경: 포트포워딩의 한계

홈서버에 블로그(Next.js)을 운영하고 있고 아래와 같은 구조로 블로그 서비스를 운영했습니다.

Cloudflare DNS (A 레코드: 공인 IP)
  → 공유기 포트포워딩 (80, 443)
    → Nginx Proxy Manager (리버스 프록시)
      → Docker 컨테이너들

잘 돌아가던 구조였는데, 서버가 다운되고 복구한 후 522 에러가 발생했습니다. 원인을 찾아보니 공유기 포트포워딩이 풀려 있었습니다.

이 사건을 계기로 포트포워딩 방식의 문제점이 눈에 들어왔습니다.

| 문제 | 설명 |

|---|---|

| 공인 IP 노출 | A 레코드에 집 IP가 그대로 박혀 있음 |

| IP 변경 시 장애 | ISP가 IP를 바꾸면 DDNS 없이는 접속 불가 |

| 포트포워딩 의존 | 공유기 재시작, 펌웨어 업데이트 시 설정이 날아갈 수 있음 |

| 방화벽 구멍 | 외부에서 직접 접근 가능한 포트가 열려 있음 |

Cloudflare Tunnel이란

Cloudflare Tunnel(구 Argo Tunnel)은 서버에서 Cloudflare로 아웃바운드 연결을 맺는 방식입니다.

Cloudflare Edge (HTTPS 종료)
  ← QUIC 터널 (아웃바운드)
    ← cloudflared (서버에서 실행)
      → Nginx Proxy Manager → Docker 컨테이너

핵심은 인바운드 포트를 열 필요가 없다는 점입니다. 서버가 Cloudflare에 먼저 연결하기 때문에 공유기 포트포워딩이 필요 없고, 공인 IP도 노출되지 않습니다.

포트포워딩 vs Cloudflare Tunnel

| 항목 | 포트포워딩 | Cloudflare Tunnel |

|---|---|---|

| 포트 개방 | 80, 443 필수 | 불필요 |

| 공인 IP 노출 | O (A 레코드) | X (CNAME) |

| IP 변경 대응 | DDNS 필요 | 자동 (아웃바운드) |

| 공유기 의존 | 높음 | 없음 |

| DDoS 방어 | 직접 노출 | Cloudflare 프록시 |

| 비용 | 무료 | 무료 |

| 레이턴시 | 직접 연결 | +약간 (Cloudflare 경유) |

설치 과정

1. cloudflared 설치

# Debian/Ubuntu
curl -L -o cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

2. Cloudflare 인증

cloudflared tunnel login

브라우저가 열리면 도메인을 선택하고 승인합니다. 인증서가 ~/.cloudflared/cert.pem에 저장됩니다.

3. 터널 생성

cloudflared tunnel create gats-homelab

터널 ID와 credential 파일이 생성됩니다.

4. config.yml 작성

# ~/.cloudflared/config.yml
tunnel: <터널-ID>
credentials-file: /home/<user>/.cloudflared/<터널-ID>.json

ingress:
  - hostname: blog.gatslee.com
    service: http://localhost:80
  - hostname: cs.handbook.gatslee.com
    service: http://localhost:80
  - service: http_status:404

기존 Nginx Proxy Manager(80번 포트)로 트래픽을 보내면 NPM이 호스트명 기반으로 라우팅합니다. 기존 NPM 설정을 그대로 활용할 수 있어서 마이그레이션이 간단합니다.

5. DNS 라우팅

# 기존 A 레코드 삭제 후 CNAME 등록
cloudflared tunnel route dns gats-homelab blog.gatslee.com
cloudflared tunnel route dns gats-homelab cs.handbook.gatslee.com

Cloudflare DNS에 <터널-ID>.cfargotunnel.com을 가리키는 CNAME이 자동 생성됩니다.

6. systemd 등록 (영구 실행)

sudo mkdir -p /etc/cloudflared
sudo cp ~/.cloudflared/config.yml /etc/cloudflared/
sudo cp ~/.cloudflared/<터널-ID>.json /etc/cloudflared/
sudo cloudflared service install
sudo systemctl enable --now cloudflared

전환 후 확인

# 서비스 상태
systemctl status cloudflared

# 외부 접속 테스트
curl -s -o /dev/null -w "%{http_code}" https://blog.gatslee.com
# 200

정리

| Before | After |

|---|---|

| A 레코드 (공인 IP 노출) | CNAME (터널 경유) |

| 공유기 포트포워딩 80, 443 | 포트 개방 없음 |

| IP 변경 시 수동 대응 필요 | 자동 (아웃바운드 연결) |

| DDNS 서비스 필요 | 불필요 |

서버가 다운되는 사고가 없었으면 아마 포트포워딩으로 계속 운영했을 겁니다. 문제가 터져야 더 나은 구조를 찾게 되는 건 좀 아이러니하지만, 결과적으로 인프라가 훨씬 견고해졌습니다. 홈서버를 운영하시고 있다면 Cloudflare Tunnel은 무조건 추천합니다.