Notion、Figma、Miro 都順了：Clash 辦公分流設定攻略

為什麼辦公工具值得獨立分流

Notion、Figma與Miro看起來都是「打開網頁、登入帳號、開始工作」的 SaaS 工具，但實際連線型態遠比單一網站複雜。Notion 可能同時涉及工作區頁面、圖片與檔案、即時同步及分享頁面；Figma 除了編輯器主頁，還會載入畫布資料、字型、圖片、留言與協作事件；Miro 則常在同一塊白板裡並行處理游標、便利貼、圖片、附件與多人操作訊息。只把瀏覽器首頁加入代理規則，並不代表整個工作流程都已經走上合適的出口。

對許多使用者而言，真正的問題不是「完全打不開」，而是載入一半、同步延遲或偶發重新連線。例如 Notion 頁面文字已經出現，圖片卻長時間顯示空白；Figma 可以開啟檔案，但縮放畫布時元件遲遲不出現；Miro 能進入白板，卻在多人同時編輯時不斷跳出連線恢復提示。這些症狀很容易被誤判成服務本身不穩，實際上可能是不同主機被分到不同策略、DNS 解析結果不一致，或長連線在某個出口上品質不佳。

因此，辦公分流的重點不是把所有流量一律交給代理，而是先建立工具、資源與本地服務的邊界。工作區與協作資料需要穩定出口時，讓相關網域命中同一個策略組；作業系統更新、公司內網、印表機與本地 NAS 則維持直連。這樣既能改善跨區服務的可用性，也不會因為一條過寬的規則，讓日常本地網站、視訊會議或內部系統全部繞遠路。

先分三類：工作區、資源與即時協作

建立規則前，建議把三個工具的流量先按功能分桶，而不是直接把搜尋到的網域整批貼進設定檔。第一類是工作區與控制平面，負責登入、工作區列表、檔案索引、權限與分享設定；第二類是靜態資源與檔案服務，包括圖片、縮圖、字型、附件、匯出檔及其他 CDN 內容；第三類是即時協作資料，涉及畫布事件、游標位置、留言更新或長時間保持的連線。三類流量不一定使用相同主機，也不一定在每次版本更新後保持完全不變。

以 Notion 為例，使用者常會先從 notion.so 或工作區自訂網域進入，但頁面中的圖片、檔案與分享內容可能來自不同的資源主機。Figma 的編輯器通常不只依賴 figma.com，還可能載入圖片、字型或其他資源；Miro 也可能因為白板附件與媒體內容而出現額外的網域。這裡不宜把「網路上某份固定清單」當成永久答案，因為服務供應商可能調整 CDN、登入流程或區域入口。更可靠的方式，是在你實際開啟文件、載入畫布與上傳附件時觀察 Clash 連線日誌，再逐步收斂清單。

規則順序同樣重要。若你先放了一條過寬的 DOMAIN-SUFFIX，後面再寫更精細的 DOMAIN，部分核心會依規則先後直接採用前面的結果，導致你以為「精確規則已經生效」，實際上流量早已被前一條攔走。一般可採用「本地與公司網域 → 明確的辦公服務網域 → 可信的資源後綴 → 其他流量」的順序，並把自訂工作區、公司登入入口與私人服務分開處理。

• 工作區與登入網域：先以連線日誌確認實際主機，再使用精確的 DOMAIN 規則。
• 同一服務的資源後綴：只有在確認不會涵蓋無關站點後，才考慮 DOMAIN-SUFFIX。
• 長連線或即時協作：確認客戶端核心與節點能穩定維持連線，不要只測一次首頁延遲。
• 公司內網與私有部署：優先使用 DIRECT、內部 DNS 或既有企業規則，避免被公共後綴規則誤送代理。

Clash 規則與策略組的實作思路

如果你使用 Clash Verge、Clash Verge Rev 或其他支援 Mihomo 的客戶端，建議先建立一個用途清楚的策略組，例如 WORK-COLLAB，再把 Notion、Figma、Miro 的規則集中指向這個組。策略組裡可以放一條穩定的代理、備用節點或 url-test 組，但不要把工作流服務直接散落到多個互不相干的節點名稱。集中管理的好處是：需要切換出口時只改一個地方，排查時也能快速確認三個工具是否真的使用同一套路徑。

proxy-groups:
  - name: WORK-COLLAB
    type: select
    proxies:
      - Stable-Proxy
      - Backup-Proxy
      - DIRECT

rules:
  - DOMAIN,notion.so,WORK-COLLAB
  - DOMAIN-SUFFIX,figma.com,WORK-COLLAB
  - DOMAIN-SUFFIX,miro.com,WORK-COLLAB
  - DOMAIN-SUFFIX,notion.site,WORK-COLLAB
  - DOMAIN-SUFFIX,公司內部網域,DIRECT
  - MATCH,PROXY

上面的片段只是結構示例，不能直接當成完整網域清單。首先，請把 Stable-Proxy、Backup-Proxy換成你的實際節點或既有策略組名稱；其次，根據連線日誌補上確實出現的資源主機；最後，確認你的核心是否支援設定檔中使用的策略組類型與欄位。不同客戶端可能提供覆寫、腳本或規則提供者功能，若訂閱更新會覆蓋本地 YAML，直接改主設定檔的做法就可能在下一次更新後失效。

對家庭多裝置而言，策略組名稱最好保持穩定，並把規則提供者與本地覆寫分層管理。桌面端可以用圖形介面手動測試，手機、平板與電視則常透過同一個局域網上的 Clash 或 Mihomo 核心共享配置。此時要特別留意：某個裝置能正常開啟 Figma，不代表其他裝置的 DNS、MTU、IPv6 或 TUN 路由也完全相同。建議先在一台主力電腦完成驗證，再逐一加入其他裝置，而不是一開始就讓整個家庭網路全面套用尚未確認的規則。

用真實工作流程驗證，而不是只測首頁

設定完成後，請依照實際工作順序測試。Notion 至少應測試登入、開啟含圖片的頁面、下載附件、編輯後等待同步，以及使用分享連結檢查未登入頁面；Figma 應測試開啟大型檔案、縮放與拖曳畫布、載入元件、邀請協作者、發送留言與匯出圖片；Miro 則應測試進入白板、移動多個物件、貼上圖片、邀請成員及在另一台裝置上確認更新。每一步都觀察 Clash 的連線日誌，記下主機名稱、命中規則、使用策略與是否出現連線重試。

若頁面能開但檔案同步不穩，先檢查是否有某些資源主機落入 MATCH 或直連；若畫布載入速度忽快忽慢，則比較不同節點在長連線與大檔案下載上的表現，不要只看短網址探針的毫秒數；若只有手機失敗，應檢查手機是否使用了另一組 DNS 或 IPv6 路徑。對於 TUN 模式，還要確認系統路由沒有同時被其他 VPN、企業安全軟體或舊代理客戶端接管，否則日誌裡看到的命中結果可能不是唯一影響因素。

DNS 是辦公分流中很容易被忽略的一層。當你使用 fake-ip、嗅探或遠端 DNS 時，瀏覽器看到的解析結果與系統工具顯示的結果可能不同；這本身不一定是錯誤，但必須確保規則匹配方式與核心設定相互配合。若你以 IP 規則取代網域規則，服務商一旦更換 CDN 位址，原有設定就會迅速失效。排障時應先確認網域是否被正確嗅探、規則是否命中，再考慮是否需要調整 DNS 模式，而不是一看到延遲就反覆更換節點。

1. 先清除瀏覽器快取或用私人視窗重現，排除舊登入狀態造成的假象。
2. 在 Clash 日誌中搜尋工具名稱、請求網域與 REJECT、DIRECT、MATCH 等結果。
3. 一次只增加一組規則，重新載入設定，再重做同一個工作流程。
4. 確認同步、上傳與協作事件都完成後，再把規則整理進長期使用的覆寫檔。

與只提供瀏覽器代理的擴充功能相比，Clash 能把桌面端多個應用程式、非瀏覽器連線與家庭裝置放進同一個可觀察的規則框架；而某些只支援全域開關的 VPN 工具，雖然上手簡單，卻很難對 Notion 附件、Figma 畫布與 Miro 即時協作做細緻分流。完成本文設定後，Clash V.CORE 可用清楚的策略組、規則命中紀錄與多裝置配置，把這些工作流服務維持在穩定出口，同時保留公司內網與本地服務的直連彈性；如果你希望少花時間處理覆寫與規則同步，現在就可以前往下載 Clash V.CORE，從一台主力工作裝置開始驗證。