Tailscale 的十月並不好過，但稱為「大規模故障」並不準確。2026 年 9 月 1 日至 10 月 31 日，其狀態頁記錄九宗事故，沒有一宗評為「重大」（major），控制面最長一次為 44 分鐘。真正拖了 41.7 與 48.0 小時的是 Funnel 公開 DNS，而官方更新寫明 tailnet 內部的 MagicDNS 與 Serve 不受影響。
拆開是三層問題：每月小病（協調服務、主控台、Funnel 輪流退化數分鐘至數小時）；長期 bug（MagicSock 接收迴圈停擺，最舊一宗四月開到十月仍未指派）；安全公告（10 月 26 日四份 TS-2026-014 至 017，兩日後在 1.104.4 修好，但都沒有 CVE 編號）。
六十日事故全表：九宗，零宗「重大」
資料取自 status.tailscale.com 的 Statuspage API（2026-10-31 10:07Z），時長由 ISO-8601 時間戳計算，非估算。
| 開始（UTC） | 事故 | 影響 | 時長 |
|---|---|---|---|
| 2026-09-01 12:47 | Funnel 連線問題 | major | 3 小時 31 分 |
| 2026-09-01 23:10 | SCIM 群組未更新 | none | 29 分 |
| 2026-09-16 06:43 | Iru 裝置 posture 整合失敗 | none | 2 小時 13 分 |
| 2026-10-01 13:12 | 協調服務：登入回 500 | minor | 44 分 |
| 2026-10-02 21:05 | Funnel 效能退化與逾時 | minor | 2 小時 55 分 |
| 2026-10-08 15:51 | 管理主控台登入錯誤 | minor | 6 分 |
| 2026-10-24 17:23 | Funnel 主機名公開 DNS 不解析 | minor | 41.7 小時 |
| 2026-10-27 14:16 | Funnel 公開 DNS 不解析（復發） | minor | 48.0 小時 |
| 2026-10-30 23:56 | 協調服務錯誤率上升 | minor | 44 分 |
DERP 中繼整段期間零事故。另需標明：九宗的 component 欄位皆空，上表分類依標題判斷，非官方標籤；八宗從未公布根因。
Funnel 兩宗個案：41.7 小時與 48.0 小時
10 月 24 日 17:23:30Z 起，Funnel 主機名的公開 DNS 取不到位址。Tailscale 於 19:52Z 稱已推設定變更、記錄恢復正常，但事故到 10 月 26 日 11:07:10Z 才結案，全程 41.7 小時（2,504 分鐘）。三日後重演：10 月 27 日 14:16:46Z 開始，全程只有一則「調查中」更新，10 月 29 日 14:17:31Z 直接結案，共 48.0 小時（2,881 分鐘），無修復說明，官方亦未表示兩宗同因。
官方描述值得逐字讀：「受影響裝置顯示 Funnel 已啟用、憑證有效，但公開 DNS 查詢不回位址……MagicDNS 與 Serve 不受影響。」獨立證據見 GitHub #21852：2026-10-19 15:42Z，報告者以 +norecurse 查 dnsimple 四個授權伺服器，對 A 與 AAAA 一律回 authoritative NXDOMAIN——問題在伺服器端授權區。
澄清：出問題的不是 MagicDNS
不少中文轉述寫成「MagicDNS 掛了」，與官方文字相反。MagicDNS 是 tailnet 內部的解析，由客戶端經 100.100.100.100 處理；十月兩宗壞的是 ts.net 公開 DNS，即外部訪客能否經 Funnel 網址連入。服務只供內部使用，那兩天你不會察覺；同事經互聯網進入則見「找不到網域」，而 tailscale status 與 funnel status 都顯示正常——#21114 的報告者指出兩者都在說謊。
長期 bug 一：MagicSock ReceiveIPv4／ReceiveDERP 集群
目前最集中的未修問題，共通點是資料面停擺、控制面仍顯示 Connected。
- #20616（macOS 1.98.8）：開機後 ReceiveIPv4 停止且不重試，健康檢查顯示「The MagicSock function ReceiveIPv4 is not running」。
- #21832（iOS 1.104.1）：ReceiveDERP 停止，VPN 仍顯示 Connected，切換 VPN 可暫復；12 日 21 則留言，期內最活躍。
- #19504（iOS 1.96.5）：同族的 ReceiveIPv4 停擺，六個月 28 則留言，仍開放。
- #22082（macOS App Store 版）：換網後直連 UDP 不再建立，對端留在 DERP；兩端 tcpdump 見 disco ping/pong 已到 en0 卻未處理。
四宗皆無指派、無 changelog 承認。可行復原只有結束應用再開：tailscale down／up、debug rebind、debug restun 均無效。
長期 bug 二：Funnel NXDOMAIN 仍未關閉
#21852 是客戶端視角的同一症狀，2026-10-22 後無新活動，價值在時間戳：事故頁仍寫「調查中」時，授權區確實對存在的名稱回 NXDOMAIN。另一宗 #21114（Funnel 在協調服務重連後停止服務）已由工程師 bcreane 接手。
長期 bug 三：macOS 上載 23 Mbps、下載 890 Mbps
#20898（2026-08-17 開）在 2.5GbE 區網、直連下量得上載約 23 Mbps、下載約 890 Mbps，原生區網為 2.35 Gbps；報告被標為 T3 Performance/Debugging。近 39 倍的方向不對稱，已超出加密開銷可解釋的範圍。
v1.104.4 與 TS-2026-014～017 四個公告
四份公告在 10 月 28 日的 1.104.4 全部修好。
| 編號 | 元件 | 影響 |
|---|---|---|
| TS-2026-014 | SSH 轉送 | 具轉送權限的對端可經特權 -L 撥號、以 -R 替換 root socket，接觸 Docker socket 與 tailscaled 本機 API |
| TS-2026-015 | SSH 工作階段 | 連續 window-change 與 env 附加令記憶體無上限增長，OOM 殺掉 tailscaled |
| TS-2026-016 | Serve 的 Unix 後端 | TCP→Unix 轉送以 root 撥號，可達任意 root-only socket，官方稱可致「full node takeover」 |
| TS-2026-017 | Serve 的 HTTP/2 | 多個 mount 共用 serve context，capability 可能送到未授權的 mount |
四份都沒有 CVE、沒有 CVSS，也沒有「已被利用」的說明。GitHub Advisory Database 對 tailscale/tailscale 只有三筆，全屬 2022 至 2023 年（CVE-2022-41924 評分 9.6、CVE-2022-41925 評分 3.8、CVE-2023-28436 評分 5.7），2026 年一筆也未同步。任何「CVE-2026-xxxxx」都是編造；沒有 CVE 不等於風險低。
「full node takeover」到底是什麼意思
最強的字眼在 TS-2026-016：Serve 的 Unix socket 後端可令本機 API 暴露給遠端，官方形容為「full node takeover」。前提是本機操作者能寫 serve 設定，或本機使用者能寫入後端路徑；它不是未經驗證即可利用的遠端漏洞，而是把「本機可寫設定」放大成 root 級撥號與節點接管。TS-2026-014 的入口是 SSH 轉送：政策允許 forwarding 時，對端可接觸 Docker socket 或 tailscaled 本機 API。未及升級者設 TS_SSH_DISABLE_FORWARDING=1 並重啟，只關轉送不關 SSH，正解仍是 1.104.4。
版本時間線
| 版本 | 日期 | 重點 |
|---|---|---|
| 1.102.5 | 2026-09-29 | Linux 客戶端落後時不再停掉 tailscaled，改為重連 |
| 1.104.1 | 2026-10-07 | Go 1.27、netmap 快取、DNS 修正；停止支援 macOS 12、iOS 15 |
| 1.104.2 | 2026-10-21 | Go 1.27.3 應對 TS-2026-013；修正 Windows 重複斷線與 DNS 解析器行為 |
| 1.104.4 | 2026-10-28 | 安全版本，修好 TS-2026-014 至 017 |
1.102.5 的 changelog 標題寫 2026-10-05，GitHub 發布時間為 2026-09-29，兩者未對齊。1.104.0 為測試候選、1.104.3 屬內部版本。
讀者自查清單
- 執行 tailscale version；有用 SSH 轉送或 Serve Unix 後端，1.104.4 是底線。
- 未及升級，先在 tailscaled 服務環境設 TS_SSH_DISABLE_FORWARDING=1 再重啟。
- 檢查 ACL 是否對一般使用者開放 forwarding。
- 「Connected 但完全不通」：查 tailscale status –json 的 LastHandshake 與 RxBytes；tailscale ping 不足，改用 –tsmp。
- macOS MagicDNS 短暫停頓（#21733）：dscacheutil -flushcache; killall -HUP mDNSResponder。
- Funnel 對外不通而內部正常：外部 dig +norecurse 查 ns1.dnsimple.com，看是否回權威 NXDOMAIN。
常見問題
Tailscale 十月是否發生大規模故障？
沒有。八宗 minor、一宗 none，唯一 major 是 2026-09-01 的 Funnel 連線問題（3 小時 31 分）。十月最長的是 Funnel 公開 DNS 的 41.7 與 48.0 小時。
這些公告為什麼沒有 CVE 編號？
Tailscale 以自家 TS-2026-0xx 編號發布，10 月的六份公告都沒有 CVE 與 CVSS，Advisory Database 亦未收錄。這不代表風險低，只是沒有通用識別碼可搜，嚴重程度要看公告本文。
只用一般連線，沒開 SSH 或 Serve，要做什麼？
四份公告的前提都用不到你的設定。仍建議升到 1.104.4，它包含 1.104.1 與 1.104.2 的 DNS、netmap 與 Windows 斷線修正。
Funnel 出事時，tailnet 內部連線會斷嗎？
不會。官方文字明言 MagicDNS 與 Serve 不受影響，失敗的只有公開 ts.net DNS。對外分享的 Funnel 網址則無法解析。
你目前跑的是哪個版本？若曾遇過「顯示 Connected 但完全不通」，歡迎留言說明平台與版本，我可以把個案對應到這幾條 issue 編號。
分類：Technology
標籤：Tailscale · 網絡安全 · 服務事故 · MagicDNS · Funnel · VPN · 開源 · 安全公告
