まず念頭に置くこと：比較記事ではなく「キャンバスと双方向接続」
プラグイン市場や課金プランの比較は各公式情報に任せ、ここでは ファイルを開いたあとのレンダリング と 共同編集の反映 をネットワーク面から眺めます。デザインツールは静的ページよりも、エディタ本体、アセット、計測、プレビュー、そして コラボ用の常時接続 が同時多発しやすく、Clash のダッシュボードやログに並ぶ FQDN は一見ランダムに見えます。ブラウザ版と デスクトップアプリ では、OS のルーティングと証明書周りの差で症状が分かれやすい点も、Notion や文書SaaSと同様の論点です。再現性を上げるには、問題が出る操作を一つに絞り、同時に開いている他タブやVPNを一時的に減らして、ログに残る接続名を明確化するとよいでしょう。
症状の分け方：白画面と「追従しない」は原因レイヤが違う
初回のファイル一覧やエクスポートだけ遅い 場合は、大きなバンドル取得や TLS ハンドシェイク、あるいは DNS 応答 が律速のことがあります。一方、すでに画面は出ているのに、相手のカーソルや更新だけ遅延する、しばらくすると同期アイコンの挙動が怪しい 場合は、短い HTTPS 単発より、WebSocket や同等の長接続、あるいはストリーミングに近い取得が影響している可能性が上がります。Clash 利用者に起きがちなのは、GEOIP や広い MATCH によって figma 系のホストが 日によって違うプロキシ に触れること、画像用 CDN と制御用ホスト で出口が分かれて一瞬だけ整合が崩れることです。感覚の正しさを確認する近道は、不調の瞬間の 接続名と命中ルール をログに残すことです。
WebSocketが絡みやすい理由：同時編集の裏側
多人数でフレームやコンポーネントを扱う UI では、小さな変更を都度 往復 しやすいため、WebSocket あるいはストリーミングに近い アップグレードされた HTTP の利用が想定されます（内部実装の詳細は更新で変化し得ます）。重要なのは、短い API 呼び出しと比べ、中間プロキシのタイムアウト や 輻輳時の再送、ノード切替直後 の影響を受けやすい点です。チーム全員に症状が出るなら Figma 側要因も考え、自分だけ、あるいはプロキシ有効時だけ なら端末の経路を疑う価値が高まります。大人数ルームにいると接続本数が増え、一見「キャンバス性能」のように見えることもあるため、同じ社内回線の別端末と比較するのが有効です。
figma 周辺のドメイン：公開表より接続ログを正にする
例として figma.com や配信用に見えるサブドメイン、画像やフォント、モバイル連携、計測を担う別ホスト名が会話に出ることがあります。ただし CDN やリージョン の都合で名前は入れ替わり得るため、ネット上の固有名の一覧に頼るより、自分の Clash ログに出た FQDN を正としてください。ルールの書き方では、DOMAIN-KEYWORD,fig のような短い照合は 無関係な第三者サイトまで誤爆 しやすいので、安定してきたら DOMAIN-SUFFIX へ集約し、上から最初にマッチ する行へ明示的に寄せる方が安全です。企業内ではゼロトラストや Web フィルタが wss を扱いにくい構成になっている例もあるため、職場端末に限る症状なら、個人回線の同一プロファイルで再現するかを分けると次の手が明確です。
分流の方針：figma 系のホスト束を同じ出口へ揃える
共同編集に関わるセッションは、接続の張り直し のたびにアプリが「一瞬遅延した」と感じられやすいです。自動選択系の url-test 入りのグループを使っていて、ホストごとに別ノード に落ちると、一見「キャンバスが不安定」に見えます。対策として、ログに列挙された figma 関連を、一つの遅延が読み取りやすいポリシー に集約し、ルール配列の先頭近く で揃えて扱うのが再現性が高いです。国コードだけで大雑把に弾きたい場面は GEOIP / GEOSITE 分流 を参照しつつ、困っている FQDN を足す 方がデザイナー体験のブレに直結しやすい、という立ち位置です。
分流ルールの例：プロファイルの名前に合わせて置き換える
下記は 説明用 の YAML スケッチで、YOUR_PROXY_GROUP は手元の proxy-groups の表記に合わせてください。居住国や事業所の方針によって、直結（DIRECT）の方が安定 なケースと、特定のプロキシにまとめた方が 速いケースの両方があり得ます。ここでの目的は、万人向けの正解表を置くことではなく、ログ上の挙動と主観の遅延が揃う経路 を一つに決めることです。
# Example: Figma-related hosts (tune to your connection log)
rules:
- DOMAIN-SUFFIX,figma.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,figma.app,YOUR_PROXY_GROUP
# Add more DOMAIN-SUFFIX from dashboard when you see misses:
# - DOMAIN-SUFFIX,figmaapi.com,YOUR_PROXY_GROUP
実装では、画像や埋め込み、フォント、モバイル連携、ワイヤ用の補助ホストが 別名 になる場面が多いので、不足はダッシュボードの接続一覧と突き合わせて DOMAIN-SUFFIX を追加してください。ルール同士の 順序 は、細かい一致を上に、広い GEOIP や MATCH を下に、という ルール優先度 の基本に沿うのが安全です。
DNS・FakeIP・DoH：ルールの手前手後の整合
多くの分流は、名前解決の結果 と一体で解釈されます。OS の DNS だけが ISP 向き に残ると、得られた IP がルール想定と食い違い、ブラウザだけ 一瞬でタイムアウト したように見える、というズレが起きます。Clash Meta 系の nameserver-policy や DoH を使う場合は、変更点を一つずつ戻しながら検証すると切り分けが楽です。TUN との併用時の注意点は Meta コアの DNS 防漏洩 に集約しています。HTTPS の宛先が IP 表示のまま で DOMAIN 行に乗らないときは、Sniffer による SNI 復元 も候補になります。
システムプロキシと TUN：ブラウザ版とアプリ版を同じ配線に
ブラウザは OS プロキシ を踏みやすい一方、一部のデスクトップアプリは 直結 しやすく、同一ファイルでも見え方の差 が出ることがあります。TUN はルーティング層で捕捉しやすく、同一プロファイルの分流 に乗りやすいため、長接続の取りこぼしを減らしやすい場面があります。導入の流れは Clash Verge Rev の TUN 解説 を参照し、初回構成は Windows 向けセットアップ と併読すると、モード同士の切替が掴みやすいでしょう。他の 常駐 VPN や社内 二重化 があるとレイテンシと切断感が増すため、まずは最小の経路に絞って試す価値があります。
補足： デザイナー向けSaaSは WebSocket 前提の不調 を「帯域が遅い」と誤解しがちです。他サービスが速いのに Figma だけ遅いときは、figma 系 FQDN の出口が分裂していないか を優先してください。
推奨の切り分け順：ログ → ルール → DNS → TUN
- Clash を Rule モードで動かし、追記ルールが購読のマージで消えていないか確認する。
- 不調の操作を一つに絞り、接続ログの FQDN と 命中行 ・ 実出口名 を同じ時間帯に揃えて控える。
DOMAIN-SUFFIXで figma 系を 想定の単一ポリシー に寄せ、再測定する。- FakeIP / DoH 併用時は、名前解決が Clash の意図と揃うか DNS ログ を点検する。
- ブラウザとアプリで差がある場合、TUN かアプリ側のプロキシ表記の確認へ進む。改善しないなら、ノード品質と Figma 側の状況を分ける。
注意： 勤務先や契約により、代理や迂回の利用が制限される場合があります。許可のある環境でのみ実施し、顧客データの扱いは社内方針に従ってください。
他稿との棲み分け：Notion や文書SaaSとの違い
同じ WebSocket 安定化 という大枠でも、Notion 稿 はナレッジ同期・ブロック更新の帯域が主題で、ドメインの束 は文書用に偏ります。本稿の Figma は キャンバスと同時編集 が前面のため、接続名の揃え方は似ていても、コピーしたルール行を流用 すると誤配線のまま、という罠に注意してください。UI／UX 以外の生産性ツールを広く扱う場合は、ストリーミング系や AI 系の各記事と 照合用のログ行 を分けて持つと、来年以降のプロファイル整理も早くなります。
まとめ
Figma の キャンバス まわりの不具合表現の一部は、サーバー障害に見えても、端末の Clash 分流 と DNS 、そして WebSocket 前提の 長接続 の一貫性に結びつく場合があります。ログに出た figma 系 FQDN を DOMAIN-SUFFIX で 同一出口 に揃え、FakeIP ・Sniffer ・DoH ・TUN の整合を取れば、設計協業 の体感ブレを減らしやすいです。2026 年時点でも、流行に乗った雑多な KEYWORD 拡大より、観測に基づくサフィックス追記 が運用として堅いクライアントの入手先は 公式ダウンロード 、用語の整理は ドキュメント を合わせて参照してください。
Clash 系クライアントの強みは、経路の理由を テキストで再現性高く 残せる点にあり、デザイナーとエンジニアが同じプロファイル言語を見られると、接続の不安定さ の共有コストを下げられます。一度ルールの束が定まれば、同じ回線品質でも「キャンバスが気になる時間帯」が短く感じられやすくなるはずです。