一、先對齊現象：轉圈、半載入與協作不同步常是三件事疊在一起
Figma 在瀏覽器內同時依賴多種連線：帳號工作階段、設計檔中繼資料、字型與圖片等靜態資源、以及讓多人游標與編輯事件即時同步的通道。當你遇到協作載入失敗時，表面看起來都是「轉圈」，但底層可能是某一條腳本請求逾時、WebSocket 握手被中斷，或同一檔案的不同請求被規則拆到不同出口導致工作階段狀態不一致。
因此，請避免一開始就把所有問題都歸咎到單一策略群組。較務實的做法是：先在「僅開啟首頁／檔案列表」與「進入具體畫布並開啟多人協作」兩種情境下各收集一次連線紀錄，確認各自命中的規則與 DNS 行為，再決定要不要把 CDN 類資源與即時協作類主機拆到不同群組。若你尚未成功匯入訂閱或策略名稱不確定，建議先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教程》，避免在錯誤的群組名稱上反覆試錯。
二、為什麼要把 Figma CDN 與 WebSocket 拆開思考
Figma CDN類流量多半承載體積較大的靜態內容與分段下載，目標是盡快把資源送到瀏覽器；這與WebSocket追求的「長連線穩定、低抖動、少重連」並不完全相同。若你把兩者硬塞在同一個只看延遲數字的節點選擇裡，可能出現資源顯示載完、協作卻頻繁重連的體感；也可能出現協作勉強可用、畫布卻卡在骨架畫面，因為某一條腳本子網域仍被地區策略或前置直連規則截走。
在撰寫 Clash 分流規則時，請優先對齊你環境中實際出現的主機名稱，而不是只抄一份過期清單。Figma 會依區域與產品調整邊緣與 API 命名；最可靠的方式仍是在你電腦上，於「開啟檔案」與「與同事同時編輯」兩種動作下各收集一次日誌，再把重複出現的後綴整理成 DOMAIN-SUFFIX。這與我們在 Discord 場景強調的「客戶端多子網域」邏輯相近，但主機名稱集合不同，請勿混用規則。
三、用瀏覽器開發者工具對齊：哪一些是「靜態」、哪一些是「長連線」
在撰寫規則之前，建議先用瀏覽器開發者工具的網路面板觀察：哪些請求是大型腳本或字型檔（常落在 Figma CDN或第三方邊緣網域），哪些請求在類型欄位顯示為 WebSocket 或長時間保持 pending。當你看到 WebSocket 狀態在 connecting／closed 之間反覆跳動，或同一頁面同時存在大量失敗的腳本請求，就很適合回到 Clash 連線清單逐條對照主機名稱與策略。
請記得：廣告攔截、隱私擴充套件或公司 SSL 檢視，有時會破壞 WebSocket 或阻擋特定子網域；若你只在開啟某個擴充套件時才出現協作載入失敗，應先以無痕視窗或乾淨設定檔交叉驗證，再歸因到 Figma 代理規則。這一步能避免你在 YAML 裡調整半天，其實瓶頸在瀏覽器外掛。
四、為什麼「只相信手動系統代理」有時會漏流量
許多團隊習慣只開啟系統 HTTP／HTTPS 代理，但瀏覽器與外掛程式仍可能以不同方式發起連線，或被其他安全軟體改寫路由。實務上，若症狀主要發生在桌面瀏覽器而非 Figma 桌面應用程式，我們通常會優先建議你驗證 TUN 模式是否能讓相關流量一致進核心，因為它能在網路層統一接管符合條件的封包。
啟用 TUN 會涉及路由與系統權限，請先閱讀《Clash TUN 模式開啟方法》再操作，並在開啟後回到連線清單確認瀏覽器程序相關連線是否出現在核心中。若你同時使用 WSL2 或 Docker Desktop，也可對照《WSL2 共用本機 Clash 代理》理解「哪些流量預設不會自動跟著主系統代理走」，避免把問題誤判成單一設計工具故障。
五、建議排查順序（先證明流量有進核心，再談節點）
下列順序刻意把「換節點」放在中後段：先確認 Figma 相關連線有經過 Clash，且規則命中符合預期，再談線路品質與長連線穩定度。
- 確認 Clash 正在執行，並依場景選擇系統代理或TUN；若問題主要出在瀏覽器，優先驗證 TUN。
- 在開啟檔案與載入畫布時，於連線日誌中檢查是否出現
figma.com與常見靜態資源主機名稱，以及策略是否為預期的代理群組，而非被過寬的DIRECT規則提前截走。 - 進入多人協作後，再次檢視日誌：是否有長連線相關主機名稱反覆出現、是否與登入與資源流量同一出口，避免 WebSocket 走代理而 API 直連的「分裂」狀態。
- 檢查 DNS 模式（是否
fake-ip）、以及 Figma 相關後綴是否在fake-ip-filter或nameserver-policy中有合理設定，避免解析與連線策略互相打架。 - 在規則已正確命中的前提下，再挑選掉包低、重連少的節點；若上游對長連線不友善，協作仍可能異常，此時才需要回到節點型態層面處理。
若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文聚焦 Figma 場景下的Figma CDN與WebSocket對齊。
六、網域怎麼收集：以日誌為準，不要只抄懶人包
Figma 會隨時間調整邊緣與 API 命名，第三方整理的清單可作起點，但最可靠的方式仍是在你自己的環境收集主機名稱。在 Clash 用戶端的連線清單中依關鍵字篩選 figma，並在開發者工具網路面板比對完整主機名稱，通常比單純猜測更有效。
將觀察到的名稱依後綴分組後，優先使用 DOMAIN-SUFFIX 對齊整棵子網域樹，比過寬的 DOMAIN-KEYWORD 更不易誤傷其他服務。若你看到資源來自第三方公有雲邊緣，請只加入「該次失敗時間點實際命中」的後綴，避免把整個超大後綴一刀切進代理，拖慢其他網站。
七、實務上常見的 Figma 網域方向（以實測為準）
下列方向為多數環境下登入、編輯器與嵌入預覽會出現的典型後綴家族；實際是否全部需要、以及是否應走同一策略群組，請以你的連線日誌為準：
figma.com：主站、編輯器、帳號與多數 API 流程常見。www.figma.com：行銷與部分導流頁仍可能單獨出現。embed.figma.com：文件或簡報內嵌預覽常見。- 靜態資源與分段物件有時會落在與主站不同的子網域或第三方 CDN；請以開發者工具顯示的實際主機名稱為準補規則。
- WebSocket連線可能與 REST API 共用主機，也可能落在獨立子網域；請在日誌中確認「長連線」對應的名稱，不要假設一定與腳本網域相同。
重點在於：畫布骨架出現但資源永遠補不齊時，優先懷疑 CDN 類子網域仍直連；資源大致載入、協作卻頻繁掉線時，優先核對長連線相關主機名稱是否與登入流量同一出口，並檢查是否有中間設備中斷 WebSocket。
八、DNS 與 fake-ip：別讓解析鏈放大「一直轉圈」的感受
在 fake-ip 模式下，Clash 會先回傳虛擬位址再在連線階段決策出口。若 DNS 與規則配合不當，可能出現「解析看起來成功、實際 TLS 對錯出口」或反覆重試。Figma 在載入大型檔案時會平行請求多個子網域，任一條解析被汙染或指向不理想的路徑，畫布就可能長時間停在轉圈狀態。
實務上可以分兩步：第一，確認你的 DNS 上游對海外網域可信且可達；第二，對反覆出問題的後綴在用戶端支援的欄位中設定較穩定的解析策略（例如指定 DoH），並在調整後用連線日誌比對命中是否與預期一致。若改 DNS 後載入明顯推進，代表瓶頸有相當比例在解析鏈路，而非單純節點速度。
九、分流設計檢查清單（請以你的日誌為準）
下表整理撰寫 Figma 代理規則時的檢查角度；欄位中的後綴會隨營運調整，務必以實測主機名稱為準。
| 類型 | 常見主機名稱方向 | 設定提示 |
|---|---|---|
| 帳號與編輯器 | figma.com 等 | 與工作階段同一策略脈絡，避免 API 走代理、靜態資源直連。 |
| 靜態與分段資源 | 日誌／DevTools 中的大型腳本與物件主機 | 協作載入失敗若伴隨腳本 4xx／5xx，優先核對是否誤直連。 |
| 嵌入預覽 | embed.figma.com | 簡報或文件內嵌與主編輯器可能命中不同規則，需分別驗證。 |
| 長連線與即時協作 | 日誌中持續出現的協作相關主機 | 與 WebSocket關聯高；需避免與 REST 流量出口長期不一致。 |
| 第三方 CDN | 實際請求顯示的邊緣網域 | 只加入必要後綴；過寬規則可能影響其他網站效能。 |
十、分流規則範例（請替換為你的策略群組名稱）
下列 YAML 片段示範「把 Figma 相關後綴明確指向代理群組」的寫法；請將 PROXY 替換為實際策略群組名稱，並維持規則順序：更具體的 Figma 條目應放在過寬的 MATCH 與地區直連清單之前。若你希望「大型靜態資源」與「協作長連線」分流到不同群組，可定義 PROXY_CDN 與 PROXY_LIVE，再依日誌微調。
# Example only — replace PROXY with your policy group name; add more lines from your logs
rules:
- DOMAIN-SUFFIX,figma.com,PROXY多數情況下仍以 DOMAIN-SUFFIX 為主，避免過寬的 DOMAIN-KEYWORD 誤傷其他服務。若日誌中出現與主站不同的靜態資源或協作專用子網域，請逐條補上；不確定時寧可先記錄完整主機名稱，再查後綴歸屬。
十一、圖形用戶端中如何少踩坑
在 Clash Verge Rev 等用戶端中，建議開啟即時連線清單，篩選 figma 或上述後綴關鍵字，逐條確認策略。若某條顯示 DIRECT，請回到規則表檢查是否有廣告攔截、地理分流或「繞過區域網」類規則前置命中。
若桌面端基礎設定尚未完成，可先依《Clash Verge Rev 完整設定教學》跑通訂閱與模式，再回到本文補 Figma 專用規則，可節省大量試錯時間。
十二、小結：把「轉圈與不同步」變成可驗證的規則問題
2026 年在瀏覽器使用 Figma 遇到協作載入失敗或畫布長時間轉圈時，可依序確認：瀏覽器流量是否進核心、DNS 與 fake-ip 是否一致、Figma CDN 與 WebSocket 相關主機是否各自命中預期出口，以及擴充套件與公司網路是否中斷長連線。當連線日誌能清楚對應主機名稱與策略，你就不需盲目全局代理或反覆更換節點卻無法改善體驗。
當你希望把觀測、規則與核心更新集中在同一套成熟用戶端時，官方維護方案通常能降低手寫 YAML 的低階錯誤；相較其他同類工具，Clash 在規則透明度與日誌對照上往往更一致。→ 立即免費下載 Clash，開啟流暢上網新體驗