症状：メイン UI は動くのに共同編集や埋め込みだけが不安定

Figma はブラウザ上のデザインツールとして広く使われ、2026 年現在もリモート協働の中心に置かれるサービスです。一方で Clash／Mihomo をルールモードで運用している環境では、「トップページやログインは通るのに、キャンバスの同期が遅い」「Live embed やファイルの外部プレビューだけが真っ白」「共有リンクを別タブで開くと一部のアセットだけ 403 やタイムアウト」といった、層がずれた不調が報告され続けています。

この手の症状は、単一の figma.com という印象とは裏腹に、実際の通信が複数のサブドメインと第三者 CDN（画像最適化やオブジェクトストレージのエッジなど）へ分散しているときに起きやすく、ルールの優先順位やDNSの取りこぼしが「特定機能だけ」に表れます。本稿は利用規約・コンテンツポリシー・サービス提供地域は各公式の案内に従う前提で、名前解決と経路設計に限定して整理します。

既存のHugging Face／Git LFS 向け分流のように「HTML は速いのに大容量の取得だけ落ちる」構造と近い一方、ホスト集合は完全に異なります。またAdobe Creative Cloud 向け記事と同じく「汎用デザイン／クリエイティブ SaaS」という並列の位置づけですが、DOMAIN-SUFFIX の対象は adobe.com 系ではなく figma.com 束と実測で見つかる CDN 名が中心になります。

最初に確認：企業プロキシ・ZTA クライアント・ブラウザ拡張の「HTTPS フィルタ」が Figma ドメインを誤って分割していないかを見てください。Clash より上位の層でブロックされていると、分流を整えても症状が残ります。

本チェックリストがカバーしないもの（意図的な切り分け）

記事同士の役割が重なると読者の設定が矛盾しやすいので、本稿では次のトピックを明示的に除外します。必要ならそれぞれ専用の記事へ進んでください。

  • 動画ストリーミング：Netflix／Disney+／Max などは netflix.com 束や広告・計測ドメインの扱いが別系統です。Netflix 向け記事やDisney+ 向け記事でホスト設計を分けます。
  • Steam：クライアントのストア・コミュニティ・コンテンツ DL や UDP オンラインは steampowered.com 等が中心で、Figma とはルール集合が交わりません。Steam 向け記事を参照してください。
  • 任天堂 eShop／Nintendo Switch Online：Switch 向け記事で CDN と DNS の切り分けを扱います。本稿の Figma 用サフィックスと混ぜない方が運用が簡潔です。

つまり本稿の焦点は、「figma.com およびプレビュー時に増える静的アセットホストを、意図したプロキシグループへ確実に流す」ことに絞ります。

なぜ「広い GEOIP ルール」や「末尾 MATCH だけ」では足りないのか

Figma のページは短時間に多数のサブリクエストを発行します。共同編集ではリアルタイム同期用のホスト、埋め込みでは embed.figma.com 周辺とサンドボックス化されたリソース、サムネイルやプレビュー画像は別名の CDN に乗ることがあります。設定によっては次の落とし穴があります。

  • 誤った先行ルール：広い GEOIP や別サービス向けの RULE-SET が、意図せず Figma のリクエストを先に拾い、DIRECT や安価ノードへ落としてしまう。
  • サフィックスの穴：figma.com は DOMAIN-SUFFIX,figma.com で一括カバーしやすい一方、実際の失敗が *.cloudfront.net や画像 CDN の独自ドメインに出ている場合、サフィックス束に入っていないと取りこぼす。
  • ノード要件の違い：低遅延が重要な同期と、帯域が重要なサムネイル取得で最適な出口が異なる場合、単一の「海外まとめ」グループでは折り合いが付かない。

評価順の基本はルール分岐の詳解と同じで、「細かいほうが上、広いほうが下」です。DOMAIN,embed.figma.com のような明示行を先に置き、続けて DOMAIN-SUFFIX,figma.com、さらにログで拾った CDN 名を続ける構成が扱いやすいです。

ステップ 1：DNS（Fake-IP）と証明書／WebSocket の前提を揃える

共同編集系は WebSocket や長命接続を伴うことがあり、dns.enhanced-mode: fake-ip 環境では名前解決と実接続の経路が一瞬でもズレると、「ログイン後だけ固まる」「カーソルだけ遅延」といった中途半端な症状に見えます。

  • DoH の初回：リゾルバ URL 自体がプロキシ必須ドメインだと、最初の数クエリだけタイムアウトが連鎖することがあります。
  • Split DNS：企業 VPN や別 DNS アプリと二重にリゾルバが競合していないか確認します。
  • IPv6：AAAA が返るが下りだけ不通な経路では、ブラウザの再試行が増えて体感が悪化します。

接続ログを読む前に、DNS・遅延テストが全滅に見えるときの記事でリゾルバとヘルスチェックを整えると、Figma 専用ルールの試行錯誤が短くなります。

ステップ 2：プロキシグループの切り方（実務パターン）

次のパターンは運用で扱いやすい構成です（グループ名は例です）。

  • パターン A（Figma を他の海外 SaaS と同じ出口でよい）：DOMAIN-SUFFIX,figma.com を既存の「海外まとめ」グループへ追加するだけでよいケース。問題は DNS や TUN の取りこぼし側にありがちです。
  • パターン B（Figma だけ別ノードへ）：🎨 Figma のような独立プロキシグループを用意し、figma.com 束とログで特定した CDN をそこへ集約します。API 系の広い RULE-SET より上に置くか、少なくとも DIRECT に落ちる広いルールより上に置きます。

パターン B では、広いサフィックスを先に書きすぎると、後段で細かく分けたいホストまで吸い込むため、Figma 向けの具体行を意図した位置に固定してから、巨大な RULE-SET を読み込むのが安全です。

ステップ 3：コピー用 DOMAIN／DOMAIN-SUFFIX の骨格

以下は出発点の例です。2026 年時点でもエッジやプレビュー用ホストの追加はあり得るため、ブラウザの開発者ツール「ネットワーク」で実際に出たホストをログと突き合わせ、不足分だけ追記する運用を推奨します。画像配信が figma.com 以外の独自名で出た場合は、その名をそのまま DOMAIN-SUFFIX か DOMAIN で拾います。

proxy-groups:
  - name: "🎨 Figma"
    type: select
    proxies:
      - "低遅延ノード"
      - "高帯域ノード"
      - DIRECT

rules:
  # Explicit embed / editor hosts first if your broader rules steal traffic
  - DOMAIN,embed.figma.com,🎨 Figma
  - DOMAIN,www.figma.com,🎨 Figma
  - DOMAIN-SUFFIX,figma.com,🎨 Figma
  # Add CDN hosts observed in DevTools (examples — verify on your network)
  # - DOMAIN-SUFFIX,example-cdn.example,🎨 Figma

実際の YAML では未定義のプロキシグループ名を書かないよう注意してください。嗅探（Sniffer）や TLS の宛先上書きを有効にしている構成では、Sniffer と fake-ip の記事の評価順も合わせて点検すると、長命コネクションの取りこぼしを減らせます。

ステップ 4：ブラウザが TUN／システムプロキシを見ているか

「デスクトップアプリは通るがブラウザだけおかしい」場合、ブラウザが OS のプロキシ設定を無視するプロファイルだったり、拡張の独自プロキシが残っていたりすることがあります。TUN でプロセス横断的に取り込めていれば差は縮まります。TUN モードの解説で、仮想 NIC とルートが期待どおりかを確認してから、ルールの A/B テストに進むと手戻りが減ります。

ステップ 5：実測──ログと開発者ツールで足りないホストを足す

ファイルを開き、数十秒だけ Clash の接続一覧を眺め、REJECT や意図しないチェーンに落ちているホストをメモします。ブラウザ側では「失敗（赤）」の URL のドメイン名をそのままルール候補にするのが早いです。

  1. ページ再読み込み前にログをクリアし、再現操作だけを取り込む。
  2. 同じドメインが DIRECT とプロキシで挙動が変わるかを比較する（地理的制限や企業フィルタの切り分け）。
  3. 一時的に該当ホストだけ別ノードへ──帯域不足か、ブロックかを切り分ける。

チェックリスト（Figma 専用・短時間版）

  1. 拡張・上位プロキシが Figma を誤遮断していないか。
  2. DNS：fake-ip、DoH 初回、IPv6 片道、競合リゾルバを疑う。
  3. ルール順：embed.figma.com や DOMAIN-SUFFIX,figma.com が、意図しない広い RULE-SET より上か。
  4. 開発者ツールで落ちているCDN 名をログと突合し、ストリーミング／Steam／任天堂向けルールに依存せず独立行として足したか。
  5. TUN でブラウザトラフィックがコアに乗っているか。

運用のコツ：デザインツールはフロントの分割デプロイでホストが増えやすいので、巨大な静的リストを丸ごとインポートするより、数分のログ採取で差分を足す方が保守しやすいです。骨格となる評価順と DNS 設計は固定し、名前だけ更新するイメージが安全です。

ドキュメントと入手経路

YAML の共通項目は当サイトのチュートリアル・ドキュメントも参照してください。クライアントの入手は説明が一貫した導線としてダウンロードページから行うのがおすすめです。

まとめ

Figma の共同編集や埋め込みプレビューの不調は、「とりあえず海外へ」という雑なまとめルールでは再現が抜けやすく、figma.com 束と実測で見つかる CDN、そしてルールの先取り順が効きます。DNS → 具体 DOMAIN／DOMAIN-SUFFIX → 巨大 RULE-SET、の順を意識し、ログで足りない名前だけ足すと修正が速くなります。

開発者向けの Git／モデル取得はHugging Face 向け記事、動画系 SaaS はSora・OpenAI 動画向け記事と役割を分けられます。Mihomo／Clash Meta 系は接続ログが読みやすく、ホスト単位の追記にも向きます。環境に合ったビルドはダウンロードページにまとめています。→ Clash クライアントを無料でダウンロードし、Figma 向け分流を試す