為什麼「一般網站能上」，Figma 卻卡在畫布或嵌入預覽？

2026 年，遠距協作與設計工具仍是高頻搜尋主題；其中 Figma 同時承載編輯器、即時游標、留言、以及對外分享頁與 Live embed（把檔案嵌到 Notion、簡報或內部知識庫）等路徑。當您遇到畫布載入極慢、縮圖永遠轉圈、嵌入區塊顯示「無法預覽」、或協作者反映游標與變更不同步，直覺常歸咎於「節點不穩」；但在 Clash／Mihomo 的實務裡，更值得先檢查的是：不同階段的連線是否真的落在同一語意的策略群組。常見成因包括：僅對 figma.com 寫了規則，但實際拉取字型、縮圖或大型資源時，瀏覽器對落在其他後綴或 CDN 網名下的主機發請求；舊的 GEOIP／寬鬆規則把該請求提早判成 DIRECT；或 fake-ip 與作業系統／瀏覽器 DoH 讓解析與連線分叉，畫面上就會表現為「看得到殼、載不中肉」。

本文將這類問題對應到可被規則命中的網名與 DNS 行為，並強調：DOMAIN-SUFFIX 只是骨架，真正能上線且不誤傷的流量，仍須對照連線日誌補齊個別 CDN 主機名。若您的訂閱與基礎模式尚未就緒，建議先完成 訂閱匯入，再回頭調整規則，以免策略群組名稱與實際節點列表脫節。

和串流、Steam、任天堂 eShop 專文有什麼不同？

站內已分別從大型串流、Steam 商店／下載／UDP 聯機、Switch eShop 與任天堂 CDN等角度寫過專文；那些場景重視的是地區授權、遊戲客戶端與 P2P、或主機／掌機專有網名。相對地，Figma 屬於瀏覽器為主的設計 SaaS：核心互動在 HTTPS、大量WebSocket 與長連線，並混有靜態資源與字型；與 Cursor 擴充市集或 Hugging Face 大檔下載 等「開發者工具鏈」相比，Figma 更貼近產品／設計協作讀者。因此本篇不重複那些文章裡的 STEAM、Netflix、任天堂關鍵字清單，而提供一份專屬設計工具的分流檢查表，避免您維護多份互相覆寫的規則。

規則優先權：figma.com 要放哪裡？

在 mode: rule 下，rules: 由上而下命中即停。與 規則分流深度文 所述一致，越具體、越貼近單一服務的條目應越靠上；寬泛的 GEOIP、整包 RULE-SET 或 MATCH 在後。針對 figma.com 與其產品子網域，常見實務層次為：

1. 內網與本機（如 DOMAIN-SUFFIX,lan,DIRECT）維持最上，依您環境調整。
2. 單一品牌後綴：DOMAIN-SUFFIX,figma.com,FIGMA_PROXY 往往可覆蓋編輯器、分享頁多數路徑；若日誌顯示另有品牌相關後綴（以實測為準），再補第二條 DOMAIN-SUFFIX。
3. 從日誌補上的 CDN 單一網名：以 DOMAIN,cdn-edge.example.net,FIGMA_PROXY 形式放在「會把海外流量誤判成直連」的寬泛條目之前。
4. 若您把 Git 拉取、AI API 或IDE 外掛放在獨立群組，請確認沒有更早的規則把 Figma 相關網名搶走，或反過來讓 Figma 誤用「只為 CLI 調過的窄節點」。

教學用 YAML 骨架（務必用日誌補齊真實 CDN 清單）

以下僅示範結構，實際 CDN 供應商與主機名會隨產品更新而變；不得未經實測就照搬。註解使用英文以利版本控管。

YAMLproxy-groups:
  - name: "FIGMA_PROXY"
    type: select
    proxies:
      - "FIGMA_STABLE"
      - "PROXY_FALLBACK"
  - name: "FIGMA_STABLE"
    type: url-test
    proxies:
      # Replace with nodes from your subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 300
  - name: "PROXY_FALLBACK"
    type: select
    proxies:
      # your subscription list

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  # Place before broad GEOIP / RULE-SET that may steal SaaS traffic
  - DOMAIN-SUFFIX,figma.com,FIGMA_PROXY
  # If embed or thumbnail hostnames appear outside figma.com in logs:
  # - DOMAIN,pixel-static.examplecdn.com,FIGMA_PROXY
  # Optional: distinguish comments / presence if your logs show distinct hosts

說明：多數情形下，單條 DOMAIN-SUFFIX,figma.com 已涵蓋 www.figma.com、embed.figma.com 這類仍在該後綴樹狀結構內的節點。若 Network 分頁出現完全不同品牌後綴的大檔或字型網名，請改以 DOMAIN 單筆依日誌置前補列。

實測步驟：從日誌收斂，而不是從關鍵字猜測

在重現「畫布壞、嵌入壞、一般網站卻好」的當下，建議依序：

1. 開啟 Clash 連線日誌，重新整理 Figma 分頁或嵌入頁，記下失敗或長時間掛起的目標網名與命中的策略群組。
2. 以瀏覽器開發者工具的 Network 對照，特別注意 type 為字型、圖像、websocket、或 initiator 指向第三方 script 的跨網名請求。
3. 針對尚未覆蓋的網名，在較寬泛規則之前新增 DOMAIN 或更精細的 DOMAIN-SUFFIX，指到 FIGMA_PROXY，重載後再觀察。
4. 大檔或長連線測試期間，暫時將群組改為手動固定單一節點，排除 url-test 抖動造成的假陽性。

DNS、fake-ip 與「解析走一套、連線卻走另一套」

在 fake-ip 搭配 TUN 或系統代理時，若瀏覽器啟用 DoH、或作業系統另有 VPN／企業憑證攔截，可能出現規則看似正確、但媒體階段仍斷的體感。請回頭確認：誰在解析、Clash 的 DNS 設定是否與實際出口一致。若曾懷疑節點延遲顯示異常，可再對照 節點與 DNS 排查文 釐清層次。另若您使用 TUN 模式，請先確認應用程式流量有進入核心，否則規則無從命中。

Figma 專用分流檢查清單（與串流／遊戲不重複）

• figma.com 後綴已置前：且未被更上層 GEOIP,cn,DIRECT 或誤判內建清單提前帶走（依您訂閱實際條目檢查）。
• 嵌入與分享頁有獨立觀測：Live embed／檔案外鏈與編輯器同源或跨網名皆在日誌中命中 FIGMA_PROXY。
• CDN 網名從 Network 回填：任何不在 figma.com 後綴下的大檔或字型請求，皆已個別列為 DOMAIN。
• WebSocket／長連線：協作同步失敗時，優先對照被拒絕或逾時的主機列，而非急著換頻繁切換的節點池。
• DNS 一致性：fake-ip、系統預設與瀏覽器 DoH 無多套解析打架。

常見誤會

• 以為設計協作與 Netflix、Steam「同一組海外節點」就能順：大檔穩定性與瀏覽器長連線特性不同，混在一起除錯常更難。
• 只複製公開社群上的「全神煞費清單」：未對照個人日誌，容易過時或過寬。
• 把嵌入失敗全怪 Figma 官方：在規則未讓所有相關網名走同一出口前，更換節點往往無法對症。

結語

Figma 在網路層上常是多網名、多階段載入：一階走對、另一階沒有，產品就會表現成「永遠載入中」或嵌入預覽整片空白。在 Clash 生態裡，最穩的起手式仍是先讓流量進可觀測的路徑，再用日誌與瀏覽器工具把真實網名收斂到規則表，並以獨立 FIGMA_PROXY 策略群組維持語意清楚。相較拼湊多款小工具，使用同一用戶端與可讀的 YAML，有利於團隊在半年後仍能審計與修改。若尚未安裝，可先參考本站 說明與教學文件 完成基礎拓樸。