為什麼 Notion、Figma 與 Miro 適合用分流思維處理

Notion、Figma 與 Miro 都是典型的雲端工作工具，但三者產生的網路流量並不完全相同。Notion 主要涉及頁面載入、資料庫同步、圖片與檔案附件；Figma 除了登入與檔案讀取，還會長時間維持協作連線，讓游標、留言、元件變更可以即時同步；Miro 則常見大型白板、圖片、嵌入內容與多人編輯。若你在 Clash 裡直接開啟全域代理，確實可能很快連上服務，卻也會把本地網站、公司內部系統、印表機、NAS 和一般影音流量一併送到代理節點，導致延遲增加或頻寬被不必要地消耗。

比較穩妥的做法，是先把工作流程拆成「需要穩定代理的雲端服務」、「可以直連的本地與一般網站」以及「必須依公司或學校政策處理的內部資源」。這種分層不只是為了速度，也方便排錯：當 Figma 協作卡住時，你可以先檢查 Figma 相關請求是否命中預期策略；當 Notion 圖片載入慢時，也能分辨是節點延遲、規則遺漏，還是服務本身的 CDN 暫時異常，而不是一律把問題歸咎於 Clash。

本文以支援 Mihomo／Clash.Meta 核心的圖形用戶端為例，介面名稱可能因 Clash Verge、Clash Verge Rev 或其他客戶端版本而略有不同，但判斷原則一致：確認目前載入的設定檔、建立服務分流、保留本地直連、觀察連線紀錄，最後才考慮是否需要 TUN 模式。請先確保你使用的是可信的訂閱來源，並遵守所在地、公司或學校的網路規範。

先整理三種工具的連線特性與使用場景

在編輯 YAML 或調整規則以前，建議先列出你每天實際使用的服務。很多「Notion 打不開」或「Figma 只有部分功能正常」的問題，並不是主網域完全無法連線，而是登入、API、圖片、字型、附件或即時協作所使用的請求走了不同路徑。你可以先開啟 Clash 的連線列表，依照使用工具的順序重新載入頁面，再記下目的地、連線模式與實際命中的策略。

工具 常見流量特徵 排錯時優先觀察 建議策略方向
Notion 頁面、資料庫、登入、附件與圖片載入 主頁能否開啟、工作區能否同步、附件是否逾時 依實際可用性選擇穩定代理群組，避免頻繁切換節點
Figma 檔案載入、字型、圖片、API 與長時間協作連線 檔案是否卡在載入、多人游標是否延遲、留言是否同步 優先使用延遲低且長連線穩定的策略，不要只看短暫测速結果
Miro 大型白板、嵌入內容、素材、圖片與多人編輯 白板是否完整顯示、縮放是否卡頓、素材是否載入 保持同一工作區使用相對穩定的出口，避免編輯中途改變節點
本地網站與內部系統 區域網路、公司網域、路由器管理頁與內網服務 是否能解析內部 DNS、是否能連到區網 IP 通常使用 DIRECT，並確認不會被代理規則誤攔截

這張表不是要求你盲目新增大量網域，而是提供一個觀察順序。不同帳號區域、服務版本、瀏覽器擴充功能與訂閱規則可能讓實際目的地有所差異。特別是 Figma 與 Miro，不能只測試首頁就宣稱設定完成；應該開啟一個實際檔案，進行捲動、縮放、留言或多人編輯，因為真正影響體驗的往往是後續的 API 與即時連線。

如果你使用桌面版應用程式，也要單獨測試桌面程式。瀏覽器可能自動讀取系統 Proxy，但桌面應用程式、Electron 程式或背景更新程序未必完全遵循相同設定。當瀏覽器版本正常、桌面版卻持續離線時，請在 Clash 連線列表確認是否真的出現對應請求；完全沒有記錄通常代表程式沒有經過目前這個代理入口。

Clash 規則設計：服務分流與本地直連並行

規則的核心不是把所有雲端服務都放進同一個巨大清單，而是讓規則具備清楚的優先順序。一般而言，較具體的服務規則應放在較寬泛的規則之前，否則先命中的 GEOIP、通用規則或既有 RULE-SET 可能讓你新增的分流永遠不會生效。你可以把 Notion、Figma、Miro 分成三個邏輯群組，也可以先放進一個名為 WORKFLOW 的策略群組，重點是之後能在介面中快速辨認。

以下是一個用來理解結構的簡化片段。實際網域應以 Clash 連線紀錄、服務官方文件與你的設定檔格式為準；不要因為看到網路文章列出某些網域，就不加確認地把它們全部寫入規則。

proxy-groups:
  - name: WORKFLOW
    type: select
    proxies:
      - AUTO
      - DIRECT

rules:
  - DOMAIN-SUFFIX,notion.so,WORKFLOW
  - DOMAIN-SUFFIX,figma.com,WORKFLOW
  - DOMAIN-SUFFIX,miro.com,WORKFLOW
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

這個例子只展示規則排列與策略命名，不代表所有 Notion、Figma 或 Miro 相關流量都只會使用單一主網域。若連線列表顯示附件、登入或協作請求落到其他網域，先確認該目的地與服務的關聯，再決定要加入精準規則、引用現有規則集，或讓它依原有通用規則處理。過度寬鬆的 DOMAIN-SUFFIX 可能把不相關服務一併送入代理，也可能讓後續維護變得困難。

規則順序與策略選擇

完成第一版規則後，先不要立即加入大量例外。可以依序檢查三件事：第一，規則是否真的在目前生效的設定檔裡；第二，對應請求的策略欄位是否顯示 WORKFLOW，而不是被其他規則提前匹配；第三，WORKFLOW 目前選到的節點是否適合長時間協作。對 Figma 與 Miro 而言，節點的短時間延遲只是參考，持續編輯十至二十分鐘後是否仍穩定，通常更有意義。

如果你使用自動選擇或 URL 測速群組，請留意測速網址與實際工作流不一定相同。測速成功只代表某個測試端點在當下可達，不能保證 Notion 的資料庫同步、Figma 的即時協作或 Miro 的素材上傳都具備相同表現。建議先用 AUTO 做初步比較，再在實際檔案中選定一個穩定節點，避免工作進行到一半因自動切換而重新連線。

為什麼本地網站應明確保留 DIRECT

許多使用者只處理三個雲端工具，卻忽略本地流量。當你開啟全域代理或 TUN 後，路由器管理頁、NAS、公司內網、印表機和本地開發伺服器可能被送到代理端，結果是 DNS 解析異常、登入頁面打不開，甚至讓你誤以為內部服務故障。對常見的私有網段、localhost、公司內部網域與已知本地域名，應根據實際環境設計 DIRECT 規則。

不過，DIRECT 也不是越多越好。若公司內部 DNS 解析出的是公開 IP，或某個內部網域同時包含外部 SaaS 服務，就不能只依名稱猜測。排錯時可先用瀏覽器開啟目標頁面，再查看 Clash 是否產生連線，以及請求被哪條規則命中。對不熟悉的網域，保留紀錄、逐一驗證，比一次加入大型白名單更安全。

從登入到多人協作：用實際工作流程驗證設定

設定完成後，建議不要只測試「首頁能否開啟」。真正有用的測試應該模擬你平常的工作順序，而且每完成一個階段就觀察連線紀錄。這樣可以知道問題是出在登入、檔案內容、即時同步，還是本地資源。

  1. 先確認代理入口：查看系統 Proxy 或客戶端的 mixed-port 是否正在監聽，並確認沒有其他 VPN、加速器或第二個 Clash 用戶端搶佔設定。若使用 TUN，先記下啟用前後的差異，不要同時修改太多項目。
  2. 測試 Notion 工作區：先登入，再開啟一個包含圖片、資料庫與附件的頁面。觀察文字、封面、圖片是否分段載入，並嘗試編輯一個區塊後重新整理，確認內容能正常同步。
  3. 測試 Figma 檔案：開啟實際設計檔，等待圖層與縮圖載入，再進行縮放、拖曳、留言與多人游標測試。如果只有檔案縮圖正常、正式畫布持續轉圈，請把注意力放在連線紀錄中的額外目的地，而不是反覆更換首頁規則。
  4. 測試 Miro 白板：開啟一張元素較多的白板，測試縮放、拖曳、貼上圖片與新增便條。若白板能開啟但素材缺失，可能是附件或嵌入內容沒有使用同一條分流路徑。
  5. 測試本地服務：在上述測試期間，同時開啟公司內部網站、NAS 或本地開發頁面，確認它們仍走 DIRECT。這一步可以及早發現 TUN 或寬泛代理規則對內網造成的影響。

遇到問題時，先看「有沒有請求」再看「請求走哪裡」。如果完全沒有相關連線，可能是應用程式未使用系統 Proxy、DNS 被其他工具接管，或該功能採用不受目前模式涵蓋的網路通道。如果有連線但策略顯示 DIRECT，則通常要檢查規則順序、域名解析結果與目前啟用的設定檔。如果策略正確但仍逾時，才進一步比較節點品質、協定相容性、TLS 錯誤與服務端狀態。

桌面應用程式特別容易造成「瀏覽器正常、App 異常」的誤判。你可以先關閉桌面版，只保留瀏覽器測試；接著重新啟動應用程式並在 Clash 裡觀察新的連線。若桌面版始終沒有任何記錄，請檢查應用程式自己的 Proxy 選項、系統代理權限與是否啟用了獨立的網路沙盒。不要在沒有證據的情況下連續加入網域，否則最後只會得到一份難以理解、也難以還原的規則清單。

至於 TUN 模式，適合用來驗證那些不讀取系統 Proxy 的程式是否能被接管，但不宜把它當成所有問題的萬用解法。TUN 可能與公司 VPN、零信任軟體、虛擬機器網路或其他路由服務衝突。若啟用 TUN 後 Notion、Figma、Miro 變正常，請比較連線紀錄與路由表，再決定是否長期使用；若只是在 TUN 下偶爾成功，則仍要回頭查明真正未被代理的程序或規則。

日常維護：讓工作流程設定保持可預期

工作工具的網域、登入流程與 CDN 可能隨版本更新而改變，因此規則不應被視為一次設定、永久不動的檔案。建議每次訂閱更新或 Clash 用戶端升級後，重新測試至少一個 Notion 頁面、一個 Figma 檔案和一張 Miro 白板，並查看是否出現新的目的地。若規則使用遠端 RULE-SET，也要確認更新後的內容沒有覆蓋你原本依賴的自訂規則。

建議把設定分成「訂閱提供的基礎規則」和「自己維護的工作流規則」。前者負責一般地區、廣告或常見服務分類，後者只放你確實驗證過的 Notion、Figma、Miro 與本地例外。這樣做的好處是日後更換訂閱或節點時，不必重新猜測所有規則的來源。若你需要把設定交給團隊成員，也應移除訂閱網址、節點密鑰和個人帳號資訊，只分享規則邏輯與測試方法。

另外，請避免把「速度最快」當成唯一目標。設計檔與白板協作更在意連線持續性、丟包率和重新連線速度；Notion 資料庫則更在意同步是否可靠；本地網站則需要保持低延遲直連。把不同工作流全部綁定同一個會自動跳轉的策略，有時反而會讓結果不穩定。可以在工作時間使用固定穩定節點，閒暇時再測試其他節點，並記下測試日期、網路環境與實際結果。

與只提供全域開關、遇到內網或桌面程式就難以細分的同類工具相比，Clash 的優勢在於可以把策略群組、域名規則、連線紀錄與本地直連放在同一套可檢查的流程裡：例如讓 Figma 與 Miro 使用穩定出口，同時讓公司內網和 NAS 保持 DIRECT，遇到同步異常時還能沿著規則命中結果逐層排查。若你正在尋找一套能兼顧 Notion、Figma、Miro 與日常本地網路的可調整方案，Clash 會比單純全域代理更容易長期維護，也可以依你的平台選擇合適用戶端開始設定。

立即免費下載 Clash，開啟流暢上網新體驗 →