Cloudflare Tunnel 설정 및 서버 포트 닫기 가이드

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

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

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

cloudflared은 region1.v2.argotunnel.com 및 region2.v2.argotunnel.com의 7844번 포트로 나가는 아웃바운드 연결이 필요합니다. 이 서비스는 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 세션을 열어두어야 합니다.

Ubuntu 또는 Debian에 cloudflared 설치하기

Cloudflare는 모든 .deb 릴리스마다 cloudflared 패키지를 제공하므로, 설치는 다운로드 한 번과 dpkg 호출 한 번으로 완료됩니다.

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

시스템 아키텍처를 확실히 모른다면 먼저 dpkg --print-architecture을 실행하십시오. 64비트 ARM 환경에서는 파일 이름이 amd64가 아닌 arm64로 끝나며, 그 외의 사항은 동일합니다. cloudflared --version을 실행하여 버전 문자열이 출력되면 다음 단계로 넘어가기에 충분합니다.

이 방식으로 설치된 패키지는 apt의 업데이트 경로에서 제외되므로 apt-get upgrade은 해당 패키지를 업데이트하지 않으며, 업데이트 관리는 사용자의 몫입니다. sudo cloudflared update는 최신 릴리스를 가져와 기존 바이너리를 교체합니다. 서비스가 이미 존재한다면, 실행 중인 프로세스가 새 바이너리를 사용하도록 sudo systemctl restart cloudflared을 이어서 실행하십시오. 터널 데몬은 포트를 열지 않더라도 인터넷에 노출되는 소프트웨어이므로, 다른 패치 작업과 동일한 주기로 업데이트를 수행하십시오.

로그인 및 명명된 터널 생성

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, 현재 유지 중인 연결 수를 출력해야 합니다.

실제 ingress 규칙을 포함한 config.yml 작성

설정 파일은 홈 디렉터리가 아닌 /etc/cloudflared/config.yml에 작성해야 합니다. 이유는 다음과 같습니다. cloudflared service install는 발견한 설정을 /etc/cloudflared/config.yml으로 복사한 뒤, --config /etc/cloudflared/config.yml를 systemd 유닛에 하드코딩합니다. 만약 ~/.cloudflared/config.yml에 파일을 작성하면, 해당 복사본은 일회성 스냅샷으로 남습니다. 이후 홈 디렉터리의 파일을 수정해도 서비스는 이전 규칙을 그대로 사용하며, 별도의 경고도 발생하지 않습니다. 파일을 제 위치에 직접 작성하면 이러한 문제를 원천적으로 방지할 수 있습니다.

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

규칙은 위에서 아래로 읽히며, 가장 먼저 일치하는 규칙이 적용됩니다. hostname이 없는 규칙은 모든 호스트 이름과 일치하므로, catch-all 규칙은 반드시 마지막에 위치해야 합니다. 이를 생략하면 설정은 The last ingress rule must match all URLs (i.e. it should not have a hostname or path filter) 오류와 함께 거부됩니다. http_status:404은 404 응답 외에는 아무 작업도 하지 않는 내장 서비스입니다. 이 서비스는 필수적입니다. 이를 사용하지 않으면, 의도치 않게 노출된 호스트 이름으로 들어온 요청이 마지막에 위치한 실제 규칙으로 전달될 수 있기 때문입니다.

service: URL에는 localhost 대신 127.0.0.1를 사용하십시오. Ubuntu에서 localhost는 먼저 ::1으로 해석되는데, IPv4 루프백에만 바인딩된 애플리케이션은 해당 연결을 거부합니다. 이때 로그에는 dial tcp [::1]:8080: connect: connection refused가 기록되며 방문자는 502 오류를 보게 됩니다.

이 구간은 트래픽이 머신 외부로 나가지 않으므로 일반 http://를 사용하는 것이 올바릅니다. https://은 로컬 애플리케이션이 반드시 TLS(transport layer security)를 요구할 때만 사용하십시오. 이때 인증서가 호출한 이름과 일치하지 않으면 x509: certificate is valid for example.com, not localhost 오류가 발생합니다. 이 문제는 originRequest 아래에 originServerName을 설정하여 해결하거나, 위험을 감수하고 noTLSVerify: true을 사용하십시오.

서비스를 시작하기 전에 규칙을 확인하십시오:

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은 설정이 유효한지 보고하거나 오류가 발생한 규칙의 이름을 알려줍니다. ingress rule는 하나의 URL을 입력받아 일치하는 첫 번째 규칙을 출력합니다. 이는 path 정규 표현식이 의도대로 동작하는지 확인하는 가장 빠른 방법입니다.

터널을 가리키도록 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 80; 대신 listen 127.0.0.1:8080;을 사용해야 하며, 이는 이 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뿐입니다. SSH, RDP(remote desktop protocol) 또는 게임 서버와 같은 다른 TCP 프로토콜을 사용하려면 클라이언트 측에도 소프트웨어가 필요합니다. 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를 확인하십시오. 이후 7844 포트의 UDP 및 TCP 아웃바운드 통신이 허용되는지 확인하십시오. UDP와 QUIC를 차단하면서 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을 사용하거나 직접 공개 서버에 리버스 프록시를 구축하십시오.