Clash 打造 Notion、Figma、Miro 流暢協作的分流方案

先拆解協作流量:為什麼三個平台需要獨立分流

Notion、Figma、Miro 都屬於雲端協作工具,但實際產生的流量並不只有「打開網頁」這一種。Notion 會載入頁面資料、圖片、檔案與嵌入內容,編輯時還會持續進行同步;Figma 除了介面資源,還依賴即時協作、字型、圖片與原型預覽服務;Miro 則大量使用白板資料、游標狀態、留言、附件以及 WebSocket 長連線。只把瀏覽器設成全域代理,雖然有機會立即改善載入,卻會讓本地網站、公司內網、印表機和其他不需要代理的服務一起繞道,延遲與流量消耗都會增加。

更合適的做法是建立一個「協作平台」策略組,只把確認需要代理的雲端工作流送往這個策略組,其他流量繼續依照既有規則直連。這種分流方式有三個好處:第一,登入、頁面載入與同步連線使用相同的出口,不容易因地區或網路路徑不同而互相干擾;第二,本地服務與海外協作平台分開,開會、列印、存取區網檔案時不必反覆切換全域模式;第三,問題更容易定位,可以在 Clash 的連線記錄中確認究竟是網域沒有命中、策略組節點不穩,還是 DNS 或 WebSocket 被錯誤處理。

開始前先確認用戶端使用的是 mihomo 核心。Clash Verge Rev、部分新版 Clash Verge 與其他基於 Clash Meta 的用戶端通常支援 GEOSITE、RULE-SET、TUN 和網域嗅探,但不同版本的設定欄位仍可能略有差異。若使用的是停止維護的原版 Clash,請優先採用明確的 DOMAIN-SUFFIX 規則,不要直接貼上依賴 mihomo 專屬欄位的完整設定。

建立協作策略組:先解決節點選擇問題

三個平台的穩定度通常比單次下載速度更重要。Notion 編輯頁面、Figma 多人游標和 Miro 白板都需要持續連線,節點若頻繁切換,可能出現登入失效、畫面停在載入中、游標消失或修改延遲寫回等現象。因此建議先建立一個獨立的 WORKFLOW 策略組,讓 Notion、Figma、Miro 共用同一個出口,再視實際情況拆成不同策略。

proxy-groups:
  - name: WORKFLOW
    type: url-test
    proxies:
      - "節點-香港-01"
      - "節點-日本-01"
      - "節點-新加坡-01"
    url: "http://www.gstatic.example/generate_204"
    interval: 300
    tolerance: 80
  - name: WORKFLOW-MANUAL
    type: select
    proxies:
      - WORKFLOW
      - "節點-香港-01"
      - "節點-日本-01"
      - DIRECT

上面的網址只是格式示意,請替換成你所使用服務商提供的測試網址或現有設定中的健康檢查網址,不要照抄不存在的示例位址。url-test 會按照週期測試候選節點並選擇延遲較低者,interval: 300 代表約五分鐘檢查一次;tolerance: 80 則表示目前節點沒有明顯落後時,不會因幾毫秒差異頻繁切換。若協作中途不希望自動換節點,可以只使用 select,手動固定一個穩定出口。

節點選擇不要只看面板顯示的延遲。健康檢查通常只測一個網址或 TCP 連通性,不能代表 Figma 原型預覽、Miro 長連線或檔案上傳一定順暢。實際測試時可分成三組情境:

• 編輯穩定性:在 Notion 建立測試頁面,連續輸入、拖曳區塊並重新整理,觀察修改是否能在幾秒內同步完成。
• 即時協作:在 Figma 或 Miro 開啟同一份檔案,讓另一個裝置移動游標、編輯物件或新增留言,確認畫面更新沒有長時間停頓。
• 檔案傳輸:上傳一張中等大小的圖片或設計素材,比較不同節點的上傳時間與失敗率,不要只測首頁載入時間。

如果某個節點首頁很快,但 WebSocket 或檔案上傳經常中斷,就不要把它放進 WORKFLOW 的候選清單。對協作工具來說,穩定保持連線通常比瞬間峰值速度更有價值。

規則分流寫法:網域、程序與順序一起處理

規則必須放在 MATCH 之前,因為 Clash 會由上到下比對,第一次命中後立即停止。實際使用時,建議把平台官方文件列出的主網域與資源網域整理成規則集,並在 Clash 連線記錄中補齊漏掉的網域。以下使用保留名稱示範結構,其中 notion-workspace.example、figma-assets.example 與 miro-realtime.example 不是可直接連線的真實網域,請替換成你從連線記錄確認過的實際後綴。

rules:
  - DOMAIN-SUFFIX,notion-workspace.example,WORKFLOW
  - DOMAIN-SUFFIX,notion-sync.example,WORKFLOW
  - DOMAIN-SUFFIX,figma-assets.example,WORKFLOW
  - DOMAIN-SUFFIX,figma-realtime.example,WORKFLOW
  - DOMAIN-SUFFIX,miro-board.example,WORKFLOW
  - DOMAIN-SUFFIX,miro-realtime.example,WORKFLOW
  - GEOIP,PRIVATE,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

不要只加入三個首頁網域。首頁可能可以打開,但圖片、字型、API、附件或即時通訊會從其他網域載入。以瀏覽器開發者工具查看請求,或直接在 Clash 的連線頁面搜尋平台名稱,把狀態為 timeout、reset、failed 的相關請求記下來,再逐一確認它們是否屬於協作平台。不要因為網域名稱含有相似關鍵字就全部加入,廣泛使用 DOMAIN-KEYWORD 容易把無關服務誤送到代理。

用規則集降低維護成本

如果訂閱或設定檔支援 rule-providers,可把協作平台規則獨立成一份規則集,之後只更新規則集而不必反覆改主設定。規則集的內容仍應由可信來源維護,並確認格式與核心相容。下面是結構範例:

rule-providers:
  workflow:
    type: http
    behavior: domain
    format: yaml
    url: "https://rules.example/workflow.yaml"
    path: ./ruleset/workflow.yaml
    interval: 86400

rules:
  - RULE-SET,workflow,WORKFLOW
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

示例中的規則網址只是佔位格式,請換成實際可用且你信任的規則來源。若來源使用純文字格式,要把 format 改成對應值;若核心不支援 format 或 RULE-SET,就退回手寫 DOMAIN-SUFFIX。規則集更新失敗時,Clash 可能繼續使用舊檔,所以更新後要查看時間戳與錯誤記錄,不能只看設定檔已經成功載入。

DNS、TUN 與 WebSocket:同步不穩定時的三個關鍵設定

分流規則正確,不代表連線一定穩定。協作平台常見的問題來源是 DNS 回傳錯誤位址、瀏覽器流量沒有進入 Clash,以及即時通訊連線被中途設備重置。桌面環境若使用 mihomo,可以先採用 TUN 加 DNS 接管的方式,讓不遵循系統代理的程序也能進入同一套規則。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
    - "time.*"
  respect-rules: true
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://dns.example/dns-query
  proxy-server-nameserver:
    - https://dns-proxy.example/dns-query

dns-hijack 會把裝置發往 53 埠的 DNS 查詢導入 Clash;fake-ip 則讓 Clash 依原始網域保留分流判斷,避免應用程式先取得真實位址後只剩 IP 可比對。respect-rules: true 可讓 DNS 解析方向參考規則,但這些欄位是否完整支援,仍要以目前 mihomo 版本和用戶端設定編輯器為準。default-nameserver 應填純 IP,它負責啟動時解析加密 DNS 上游的網域,不要把 DoH URL 填進這個欄位。

若開啟 fake-ip 後,公司內網名稱、NAS、區域印表機或本地開發環境異常,先確認它們是否屬於 lan、local 等網域,必要時加入 fake-ip-filter。若問題只發生在某個特定程式,可暫時切換到 redir-host 做對照測試。這不是永久解法,而是用來判斷故障是否由 fake-ip 相容性引起。

即時同步與長連線的檢查方法

Figma 和 Miro 的即時協作通常需要長時間保持的 HTTPS 或 WebSocket 連線。當頁面載入成功,但多人游標、留言或畫布更新停止時,不要立即改 DNS。先在 Clash 連線記錄中找出該平台的長連線,確認它命中的策略組是否為 WORKFLOW,以及連線是否反覆出現 closed、timeout 或 connection reset。若每隔固定秒數斷線,可先換一個節點測試;若所有節點都一樣,再檢查瀏覽器擴充功能、公司防火牆與系統時間。

• 不要同時啟用兩個 VPN、另一個 TUN 工具或瀏覽器專屬代理,多層接管容易造成路由迴圈。
• 確認系統時間自動同步。TLS 憑證驗證與部分登入流程對時間誤差很敏感。
• 若只是不斷重新登入,檢查瀏覽器是否阻擋第三方 Cookie、網站儲存空間或企業安全擴充功能。
• 若只有附件上傳失敗,把上傳相關網域從連線記錄中補入規則,不要直接把整個瀏覽器改成全域模式。

三種工作情境的實際調校方式

完成共同的 WORKFLOW 分流後,可以依平台特性做細分。日常建議先維持一個策略組,等收集到一至兩天的連線記錄後再拆分。過早建立太多策略組,會讓問題變成「到底是哪個群組出錯」,反而增加排查時間。

Notion:重點是頁面、附件與同步出口一致

Notion 若出現文字能輸入但重新整理後消失,先不要判斷為資料遺失。查看連線記錄,確認同步請求是否曾經逾時,再用固定節點重新開啟頁面測試。頁面主站、附件儲存與登入請求若被分到不同出口,可能造成 Cookie 或地區判斷不一致。將已確認的主網域、同步網域和附件網域放入同一個 WORKFLOW 策略組,通常比單純提高頻寬更有效。

Figma:先分辨資源載入與即時協作

Figma 首次開啟慢,可能是字型、圖片、縮圖或 JavaScript 資源載入慢;多人編輯延遲,則更可能是即時連線或節點穩定性問題。先用瀏覽器無痕視窗排除擴充功能,再觀察 Clash 連線頁面中的請求類型。若只有圖片或字型失敗,補齊對應資源網域;若畫布內的游標和物件更新中斷,優先固定節點,並避免讓 url-test 在工作中途頻繁切換。

Miro:長連線與大型白板要分開觀察

Miro 白板同時載入大量圖片、卡片與留言時,初始載入時間可能較長,這不一定代表代理設定錯誤。可先建立一張只有少量物件的測試白板,比較空白白板、一般白板與大型白板的差異。若小白板也無法即時同步,排查 WebSocket 與節點;若只有大型白板緩慢,則要考慮瀏覽器記憶體、硬體加速和附件數量。不要把所有大型檔案下載請求不加判斷地送進代理,可依實際連線記錄精準加入資源網域。

驗證結果與常見故障排查

設定完成後,不要只用「首頁能打開」作為成功標準。至少完成登入、編輯、即時同步、重新整理和附件操作五項測試,並在每項測試時記錄目前模式、策略組、節點和錯誤訊息。這樣換節點或修改 DNS 後,才有可比較的基準。

1. 在 Clash 用戶端確認目前模式為「規則」而不是「直連」,並確認系統代理或 TUN 只有一套正在生效。
2. 開啟平台頁面後,在連線記錄搜尋平台名稱,逐筆確認主站、API、資源和即時連線的策略組。
3. 對同一平台先使用固定節點測試,再使用 url-test 測試,比較是否由自動切換造成中斷。
4. 用瀏覽器無痕視窗重新登入,排除快取、Cookie、擴充功能與舊連線狀態造成的假象。
5. 完成測試後重新載入設定檔,確認自訂規則仍在生效位置,且 MATCH 仍然位於規則清單最後。

可長期維護的協作分流原則

這套方案的核心不是把所有海外服務一律代理,而是把工作流拆成可觀察、可調整的幾個部分。先用一個 WORKFLOW 策略組統一 Notion、Figma、Miro 的出口,再依連線記錄補充資源與即時同步網域;規則放在 MATCH 之前,內網與本地服務保留直連;桌面環境需要接管命令列或不遵循系統代理的程式時,再開啟 TUN 和 DNS 劫持。

節點方面,優先選擇長連線穩定、上傳成功率高的節點,不要只按照面板延遲排序。設定方面,保留原始設定檔與測試副本,每次只改一個變數,例如先換節點、再改規則、最後才調整 DNS。當問題再次出現時,按照「規則命中 → DNS 結果 → 代理節點 → WebSocket 狀態 → 瀏覽器與系統」的順序排查,通常能比反覆切換全域模式更快找到原因。