1 デザインツールは「1 サイト＝1 ホスト」ではない
Figma の画面は単一のオリジンに見えても、実際には認証フロー、エディタ本体、プレビュー用の埋め込み、画像とフォントの取得、サードパーティ製ウィジェット、そして複数ユーザー間のカーソル同期が、別々のホスト名とプロトコル特性を持ちます。FigJam も同じエコシステム上にあり、ブレインストーミングやスタンプ、タイマーなどのインタラクションは短い HTTPS リクエストと、切断に敏感なリアルタイムチャネルが混在します。ここで Clash 分流を雑に「とりあえず海外ノード」に丸投げすると、レイテンシの低いノードでも途中で別ルールに落ちたセッションだけがタイムアウトし、「たまに同期が止まる」「プラグインだけ読み込み中のまま」といった不安定な再現になりがちです。
そのため本稿では、症状ごとに「どのカテゴリの通信か」を先に決め、同じ品質ポリシー（同じセレクタ／同じ自動選択グループ）へ揃える方針を取ります。Mihomo 系コアであれば接続ログにホスト名が残るため、テンプレのリストに無い新しいサブドメインを見つけたら、週次レビューで Rule Provider か手書きルールに追記する運用が現実的です。社内ポリシーで特定の CDN だけ直結させたい場合は、そのホストを DIRECT 側に明示し、逆にブロックされやすい帯域だけプロキシへ寄せる、という二層設計もよく使われます。
2 四つのレイヤー：サインイン、フォント、プラグイン、長接続
まず実務で便利なのは、トラブルを次の四つにラベル付けすることです。第一にサインインとセッションです。メール／パスワードに加え、Google や SAML などの OAuth を挟むと、ブラウザのポップアップとデスクトップアプリの埋め込み WebView で、参照する証明書ストアやプロキシ設定が食い違うことがあります。第二にWeb フォントとタイポグラフィです。ファイル内で指定されたフォントが Google Fonts（fonts.googleapis.com／fonts.gstatic.com）などから読み込まれる場合、メインの figma.com だけ通してもフォントリクエストが別経路のままだと、表示だけ崩れます。
第三にプラグインとコミュニティリソースです。公式のプラグイン管理画面やマーケット、スクリプトのホスティング先は、コアの API ホストと一致しないサブドメインや、一時的なオブジェクトストレージ URL に分散することがあります。第四にキャンバス同期と FigJam のリアルタイム性です。ここは短い REST というよりキープアライブが効く長めの接続になりやすく、出口ノードの輻輳や UDP／TCP の扱い差で、他サイトは問題ないのに Figma だけカクつく、という報告形式と相性が良いです。
- ログイン／トークン更新：
figma.com配下に加え、Google ログインならaccounts.google.comなど IdP 側を同じ意図のルールに含める（詳細は Google 連携全般のリストを参照）。 - フォント読み込み： デザインファイルに埋め込まれた外部 CSS が参照するホストをブラウザの開発者ツールで確認し、必要なら
DOMAIN-SUFFIXで束ねる。 - プラグイン・スクリプト： マーケット画面が真っ白なら、静的 JS のホストが
MATCH側の意図しない出口に流れていないかログで確認。 - 同期： ノードを切り替えた直後だけ不安定なら、長接続の切り替わりが原因の可能性。同一セレクタに固定して再現性を見る。
3 束ねるドメインのベースライン
多くの環境では、DOMAIN-SUFFIX,figma.com がエディタ・FigJam・埋め込みの大半をカバーします。開発者向けドキュメントや一部の検証 UI は figma.dev など別トップレベルに現れることがあるため、チームにエンジニアが混ざるなら同じアウトバウンドに寄せておくと質問が減ります。静的アセットは *.figma.com 配下にまとまっていることが多いですが、計測タグや A/B 用のサブドメインが増えると、手元のログにだけ現れる名前が出ます。ここで第三者の巨大リストに丸ごと依存するより、自チーム用の短い YAML 断片を Git で管理し、Pull Request で増分レビューする方が、デザイナーとインフラの共通言語になりやすいです。
API 連携や Organization 管理で api.figma.com を直接叩く自動化を走らせている場合、そのホストだけ別ポリシーにしたいこともあります。逆に「デザイナーのブラウザとバッチ処理を同じ出口にしたい」なら、明示的な DOMAIN ルールを先に置き、細かい例外を上に積む Clash 共通の順序ルールを踏襲してください。HTTPS／SNI を扱う Sniffer を有効にしている環境では、ログ上のホストとルールのマッチ結果が一致しているかをセットで見ると取りこぼしが減ります。
4 YAML 例：DOMAIN-SUFFIX と Google Fonts
以下は 例示です。FIGMA_PROXY は実際のポリシー名に置き換え、最終 MATCH より上に配置してください。Google ログインを同じトンネルに載せたい場合は、IdP 用のサフィックスを別セクションで追加します（既存の「Google 系」リストと重複しないよう整理）。
# Place ABOVE the final MATCH. Replace FIGMA_PROXY with your policy name.
- DOMAIN-SUFFIX,figma.com,FIGMA_PROXY
- DOMAIN-SUFFIX,figma.dev,FIGMA_PROXY
- DOMAIN-SUFFIX,googleapis.com,FIGMA_PROXY
- DOMAIN-SUFFIX,gstatic.com,FIGMA_PROXY
googleapis.com と gstatic.com は、フォント以外の Google 資産も巻き込む幅の広い指定です。チーム方針で「フォントだけプロキシ」にしたい場合は、接続ログで実際に出るホストに絞り、より具体的な DOMAIN-SUFFIX に分割してください。企業ネットワークで Split Tunnel の VPN と併用している場合、同じホストが VPN 側と Clash TUN 側で二重に捕まらないかも、企業 VPN と Clash の記事の観点とあわせて確認すると安全です。
ブラウザ拡張とデスクトップの差
ブラウザから Figma を使う場合、拡張機能が追加のリクエストを発行します。デスクトップアプリは Electron 系のネットワークスタックを持ち、OS のシステムプロキシ設定と TUN の吸い上げ範囲が一致していないと、「片方だけログインできる」状態が起きます。両方を同じルールに載せるには、クライアント側でシステムプロキシと TUN のどちらを正とするかを決め、TUN モードのガイドに沿って矛盾がないか確認するのが近道です。
5 Rule Provider：購読リストと手元の追記をどう合成するか
SaaS 向けのコミュニティ Rule Provider には figma.com が含まれていることも多いですが、バージョンによってはサブドメインが古いままです。新機能のロールアウトでエッジホストが増えた直後にだけ問題が出る、というパターンは、まさにリスト更新の遅れとログの差分で説明できます。運用上は「週1回はルールを再取得」「接続ログで未登録ホストをキャプチャして手書き YAML に追記」の二本立てが壊れにくいです。Mihomo では rule-providers とメイン rules: の評価順を設定で制御できるため、Figma 専用の軽量ファイルを先に評価させ、巨大な一般リストは後ろに回すと、意図したポリシーが上書きされにくくなります。
デザイン組織では、ブランドガイドやコンポーネントライブラリのリンクが社内ポータルから Figma に直飛びする運用が一般的です。短い URL リダイレクトや短縮リンク経由の場合、最初の1ホップだけ別ドメインになり、ルールの穴に落ちることがあります。リダイレクトチェーン全体をブラウザのネットワークパネルで追い、最終的に繋がっているホスト集合をルールに反映させてください。
6 Windows デスクトップと PROCESS ルール
ドメインルールだけでは、同一ホストへのアクセスが別アプリから別ポリシーに振り分けたい、という要件を表現しきれないことがあります。例えば、会社支給 PC でブラウザは直結のまま、Figma デスクトップだけ特定のプロキシグループへ寄せたい場合、Mihomo 互換の PROCESS-NAME／PROCESS-PATH 系ルールが有効です。具体的な書き方と注意点は、Windows におけるプロセス名ルーティングの記事を参照し、実行ファイル名の大文字小文字や実際のパスをログで確認してから適用してください。
PROCESS は強力な反面、クライアントのアップデートでバイナリ名やインストール場所が変わるとルールが無効になる点に注意が必要です。ドメインベースのベースラインを先に固め、PROCESS は「最後の仕上げ」として使うと運用負荷が下がります。macOS では TUN とシステムプロキシの組み合わせで同等の体験を得ることが多く、プロセスルールよりも全体キャプチャの設計を優先するチームもあります。
7 Sniffer、DNS、長時間接続の安定化
ポート番号ベースの判定だけでは足りないケースでは Sniffer が SNI からホストを復元しますが、誤った優先順位は別ポリシーへの誤配送を招きます。Sniffer の挙動を理解したうえで、Figma 関連のドメインが期待どおりマッチしているかをログで確認してください。また DNS と fake-ip の組み合わせがずれると、一瞬だけ別経路に落ちて同期がリセットされることがあります。Meta カーネル向け DNS のベストプラクティスに沿って、リゾルバとルールの意図を揃えます。
FigJam のブレインストーミングで複数人が同時に操作する場面では、レイテンシの絶対値よりも接続の継続性が体験を左右します。自動 URL テストでノードを頻繁に切り替えるポリシーにしていると、長接続が毎回張り直されてカクついて見えることがあります。url-test とフォールバックのパラメータを、デザインセッション向けに少し保守的に設定し直す、という調整も一案です。
8 切り分けチェックリスト
- ログインだけ失敗： OAuth のポップアップ用ドメインと
figma.comが同一アウトバウンドか。ブラウザとデスクトップでプロキシ設定が一致しているか。 - フォントだけ豆腐：
fonts.gstatic.com等が別ルールに流れていないか。コンテンツブロッカーと競合していないか。 - プラグイン市場だけ空白： 接続ログに出た未登録ホストを Rule Provider に追加。キャッシュ破損ならアプリの再インストールも検討。
- 同期だけ頻繁に途切れる： 出口ノードの切り替わりが多すぎないか。UDP や長接続に弱いノードを避ける。
- 埋め込みだけ表示されない：
embed系サブドメインや外部 iframe のホストがルールに含まれるか。
9 まとめ
2026 年も Figma／FigJam を中心にしたデザイン協業は拡大しており、Clash 分流では「AI ベンダー1社のドメイン」よりプロダクト横断のホスト束ねが鍵になります。本稿では figma.com と figma.dev を基準に、Web フォント用の googleapis.com／gstatic.com を同じ意図のポリシーへ寄せる例を示し、Rule Provider と手書きルールの合成、Windows の PROCESS、Sniffer と DNS、長接続の安定化という順で切り分ける流れを整理しました。
チームでテンプレートを配布する際は、デザイナーが使うチャネル（ブラウザ／アプリ）と、インフラ側の TUN・システムプロキシの前提を文書化し、ログに残ったホスト名と更新日をセットで記録すると、後から同じ症状を追いやすくなります。クライアントの入手は当サイトのダウンロードページから行い、オープンソースの参照は GitHub を別途利用する、という住み分けが安全です。
ルールと DNS を一体で扱える Clash 互換スタックは、SaaS の細かなホスト追加に追従しやすいという利点があります。出口の品質とルール設計を揃えれば、サインインからフォント表示、プラグイン、FigJam のリアルタイム体験まで、一連の協業フローを途切れさせにくくできます。
