Cloudflare Tunnel 설정 후 포트 80, 443 닫는 법

Cloudflare Tunnel의 역할과 열린 포트가 없다는 것의 진정한 의미

Cloudflare Tunnel은 cloudflared라는 작은 데몬을 VPS에 설치합니다. 이 데몬은 Cloudflare를 향해 외부로 연결을 생성하고 이를 유지합니다. 호스트네임에 대한 요청은 Cloudflare의 엣지 서버에 도달한 뒤, 이미 생성된 연결을 통해 서버로 전달되므로 외부에서 서버로 직접 연결을 시도할 필요가 없습니다.

대부분의 가이드에서 다루지 않는 중요한 단계가 있습니다. 터널을 설치한다고 해서 기존 연결이 자동으로 닫히지는 않습니다. 방화벽에서 80번과 443번 포트가 여전히 열려 있고 애플리케이션이 0.0.0.0에서 대기 중이라면, 기존 경로를 대체한 것이 아니라 두 번째 진입로를 추가한 셈이 됩니다. 오리진 IP는 여전히 접근 가능하며, 이를 찾아낸 공격자는 Cloudflare를 거치지 않고 서버로 직접 침입할 수 있습니다. 이러한 포트를 닫는 것은 수동으로 수행해야 하는 작업이며, 이 단계를 완료해야 비로소 앞선 모든 설정의 가치가 생깁니다.

cloudflared은 7844번 포트를 통해 region1.v2.argotunnel.com 및 region2.v2.argotunnel.com로 향하는 아웃바운드 연결이 필요합니다. 이 데몬은 QUIC 프로토콜을 위해 UDP를 사용하며, 연결이 실패할 경우 HTTP/2를 위한 TCP로 전환합니다. 송신(egress) 필터링이 적용된 네트워크 환경이라면 두 프로토콜을 모두 허용하거나, --protocol http2을 사용하여 TCP 경로를 강제하십시오.

시작하기 전에

• Cloudflare 계정에 등록되어 있고 Cloudflare 네임서버를 사용하는 도메인이 필요합니다. cloudflared tunnel route dns은 해당 존에 레코드를 작성하므로, 먼저 존이 존재해야 합니다.
• VPS에서 7844 포트를 통한 UDP 및 TCP 아웃바운드 접근이 허용되어야 합니다.
• 첫 테스트를 위해 python3 -m http.server 8080만 사용하더라도, 로컬에서 이미 대기 중인 애플리케이션이 있어야 합니다.
• 방화벽을 수정하기 전에 서버에 sudo이 설치되어 있어야 하며, 두 번째 SSH 세션을 열어두어야 합니다.

Install cloudflared on Ubuntu or Debian

Cloudflare attaches a .deb package to every cloudflared release, so the install is one download and one dpkg call.

curl -fsSL -o /tmp/cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i /tmp/cloudflared.deb
cloudflared --version

Run dpkg --print-architecture first if you are not certain what the box is. On 64-bit ARM the filename ends in arm64 rather than amd64 and nothing else changes. cloudflared --version printing a version string is the only confirmation you need before moving on.

A package installed this way sits outside apt's update path, so apt-get upgrade will never move it and its updates become your job. sudo cloudflared update fetches the newest release and replaces the binary in place; once the service exists, follow it with sudo systemctl restart cloudflared so the running process is the new binary. Put that on the same schedule as the rest of your patching, because a tunnel daemon is internet-facing software even though it opens no port.

로그인 및 명명된 터널 생성

cloudflared tunnel login

헤드리스 VPS에서는 브라우저가 열리지 않으므로, 출력된 URL을 복사하여 노트북의 브라우저에 붙여넣고 영역(zone)을 선택합니다. 완료되면 ~/.cloudflared/cert.pem가 생성됩니다.

cert.pem는 귀하의 계정 자격 증명입니다. 이 파일은 터널 생성, 해당 영역에 DNS 레코드 작성, 터널 삭제 권한을 부여합니다. 실행 중인 터널은 이 파일을 사용하지 않습니다. 이 파일 하나만으로도 누군가 귀하의 도메인에 새로운 호스트 이름을 게시할 수 있으므로 비밀번호처럼 취급하십시오.

cloudflared tunnel create homelab

성공적으로 실행되면 아래 두 줄이 출력되며, 여기에 포함된 UUID는 설정 파일에 붙여넣을 값입니다.

Tunnel credentials written to /home/you/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel homelab with id 6ff42ae2-765d-4adf-8112-31c55c1551ef

해당 JSON 파일은 터널의 식별자이며, 실행 중인 서비스에 필요한 유일한 자격 증명입니다. 이 파일을 가진 사람은 누구나 귀하의 터널로 등록하여 트래픽을 수신할 수 있습니다. 이 파일만 단독으로 교체할 방법은 없으며, 폐기하려면 cloudflared tunnel delete homelab을 수행하고 새 터널을 생성해야 합니다.

자격 증명 파일을 안전한 위치에 보관하십시오

서비스는 root 권한으로 실행됩니다. 따라서 백업 작업이나 공유 계정으로 접근할 수 있는 홈 디렉터리에 파일을 두지 말고, root 소유의 디렉터리에 보관하십시오.

sudo install -d -m 700 -o root -g root /etc/cloudflared
sudo install -m 600 -o root -g root \
  ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json \
  /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
rm ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
sudo ls -l /etc/cloudflared
cloudflared tunnel list

ls -l 명령은 JSON 파일에 대해 -rw------- root root을(를) 표시해야 합니다. cloudflared tunnel list은(는) cert.pem을(를) 읽으므로 정상적으로 작동하며, 터널 이름, UUID, 현재 유지 중인 연결 수를 출력해야 합니다.

Write config.yml with real ingress rules

Write the config at /etc/cloudflared/config.yml, not in your home directory. Here is why. cloudflared service install copies whatever config it finds to /etc/cloudflared/config.yml and then hard-codes --config /etc/cloudflared/config.yml into the systemd unit. If you author the file in ~/.cloudflared/config.yml, that copy is a one-time snapshot. Every later edit to the home copy changes nothing, the service keeps serving the old rules, and nothing warns you. Authoring the file in place removes the whole problem.

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
loglevel: info

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:8080
  - hostname: files.example.com
    service: http://127.0.0.1:8081
  - hostname: grafana.example.com
    path: ^/api/
    service: http://127.0.0.1:3000
  - service: http_status:404

Rules are read top to bottom and the first match wins. A rule with no hostname matches every hostname, which is why the catch-all has to sit last. Leave it out and the config is rejected with The last ingress rule must match all URLs (i.e. it should not have a hostname or path filter). http_status:404 is a built-in service that answers 404 and does nothing else. It earns its place: without it, a request for a hostname you never meant to publish falls through to whichever real rule happens to be last.

Use 127.0.0.1 in the service: URL rather than localhost. On Ubuntu, localhost resolves to ::1 first, and an app bound only to the IPv4 loopback refuses that connection. The log line is dial tcp [::1]:8080: connect: connection refused and the visitor sees a 502.

Plain http:// is correct here because the hop never leaves the machine. Use https:// only when the local app insists on TLS (transport layer security), and expect x509: certificate is valid for example.com, not localhost when its certificate does not match the name you dialled. Fix that with originServerName under originRequest, or accept the risk with noTLSVerify: true.

Check the rules before starting anything:

sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress validate
sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress rule https://app.example.com/login

ingress validate reports the config valid or names the rule that broke it. ingress rule takes one URL and prints the first rule matching it, which is the quickest way to learn that a path regex is not matching what you assumed.

터널을 가리키도록 DNS 설정

cloudflared tunnel route dns homelab app.example.com
cloudflared tunnel route dns homelab files.example.com
cloudflared tunnel route dns homelab grafana.example.com

각 호출은 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com를 가리키는 프록시된 CNAME 레코드를 작성합니다. 해당 대상은 Cloudflare 네트워크 내부에서만 해석되므로, 호스트 이름에 대한 공개 DNS 응답은 Cloudflare 주소가 되며 VPS IP는 절대 노출되지 않습니다. config.yml의 와일드카드 hostname를 사용하더라도 실제로 사용하는 모든 이름에 대해 일치하는 DNS 레코드가 필요합니다.

레코드가 이미 존재하는 경우, 명령은 다음과 같이 실패합니다.

Failed to add route: code: 1003, reason: Failed to create record app.example.com with err An A, AAAA, or CNAME record with that host already exists.

기존 레코드는 대부분 VPS의 공인 IP를 가리키는 이전 A 레코드이며, 이는 삭제해야 할 레코드입니다. Cloudflare 대시보드에서 해당 레코드를 삭제한 뒤 명령을 다시 실행하십시오. 레코드를 그대로 두면 DNS가 계속 오리진 IP를 게시하게 되어 터널이 아무것도 숨기지 못하게 됩니다.

재부팅 후에도 유지되도록 서비스로 설치하기

오류가 발생했을 때 저널 로그보다 터미널에서 직접 확인하는 것이 훨씬 쉽기 때문에, 먼저 포그라운드에서 한 번 실행합니다.

sudo cloudflared --config /etc/cloudflared/config.yml tunnel run homelab

정상적으로 시작되면 각 에지 로케이션마다 하나씩, 총 여러 줄의 Registered tunnel connection 로그가 출력되며 각각 고유한 connIndex을 가집니다. 브라우저에서 호스트 이름 중 하나를 불러와 인그레스 규칙이 의도한 대로 연결되는지 확인한 다음, Ctrl-C를 눌러 종료합니다.

sudo cloudflared --config /etc/cloudflared/config.yml service install
systemctl status cloudflared

이 명령은 /etc/systemd/system/cloudflared.service와 함께 cloudflared-update.service 및 cloudflared-update.timer을 작성하고, 사용자를 대신하여 systemctl enable cloudflared.service와 systemctl start cloudflared.service을 실행합니다. 여기서 중요한 부분은 enable인데, 재부팅 후 터널을 다시 활성화하는 역할을 하기 때문입니다. 유닛의 ExecStart는 cloudflared --no-autoupdate --config /etc/cloudflared/config.yml tunnel run으로 고정되어 있으므로, 해당 설정 경로는 변경할 수 없습니다.

이 단계에서 발생하는 세 가지 오류는 명확한 메시지를 출력합니다. possible conflicting configuration in /home/you/.cloudflared/config.yml and /etc/cloudflared/config.yml은 두 파일이 모두 존재하여 cloudflared가 임의로 판단하지 않겠다는 의미이므로, 필요 없는 파일을 삭제하십시오. configuration file ... must contain entries for the tunnel to run and its associated credentials (tunnel: TUNNEL-UUID, credentials-file: CREDENTIALS-FILE)은 설정에서 명명된 터널 키 대신 빠른 url: 약어를 사용 중이라는 의미이며, 이 약어는 서비스로 실행할 수 없습니다. cloudflared service is already installed은 이전 유닛이 남아 있다는 의미이므로, 먼저 sudo cloudflared service uninstall을 실행하십시오.

설정 다시 불러오기(reload) 기능은 없습니다. /etc/cloudflared/config.yml를 수정한 후에는 sudo systemctl restart cloudflared을 실행하십시오. 그런 다음 추측하지 말고 재부팅 후에도 정상 작동하는지 직접 증명하십시오.

sudo reboot
# once it is back
systemctl is-enabled cloudflared
systemctl is-active cloudflared
journalctl -u cloudflared -n 50 --no-pager
curl -sI https://app.example.com

is-enabled가 enabled를 출력하고 is-active이 active을 출력하는 것이 이 섹션의 핵심입니다. 경로가 존재하고 서비스가 실행 중이라면, 서버에서 cert.pem이 수행할 추가 작업은 없습니다. rm ~/.cloudflared/cert.pem. 나중에 호스트 이름을 추가하려면 cloudflared tunnel login을 다시 실행하기만 하면 됩니다.

80번과 443번 포트 닫기, 그렇지 않으면 터널은 추가 경로일 뿐입니다

두 가지 변경 사항이 모두 필요합니다. 하나만 수행하면 원본 서버에 여전히 외부에서 접근할 수 있습니다.

첫째, 애플리케이션을 루프백 주소에 바인딩하십시오. Nginx의 경우 listen 127.0.0.1:8080; 대신 listen 80;를 사용해야 하며, 이는 이 Nginx 리버스 프록시 설정 설명에서 다룬 내용과 같습니다. Docker Compose에서는 ports: - "127.0.0.1:8080:80"을 사용합니다. 일반적인 "8080:80" 형식은 모든 인터페이스에 포트를 게시하며, Docker는 ufw가 패킷을 확인하기 전에 자체 NAT(네트워크 주소 변환) 규칙을 작성하므로 ufw의 거부 규칙으로 이를 차단할 수 없습니다. 이 함정에 대해서는 Docker 게시 포트가 ufw를 무시하는 이유에 별도로 정리되어 있습니다.

sudo ss -lntp

이전한 모든 서비스는 이제 Local Address 열에 127.0.0.1:8080가 표시되어야 합니다. 0.0.0.0:8080 또는 *:8080으로 표시된 줄은 여전히 외부 세계의 연결을 수신하고 있다는 의미입니다.

둘째, 포트를 닫으십시오.

sudo ufw status numbered
sudo ufw delete allow 'Nginx Full'
sudo ufw status

80번과 443번 포트에 대한 허용 규칙을 단순히 거부 규칙으로 덮어쓰지 말고 삭제하십시오. ufw는 일치하는 첫 번째 규칙에서 처리를 멈추므로, 목록 상단에 남아 있는 이전 허용 규칙이 우선 적용되기 때문입니다. SSH 규칙은 유지하십시오. ufw 방화벽 기초 가이드에서 나머지 규칙 설정을 다룹니다. 대부분의 VPS 제공업체는 제어판에서 별도의 네트워크 방화벽을 운영하며, 이는 ufw와 별개이므로 해당 설정에서도 80번과 443번 포트를 닫아야 합니다.

이제 다른 곳에서 확인하십시오. 서버 내부에서 실행하는 curl http://127.0.0.1:8080은 외부 세계에서의 접근성을 증명하지 못합니다.

# run these from a different machine
nc -vz 203.0.113.10 443
curl -sI https://app.example.com

원시 IP에 대해 nc가 거부되거나 시간 초과가 발생하고, 호스트 이름을 통한 200은 성공하는 것이 우리가 원하는 결과입니다. 포트가 실제로 열려 있는지 확인하는 방법에서 더 많은 테스트 방법을 다룹니다.

터널은 전송 수단일 뿐 인증 수단이 아닙니다. 터널을 통해 게시하는 모든 서비스는 앞에 로그인 절차를 두지 않으면 누구나 접근할 수 있습니다. 엣지에서 Cloudflare Access를 사용하거나 서버 내부에서 애플리케이션 앞단에 OAuth2 프록시를 배치하십시오. SSH 또한 별도의 대응이 필요합니다. 터널은 SSH를 보호하지 않으므로 22번 포트는 열어두되, 본인의 소스 주소로만 접근을 제한하십시오.

Cloudflare Tunnel의 이점과 비용

얻을 수 있는 이점은 확실합니다. 오리진 IP가 공개되지 않고, 인바운드 포트를 개방할 필요가 없으며, 공인 IP가 없는 환경에서도 설정이 가능합니다. 공개 인증서는 Cloudflare가 관리하므로 서버에서 ACME(automatic certificate management environment) 클라이언트를 실행할 필요가 없으며, 대규모 트래픽 공격은 대역폭을 소모하기 전에 엣지에서 차단됩니다.

비용 또한 확실합니다. Cloudflare는 엣지에서 TLS를 종료합니다. 방문자의 요청은 그곳에서 복호화된 뒤 터널을 통해 다시 암호화되므로, Cloudflare는 트래픽 내용을 읽을 수 있습니다. 이것이 방화벽, 캐싱, Access 규칙을 가능하게 하는 원리이며, 프록시를 사용하는 동안에는 이를 끌 수 있는 설정이 없습니다. 평문 데이터가 제3자에게 노출되는 것이 허용되지 않는다면, 여기서 중단하고 다른 대안을 선택하십시오.

또한 Cloudflare는 연결성을 위한 필수 의존 요소가 됩니다. cloudflared이 연결되지 않으면 방문자는 애플리케이션 대신 Cloudflare의 Error 1033 페이지를 보게 되며, 사용자는 대체 경로로 활용할 수 있었던 직접 연결 방식을 스스로 제거한 셈이 됩니다.

일반적인 브라우저에서 공개 호스트네임으로 접근 가능한 프로토콜은 HTTP, HTTPS, WebSocket뿐입니다. 그 외의 TCP 프로토콜, SSH, RDP(remote desktop protocol) 또는 게임 서버는 클라이언트 측에도 소프트웨어가 필요합니다. cloudflared access tcp를 사용하여 로컬 포트를 포워딩하거나 WARP 클라이언트를 사용해야 합니다. 이러한 프로토콜을 위한 클라이언트 없는 접근 경로는 존재하지 않습니다.

요청 본문은 엣지에서 제한되며, 제한을 초과하는 업로드는 애플리케이션에 도달하기 전에 HTTP 413 오류로 거부됩니다. 2026년 8월 기준으로 이 제한은 무료 및 Pro 플랜에서 100 MB이며 유료 티어에서는 더 높습니다. 따라서 특정 수치를 기준으로 설계하기 전에 Cloudflare의 현재 제한 페이지를 확인하십시오. 또한 Cloudflare의 셀프 서비스 약관은 프록시를 주로 비디오나 기타 대용량 비-HTML 파일을 제공하는 용도로 사용하는 것을 제한하고 있으므로, 미디어 라이브러리를 무료 터널에 연결하기 전에 약관을 읽어보는 것이 좋습니다.

Cloudflare Tunnel, 리버스 SSH 터널, 또는 Tailscale Funnel

이 세 가지 방식은 모두 아웃바운드 전용이므로, 인바운드 포트가 열려 있지 않거나 공인 IP가 없는 서버에서도 작동합니다. 이들의 차이점은 평문 데이터에 대한 접근 권한을 누가 가지는지, 그리고 외부에서 어떤 호스트네임으로 접속하는지에 있습니다.

리버스 SSH 터널은 공인 IP를 가진 별도의 서버가 필요하며, 해당 서버가 관문 역할을 합니다. 인증서, 리버스 프록시, 방화벽을 직접 관리해야 하므로 제3자가 데이터를 복호화할 수 없습니다. 관리해야 할 요소가 많으며, 네트워크 단절 시 연결을 유지하려면 Restart=always을 포함한 systemd 유닛이나 autossh가 필요합니다. CGNAT 환경을 위한 리버스 SSH 터널 구축 가이드에서 관련 내용을 다룹니다.

Tailscale Funnel은 가장 유사한 대안입니다. 동일하게 아웃바운드 전용이며, TLS 종료가 사용자 서버에서 이루어지므로 Tailscale의 릴레이 서버는 평문 데이터를 볼 수 없습니다. 단점은 도메인 이름과 포트 제약입니다. Funnel은 사용자의 tailnet 내 ts.net 도메인만 사용할 수 있으며, 포트는 443, 8443, 10000번만 지원합니다. Tailscale Serve와 Funnel의 차이점에서 상세 내용을 확인할 수 있습니다.

따라서 본인의 환경에 가장 중요한 제약 사항에 따라 선택하십시오. 사용자의 도메인으로 접속해야 하고 Cloudflare가 트래픽을 읽는 것을 수용할 수 있다면 Cloudflare Tunnel을 선택하십시오. ts.net 호스트네임을 사용해도 괜찮고 프록시에 평문 데이터를 넘길 수 없다면 Tailscale Funnel을 선택하십시오. 이미 공인 IP를 가진 서버를 보유하고 있고 제3자의 개입을 완전히 배제하고 싶다면 리버스 SSH 터널을 선택하십시오.

FAQ

Cloudflare Tunnel을 사용하면 포트 443을 계속 열어두어야 합니까?

아니요. cloudflared은 포트 7844를 통해 Cloudflare로 아웃바운드 연결을 생성하며, 모든 요청이 해당 연결을 통해 전달되므로 인바운드 포트를 사용하지 않습니다. 다만, 터널을 설치한다고 해서 기존 포트가 자동으로 닫히지는 않습니다. ufw에서 80번과 443번 포트에 대한 허용 규칙을 삭제하고, 클라우드 제공업체의 네트워크 방화벽에서도 해당 포트를 닫으십시오. 애플리케이션을 127.0.0.1에 바인딩하고, VPS IP를 노출하는 남아있는 A 레코드를 삭제하십시오. 서버 내부에서 sudo ss -lntp로, 다른 기기에서 nc -vz <your-ip> 443로 확인하십시오.

호스트네임에서 Cloudflare Error 1033이 발생하는 이유는 무엇입니까?

Error 1033은 Cloudflare가 해당 호스트네임에 대한 DNS 레코드를 보유하고 있으나 요청을 수신할 정상적인 cloudflared을 찾을 수 없음을 의미합니다. 프로세스가 중단되었거나, 실행 중이지만 Cloudflare에 연결하지 못하는 상태입니다. systemctl status cloudflared과 journalctl -u cloudflared -n 50를 확인하십시오. UDP와 QUIC을 차단하면서 TCP 폴백을 허용하지 않는 방화벽은 이 오류를 발생시키므로, 아웃바운드 포트 7844의 UDP 및 TCP 허용 여부를 확인하십시오. cloudflared tunnel info homelab은 현재 Cloudflare가 인식하는 연결 상태를 보여주며, 목록이 비어 있다면 귀하의 측에 문제가 있는 것입니다.

터널을 통해 502 Bad Gateway 오류가 발생하는 이유는 무엇입니까?

502 오류는 cloudflared까지는 도달했으나 로컬 서비스에 연결하지 못했음을 의미하며, 따라서 문제는 Cloudflare가 아닌 그 사이 구간에 있습니다. 로그를 확인하십시오. dial tcp [::1]:8080: connect: connection refused는 지정한 위치에서 수신 대기 중인 서비스가 없음을 의미합니다. 해당 메시지의 [::1]은 보통 애플리케이션이 IPv4만 바인딩하는데 service: URL에 localhost을 작성했을 때 발생하므로, 대신 http://127.0.0.1:8080를 입력하십시오. HTTP/1.x transport connection broken: malformed HTTP response은 반대의 불일치 사례로, 일반 HTTP를 사용하는 오리진에 https://을 작성한 경우입니다.

Cloudflare Tunnel을 통해 SSH, RDP 또는 게임 서버를 운영할 수 있습니까?

일반 클라이언트로는 불가능합니다. 터널을 통한 공용 호스트네임은 브라우저가 사용하는 HTTP, HTTPS, WebSocket 프로토콜만 지원합니다. 다른 TCP 프로토콜을 사용하려면 클라이언트 기기에도 cloudflared access tcp를 통한 로컬 포트 포워딩이나 WARP 클라이언트와 같은 소프트웨어가 필요합니다. 별도의 설치 없이 어떤 기기에서든 SSH를 사용하려면 터널은 적합한 도구가 아닙니다. 포트 22를 열어두되 소스 IP 주소로 접근을 제한하십시오.

Cloudflare가 터널을 통해 내 트래픽을 볼 수 있습니까?

네. Cloudflare는 엣지에서 TLS를 종료하고 요청을 복호화한 뒤, 터널을 통해 서버로 다시 암호화하여 전달합니다. 이 복호화 과정 덕분에 방화벽, 캐싱, Access 정책이 작동하며, 동시에 평문 데이터가 Cloudflare 서버에 존재하게 됩니다. Cloudflare 프록시를 사용하는 한 이를 피할 수 있는 설정은 없습니다. 이것이 허용되지 않는다면 Tailscale Funnel을 사용하거나 공용 서버에 직접 리버스 프록시를 구축하십시오.