Figma が開かない・ずっと読み込み？FigJam 含むメイン域と静的 CDN を Clash（mihomo）で分流し、DNS・Fake-IP まで校準する実測メモ（2026）

1. 本稿の位置づけ（Notion／Reddit／開発者 AI 稿との棲み分け）

長尺ストリーミングを前面に出した YouTube や Netflix の既稿とは異なり、Figma 系の不調は初回の HTML／バンドル JS／画像・フォントが別ホストの CDNに乗っている典型が多く、症状は「再生品質」よりエディタが立ち上がらない・共同編集の同期が不安定に寄りがちです。検索ニーズも画質より読み込みとログイン後のスピナーが中心になりやすいため、ルール設計のゴールをキャンバスとパネルの安定表示に置きます。

購読の取り込みとルール評価順の基本は、サブスクリプション導入と ルールルーティングの解説と共通です。以降は Figma／FigJam 特有の名前空間に絞ります。

2. 段階別の症状：表ページ・キャンバス・埋め込み・デスクトップアプリ

figma.com の表ページやログイン画面すら白画面・タイムアウトになる場合は、www.figma.com や認証まわりが意図しない出口に乗っているか、DNS が分流と噛み合っていない可能性が高いです。端末のプライベート DNS、他社 VPN、フィルタ製品が挟まっている場合も同じ見え方になります。

左のファイル一覧は出るのにキャンバスだけグレー／スピナーのままというパターンは、アプリ本体の HTML とは別名の静的バンドルが策略の外に残っている典型です。多くの環境で static.figma.com のような静的リソース用ホストが開発者ツールの Network に現れます。インフラは変更され得るため、手元で失敗した URL のホストを正としてください。

FigJam ボードだけ不安定・埋め込み（embed）だけ 403 や無限読み込みになる場合は、embed.figma.com 経由のパスが別策略に落ちている、または埋め込み元サイトの CSP・サードパーティ Cookie と経路の問題が重なっていることがあります。公式のデスクトップアプリは OS のプロキシを読まない経路が残る場合があるため、ブラウザでは再現しないのにアプリだけ壊れるときは後述の TUN も視野に入れます。

3. 押さえたい Figma 系ドメインの型

出発点として多くの環境で登場しやすいのは、figma.com（サブドメインを含む表側のサイト・API・リアルタイム協業の多く）、static.figma.com（バンドルや静的アセットの配信で CloudFront 背後に現れやすい）、embed.figma.com（Embed Kit 2.0 系の埋め込み）、www.figma.com と help.figma.com（ドキュメント閲覧）などです。DOMAIN-SUFFIX,figma.com 一発で多くのサブドメインを覆えるため、実務ではまずこれを専用策略へ寄せ、ログで別 TLD や外部 SaaSだけを足す運用が扱いやすいです。

UI のフォントやアイコンでGoogle Fontsが混ざる場合、fonts.googleapis.com や fonts.gstatic.com が失敗ログに出ることがあります。ここを広い DOMAIN-SUFFIX で丸ごと同じ出口に寄せると無関係なページまで巻き込むため、Figma 閲覧中の Network に出た事実だけをルール化するのが安全です。Clash 分流では、広い MATCH より前に具体的なサフィックスを置くのが基本で、その順序は ルールルーティングの解説どおりです。

4. mihomo ルール例：FIGMA 策略の上へ DOMAIN-SUFFIX を積む

実務では Figma／FigJam 閲覧向けの策略グループを一つ切り、レイテンシの安定したノードを載せる形が扱いやすいです。自動切り替え系では、読み込み中に出口だけが頻繁に変わると WebSocket やセッションが不安定になることがあるため、不調時は手動で出口を固定し改善するかを見るのも有効です。

以下は構造の例です。プロキシ名と最終 MATCH は環境に合わせて置き換え、ログに出たホストで不足分を足してください。

# proxy-groups: dedicated group for Figma (main + static + embed)
proxy-groups:
  - name: FIGMA
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

# rules: suffix covers www / static / embed / api-style subdomains
rules:
  - DOMAIN-SUFFIX,figma.com,FIGMA
  - MATCH,PROXY

組織向けのカスタムドメインや、ログにだけ現れるサードパーティホストがある場合は、そのホスト名を個別に追加してください。DOMAIN-KEYWORD は誤爆しやすいので、長期運用ではログ上の実名への置き換えを推奨します。TUN を使う場合は TUN モードの解説も参照し、システムプロキシでは追い切れないプロセスが残っていないか確認してください。

5. DNS・Fake-IP・Sniffer：名前と実接続を一致させる

Fake-IPを有効にしている構成では、ブラウザが握っているアドレスと、ルールが参照するドメイン情報の間にズレが生じやすくなります。Clash 分流が効かないように見えるのは、出口ではなく名前解決の経路が混線しているケースが多いです。nameserver とプロキシ経由の解決の書き分け、Fake-IP フィルタが自分のテンプレートでどう定義されているかを一度通読してください。

mihomo 系では Sniffer が TLS の SNI などから接続の実名を復元し、ルール再評価に使えるため、Fake-IP と併用する場面で「ドメインが取れず策略が空振りする」状況を減らせます。手順の詳細は Sniffer・SNI・ログの稿を参照し、実装差は手元のコアのドキュメントを正としてください。

Figma のように表ページと静的 CDN が別名のサービスでは、DNS だけ別出口に出ていると枠は開いてもキャンバスだけ別ルートという分断が起きやすい点に注意します。考え方の骨格は Claude 向けの稿でも述べているDNS と出口の二正面と同型です。

6. ブラウザ拡張・デスクトップアプリ・TUN

ブラウザでは問題なくても公式デスクトップアプリだけ不安定な場合、OS のプロキシ設定を読まない経路や、別プロセスの DNS が残っていることがあります。TUN でアプリ全体のデフォルト経路を揃えると切り分けが速い場面があります。併せて、プライバシー拡張・広告ブロックがサードパーティ要求を落としていると「CDN だけ死んでいる」ように見えることがあります。拡張を一時停止して同じノード・同じルールでも再現するかを比較すると、原因が経路かローカルかを分けやすくなります。

企業ネットワークではSplit Tunnelやゼロトラストクライアントが Figma 向けトラフィックだけ別経路にしている例もあります。その場合、個人側の mihomo ルールを増やしても効果が限定的になるため、IT ポリシーと二重に効いていないかも確認してください。

7. ログでホストを拾い足す手順

推奨の手順は次のとおりです。（1）mihomo のログで問題ファイルを開いたときのホストがどの策略にマッチしたかを確認する。（2）マッチは正しいのにキャンバスだけ失敗する場合、開発者ツールから失敗した URL のホストをメモし、未登録のサフィックスだけを追加する。（3）Fake-IP 利用時は Sniffer の有無と DNS の整合を確認する。（4）購読ルールの更新順と、手書きルールの位置が上書きされていないかを確認する。フェイルオーバの挙動は url-test / fallback の稿も参照してください。

ルールを増やすほど無関係なトラフィックまで同じ出口に吸い上げるリスクが上がります。繰り返しログに現れた名前から必要最小限だけ足す運用が、長期的なメンテナンスに繋がります。

8. つまずきやすい点とコンプライアンス

第一に、www.figma.com だけを足して満足することです。表側は通っても 静的バンドルが別名のままだと、スピナーとキャンバスの不調が残りやすいです。DOMAIN-SUFFIX,figma.com で多くを一括できますが、最終的にはログの実名で裏を取ってください。

第二に、広すぎる AWS や Google のサフィックスを安易に同じ策略へ寄せることです。仕事用の他サービスまで巻き込み、遅延や認証エラーを誘発することがあります。

第三に、本稿はサービス利用規約や著作権、国や地域の法令を踏み越えた利用を助長するものではありません。ここで扱うのは、正当な契約の範囲内で自宅や会社支給機のネットワーク経路を整理する一般的な知識に限られます。

9. まとめ

Figma／FigJamの不調は、ブランドは一つでも表ページ・静的 CDN・埋め込み・APIが別ホストに分かれやすいため、検索で多い「開かない・ぐるぐる・キャンバスだけ出ない」を段階別に切り分ける必要があります。mihomo のルールで figma.com 系を専用策略に揃え、DNS・Fake-IP・Sniffer で名前と実接続を一致させ、必要なら TUN でデスクトップアプリ経路まで含めて揃える、という三層は、YouTube／Netflix 稿の長尺ストリーミングや、Cursor／DeepSeek 稿の開発者向け APIとは役割を分けて使うと整理しやすいです。ホスト名は将来的にも変わり得るため、最終的には自分のログに出た名前を正としてルールを足し込むのがいちばん確実です。全体の手順のおさらいは チュートリアル総覧にまとまっています。

同じ Clash 系でも GUI とコアの世代で既定値が変わります。安定したクライアントから揃えるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから始めるのがおすすめです。