Tailscale vs WireGuard：跨設備 Mesh VPN 私網互聯評測
而 WireGuard 與 Tailscale，正好代表了這個思路的兩種實現層次：一個是「給你最底層的積木，你自己拼」，另一個是「幫你把積木拼好，還附上說明書與自動修復」。
二、底層原理拆解：WireGuard 與 Tailscale 不是同一個層級的對手
在進入實測之前，必須先澄清一個常見誤解。很多比較文章把這兩者寫成「二選一的競品」，但嚴格說起來，它們解決的是不同層級的問題。搞清楚這件事，後面的選型邏輯才會清楚。
WireGuard：極簡主義的加密隧道協議
WireGuard 是一個運行在 UDP 之上的加密隧道協定，2018 年正式進入 Linux 核心，目前已有 Windows、macOS、iOS、Android、BSD 的原生或官方實作。它的設計哲學可以用一句話概括：用最少的程式碼，做最正確的事。
它的技術特徵相當明確：
但 WireGuard 刻意「不做」的事情也很多。它沒有內建金鑰分發機制、沒有 NAT 穿透、沒有節點發現、沒有 ACL 權限系統、沒有 DNS 整合。這些全部要你自己來。換句話說，WireGuard 給你的是「一條加密隧道」，而不是「一個網路」。
打個比方：WireGuard 像是給了你一條條電話線，但誰該打給誰、電話號碼怎麼分配、誰有權打給誰，全部得你自己寫在紙上，而且每換一個號碼就要重寫一次。
Tailscale：把 WireGuard 變成「零設定」網狀網路
Tailscale 的做法是：資料層直接用 WireGuard，控制層自己實作一套協調服務。它把上述 WireGuard 缺席的那些功能全部補上：
MagicDNS：每個節點自動獲得一個固定網域名稱，不用記 IP。
所以正確的理解方式是：Tailscale 不是 WireGuard 的替代品，而是 WireGuard 的作業系統。它的價值不在加密本身（加密是 WireGuard 做的），而在於把「維運一個跨地域私網」這件麻煩事自動化。
控制平面與資料平面的分工
把架構用一句話拆開：
理解這個分工之後，你就會明白為什麼「Tailscale 比較慢」這個說法只在一部分情境下成立——因為它慢的地方通常不是協定本身，而是實作方式與中繼路徑。
三、實測環境與測試方法
為了讓數據有參考價值，先把環境講清楚。所有測試都重複三次取中位數，並排除單次極端值。
硬體與網路環境說明
軟體版本方面，WireGuard 使用 Linux 核心態模組 1.0.2023 系列；Tailscale 使用 1.5x 系列客戶端，Linux 端啟用核心態 WireGuard 加速。兩邊的 MTU 都設為 1420 作為基準，避免因分段造成誤差。
測試項目與指標定義
本次評測鎖定五個面向：
四、五項核心指標實測對比
1. 初次設定時間與配置複雜度
這一項的差距，是整篇評測中最懸殊的部分。
純 WireGuard 自架流程（以兩台設備互通為例）：
wg genkey | tee privatekey | wg pubkey > publickey 產生金鑰對。把雙方的公鑰互相交換（用 Clipboard、加密訊息或 SSH 傳遞）。
wg0.conf，在 [Peer] 區段填入對方公鑰、Endpoint、AllowedIPs、PersistentKeepalive。啟動介面 wg-quick up wg0，測試連通。
如果雙方都在 NAT 後方，還得額外部署一台有公網 IP 的中繼節點，並確認轉發設定正確。
兩台設備，熟悉的狀況下大約 10 到 15 分鐘可以搞定。但這個數字會隨節點數量呈非線性成長——因為每加一台設備，理論上都要跟所有既有節點交換一次金鑰、補一次設定。N 台設備需要維護 N×(N-1)/2 組 Peer 關係，六台就是 15 組。這也是為什麼大型 WireGuard 部署通常會搭配自動化腳本或設定管理工具。
Tailscale 流程：
兩端安裝客戶端。
tailscale up，瀏覽器跳出登入頁，用 Google 帳號登入。完成。
實測六台設備（含 CGNAT 後的樹莓派）從安裝到全部互通，總共花了約 12 分鐘，其中大部分時間是在等 NAS 套件安裝與手機 App 下載。設定本身幾乎是零。
值得一提的是，Tailscale 的節點數量成長幾乎不增加設定負擔——第 50 台設備加入的流程，跟第 2 台一模一樣。這一點在實務上的價值極高，尤其是當你要幫家人或同事加入設備時，不需要在電話裡教他們怎麼貼公鑰。
2. 直連打洞成功率與延遲表現
這是 Mesh VPN 的靈魂所在。以下是六個節點之間的實際路徑判定結果：
結果相當有意思。六組中有五組成功直連，只有 D ↔ E 這一組退回 DERP 中繼。推測原因是兩端都缺乏穩定的可預測埠映射（一端 CGNAT、一端是共享 VPS 網路），握手的時序對不上。
但這裡有一個關鍵補充：在純 WireGuard 架構下，D ↔ E 這組根本連不起來，除非額外再架一台中繼。而 Tailscale 只是默默地降到 61ms，使用者完全無感。這就是「多花的那一點架構複雜度」換來的實際價值。
至於 A ↔ D 那組打洞成功，延遲 8ms 算是相當漂亮，跟同城市固網直連的水準接近。實測時我反覆重啟兩端服務十次，成功直連九次，打洞穩定度算高。
要查看目前的連線狀態，可以在任一節點執行 tailscale status，輸出中會標註 direct 或 relay "tok" 之類的字樣，這對於排查「為什麼這麼慢」非常有用。
3. 吞吐量與 CPU 佔用（含 DERP 中繼對照）
吞吐量測試使用 iperf3，分別測 TCP 單執行緒與四執行緒。以下是關鍵結果：
幾個觀察：
第一，直連狀態下 Tailscale 與原生 WireGuard 的差距比想像中小。在 A↔E 這組，差距約 27%，主要原因不是協定開銷，而是東京端 VPS 跑的是 userspace 版 WireGuard（wireguard-go），少了核心態的零拷貝與 GSO 加速。如果把兩端都換成支援核心態的 Linux 客戶端，差距會進一步縮小——A↔B 那組跑到 1.42 Gbps 就是證明。
第二，DERP 中繼的效能落差非常明顯。從直連的 648 Mbps 掉到 78 Mbps，只剩約八分之一。這代表中繼是「保命機制」而不是「常態路徑」。如果你的節點常常落在中繼狀態，傳大檔就會非常痛苦。診斷方法很簡單：tailscale status 看看有沒有 relay 字樣，或是在 tailscale netcheck 中檢視 UDP 是否被封鎖。
第三，CPU 佔用是隱形成本。Tailscale 在 userspace 模式下，每個封包都要經過使用者空間與核心空間的上下文切換，CPU 消耗明顯較高。在低功耗設備（例如樹莓派 Zero 或老舊路由器）上，這可能成為實際瓶頸，反而不如直接用核心態 WireGuard 來得省資源。
順帶一提，Tailscale 從 1.54 版開始在 Linux 上提供核心態加速選項，可以透過環境變數或設定啟用。如果你的節點是 Linux 且 CPU 較弱，这个設定值得花時間調一下。
4. 行動網路切換與 Roaming 穩定度
對行動裝置使用者來說，這一項比吞吐量更重要。測試方式是：手機開著持續 ping 桌機，然後在 Wi-Fi 與 5G 之間來回切換五次，記錄掉包數與恢復時間。
PersistentKeepalive 週期或下一次發送封包才會更新端點。實測恢復時間約 3 到 8 秒，期間掉包 4 到 11 個。若有開啟 Endpoint 自動更新則表現好些。差異的來源在於 Tailscale 的控制層會持續監控網路介面狀態變化，一旦偵測到 Wi-Fi 斷開或行動網路切換，就立即觸發路徑重協商。原生 WireGuard 則是「被動」等封包觸發，所以延遲較長。
這個差距在一般使用下可能無感，但如果你經常在移動中保持 SSH 連線、遠端桌面或遊戲串流，那 3 秒與 1 秒的差別就是「連線斷掉要重連」與「只是卡一下」的差別。
5. 安全性與金鑰管理審視
安全性要分兩個層次看：加密強度與信任模型。
加密強度方面，兩者其實站在同一條線上。Tailscale 的資料層就是 WireGuard，用的是同一套 Curve25519 + ChaCha20-Poly1305 組合。所以「Tailscale 比較不安全」這種說法，在封包加密層面並不成立。DERP 中繼也只轉發加密後的封包，中繼伺服器看不到明文。
真正的差異在信任模型。純自架 WireGuard 是完全自治的——金鑰在你手上，沒有第三方知道你的節點清單、IP、甚至連線時間。Tailscale 則需要信任它的協調伺服器，因為：
協調伺服器知道你有哪些節點、各自的公鑰、以及大致位置（透過 IP 推斷）。
ACL 政策、裝置授權、使用者身分都存放在雲端。
對大多數個人使用者來說，這個信任成本可以接受，畢竟 Tailscale 是開源且有第三方稽核的商業公司。但對企業、記者、或對隱私極度敏感的人來說，這就是一個必須認真評估的取捨。後文會討論自架控制平面的替代方案。
另外提醒一點實務細節：不要把 Tailscale 當成「對外服務的替代品」。它的定位是私網互聯，不是公開網站託管。雖然有 Tailscale Funnel 可以對外暴露服務，但那需要額外設定且有其風險，不要因為方便就隨手把 NAS 管理介面開上去。
五、功能面差距：Tailscale 多出來的那些東西值不值得
除了效能與連線品質，功能面的差異往往才是真正決定「用起來爽不爽」的關鍵。
MagicDNS、ACL 與身份驗證
MagicDNS 是我認為最被低估的功能。它讓每台設備自動獲得一個像 nas.tailnet-name.ts.net 這樣的名字，不用記那串 100.x.y.z 的 CGNAT 位址，SSH 設定檔、瀏覽器書籤、內部服務設定全部可以直接寫域名。這聽起來很小，但實際上大幅降低了日常使用的摩擦。
ACL 存取控制則是把「誰能連誰」集中管理。你可以用一份 JSON 或 HuJSON 設定檔定義：
tag:server 的節點，只允許來自 tag:admin 的 22 埠連線。家人使用的設備只能存取特定的媒體伺服器。
訪客裝置只能上網，不能碰到任何內網資源。
這種以「身份」而非「IP」為基礎的控管，在設備經常更換 IP 的環境下非常實用。純 WireGuard 要做到同等效果，得靠 AllowedIPs 配合 iptables 或 nftables 規則，可讀性與維護性都差很多。
至於身份驗證與裝置授權，與 SSO 整合後可以設定裝置金鑰過期時間、強制重新認證，甚至能遠端撤銷遺失裝置的存取權。這在多人團隊裡是剛需。
子網路路由、Exit Node 與 Funnel
Subnet Router（子網路路由） 讓你可以把「整個實體區網」帶進 Tailnet。比如說，你家的印表機、智慧家電、或 NAS 上跑的另一個網段，只要能從一台已加入 Tailscale 的機器連到，就可以透過 --advertise-routes 廣播出去。這等於不用在每台設備都裝客戶端，就能存取整個內網。
Exit Node（出口節點） 則是反過來用：讓遠端設備的所有對外流量都經過某一台機器。典型用途有兩個——出國時把流量導回台灣，繞過地區限制；或在公用 Wi-Fi 環境下，把流量透過自家線路加密出去。這功能在原生 WireGuard 上也能做，但設定 AllowedIPs 為 0.0.0.0/0 後還要處理 DNS 與防火牆，麻煩不少。
Tailscale Funnel 可以把 Tailnet 內的服務以 HTTPS 形式對外公開。老實說這個功能爭議不小，因為它打破了「私網不對外」的預設；但如果只是要給朋友臨時看個檔案或 demo，確實方便。使用前務必想清楚風險。
那些 Tailscale 沒給你的（自架選項：Headscale / NetBird / Nebula）
如果你認同 Mesh 的價值、但不想把控制平面交給第三方，有幾條路可以走：
這幾個方案各有取捨，但共同點是：你省下了信任第三方的成本，換來的是自己維運控制平面的責任。伺服器掛了、憑證過期了、版本升級出問題了，都得自己處理。值不值得，取決於你的技術意願與風險偏好。
六、費用、隱私與長期維運成本
免費額度與企業方案
Tailscale 的免費方案對個人使用者相當大方，涵蓋多數家用自架場景（節點數量與使用者數有上限，但對家庭來說通常遠遠夠用）。企業方案則按使用者數計費，並額外提供 SSO、裝置管理、稽核日誌、ACL 進階功能等。
純 WireGuard 的軟體本身完全免費，但你「隱形成本」可能更高：
如果需要在 CGNAT 環境下有穩定中繼，得租一台 VPS，一年下來是實打實的支出。
設定與排錯的時間成本。以時薪換算，前幾次建置花掉的時間可能就超過好幾年的訂閱費。
節點數量成長後的維護成本。每次換設備、換 ISP、換 IP，都要手動調整設定。
所以「WireGuard 免費」這個說法要打個折扣——它免費的是授權，不是總持有成本。
依賴第三方協調伺服器的風險
使用 Tailscale 意味著你的私網在某種程度上依賴一家公司的服務持續運作。實際風險包括：
資料可見性：如前述，節點清單與連線中繼資料會經過對方伺服器。
實務上的緩解做法：把關鍵服務同時保留一條純 WireGuard 的備援路徑，或者直接評估 Headscale 自架。雞蛋不要放在同一個籃子裡，這個原則在網路架構上永遠適用。
七、選型建議：什麼人該用哪一套
直接用 WireGuard 的情境
至少一端有穩定公網 IP：這樣不需要打洞與中繼，架構可以極簡。
完全不想依賴第三方：金鑰與節點資訊百分之百自己掌握。
該選 Tailscale 的情境
需要行動裝置支援：手機、筆電的 Roaming 體驗明顯較好。
不想花時間維運：設定一次、忘記它存在，是很多人最真實的需求。
團隊協作場景：多人共用、需要 SSO 與裝置管理。
混合架構的實務做法
其實這兩者不必二選一。我自己目前的架構就是混合的：
這種做法把兩者的優勢都吃到了：日常使用的便利性交給 Tailscale，效能與自主性交給 WireGuard。設定上也不算複雜，因為固定鏈路只有少數幾條，維護負擔有限。
另外補一個小技巧：Tailscale 支援設定 --advertise-routes 時把 WireGuard 所在的網段也放進去，這樣其他 Tailnet 節點也能透過它存取那條固定隧道後的資源。等於用 Tailscale 當「前端接入層」，WireGuard 當「骨幹傳輸層」。
八、結語：不是誰打敗誰，而是問題層級不同
回顧整篇評測，最重要的結論其實在第一段就說了：WireGuard 是協定，Tailscale 是產品。把它們放在一起比「誰比較好」，有點像在問「引擎跟整台車哪個比較好」——答案取決於你是要造車，還是要開車。
純 WireGuard 給你的是一條乾淨、高效、可完全掌控的加密隧道。它的效能上限最高，依賴最少，但也把所有的複雜度都留給你自己。當節點數量少、環境單純、你又願意花時間維護時，它依然是最優雅的選擇。
Tailscale 則是在 WireGuard 之上補上了整套「網路作業系統」：金鑰分發、NAT 穿透、DERP 中繼、MagicDNS、ACL、Subnet Router、Exit Node。它用一點效能與信任成本，換來大量的便利性與穩定性。對於節點分散、環境複雜、又不想天天調設定的現代使用者來說，這個交易通常划算。
實測數據也支持這個判斷：在直連狀態下，Tailscale 的效能損失約在 20% 到 30% 之間，且隨著核心態加速的普及正在縮小；而它在打洞成功率、Roaming 恢復速度、設定效率上的優勢，則是純 WireGuard 短期內很難補上的。至於 DERP 中繼那八倍的效能落差，則提醒我們：中繼是保險，不是常態，如果發現自己經常落在中繼路徑上，該做的不是換工具，而是檢查為什麼打洞失敗。
最後給正在猶豫的人一句實用建議：如果你不確定該選哪個，先裝 Tailscale 用兩週。它幾乎零成本、零風險，用起來的體感會直接告訴你答案。等你真的碰到它的天花板——效能不足、隱私顧慮、或想自架控制平面——那時候你對 WireGuard 的需求也會變得非常具體，學起來反而更快。