家用 IP 不固定、不想開端口？Cloudflare Tunnel 幫你解決。

自架服務是件有趣的事——把 Gitea、Nextcloud、或自己寫的 Web App 跑在 NAS 上，然後想讓外面的人也能用。這時候大多數人會遇到三個障礙：

1. IP 不固定：家用寬頻的 IP 每次重撥可能都不同，對方根本不知道要連哪裡
2. 端口轉發麻煩且危險：路由器要開洞，把外部的連線直接導進家裡的 NAS，任何掃描器都找得到
3. ISP 封鎖 80/443：很多家用方案直接把 HTTP/HTTPS 端口封死，想架網站只能繞路

DDNS 解決第一個問題，但第二、第三個還是擺在那裡。

Cloudflare Tunnel 可以處理固定 IP 與入站端口轉發問題，但它不是完整的應用程式安全方案；公開服務仍需要登入、更新、權限與備份。方案功能、流量限制與價格也可能變動，請以 Cloudflare 當前文件和方案頁為準。

🎯 這篇適合誰

Cloudflare Tunnel 是什麼

Cloudflare Tunnel（舊稱 Argo Tunnel）的核心概念是反向隧道：不是讓外部連線進來，而是你的 NAS 主動連出去，在 Cloudflare 的伺服器上建立一條加密隧道。

流程如下：

1. NAS 上執行一個叫 cloudflared 的小程式
2. cloudflared 主動向 Cloudflare 建立長連線（outbound-only）
3. 外部用戶訪問 gitea.yourdomain.com，Cloudflare 接到請求後，透過這條隧道轉發到你的 NAS
4. NAS 回應，再由 Cloudflare 回傳給用戶

因為連線是從 NAS 主動發出去，路由器通常不需要開入站端口。公開訪客仍會先連到 Cloudflare；這能減少直接暴露家用 IP 與 NAS 入站端口的機會，但不代表服務本身、來源伺服器或 Cloudflare 上的應用設定沒有其他風險。

與傳統端口轉發相比，安全性的差異很明顯：

需要準備什麼

在開始之前，確認以下三樣東西都備齊：

• Cloudflare 帳號：到 cloudflare.com 註冊；可用功能依帳號與方案而異
• 一個網域：完整 DNS 設定通常由 Cloudflare 管理；若使用部分（CNAME）設定，DNS 記錄可能仍要在外部 DNS 供應商手動建立
• NAS 上有要對外公開的服務：例如 Gitea（:3000）、Nextcloud（:8080）、或任何監聽在某個 port 的 Web 服務

域名轉移方式：登入 Cloudflare → Add a Site → 輸入域名 → 選 Free 方案 → Cloudflare 會給你兩個 Name Server → 到你的域名購買商那裡把 NS 改掉 → 等幾分鐘到幾小時生效。

安裝 cloudflared 在 NAS 上

cloudflared 是 Cloudflare 官方的隧道程式，負責維持那條從 NAS 連到 Cloudflare 的長連線。

方法一：Docker Compose（推薦，適合 NAS）

對 Synology 或其他跑 Docker 的 NAS 來說，Docker 方式最乾淨——版本更新、重啟管理都交給 Container Manager。

在 NAS 上建立一個目錄（例如 /volume1/docker/cloudflared/），新增 docker-compose.yml：

複製services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}

TUNNEL_TOKEN 的值在下一步建立 Tunnel 時會取得。建議放在不提交到 Git 的 .env 或平台的 secrets 中，不要把完整 token 寫進公開 repository；執行前先確認 Compose 會正確讀到環境變數，再執行 docker compose up -d。固定 image 版本也比 latest 容易回溯與稽核。

方法二：直接下載 binary（適合一般 Linux）

如果是 Debian/Ubuntu 系的 Linux 主機：

複製# 下載並安裝
curl -L --output cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

# 驗證安裝
cloudflared --version

安裝後需要用 token 認證（指令在建立 Tunnel 後取得）：

複製sudo cloudflared service install eyJh...（你的 token）
sudo systemctl enable --now cloudflared

這種把 token 直接放在命令列的示範只適合理解流程；在共用電腦或有命令歷史紀錄的環境，token 可能被留下。正式部署請依 Cloudflare 文件使用受控的設定檔、服務管理器或 secrets，並在疑似外洩時立即輪替 token。

在 Cloudflare 建立 Tunnel

這裡走的是 Zero Trust Dashboard，步驟如下：

Step 1：進入 Tunnels 頁面

登入 Cloudflare → 左側選單點 Zero Trust → Networks → 連接器（Tunnels） → 點「新增通道」。

Step 2：選擇通道類型

選擇 Cloudflared（另一個選項 Mesh 是測試版，用途不同）→ 點「選取 Cloudflared」。

Step 3：為通道命名並取得 Token

輸入一個好記的名稱，例如 synology-nas，儲存後下一頁選作業系統為 Docker，頁面會顯示含有 Token 的指令。把 Token（eyJh... 開頭的長字串）複製起來，貼到 docker-compose.yml 的 TUNNEL_TOKEN 欄位。

Step 4：在 Container Manager 建立專案

回到 NAS，開啟 Container Manager → 專案 → 建立，路徑選 /docker/cloudflared，來源選「建立 docker-compose.yml」，貼入設定並填入 Token。

Container 啟動後幾秒，Cloudflare Dashboard 上的 Tunnel 狀態會從 Inactive 變成 Healthy（綠色）。

Step 5：設定公開主機名稱與來源服務

Tunnel 頁面 → 你的 Tunnel → 路由通道 → 填入以下資訊：

• 子網域：例如 vaultwarden
• 網域：選取你的域名
• 類型：HTTP
• URL：填入 http:// 加上實際可達的來源位址，例如 http://192.168.1.50:8888

如果 cloudflared 在 Docker 容器內執行，localhost 指的是 cloudflared 容器本身，不是 NAS 主機。若服務與 cloudflared 在同一個 Compose network，可使用服務名稱（例如 http://app:8080）；否則使用 NAS 或內網主機的可達位址，並先從 cloudflared 容器測試連線。

儲存後，Cloudflare 會自動在 DNS 新增一筆 CNAME 記錄。幾秒後就可以從外部用 https://vaultwarden.yourdomain.com 訪問。

設定多個服務

一個 Tunnel 可以掛多個 Public Hostname，不需要跑多個 cloudflared。

在 Tunnel 的公開主機名稱設定中繼續新增 route 即可：

每條 hostname 獨立設定，流量會由同一條 Tunnel 分發到不同的本地端口。

如果服務跑在另一台機器（例如同網路的另一台電腦），URL 改成那台機器的區域 IP；確認該服務的 firewall 只允許必要來源：

複製http://192.168.1.50:8080

安全設定

Tunnel route 建好後，公開主機名稱可能讓網際網路上的訪客直接連到來源服務。如果服務本身沒有登入保護，任何知道網址的人都能嘗試存取。Cloudflare 官方建議先建立 Access application，再設定 Tunnel route；Access policy 預設拒絕未符合 Allow 規則的使用者。

Cloudflare Access：加一道登入牆

Zero Trust → Access controls → Applications → 建立 Self-hosted application，再新增 public hostname：

• Application name：自訂名稱
• Application domain：填你的 subdomain（例如 gitea.example.com）

建立後設定 Policy（誰可以進來）：

• Email：只允許特定 email 地址
• Email domain：允許整個 email 網域（例如 @yourcompany.com）
• IP ranges：只允許特定 IP 段

Email OTP 驗證

Access 可以搭配 Email OTP 或其他身分提供者；可用的登入方式和管理畫面會依 Zero Trust 設定與方案而異。不要只因為有 OTP 就把服務視為絕對安全，仍要限制 Allow policy 的對象與權限。

更高安全性的場景可以接 GitHub OAuth、Google OAuth、或硬體 TOTP。

Cloudflare Tunnel vs 其他方案比較

幾個選擇的時機：

• 想讓完全不認識的人訪問你的服務（客戶、公開 API）→ Cloudflare Tunnel
• 只有自己或信任的人需要存取（個人用、家人）→ Tailscale 更合適
• 需要完整控制流量、自訂 nginx 設定→ VPS 反向代理

常見問題

Q1：重開機後 Tunnel 斷線，外部連不進來？

Docker 方式已設定 restart: unless-stopped，NAS 重開機後 Container 會自動重啟，Tunnel 會自動重新建立。如果用 binary 方式安裝，確認 systemd service 是否啟用：

複製sudo systemctl is-enabled cloudflared
# 應顯示 enabled

Q2：我的域名不在 Cloudflare，可以用 Tunnel 嗎？

可以，但設定方式取決於 DNS 架構。完整設定通常由 Cloudflare 管理 DNS；部分（CNAME）設定則可能需要在外部 DNS 供應商手動建立 CNAME。Cloudflare 官方文件也提醒，部分設定不會由 Cloudflare 代管整個 DNS zone。

Q3：免費方案有流量限制嗎？

不要把 Tunnel 當成無限制的檔案傳輸或影音串流方案。流量、產品相容性、合理使用與方案限制可能變動；正式公開前請查閱當前的 Cloudflare 方案與服務條款，並確認你的應用程式符合規範。

Q4：Cloudflare Tunnel 和 Tailscale 可以同時用嗎？

可以，而且這是很理想的架構：

• Tailscale：私人訪問，例如 SSH 進 NAS、存取家裡的 Samba 分享
• Cloudflare Tunnel：公開訪問，例如讓朋友用你架的服務、公開 API

兩者不衝突，裝在同一台 NAS 上完全沒問題。

總結

Cloudflare Tunnel 解決的是公開訪問的問題——讓外部任何人都能透過域名訪問你的服務，同時不暴露家用 IP、不開路由器端口。

Tailscale 解決的是私人訪問的問題——只有安裝了 Tailscale 並加入你的 network 的裝置才能連進來，適合個人或小團隊。

🔗 延伸閱讀

• Nginx Proxy Manager 反向代理完整教學
• Tailscale 在 Synology 的完整設定教學
• QuickConnect vs DDNS vs Tailscale：遠端存取方式比較
• Synology NAS 資安清單：帳號、網路與存取控制

如果你的服務需要公開，Cloudflare Tunnel 是一種減少入站暴露的方案，不是唯一或必然最安全的方案。先用測試服務驗證來源連線、Access policy、備份與回復流程，再公開正式服務；實際完成時間會依 DNS、Docker network、認證與應用程式設定而不同。

資訊來源與更新範圍

本文於 2026 年 8 月 4 日重新核對。Cloudflare Dashboard 的選單名稱、Access 功能與方案限制可能改變；以下官方文件用來確認本文的原則，實際畫面請以目前文件為準：

• Cloudflare：公開自架應用程式：Access application、public hostname、Tunnel 與 token 驗證
• Cloudflare：新增 Web applications：Access policy 與自架應用程式的基本概念
• Cloudflare Tunnel Docker 映像檔：確認容器映像檔與版本資訊

本文不保證特定方案的流量、價格或功能，也不會把「不開路由器端口」等同於完整資安防護；公開服務仍需自行負責身分驗證、最小權限、更新、日誌與備份。

關於作者 Dairny

15 年以上系統管理與 IT 維運經驗，NAS 從 FreeNAS 一路玩到 Synology。文章裡的每個步驟，都在自己的環境實際跑過。更多關於我 →