為什麼 Notion、Figma、Miro 需要獨立的 Clash 分流？

對設計師、產品經理與遠端團隊來說，Notion、Figma、Miro 已經不只是偶爾開啟的網站，而是每天持續使用的工作基礎設施。Notion 需要穩定載入頁面、圖片與資料庫內容，Figma 需要長時間維持檔案同步、多人游標與元件更新，Miro 則經常同時傳輸畫布、貼圖、附件與即時協作事件。只要其中一部分網域走錯出口，就可能出現「首頁能開、工作區載入不完整」「登入成功但檔案一直轉圈」「畫布打開了，貼圖與附件卻無法同步」等問題。

許多人遇到這些現象時，第一反應是更換節點或把整台電腦切換成全域代理。但全域模式雖然直觀，卻可能讓銀行、公司內網、國內影音服務與本地開發環境也繞遠路，造成速度下降、驗證失敗或 DNS 行為變得難以預測。更合理的做法是使用 Clash 分流：把 Notion、Figma、Miro 及其實際依賴的登入、靜態資源與 API 網域交給穩定的代理策略，同時讓國內網站與區域服務維持直連。

本文的重點不是提供一份永遠不變的網域清單，而是建立一套可以觀察、測試與維護的工作流。服務商可能調整 CDN、登入供應商與 API 主機，過度依賴幾條固定規則，反而會在版本更新後失效。因此，應先理解流量特徵，再利用 Clash 的連線紀錄驗證實際命中結果，最後才補充規則與 DNS 設定。

使用提醒：Clash／mihomo 是本機代理與規則管理工具，不會自行提供遠端節點。請使用合法、可信且符合服務條款的訂閱或網路出口；本文中的網域只適合作為排查起點，實際規則仍應以你自己的連線紀錄為準。

先拆解三種服務的流量結構

在建立配置以前，最好不要只把 notion.so、figma.com 或 miro.com 加進代理清單。現代 SaaS 服務通常由多個層次組成，主頁、登入、API、圖片、字型、附件與即時通道可能分散在不同主機。只代理一個主域名，常常只能解決「網站外框能顯示」，卻不能保證工作區真的可用。

  • Notion：常見流量包括 Notion 主站、登入與帳戶服務、工作區 API、圖片與檔案資源，以及嵌入內容。當頁面文字出現但圖片空白，或資料庫欄位一直顯示載入中，通常代表資源或 API 的實際主機沒有命中預期策略。
  • Figma：除了網站介面，還會涉及檔案資料、圖片縮圖、字型載入、評論通知與即時協作連線。Figma 的檔案可能可以開啟，但若協作游標停止、儲存狀態不更新，便要檢查長連線與背景 API，而不能只測試登入頁。
  • Miro：白板本身通常包含大量圖片、便條、附件與嵌入物件。載入速度慢不一定是節點延遲，也可能是某個 CDN 或檔案主機被分到不適合的出口，導致畫布主體先出現、內容卻逐項補載。

建議第一次排查時開啟 Clash 的 Connections 或「連線」頁面，依序登入三個服務、開啟一個實際工作區、拖動畫布或修改一段文字，再觀察新增的主機。記下三項資訊：完整網域、命中的規則名稱、最後使用的策略組。不要只看瀏覽器網址列，因為網址列顯示的主站與背景請求很可能完全不同。

測試動作 應觀察的結果 常見異常方向
登入帳戶 登入頁、驗證與回呼均能完成 登入主機未代理，或本機時間／瀏覽器 Cookie 異常
開啟既有檔案 文字、縮圖、附件可完整載入 API、圖片 CDN 或檔案主機命中 DIRECT
進行多人協作 游標、評論與儲存狀態持續更新 WebSocket、長連線或節點中途切換不穩

基礎配置：先建立可維護的服務策略組

如果你使用的是 Clash Verge Rev、Mihomo Party 或其他支援 Mihomo 核心的客戶端，可以先將協作工具集中到一個獨立策略組，例如 WORKFLOW。這樣做的好處是日後更換節點時不必逐條修改規則，也能在遇到 Figma 長連線不穩時，快速固定到一個已驗證的節點。策略組不宜一開始就加入過多節點，先挑選延遲合理、連線穩定且地理位置接近服務區域的選項即可。

YAMLproxy-groups:
  - name: WORKFLOW
    type: select
    proxies:
      - "工作節點 A"
      - "工作節點 B"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,notion.so,WORKFLOW
  - DOMAIN-SUFFIX,notion.site,WORKFLOW
  - DOMAIN-SUFFIX,figma.com,WORKFLOW
  - DOMAIN-SUFFIX,miro.com,WORKFLOW
  - MATCH,DIRECT

上面的配置只是最小骨架，不能視為完整的生產規則。DOMAIN-SUFFIX 適合先處理主域名及其子域名，但如果連線紀錄顯示圖片、附件或 API 使用另一個供應商域名，就要依實際結果增加更精確的 DOMAIN 或 DOMAIN-SUFFIX 規則。相比直接寫 DOMAIN-KEYWORD,google、DOMAIN-KEYWORD,cloud 這類寬泛條件，明確指定主機更容易避免誤代理與規則互相搶命中。

  1. 建立工作策略組：把一至三個已知穩定的節點放入 WORKFLOW，先不要使用會頻繁自動切換的組合。
  2. 加入最小規則：先加入三個服務的主域名，重新載入配置後，分別開啟 Notion、Figma 與 Miro 的實際工作區。
  3. 查看連線紀錄：把未命中或命中 DIRECT 的關鍵主機記錄下來，再逐項補充規則，而不是一次貼上來源不明的完整規則集。
  4. 逐個功能驗證：測試登入、檔案開啟、圖片載入、編輯儲存與多人協作，確認每一項功能都走到預期策略。

實務技巧：把三個服務分成獨立策略組也有助於定位問題。例如只有 Figma 需要固定節點時，可建立 FIGMA 組，而 Notion 與 Miro 繼續共用 WORKFLOW，避免為了單一服務更換整組工作出口。

TUN、DNS 與多設備：解決「瀏覽器能用，App 卻不行」

只開啟系統代理時，通常能處理遵循作業系統代理設定的瀏覽器與桌面應用程式，但不保證所有背景程序都會使用同一條路徑。Figma 桌面版、Miro 桌面版、Electron 應用程式、圖片上傳元件與企業安全工具，可能自行建立連線或忽略 HTTP 代理，於是出現瀏覽器正常、桌面版卻無法同步的分裂情況。

此時可以考慮啟用 TUN 模式，讓 Mihomo 在網路層接管較廣泛的流量。TUN 並不是「速度加倍」開關，而是改善應用程式代理相容性的工具。啟用前要確認客戶端已取得建立虛擬網卡所需的權限，並檢查系統中是否同時運行 VPN、企業端點防護或其他虛擬網路介面。多個網路接管工具同時存在時，路由優先順序可能互相衝突。

  1. 先確認基礎代理：在不開 TUN 的情況下，使用瀏覽器完成 Notion、Figma 與 Miro 的登入和檔案測試，確定訂閱、節點與規則本身沒有問題。
  2. 開啟 TUN：在客戶端設定中啟用 TUN 或增強模式，依系統提示完成管理員權限、網路擴充功能或虛擬網卡授權。
  3. 避免代理重疊：測試期間可先關閉系統代理，避免 HTTP 代理與 TUN 同時處理同一流量而形成迴路；若客戶端文件明確要求兩者並用，則依該版本的說明操作。
  4. 重新測試桌面版：完全退出並重新開啟 Figma 或 Miro，觀察連線是否出現在 Clash 的連線列表中，再測試檔案同步、圖片載入與多人協作。

DNS 是另一個容易被忽略的因素。若規則判斷依賴域名，而 DNS 先在本地解析到不可用或不適合的結果，即使後續流量選了代理，也可能遇到連線超時。可在 Mihomo 的 DNS 設定中選擇與自身網路環境相容的遠端解析方式，並留意 fake-ip、redir-host、Fake-IP 排除清單及局域網域名的差異。企業內網、印表機、NAS 與本地開發域名不應盲目交給遠端解析。

多設備使用時，建議把「規則邏輯」與「客戶端操作」分開管理。Windows、macOS、Android 可能使用不同客戶端，但可以共用一份經過整理的規則來源；另一方面，TUN 權限、系統代理開關、DNS 行為與電池限制仍需逐台檢查。手機上的 Figma 或 Miro 若在背景被系統暫停，表現出來的同步延遲未必是 Clash 問題，應先排除省電策略與 App 背景活動限制。

穩定性驗證與常見排錯順序

完成配置後，不要只以「首頁可以開啟」作為成功標準。協作工具真正重要的是持續工作能力，因此應安排一個短時間的壓力測試：在 Notion 開啟大型資料庫並編輯多個區塊，在 Figma 內移動元件、查看多人游標與載入字型，在 Miro 內拖曳物件、貼上圖片並邀請另一位成員進入。測試時固定使用同一節點，才能把規則問題與節點品質問題分開。

  • 登入失敗：檢查帳戶驗證相關主機是否命中代理，並確認系統時間、瀏覽器 Cookie 與第三方登入視窗沒有被阻擋。
  • 頁面載入但圖片空白：查看連線紀錄中的 CDN、圖片或附件主機；不要只重複刷新主頁。
  • 編輯內容無法儲存：檢查 API 請求是否走 DIRECT，以及策略組是否在編輯期間自動切換節點。
  • 多人游標消失：優先排查 WebSocket 或其他長連線是否被規則分流、DNS 解析不一致，或節點對長連線支援不佳。
  • 速度忽快忽慢：固定節點做對照測試，再比較不同地區出口與不同 DNS 模式，不要同時修改五項設定。
  • 國內網站變慢：檢查規則順序，確保國內網域、局域網與公司內部服務在工作流規則之前已被正確分配為直連。

規則順序尤其重要。Clash 通常採用由上至下的首次命中邏輯；如果前面已有寬泛的代理規則，後面新增的精確規則可能永遠不會生效。修改後應重新載入配置，清理必要的 DNS 快取，再從連線紀錄確認命中名稱，而不是只看 YAML 是否能成功儲存。若使用遠端規則集，還要記下規則集更新時間，避免本地測試結果與其他設備實際使用的版本不一致。

不要一次改太多：同時更換節點、DNS、TUN 堆疊與規則集，最後即使問題消失，也無法知道真正原因。建議每次只調整一個變數，並保留修改前的配置備份。

如果你需要在公司、家中與行動裝置之間切換，可以為「工作協作」「一般瀏覽」與「全直連」保留不同 profile。工作 profile 只放必要的 Notion、Figma、Miro 規則與穩定策略組，遇到服務商調整網域時更容易更新；一般瀏覽 profile 則避免過度代理。這種分層方式比一份不斷堆疊例外條件的超大型 YAML 更容易審查，也更適合日後交給團隊成員共同維護。

市面上不少同類工具要嘛只提供全域開關，遇到 Notion、Figma、Miro 這類多網域與長連線服務時就很難細分；要嘛介面偏向工程師，規則、DNS 與 TUN 選項分散在不同頁面，缺乏清楚的排錯脈絡。Clash 官網 的優勢在於把訂閱管理、策略選擇、連線觀察與分流思路放在同一套可理解的工作流程裡，讓你能依本文先建立最小規則，再透過實際連線紀錄逐步完善配置，而不是依賴猜測。如果你正準備為海外協作工具整理一套穩定的 Clash 工作環境，不妨前往免費下載 Clash 官網，先用熟悉的裝置完成測試，再把驗證過的規則延伸到其他設備。