1 為何 Figma／FigJam 特別需要「拆流量」再做 Clash 分流
設計工具的可見症狀常常類似：網頁版能開檔案，但游標不同步；或本機 App 能預覽縮圖，一開啟外掛市集就載入失敗。這通常不是單一「節點延遲」能解釋，而是多種連線疊在同一個產品體驗裡：OAuth 重新導向與 Cookie 寫入走瀏覽器或內嵌 WebView；REST 與 GraphQL 類 API 走短連線；字型與外掛腳本走靜態主機或第三方 CDN；多人編輯則仰賴 WebSocket 等長連線維持狀態。只要其中一段命中錯誤的策略組，體感就會變成「半套能用」。
Clash 分流的目標，是把與 Figma／FigJam直接相關的主機名，穩定導向同一個低抖動、可預期的出口，同時讓區網資產、內部 Wiki、套件鏡像維持直連。相較全域代理，精準規則能減少大型檔案無謂繞路；相較過寬的 DOMAIN-KEYWORD，後綴與清單化規則較不會在未來誤傷無關流量。
若您的設定檔仍混用第三方訂閱與手寫規則，可先完成訂閱轉 Clash YAML，再把本文條目插在 rules 前段，讓它們優先於寬鬆的 GEOIP 或 MATCH，降低被提前截斷的機率。
2 登入、OAuth 與 API：先對齊「帳號鏈路」
產品首頁、編輯器與帳務後台主要落在 figma.com 與相關子網域；REST 風格的 api.figma.com 則常見於權杖、檔案中繼與自動化整合。登入若走 Google 或企業 IdP，瀏覽器還會短暫連到身分供應商網域（例如 Google 帳戶、Okta 類服務）。實務上建議把「Figma 本體」與「您實際使用的 IdP」分開思考：前者可用一組乾淨的 DOMAIN-SUFFIX,figma.com 收斂；後者則依組織政策決定是否併入同一策略組，避免 OAuth 回呼因出口跳動而失敗。
企業網路若啟用 HTTPS 檢查，請先確認憑證鏈信任，否則規則再正確也可能在握手階段失敗。對需要固定出口 IP 的團隊，可將上述規則指向固定節點子組而非「自動選最快」，降低授權與風控因頻繁換 IP 而中斷的風險。
3 Web 字型、靜態資源與外掛市集：CDN 也要納入同一策略組
檔案中若使用 Google Fonts 等線上字型，瀏覽器會向 fonts.googleapis.com、fonts.gstatic.com 請求 CSS 與字型檔。這兩組後綴與 Figma 核心網域不同，卻直接影響「為什麼畫面上變成後備字型」的體感。若您的規則只涵蓋 figma.com，而字型請求誤走直連或被重置，畫面仍會看起來「怪怪的」。
外掛市集與社群外掛載入時，除了 figma.com 下的資源路徑，也可能觸及其他靜態網域或腳本託管；版本更新後子主機名可能增減，因此長期維護仍應以連線日誌為準，將漏網的 DOMAIN 補進獨立 Rule Provider，而不是一次性寫死長清單後不再更新。
對 fonts.gstatic.com 這類較「通用」的後綴，若擔心影響其他網站，可改為在除錯階段用連線面板確認只有設計工作階段需要代理，再決定是否收窄為更精細的規則或獨立策略組。
4 即時協作與長連線：FigJam 白板與多人游標
FigJam與編輯器內的即時協作仰賴持續連線；若規則或 UDP／DNS 路徑不一致，常見症狀是游標延遲、註解不同步，或短暫斷線後無法自動恢復。這類流量多半仍落在 *.figma.com 命名空間內，但對抖動與斷線重連比純下載更敏感。實務上與其反覆更換節點，不如先確認：該長連線是否穩定命中與 API 相同的策略組、以及本機是否同時存在第二層 VPN 改寫路由表。
若您啟用 TUN，請一併檢查是否有「只有瀏覽器走代理、桌面 App 直連」的分裂情境；此時症狀會高度像「網頁版正常、桌面版偶發掉線」。解法通常是統一走系統代理或 TUN，並避免多個客戶端爭奪同一個系統路由。
5 Rule Provider 與可維護的 DOMAIN-SUFFIX 片段
下列 YAML 僅示範結構，請將 PROXY 換成實際策略組名稱。原則是：Figma 相關條目愈靠前愈好，並把會變動的清單放進 Rule Provider 以利版本控管與團隊共用。
rules:
- DOMAIN-SUFFIX,figma.com,PROXY
- DOMAIN-SUFFIX,figma.design,PROXY
- DOMAIN-SUFFIX,fonts.googleapis.com,PROXY
- DOMAIN-SUFFIX,fonts.gstatic.com,PROXY
# Optional IdP (example only; align with your org):
# - DOMAIN-SUFFIX,accounts.google.com,PROXY
# Append exact hosts from your connection log when needed:
# - DOMAIN,cdn.example.com,PROXY
# When the list grows, move payloads into a Rule Provider (http/file)
# and reference it with RULE-SET,<name>,PROXY in Mihomo / Clash Meta.
清單變長時，建議改為 Rule Provider：把 payload 放在可版本控管的 YAML／遠端訂閱，主設定檔只保留 RULE-SET 與策略組名稱，團隊較容易同步更新。若尚未使用 Provider，也可先把上述 DOMAIN-SUFFIX 直接寫進主設定。請謹慎使用過寬的 DOMAIN-KEYWORD：短期省事，長期容易與其他產品流量衝突；較穩健的流程仍是「日誌 → 精確 DOMAIN／DOMAIN-SUFFIX → 可選關鍵字兜底」。
6 桌面版、TUN 與 Windows 的 PROCESS-NAME 分流
Figma 桌面客戶端以 Electron 為基礎，連線行為與瀏覽器分頁並不完全相同：可能出現「Chrome 登入正常、App 內嵌視窗失敗」的落差。若開啟圖形客戶端的系統代理，請確認混合埠（常見 7890）與應用程式代理設定一致；更省心的做法則是啟用 TUN，在核心層統一接管符合規則的 TCP／UDP。
在 Windows 上，若您希望只有 Figma 相關行程走特定節點、其餘辦公軟體直連，可於 Mihomo／Clash Meta 使用 PROCESS-NAME 規則。實務上桌面版執行檔名稱多為 Figma.exe（仍以工作管理員為準）。更完整的語法與注意事項可對照Windows 行程名稱分流教學；TUN 啟用步驟則可參考Clash Verge Rev TUN 模式指南。
rules:
- PROCESS-NAME,Figma.exe,PROXY
- DOMAIN-SUFFIX,figma.com,PROXY
# ...
PROCESS-NAME 與 DOMAIN-SUFFIX 並用時，請留意規則順序：過早的寬鬆規則可能讓行程規則永遠碰不到。建議在調整後以連線面板實測「開啟檔案、開啟外掛、捲動長文件」三種操作，確認命中集合一致。
7 DNS、HTTPS Sniffer 與誤判排查
設計協作的小封包互動對 DNS 解析路徑極度敏感。若本機 DNS、Clash 的 FakeIP 與遠端解析不一致，症狀會像「偶爾能同步、多數時間轉圈」。建議檢視 fake-ip-filter 與實際命中規則，必要時延伸閱讀DNS 防洩漏與 FakeIP 實作。
若 HTTPS 流量在規則裡被錯誤分類（例如顯示為 IP 而非預期網域），可啟用 Meta 核心的 Sniffer 協助還原 SNI，並對照HTTPS 嗅探與 SNI 分流一文調整；完成後再回到連線日誌，確認外掛與字型相關主機名是否已落在正確策略組。
建議固定除錯流程：先關閉多餘 VPN，只保留 Clash；在連線列表以 figma、gstatic 等關鍵字篩選；再切換 Global 與 Rule 對照。若 Global 正常而 Rule 異常，幾乎可斷定要改規則或 DNS，而非急著更換用戶端版本。
8 總結
Figma與 FigJam要穩，關鍵是把「帳號／OAuth、API、Web 字型、外掛市集與靜態資源、即時協作長連線」視為同一條設計協作鏈路，而不是只測首頁能不能開。透過 Clash 分流、模組化的 Rule Provider，以及在 Windows 上適時搭配 PROCESS-NAME，就能把這條鏈路綁到一致的出口，並與直連流量和平共處。
相較一味追求測速數字，更值得投資的是低抖動的小封包互動與可預期的規則命中；在相同節點條件下，清楚的網域集合往往比臨時開全域代理更省事。若您希望本機與教學文章使用同一套用戶端體驗，可從站內下載頁取得安裝包後再依環境選擇系統代理或 TUN。
