1. 症状の読み解き：スピナー・コメントずれ・カーソル停止は「別レイヤー」になりやすい

キャンバス全体が読み込めない問題と、コメントだけ遅い問題、マルチプレイヤーカーソルが追従しない問題は、原因が完全に一致するとは限りません。前者は初期バンドルや WASM・スクリプトの取得、中間はイベント配信やコメント API、後者は低遅延を要するプレゼンス系の長回線が別ルートに落ちているケースが重なります。ただし共通しているのは、Figma がセッション中に複数ホストへ並列アクセスし、かつHTTPS と WebSocket を同時に維持する点です。Clash の接続一覧に出るホスト名と実際に選ばれた策略を時系列で並べると、「トップページはプロキシで通っているのに、CDN サブドメインだけ DIRECT で詰まる」といった部分的成功が想像以上に早く見えてきます。

YAML の骨格やルールモードをまだ把握していない場合は、先にサブスクリプション取り込みの記事で設定ファイルの流れを押さえておくと、以降の手順が読みやすくなります。

組織プランや SSO 経由のログインでは、認可まわりと Figma 本体でホストが分かれ、片方だけ企業プロキシの例外に入っている例も珍しくありません。ユーザー視点では「ファイル一覧は見えるのにキャンバスだけ白い」「デザインは動くのに Dev Mode だけ固まる」など、表側の UI と裏側の取得先が一致していないサインになりやすいです。最初から全局プロキシに寄せるより、ログでホスト単位に揃えた方が、後からの運用も軽くなります。

2. Figma 周辺通信を「層」に分けて考える

以下は設計メモとしての区分であり、実際のサブドメインは環境や AB テストで変わります。重要なのは、一枚岩のドメイン想定でルールを書かないことです。

層イメージ切り分けのポイント
アプリ本体・認証figma.com、www.figma.com 系ログインやファイル一覧は通るのにキャンバスだけ止まるときは CDN か長回線を疑う。
静的 CDN・アセットフォント、画像、バンドル、サムネイル配信に関わるサブドメイン大容量取得が別経路だとスピナーが長引き、一部 UI だけ欠ける。
リアルタイム協業プレゼンス、共同編集、コメント同期に関わる WebSocket（wss://）ドメインは HTTPS と同系統のことが多いが、策略が割れると「見た目は動くが中身が古い」。
埋め込み・連携embed.figma.com など社内ポータルや Notion 埋め込みだけ失敗するときにログを分離して確認。

2026 年時点でも Figma は頻繁に更新されるため、過去に動いていたルールが突然効かなくなることは珍しくありません。購読ルールに頼り切らず、自分のログで一度表を作り直すのが安全です。

デザインシステムやライブラリ運用では、公開リンクや Branch、コミュニティリソースを跨ぐ場面が増え、同一セッション内でもホストの種類が一気に増えることがあります。ここで「とりあえず広い DOMAIN-KEYWORD」に頼ると、意図しないサードパーティまで同じ策略に乗り、別アプリの速度まで落とす副作用が出ます。ログに出たサフィックスだけをルールに昇格させる癖を付けると長く持ちます。

3. ブラウザ版とデスクトップ版：経路の取りこぼし方が違う

ブラウザ版は OS のプロキシ設定を踏みやすい一方、拡張機能や企業ポリシーで特定ドメインだけ別経路になることがあります。デスクトップアプリは Electron 系の挙動に近く、Discord 記事で触れたシステムプロキシと TUN の組み合わせと相性の論点が似ています。検証では、まず「どちらのクライアントで再現するか」を固定し、同じファイルを開いて接続ログの差分を見るのが早いです。開発ツール側のマーケットプレイス問題とはホストが異なるため、切り分けの参考としてCursor 向け分流記事とは役割分担します。

デスクトップ版は自動更新のタイミングで一時的に帯域を使い、バックグラウンド取得が編集セッションと競合して体感が悪化することがあります。更新中だけ不安定なら、更新チャネルや再起動順を変える前に、まず Clash 側で更新取得ホストの策略が本体と揃っているかを確認してください。ブラウザ版でだけ再現するなら、プロファイル分離（ゲストウィンドウや新規プロファイル）で拡張の影響を切るのがコスト対効果が高いです。

4. ドメイン収集：ファイルを開く・コメントする・共同編集するを分けてログを取る

収集の基本は次の流れです。シナリオを分けると WebSocket まわりが読みやすくなります。

  1. Clash を起動し、システムプロキシまたは TUN を有効化する。併用中の別 VPN は一旦切る。
  2. Figma で問題のファイルを開き、キャンバスがスピナーのまま止まる状態を再現する。接続ビューで同時刻付近のホストをメモする。
  3. 別セッションで、コメントを投稿したり、他ユーザーのカーソル表示を確認する。更新が遅い・止まる瞬間のホスト名を記録する。
  4. DIRECT や想定外のポリシーに落ちている行に印をつけ、購読ルールのどの行より上に自作ルールを置くべきかを検討する。

ポート占有やコア起動失敗など汎用トラブルはトラブルシュート記事へ。本稿は Figma 特有のマルチドメイン構成と長回線に焦点を当てます。

ログを取る際は、スクリーンショットよりホスト名・策略名・時刻の三点セットをメモする癖を付けると後から再現しやすいです。GUI クライアントによっては接続履歴を CSV やクリップボードへ出せるため、チームで共有するときは個人を特定しうる情報（ファイル名ではなくドメイン中心）に留めると安全です。同一ファイルを複数人で開いたときだけ不具合が出る場合、オーナー側とゲスト側でログが違うこともあるため、両方から一行ずつ取ると比較が早いです。

5. 推奨する切り分け順序

  1. Clash が起動していること、システムプロキシかTUNのどちらでトラフィックを握っているかを確認する。
  2. 接続ログで Figma 関連ホストが意図したポリシーグループに入っているか、誤った DIRECT がないかを見る。
  3. fake-ip を含む DNS 設定を確認し、必要なら特定サフィックスへ nameserver-policy 等を当てて名前解決のブレを減らす。
  4. 本体・CDN・埋め込みをホスト／サフィックス単位でルール化し、購読ルール内の広い DIRECT より上側に矛盾なく配置する。
  5. 同じノードでも HTTPS は通るが協業だけ不安定な場合は、別ポリシーグループ（例：低遅延重視）へ長回線相当のドメインだけ振り分ける案も検討する。

6. システムプロキシと TUN：WebSocket の取りこぼしを減らす

システムプロキシは手軽ですが、プロキシ設定を読まないコンポーネントや、別ドライバの VPN と併用すると見かけ上の経路が分裂します。TUN はルーティング層で取り込むため一貫性は上がりますが、他 VPN との競合や権限まわりのトレードオフがあります。有効化するならTUN モードの解説を参照し、有効化後に再接続ログで Figma 関連ホストがすべて期待どおりの経路になったか検証してください。リアルタイム協業は短い切断と再接続が積み重なってユーザーには「ただ重い」に見えるため、ログの時刻粒度を細かく見る価値があります。

ブラウザの開発者ツールで Network タブを開き、WS フィルタだけを見ると、長回線が何秒周期で再試行されているかが掴めます。ここで 101 切替の直後に真っ赤な失敗が並ぶなら、プロキシではなく証明書検査や企業フィルタが先に疑われます。Clash 側の策略が揃っているのに失敗が続く場合は、上流の HTTPS インスペクションと二重になっていないかも併せて確認してください。

7. DNS／fake-ip：名前解決とルール判定のズレ

fake-ip は体感速度を上げる一方、設定次第では「ルールに渡る前の名前」と「実接続の宛先」の整合が崩れやすくなります。Figma のようにサブドメインと CDN が多く、かつ長回線を張り直すサービスでは、軽いズレでもクライアントがリトライを繰り返し、ユーザーにはただのスピナーやコメント遅延に見えます。対策の基本は、上流 DNS を信頼できるものにそろえ、ログで頻出する主要サフィックスへ専用の名前解決ポリシーを当てることです。フィールド名はコアのバージョンで差があるため、利用中の Mihomo／Clash Meta のドキュメントと照合してください。

IPv6 優先のネットワークでは、A レコードと AAAA レコードのどちらが先に使われるかで、見かけ上だけ別リージョンのエッジに刺さることがあります。Clash 側で IPv6 を切る／残すを切り替えたときだけ挙動が変わる場合は、まず OS とブラウザの IPv6 設定、ルータの DHCPv6 を含めて一度棚卸ししてください。症状が時間帯でだけ悪化するなら、DNS の TTL とエッジの負荷が重なっている可能性もあり、固定ではなくログの時系列で見るのが近道です。

8. 分流ルールの考え方（記述例は置き換え前提）

購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN／DOMAIN-SUFFIX を、矛盾なく上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。サフィックスを丸ごとプロキシに載せると、他サービスへ副作用が出ます。ログに出た特定サブドメインに絞るか、ルールセットの細分化を検討してください。

# Example only — verify hostnames in your Clash logs before use
rules:
  - DOMAIN-SUFFIX,figma.com,PROXY
  - DOMAIN-SUFFIX,figmausercontent.com,PROXY

figmausercontent.com はユーザー生成アセット周辺でログに出やすい一方、環境差が大きいです。静的配信だけ別グループ（例：PROXY_CDN）に分け、本体と同じノードに寄せるかどうかは遅延と帯域のトレードオフで決めると運用しやすいです。グループ名は proxy-groups に定義済みである必要があります。

社内で「許可ドメインリスト」運用をしている場合、セキュリティチームのリストに figma.com だけ入っていて、実際の取得が別サブドメインに逃げているケースがあります。セキュリティ側の更新待ちの間、Clash で一時的に揃えるのは救急として有効ですが、恒久対応は公式の推奨ドメイン一覧と突き合わせるのが筋です。外部公開の埋め込みだけが壊れるときは、親ページの CSP や X-Frame-Options も疑い、プロキシ以前のレイヤーを切り分けてください。

9. Discord 向け RTC 記事との違い

当サイトの Discord 記事は、ボイス RTC や UDP を含むゲートウェイにスコープが寄っています。本稿は Figma の HTTPS 取得と WebSocket 長回線 に絞り、デザインツールの協業同期を扱います。どちらも「マルチドメインを一枚岩で扱わない」という原則は共通ですが、UDP の比重は通常、Figma 側の方が低めです。ボイスとデザインツールを同日に触る場合は、Discord CDN／RTC 分流記事と別ホスト表を持つと混乱が減ります。

10. ノード選定：帯域より「往復の揺れの少なさ」

スピードテストで一位でも、短時間で往復遅延が跳ねるノードは、プレゼンスや共同編集のような小さなメッセージの連続には不向きです。TLS の再ハンドシェイクが増え、クライアント側はタイムアウトや再同期として現れます。手動選択で様子を見たり、協業専用に安定路線を固定するのが実用的です。別ノードを試す前に経路の一貫性を先に確認する方が再現性が高いです。プロトコル特性の比較はプロトコル比較記事も参考になります。

11. 追加の落とし穴：企業プロキシ、Split Tunnel、ブラウザ拡張

企業端末では OS プロキシとは別に、セキュリティ製品が特定カテゴリだけ直結させることがあります。またブラウザ拡張が localhost 経由で別の DNS を使うと、Clash 側の見え方と実接続がズレます。検証時は拡張をオフにし、可能ならプロファイルを分けたクリーンなブラウザプロファイルで再現するのが無難です。別 PC へプロキシを配る場合は、LAN プロキシの記事で allow-lan とファイアウォールの要点を押さえてください。

Wi-Fi と有線を切り替えただけで症状が消える場合、ルータの DNS キャッシュやキャリアグレード NAT の違いが影響していることもあります。コワーキングスペースや出張先でだけ再現するなら、キャプティブポータル通過前後でプロファイルが変わっていないか、Clash のプロファイル切替とセットで確認してください。最後に、Figma 側のステータスページでインシデントが出ていないかを見るのは当たり前のようで抜けがちなので、チームチャットに貼る前のワンクッションにすると誤探索が減ります。

12. まとめ：証拠ベースで CDN と WebSocket を束ねる

Figma のキャンバスがスピナーのまま進まない症状や、コメント・カーソル同期の遅延は、単一設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。2026 年もデザイン協業のインフラは変化が早いので、購読ルールに頼り切らず、自分の環境で一度ホスト表を更新する習慣を持つと安心です。

接続ログとルール編集を GUI でまとめられるクライアントを使うと、YAML を毎回手で触る負担も下がります。同種ツールのなかでも、策略表示とコアの整合が取りやすい製品ほど長く運用しやすい印象です。共同編集を安定させたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める