Cloudflare Tunnel 完整教學 2026：什麼是 Cloudflare Tunnel？不開防火牆 port 也能把自架服務搬上網（cloudflared 安裝、config.yml、Docker、Zero Trust 保護一次學會）

Cloudflare Tunnel 是 Cloudflare 提供的免費反向通道服務：你在伺服器上跑一個叫 cloudflared 的小程式，由它主動向 Cloudflare 邊緣建立 4 條加密連線，公網流量就順著這條既有連線流回你的服務。你完全不用開放任何 inbound 連接埠、不用公網 IP、不必面對 CGNAT，真實 IP 也不會曝光。cloudflared 是 Apache-2.0 授權的開源專案，Tunnel 本身免費、流量無限。

截至 2026 年 9 月 18 日，cloudflared 在 GitHub 上有 15,719 顆星、1,446 個 fork，最新版本是 2026.9.1（2026-09-11 發布）。這篇文章會把整套流程從零走完：安裝、建立 tunnel、寫 config.yml、常駐成 systemd 服務、用 Docker Compose 部署、加上 Zero Trust 身分驗證，最後附上與 ngrok、Tailscale Funnel、frp 的比較表與常見錯誤排錯。

30 秒認識 Cloudflare Tunnel

為什麼需要它？先看傳統做法痛在哪

要理解 Cloudflare Tunnel 的價值，最直接的方法是看其他三種常見做法各自卡在哪。

換句話說，傳統做法的前提都是「我得先被看見才能提供服務」；Cloudflare Tunnel 反過來，先由你的機器主動連出去，再把請求接回來。

架構原理：4 條出站連線 + 反向通道

cloudflared 啟動後，會自動與 Cloudflare 分佈在不同地理位置的邊緣節點建立 4 條持久的出站連線（預設優先 UDP QUIC，備援走 TCP HTTP/2，都是連接埠 7844），達成高可用與負載平衡。之後：

1. 訪客連到你的網域（例如 app.example.com）。
2. Cloudflare 邊緣接手，做 TLS 終止、WAF 過濾、DDoS 防護。
3. 邊緣把請求沿著那 4 條既有連線，送回你機器上的 cloudflared。
4. cloudflared 再依 config.yml 的 ingress 規則，把請求轉給本機的服務（例如 http://localhost:8080）。

這代表你的 origin 可以維持完全關閉的狀態：不需要公網入口、不需要開 80/443，真實 IP 也藏在通道後面。順帶一提，這條路上唯一的出站要求是 UDP/TCP 7844——如果你的環境有嚴格的 egress 防火牆，記得放行這個埠，否則 tunnel 會連不上。

安裝 cloudflared（Linux）

方法 1：官方 apt 套件庫（Debian / Ubuntu，推薦）

# 建立 keyrings 目錄並匯入 Cloudflare GPG 金鑰
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

# 新增 apt 軟體源
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list

# 更新套件清單並安裝
sudo apt-get update && sudo apt-get install cloudflared

# 確認版本
cloudflared --version

方法 2：二進位檔（不想動 apt 的時候）

到 github.com/cloudflare/cloudflared/releases 下載對應架構的檔案（cloudflared-linux-amd64、cloudflared-linux-arm64），chmod +x 後丟到 /usr/local/bin/ 即可。

方法 3：Docker

官方映像檔是 cloudflare/cloudflared:latest（DockerHub）。容器化部署適合已經用 Compose 管服務的人，後面〈Docker Compose 部署〉一節有完整範例。

小提醒：Cloudflare 官方支援「距離最新版本一年內」的 cloudflared。超過一年的版本可能遇到不相容的 breaking change，記得定期更新。

本機管理 Tunnel：四個指令走完

Cloudflare Tunnel 有兩種管理模式：Dashboard 遠端管理（在網頁上建立，複製安裝指令貼到伺服器跑）與本機管理（locally-managed）（用 CLI 建立，設定存在自己的 config.yml）。後者對自架族比較好用，因為設定進得了 Git、也容易備份。

~/.cloudflared/ 目錄裡有什麼

• cert.pem：登入時取得的 Origin CA 授權憑證，用來建立／刪除 tunnel 與設定 DNS 路由。
• <TUNNEL_ID>.json：單一 tunnel 的 credentials 檔，內含私鑰與 ID。搬家或換機器時一定要一起複製，否則 tunnel 起不來。
• config.yml：本機管理的設定檔（自己建立，見下節）。

config.yml 完整範例

本機管理的核心就是這個檔案。以下是涵蓋常見情境的完整範例：

tunnel: homelab-tunnel
credentials-file: /etc/cloudflared/7f3a1c9e-4b2d-4e11-9a6f-2d8c5e0b91aa.json

# 全局 origin 請求設定
originRequest:
  connectTimeout: 30s
  noTLSVerify: false

ingress:
  # 1. 一般 HTTP 服務
  - hostname: app.example.com
    service: http://localhost:8080

  # 2. 本機 HTTPS（自簽憑證時忽略驗證、覆寫 Host 標頭）
  - hostname: secure.example.com
    service: https://localhost:8443
    originRequest:
      noTLSVerify: true
      httpHostHeader: "secure.example.com"

  # 3. 路徑匹配（單一網域拆多個後端）
  - hostname: app.example.com
    path: ^/api/.*
    service: http://localhost:5000

  # 4. SSH
  - hostname: ssh.example.com
    service: ssh://localhost:22

  # 5. TCP（例如資料庫）
  - hostname: db.example.com
    service: tcp://localhost:5432

  # 6. 內建測試服務
  - hostname: test.example.com
    service: hello_world

  # 7. catch-all 一定要放最後
  - service: http_status:404

Ingress 規則的三個關鍵觀念

1. 由上往下比對，第一個命中就決定。所以越具體的規則要放越上面，http_status:404 這種 catch-all 必須放最後一行——這也是 Cloudflare 官方明定的要求。
2. path 只做匹配，不會改寫路徑。^/api/.* 命中後，後端收到的是完整原始路徑。要 strip 或 rewrite，得靠 edge 的 URL Rewrite Rules，或在本機再放一層反向代理。
3. originRequest 可以寫在全局也可以寫在單條規則裡，單條的會覆蓋全局。常用選項：connectTimeout（預設 30s）、noTLSVerify（origin 用自簽憑證時設 true）、httpHostHeader（覆寫送往 origin 的 Host）、disableChunkedEncoding。

讓它常駐：systemd 服務

cloudflared tunnel run 手動跑會在登出後中斷。要做成服務，建議開一個專用系統帳號：

sudo useradd --system --home /etc/cloudflared --shell /usr/sbin/nologin cloudflared
sudo mkdir -p /etc/cloudflared
sudo cp ~/.cloudflared/config.yml ~/.cloudflared/*.json /etc/cloudflared/
sudo chown -R cloudflared:cloudflared /etc/cloudflared

接著建立 /etc/systemd/system/cloudflared.service：

[Unit]
Description=Cloudflare Tunnel agent
After=network-online.target
Wants=network-online.target

[Service]
User=cloudflared
Group=cloudflared
ExecStart=/usr/bin/cloudflared tunnel --config /etc/cloudflared/config.yml run
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now cloudflared
systemctl status cloudflared

狀態正常的話，日誌裡會看到它對 4 個邊緣節點都建立了連線。

Docker Compose 部署

如果服務本來就跑在容器裡，cloudflared 也用容器跑最省事：

version: "3.9"

services:
  demo-app:
    image: nginx:latest
    container_name: demo-app
    restart: unless-stopped
    networks:
      - tunnel-net

  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    command: tunnel --no-autoupdate run homelab-tunnel
    volumes:
      - ./cloudflared:/etc/cloudflared
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    networks:
      - tunnel-net
    depends_on:
      - demo-app

networks:
  tunnel-net:
    driver: bridge

兩個最常見的踩雷點：

• service 千萬不要填 localhost。當 cloudflared 與應用在同一個 Docker 網路時，localhost 指的是 cloudflared 容器自己，要用 Docker 服務名稱，例如 http://demo-app:80。填錯的症狀就是 502。
• TUNNEL_TOKEN 用於 Dashboard 託管的無狀態 tunnel。從 Cloudflare Dashboard 建立 tunnel 時可取得 token，適合不想把憑證檔放進容器的人。

TryCloudflare Quick Tunnel：免帳號、30 秒上線

想先試試看、或只是要把本機東西臨時分享出去，可以直接用 Quick Tunnel：

cloudflared tunnel --url http://localhost:8080

它會立刻產生一個隨機的 *.trycloudflare.com 子網域並印在終端機上，不需要 Cloudflare 帳號、不需要網域、不用任何設定檔。

Quick Tunnel 的定位很明確：它是試用版，不是生產版。要拿掉這些限制，就得把網域加進 Cloudflare 並建立正式 tunnel。

加上 Cloudflare Access：讓服務只有你能進

如果你不想讓服務對全世界公開——例如自架的 Grafana、Uptime Kuma、內部管理後台——那 Cloudflare Access（Zero Trust）就是它的關鍵搭檔。做法是在 Cloudflare 邊緣先攔下請求、要求身分驗證，通過之後才放行到 tunnel：

1. 進入 Zero Trust Dashboard → Access → Applications，新增一個 Self-hosted Application。
2. 填入應用網域（例如 grafana.example.com）與 session 過期時間。
3. 設定 Policies：Action 選 Allow，條件比對允許的 Email、網域，或身分提供者（IdP）群組。
4. 支援的驗證方式包含 Email OTP、Google、GitHub、Microsoft Entra ID、mTLS，以及 Service Tokens（適合機器對機器）。

免費方案可以保護 50 位使用者（Seats）。 對個人、家庭、小型團隊來說，這個額度幾乎用不完，等於免費獲得一套企業級的存取控制。

費用：到底要不要錢？

與 ngrok、Tailscale Funnel、frp 的完整比較

同樣是「把本機服務變公網可達」，這四個工具的設計哲學差很多：

怎麼選？一句話版本：

• 有網域、要長期對外、想順便拿到 WAF 與 Zero Trust → Cloudflare Tunnel
• 只是要 10 分鐘內把 webhook 露出來測一下 → ngrok
• 已經在用 Tailscale 的私有網路，只想給同一 tailnet 的人看 → Tailscale Funnel
• 不想讓任何第三方碰到流量 → frp + 自己的 VPS

常見錯誤與排錯

實戰場景：三個馬上能用的情境

1. 自架服務取代 port forwarding。 在 Proxmox、樹莓派或家用 NAS 上跑好服務（例如 Uptime Kuma 監控），用 tunnel 綁一個子網域，就不用在家用路由器上開任何埠、也不必處理 CGNAT。
2. 接收 Webhook。 需要一個公開 HTTPS 端點讓第三方服務打進來時，tunnel 給你穩定網址（比 Quick Tunnel 的隨機網域可靠）；搭配 Access 的 Service Token 還能限制來源。想搞懂簽章驗證這一段，可以先看什麼是 Webhook 的完整教學。
3. 在現有反向代理前面再加一層。 已經用 Caddy 管內部路由的人，可以讓 cloudflared 指向 Caddy，變成「Cloudflare 邊緣 → tunnel → Caddy → 各服務」的兩段式架構，TLS 與路由責任切得很乾淨。

如果你的服務跑在容器裡、又想先補齊容器化的基本功，Docker 完整教學是好起點；若你更想走「完全私有網路」這條路，Tailscale 完整教學則是完全不同的取捨（Mesh VPN 走私有網段，不是對公網開放）。

延伸閱讀

• Tailscale 完整教學 2026：36K 星 WireGuard Mesh VPN，從安裝、MagicDNS、Subnet Router 到遠端連回家中自架服務——同樣是「不開防火牆」的解法，但走的是私有網路而非公開網域。
• Caddy 完整教學 2026：75K 星自動 HTTPS 網頁伺服器，從 Caddyfile、反向代理到 Docker 部署——Tunnel 前面／後面的那層反向代理。
• 什麼是 Webhook？白話文完整教學：與 API 輪詢的差異、Python FastAPI 實作與安全驗證——把 tunnel 用在 Webhook 場景時，這篇補齊安全驗證觀念。
• Uptime Kuma 完整教學 2026：91K 星自架監控神器——自架服務最該配的一個監控。
• 網站防爬蟲實戰指南：從 robots.txt 到 Cloudflare Bot 管理，2026 最新防護策略——服務上線之後，接著要面對的自動化流量問題。

資料來源

• Cloudflare 官方文件：Cloudflare Tunnel
• Cloudflare 官方文件：Quick Tunnels（TryCloudflare）
• Cloudflare 官方文件：Downloads（安裝方式）
• Cloudflare 官方文件：DNS records
• Cloudflare 官方文件：Create a tunnel (dashboard)
• cloudflared GitHub 專案（README 與 Releases）

版本與價格資訊以 2026 年 9 月 18 日查核為準；cloudflared 最新版為 2026.9.1。免費方案限制與價格請以 Cloudflare 官方公告為準。