雅寶社區 · 頂客論壇 (AHPAL.COM)

📊 軟體評測

Cloudflare Tunnel 與 Tailscale Funnel，自架服務對外曝光的差異

發表時間：2026 年 11 月 14 日 | 更新日期：2026 年 11 月 14 日 | 編輯：雅寶社區編輯團隊

反向代理掛在 VPS 上： 租一台有公網 IP 的小 VPS，用 frp、rathole 或 nginx stream 把流量導回內網。控制權最大，但要自己維運一台對外主機，安全責任全在自己身上。

反向隧道服務（Cloudflare Tunnel、ngrok 等）： 由廠商提供邊緣節點，你的機器主動向外建立連線，外部流量從廠商節點回送。零開孔、免公網 IP，代價是把一部分控制權與資料路徑交給廠商。

Mesh VPN（Tailscale、ZeroTier）： 建一個虛擬內網，讓你的裝置彼此互通。這本身不是「對公網曝光」，但 Tailscale 後來加了 Funnel，讓它可以選擇性地把某個服務推到公網。

本文要深入比較的，就是第三與第四條路線的代表：Cloudflare Tunnel 與 Tailscale Funnel。它們的共通點是「由內而外的主動連線」，但設計哲學完全不同——一個是把服務藏進 CDN 網路，另一個是把私有網路開一扇對外的小門。

Cloudflare Tunnel 是什麼？把家裡的服務「藏」進 Cloudflare 網路

Cloudflare Tunnel 的前身是 Argo Tunnel，本質上是一條從你機器到 Cloudflare 邊緣節點的持久性出站通道。你在自己的機器上跑一個叫 cloudflared 的守護程序，它會主動向 Cloudflare 的邊緣建立連線（走 QUIC 或 HTTP/2，預設端口 7844）。之後，當外部使用者請求你的網域時，Cloudflare 邊緣會把請求透過這條通道送回你的機器。

運作原理：出站連線取代入站開孔

這個模型最漂亮的地方在於：你的路由器與防火牆完全不用動。 因為連線是由內網機器主動發起的，對防火牆而言那是「對外的連線」，NAT 會自動建立狀態表讓回應封包回得來。你的機器從頭到尾沒有任何一個「對外開放」的入站端口，掃描器掃不到你，攻擊面大幅縮小。

流程大致是這樣：

cloudflared 啟動後向 Cloudflare 註冊，建立一到多條持久連線（企業版可設多條以達到高可用）。

你在 Cloudflare 的 Zero Trust 儀表板（或透過 CLI / API）設定「公開主機名 → 本地服務」的對應規則，例如 photos.example.com 指向 http://localhost:2342。

外部使用者請求 photos.example.com，DNS 解析到 Cloudflare 的邊緣 IP。

邊緣節點根據隧道設定，把請求經由已建立好的通道轉送到你的 cloudflared。

cloudflared 再把請求交給本地的 localhost:2342。

整個過程中，TLS 是由 Cloudflare 邊緣端終止的（除非你另外設定）。這代表憑證管理、TLS 版本、HTTP/2、HTTP/3、Brotli 壓縮、快取這些事情，你全部不用自己來——這對自架玩家來說是巨大的便利。

設定流程概覽：從安裝到上線大約十分鐘

以最常見的流程為例（實際步驟請以官方文件為準，版本可能變動）：

把網域加進 Cloudflare，並把 NS 指向 Cloudflare（這是使用 Tunnel 搭配自訂網域的前提）。

在機器上安裝 cloudflared，執行 cloudflared tunnel login 授權。

執行 cloudflared tunnel create <名稱> 建立隧道，會產生一組憑證 JSON。

在設定檔中定義 ingress 規則，把主機名對應到本地服務。

建立 DNS CNAME 指向 <UUID>.cfargotunnel.com，或直接用 cloudflared tunnel route dns 自動建立。

把 cloudflared 註冊成系統服務（systemd、launchd 或 Windows 服務），確保開機自動啟動。

近一兩年 Cloudflare 也強推「在儀表板直接建立隧道」的圖形化流程，會給你一段安裝指令，貼上就跑，對不熟 CLI 的人友善很多。這點比 Tailscale Funnel 的設定門檻稍低一點。

功能邊界與限制：免費方案不是沒有限制

Cloudflare Tunnel 本身在免費方案就能用，但「免費」不代表沒有限制，以下幾點是自架者最常踩到的：

請求逾時： Cloudflare 代理的 HTTP 請求有約 100 秒的上限（超過會回 524）。長時間執行的同步 API、大檔案上傳、報表匯出這類請求，很容易被切斷。WebSocket 連線則不受此限，所以即時通訊類應用沒問題。

上傳大小： 免費方案有單次請求 body 大小限制（約 100MB 級別），要傳大檔得走分段上傳或另外處理。

非 HTTP 協定要繞路： Tunnel 原生處理的是 HTTP/HTTPS。若要暴露 SSH、資料庫、SMB 這類 TCP 服務，客戶端必須安裝 cloudflared 並搭配 Access，等於「不是純公網曝光」，而是「受控的私有通道」。這一點常被誤解。

資料會經過 Cloudflare 解密： 因為 TLS 在邊緣終止，Cloudflare 在技術上能看見明文（除非你啟用應用層端對端加密）。對隱私高度敏感的服务，這點必須納入評估。

線路品質： 免費方案走的是 Cloudflare 的公開Anycast 網路，台灣使用者通常走日本或香港節點，延遲多在 30–80ms 之間，日常使用足夠，但競技型遊戲或低延遲遠端桌面就不適合。

Tailscale Funnel 是什麼？把 Tailscale 私有網路開一扇對外小門

要理解 Funnel，得先理解 Tailscale 本身。Tailscale 是一套基於 WireGuard 的 Mesh VPN，它幫你建立一個虛擬私有網路（稱為 tailnet），把你名下所有裝置——筆電、手機、NAS、雲端 VPS——串成一個彼此可直連的內網。你不需要設定任何防火牆規則，也不需要公網 IP，裝置之間會自動打洞建立點對點連線（打不通時才走 Tailscale 的中繼伺服器 DERP）。

換句話說，Tailscale 解決的是「我的裝置之間怎麼互通」，而不是「怎麼讓全世界連進來」。 這也是它與 Cloudflare Tunnel 最根本的差異。

Tailscale 的網路模型：控制平面與資料平面分離

Tailscale 的架構有一個很重要的特性：控制平面與資料平面是分開的。

控制平面（Coordination Server）： 負責身分驗證、裝置註冊、公鑰交換、NAT 打洞協調。這部分由 Tailscale 營運（開源版可自架 Headscale）。

資料平面： 真正傳資料的 WireGuard 加密通道，多數情況下是裝置之間的點對點直連，Tailscale 的伺服器碰不到你的內容。

這個設計讓 Tailscale 在隱私上比傳統 VPN 服務好很多：除非打洞失敗被迫走 DERP 中繼，否則流量根本不經過 Tailscale。而 DERP 中繼本身也是端對端加密的，中繼節點只能看到加密後的封包。

Serve 與 Funnel 的差別：一個對內，一個對外

很多人會把這兩個指令搞混，但差別非常關鍵：

tailscale serve： 把本機服務暴露給同一個 tailnet 內的其他裝置。這是「對內」的，只有你授權的裝置能連，外部網路完全看不到。適合家庭成員共用、跨裝置存取。

tailscale funnel： 把本機服務暴露到公網。任何人只要知道網址就能連進來。這是「對外」的，等於在你嚴密的私有網路上開了一扇通往世界的門。

Funnel 的運作方式是：Tailscale 在全球部署了一批 ingress 節點，你的機器透過 WireGuard 連上這些節點，然後 ingress 節點會用一個 *.ts.net 的網域對外提供服務。TLS 憑證由 Tailscale 自動申請與更新（透過 Let's Encrypt），你完全不用管。

設定流程概覽：三行指令就能上線

Funnel 的設定體驗可以用「極簡」形容（實際語法請以官方文件為準）：

在機器上安裝 Tailscale 並登入，確認 MagicDNS 與 HTTPS 憑證功能已在管理後台啟用。

執行 tailscale funnel 3000（把本地 3000 端口曝光），或使用 tailscale funnel --bg 3000 讓它在背景常駐。

系統會回傳一個網址，形如 https://你的機器名.你的tailnet名.ts.net，這就是你的公開入口。

沒有 DNS 設定、沒有憑證申請、沒有反向代理設定。對於「我只是想臨時給朋友看個東西」這種需求，Funnel 的便利性遠勝 Cloudflare Tunnel。

功能邊界與限制：它不是給你跑高流量服務的

Funnel 的定位非常明確：輕量、臨時、低流量。官方文件也直言它不是為高頻寬或高併發設計的。實務上的限制包括：

只支援特定端口： 目前僅支援 443、8443、10000 三個端口，而且只處理 HTTPS 流量。你沒辦法用它曝光純 TCP 或 UDP 服務（例如遊戲伺服器、DNS、SMTP）。

網域綁死： 只能用 *.ts.net 子網域，無法掛自己的品牌網域。這對「要給客戶看」的正式服務是硬傷，對「給朋友看」則無所謂。

沒有內建身分驗證： Funnel 一開，全世界都能連。它不像 Cloudflare Access 那樣可以在邊緣做 SSO、OTP、IP 白名單。你要保護服務，只能自己在應用層加登入機制。

流量經過 Tailscale ingress： 資料會先在 ingress 節點終止 TLS 再轉送，因此 Tailscale 在技術上能看見明文。這點與 Cloudflare Tunnel 類似，隱私考量要一致看待。

頻寬與穩定度： 社群普遍反映 Funnel 的吞吐量與延遲不如商業 CDN，而且 ingress 節點數量有限，熱門時段或跨洲連線的品質波動較明顯。

正面對決：八個維度的實際差異

接下來這段是本文的核心。我把自架者最在意的幾個面向拉出來逐項比較，最後再給一張總表。

維度一：連線模型與延遲表現

Cloudflare Tunnel 走的是 Cloudflare 遍布全球的 Anycast 邊緣網路。對台灣使用者而言，請求通常會落到最近的節點（多半是台北、東京或香港），延遲表現相對穩定，而且邊緣節點有快取與連線復用，靜態資源的載入體感很好。

Tailscale Funnel 則是穿過 WireGuard 通道到 Tailscale 的 ingress 節點，再轉給你的機器。這條路徑多了一層中繼，而且 ingress 節點的佈點密度遠不如 Cloudflare。實測上，Funnel 的首位元組時間（TTFB）通常比 Cloudflare 高出一個檔次，跨洲連線時更明顯。

結論： 對延遲敏感的服務（即時協作、影音串流、遠端桌面），Cloudflare Tunnel 明顯佔優。Funnel 適合「能打开就好」的輕量場景。

維度二：網域、憑證與品牌識別

Cloudflare Tunnel 最大的優勢之一，是可以用自己的網域。你有 example.com，就能開 photos.example.com、api.example.com，憑證由 Cloudflare 自動簽發與更新。這對要對外提供服務、甚至只是要「看起來像個正經東西」的人來說，差別很大。

Tailscale Funnel 只能給你 機器名.tailnet名.ts.net。網址又長又醜，而且綁死了 tailnet 名稱。你當然可以在前面再掛一層自己的反向代理或 CDN 來換網域，但那等於多繞一圈，失去了 Funnel 的簡單性。

結論： 需要品牌感、需要多子網域、需要對外正式提供服務 → Cloudflare Tunnel。只是臨時分享 → Funnel 夠用。

維度三：存取控制與身分驗證

這是兩者差距最大的地方之一。

Cloudflare 有完整的 Zero Trust / Access 體系。你可以在邊緣就要求使用者通過 Google、GitHub、Microsoft 等 IdP 的 SSO，或是一次性 PIN 碼、甚至只允許特定 IP 或國家。驗證沒過，請求根本到不了你的機器。免費方案就能用（有使用者數上限），對自架者來說是超值的安全網。

Tailscale Funnel 沒有這層機制。它是一扇「開了就對全世界開」的門。你只能靠應用程式自己的登入頁、HTTP Basic Auth、或者反過來用 tailscale serve 搭配 ACL 只給 tailnet 內裝置存取。

結論： 如果你要曝光的服務本身沒有強大的認證機制（例如某些自架面板、監控介面），Cloudflare Tunnel + Access 是明顯更安全的選擇。

維度四：協定支援範圍

Cloudflare Tunnel 原生支援 HTTP/HTTPS 與 WebSocket，對 SSH、RDP、資料庫等 TCP 服務則是透過 cloudflared access 在客戶端建立通道（需要客戶端也裝工具）。此外也能處理部分 UDP 場景（例如 WARP 相關）。整體彈性較大。

Tailscale Funnel 只處理 HTTPS，端口限定 443／8443／10000。要曝光 SSH，你其實該用的是 Tailscale 本身的 VPN 功能（把裝置拉進 tailnet），而不是 Funnel。

結論： 需要曝光非 HTTP 服務 → Cloudflare Tunnel 或直接用 Tailscale VPN（不是 Funnel）。純網站類 → 兩者皆可。

維度五：頻寬與流量政策

Cloudflare 免費方案沒有明文的流量上限，一般個人自架用量不太會被關切，但仍有「合理使用」的隱性邊界，而且大檔案與長連線會碰到前面提過的請求限制。付費方案（Pro／Business）可放寬。

Tailscale Funnel 則明確不是為高流量設計。官方對頻寬與併發都有隱性期待，跑影片串流或大檔案下載容易被限速或中斷。

結論： 有影音或大檔需求 → Cloudflare Tunnel（且要考慮升級方案）。輕量 API、小型網頁 → 兩者都行。

維度六：隱私與資料路徑

兩者都不是「端對端加密直達你家」的模型——因為 TLS 都在服務商節點終止，服務商在技術上能看見明文。差別在於：

Cloudflare 是全球化商業 CDN，資料會經過其邊緣節點與相關日誌系統，法遵與資料保留政策相對公開透明，但仍是「第三方可見」。

Tailscale 的 ingress 也會終止 TLS，但其核心設計強調控制平面與資料平面分離；對「非 Funnel」的一般 tailnet 流量，Tailscale 確實看不到內容。Funnel 是例外，因為它必須終止 TLS。

若你有極高的隱私需求，正解是在應用層再做一層端對端加密，或改用自架 VPS + 自管憑證的反向代理方案。

維度七：費用結構

兩者的入門門檻都是「免費」，但免費的內涵不同：

Cloudflare Tunnel： 隧道本身免費，Zero Trust 免費方案提供一定數量的使用者席位。付費主要在於進階 WAF、更高的流量政策、企業級支援。

Tailscale： 個人方案免費，裝置數與使用者數有上限（對一般自架者通常夠用）。企業功能（如 ACL 進階、SCIM、日誌串流）需付費。

對單人自架者而言，兩者幾乎都是零成本。差異會在你把家人、朋友拉進來、或要對外提供正式服務時才浮現。

維度八：維運複雜度與可觀測性

Cloudflare 提供完整的分析儀表板：請求量、狀態碼分布、緩存命中率、防火牆事件、Access 登入紀錄。對「想知道誰在打我的服務」這件事非常有幫助。

Tailscale 的管理後台相對樸素，重點在裝置管理與 ACL，流量層級的可觀測性弱得多。你要看請求日誌，得自己在應用層或反向代理上做。

結論： 需要營運級的可觀測性 → Cloudflare。只是自家用 → Tailscale 的簡潔反而舒服。

總表對照

比較維度

Cloudflare Tunnel

Tailscale Funnel

自訂網域

支援，憑證自動管理

僅 *.ts.net

邊緣身分驗證

有（Access / Zero Trust）

支援協定

HTTP/HTTPS、WebSocket，TCP 需客戶端工具

僅 HTTPS

可用端口

由主機名路由，彈性高

443／8443／10000

延遲表現

佳（Anycast 邊緣密集）

普通（ingress 節點有限）

高流量承載

較佳，付費可再放寬

不適合

設定難度

中等（需網域與 DNS）

極低（三行指令）

可觀測性

強（完整分析面板）

免費可用

是（個人方案）

真實場景選型建議：你的需求屬於哪一種？

規格表看完了，接下來談實戰。以下是我認為最常見的五種自架情境，以及對應的建議。

場景一：給家人朋友看的照片站、小型網頁

這是絕大多數人踏入自架的第一步。需求特徵是：流量小、使用者少、但希望「看起來正常一點」，最好有自己的網域名稱。

建議：Cloudflare Tunnel。 理由很簡單——你可以用 photos.你家網域，加上 Cloudflare Access 只允許特定 Email 登入，安全性與體感都遠勝一串 xxx.ts.net。而且照片站的縮圖載入會受益於邊緣快取。

如果你連網域都不想買、只是臨時給三五好友看個兩天，那 Funnel 更快，三分鐘搞定，看完就關。

場景二：自架 API、接收 Webhook

這類需求的特徵是：需要穩定的對外端點、可能需要自訂網域、請求量中等、偶有長連線（WebSocket）。

建議：Cloudflare Tunnel。 自訂網域讓你把 endpoint 寫進各種第三方服務的設定裡；Access 可以針對不同路徑設不同政策；分析面板能讓你知道有沒有人亂打。唯一要注意的是 100 秒請求上限——如果你的 API 有長時間同步處理，記得改成非同步任務 + 輪詢或 WebSocket。

Funnel 在這個場景的問題是網域醜、沒有邊緣防護、而且一旦你的 tailnet 名稱曝光，等於把入口位置告訴大家。

場景三：遠端 SSH、資料庫、遊戲伺服器

這是很多人誤用 Funnel 的地方。Funnel 只處理 HTTPS，你根本沒辦法用它曝光 SSH 或 Minecraft 伺服器。

建議： 遠端 SSH 與資料庫，正解是直接用 Tailscale 把裝置拉進 tailnet（不是 Funnel），這樣只有你授權的裝置能連，安全性最高。若你堅持要走公網，Cloudflare Tunnel 搭配 cloudflared access 可以做到，但客戶端要裝工具，便利性不如 Tailscale。

遊戲伺服器（TCP/UDP）兩者都不適合。老實說，這類需求要嘛走 VPS 代管，要嘛乖乖搞定公網 IP 與端口轉送。

場景四：多據點、多台機器的內網互通

你家裡有 NAS、公司有工作站、雲端有 VPS，想讓它們像在同一個內網一樣互通。

建議：Tailscale（不是 Funnel）。 這正是 Tailscale 的主場。裝好之後，每台機器都有一個固定的虛擬 IP，彼此直連、端對端加密、不用管 NAT。Cloudflare Tunnel 雖然也能做類似的事（WARP-to-Tunnel），但設定複雜得多，而且定位不同。

Funnel 在這個場景只是錦上添花——當你偶爾需要讓「非 tailnet 裝置」也能存取某個服務時，才打開它。

場景五：兩個一起用，才是多數人的正解

看到這裡你應該發現了：這兩者其實不是互斥的選項，而是互補的工具。

實務上很多人是這樣配置的：

Tailscale 打底： 所有個人裝置（筆電、手機、NAS、VPS）都加入 tailnet，日常遠端存取、SSH、檔案同步全部走 Tailscale，安全又省事。

Cloudflare Tunnel 對外： 需要給「沒有 tailnet 的人」存取的服務（網站、API、公開頁面），走 Cloudflare Tunnel 搭配 Access。

Funnel 當備援： 當 Cloudflare 出狀況、或你臨時在別台機器上想快速分享一個服務，Funnel 是最快的逃生門。

這種「分層」的思路，比執著於「哪個比較好」務實得多。

常見坑與疑難排解

不管選哪條路，總會踩到一些坑。以下整理社群最常回報的問題。

Cloudflare Tunnel 的常見狀況

502 Bad Gateway： 九成是 cloudflared 連不到本地服務。先確認本地服務真的在跑、端口沒打錯、而且綁定的是 0.0.0.0 或 127.0.0.1 而非某個特定網卡。若服務跑在 Docker 裡，注意容器內的 localhost 跟主機的 localhost 不是同一個。

524 Timeout： 就是前面提過的 100 秒限制。解法是把長任務改成非同步，或改用 WebSocket。

DNS 沒生效： 確認網域的 NS 已經完全轉到 Cloudflare，而且 CNAME 指向的是 UUID.cfargotunnel.com。有時是瀏覽器或本地 DNS 快取，換個網路測測看。

憑證 JSON 遺失： 隧道憑證遺失就得重建隧道，建議把憑證檔納入備份，或改用 token 型態的安裝方式。

服務重開後隧道沒起來： 記得把 cloudflared 註冊成系統服務，並確認它有正確讀到設定檔路徑。

Tailscale Funnel 的常見狀況

Funnel 開不起來： 通常是 HTTPS 憑證功能沒在管理後台啟用，或 MagicDNS 沒開。這兩個是 Funnel 的前置條件，缺一不可。

網址打得開但很慢： 先確認是不是走了 DERP 中繼。可以在 tailscale status 或 tailscale netcheck 看連線路徑。另外 Funnel 本身的 ingress 就是比較慢，這是體質問題。

換了機器名，網址就變了： Funnel 的網址綁機器名，重新命名機器等於換網址。事先想好命名規則，別用 raspberrypi 這種之後會後悔的名字。

想關掉卻關不乾淨： 用 tailscale funnel --bg 開的要在背景模式關閉，否則它會一直常駐。記得檢查 tailscale funnel status。

想曝光非 443 端口： 不行。Funnel 只認那三個端口，而且都是 HTTPS。要曝光其他服務，請改用 tailscale serve 或直接走 tailnet。

曝光之後才是開始：安全性補強清單

很多人的自架服務是在「能連就好」的狀態下上線的，然後過幾週發現日誌裡一堆來自世界各地的掃描與嘗試登入。以下幾件事，請務必在曝光前後做足。

前置驗證與最小權限

能用邊緣驗證就用。Cloudflare Access 可以在請求到達你家機器前就攔掉未授權者，這是最有效的一層。Tailscale Funnel 沒有這層，所以你的應用程式登入機制必須足夠強——強密碼、MFA、避免預設帳號。

另外，服務本身請用低權限帳號執行，容器化時避免掛載不必要的目錄，資料庫不要用 root 連線。這些老話，但在曝光情境下格外重要。

日誌、速率限制與 WAF

Cloudflare 這邊有現成的 WAF 規則、速率限制、Bot Fight Mode 可以開，免費方案就有基本防護。至少把「登入失敗速率限制」設起來，能擋掉大部分暴力破解。

Funnel 這邊就得自己在應用層或反向代理（例如在機器上跑一層 Caddy 或 nginx）做限流。如果你用 Funnel 曝光的是有登入頁的服務，請務必確認它有登入失敗鎖定機制。

備援與監控

隧道服務掛掉時，你的服務等於從網路上消失。建議：

用 uptime 監控服務（Uptime Kuma 之類）從外部定期探測你的公開網址。

Cloudflare Tunnel 可設定多條連線提高可用性；Tailscale 則可考慮多台機器跑同樣的 Funnel 做備援。

把 cloudflared 與 tailscaled 都設成自動重啟，並確認開機順序不會讓它們比依賴的服務早起。

結語：這不是二選一，而是兩種信任模型的選擇

回到最初的問題：Cloudflare Tunnel 與 Tailscale Funnel，差在哪裡？

我的總結是這樣：Cloudflare Tunnel 是一套「對外發布平台」，Tailscale Funnel 是一扇「臨時對外的小門」。

如果你要的是正式對外提供服務——有自己的網域、需要身分驗證、需要分析數據、需要擋攻擊——Cloudflare Tunnel 是更完整的答案。它把 CDN、憑證、WAF、Zero Trust 這些本來要自己拼裝的東西，包成一套幾乎零成本的方案。

如果你要的是快速、臨時、低摩擦地把某個服務分享出去，或者你本來就是 Tailscale 的重度使用者、想要一個「順手就能開」的對外窗口，那 Funnel 的簡潔無可取代。

而對大多數自架玩家來說，真正的答案往往是兩個都用：用 Tailscale 打理你的私有網路，用 Cloudflare Tunnel 處理對公網的正式曝光，Funnel 留著當緊急備援。搞懂每個工具「擅長什麼、不擅長什麼」，比爭論哪個比較強，更能讓你的自架之路走得長久。

最後提醒一句：本文提及的方案細節、免費額度與端口限制，都可能隨服務商政策調整而變動。動手前請務必以官方文件為準，尤其是流量政策與資安相關設定，寧可多花十分鐘確認，也不要上線後才發現門開得太大。

希望這篇對正在猶豫的你有所幫助。如果你有不同的實戰經驗，歡迎在論壇回文交流——畢竟自架這條路，最好的老師永遠是別人的踩坑紀錄。

🏠 返回首頁