Notion・Figma・Miroだけが重いときの考え方

Notion、Figma、Miroを仕事で使っていると、「ブラウザの一般的なページは開くのに、ワークスペースだけ読み込みが遅い」「Figmaのファイル一覧は表示されるが、画像やコンポーネントの同期で止まる」「Miroのボードは開くものの、共同編集のカーソルやコメントが数秒遅れて反映される」といった症状に遭遇することがあります。こうした場合、最初から全通信をプロキシへ流す必要はありません。Clashの分割ルーティングで、対象サービスのドメインだけを安定したプロキシグループへ送り、OSの更新、社内サービス、プリンター、ビデオ会議の音声などは通常経路に残す方が、仕事用端末の予測しやすさを保てます。

Notion・Figma・Miroは単一のWebページだけで完結するサービスではありません。画面を表示するメインドメイン、画像やファイルを配信するCDN、認証、WebSocketや長時間接続、場合によっては外部ストレージが別々のホスト名を使います。そのため、notion.soだけを追加しても画像が空白のまま、figma.comだけを追加してもコメントの同期だけ失敗する、といったことが起こります。Clashの接続ログで実際に呼び出されたホストを確認し、必要な範囲だけルールを補うことが基本です。

また、制作ツールの快適さは単純なダウンロード速度だけで決まりません。Figmaの共同編集やMiroのボード操作では、平均速度よりも遅延、ジッター、接続の安定性が重要です。Notionのページを開く場合も、HTMLが先に返ってきても画像、埋め込み、添付ファイル、検索結果のAPI通信が遅ければ、利用者には「Notionが重い」と見えます。以下では、サービス別のルール、DNSとTUNの組み合わせ、Windows・macOSでの確認手順を順番に整理します。

前提：Clashのルールは利用しているクライアントとMihomoコアの記法に合わせてください。会社の端末、社内ネットワーク、顧客データを扱う環境では、プロキシ利用が許可されているかを先に確認し、機密情報を第三者の経路へ送らない運用を徹底してください。

サービス別に分流ルールを設計する

最初におすすめしたいのは、Notion、Figma、Miroを一つの巨大な「海外サイト」グループにまとめるのではなく、用途別のプロキシグループを作る方法です。例えば、通常の閲覧と同期を同じグループにしてもよい一方、Figmaの長時間編集セッションだけは、切り替えが頻繁に起きない固定ノードへ分けると安定しやすくなります。自動選択グループは便利ですが、url-testの判定によってノードが変更されると、WebSocketや共同編集セッションが切断されることがあります。

ルールの順番も重要です。広いGEOIPや「海外サイトをすべてプロキシ」のルールより前に、サービス固有のドメインルールを置きます。ルールプロバイダを使う場合でも、最後に書かれたルールが必ず勝つとは限らないため、既存の設定で採用されているルール順序を確認してください。代表的な出発点は次のような形です。

rule-providers:
  work-tools:
    type: http
    behavior: classical
    url: https://example.invalid/work-tools.yaml
    path: ./ruleset/work-tools.yaml
    interval: 86400

rules:
  - RULE-SET,work-tools,WORK_TOOLS
  - DOMAIN-SUFFIX,notion.so,WORK_TOOLS
  - DOMAIN-SUFFIX,notion.site,WORK_TOOLS
  - DOMAIN-SUFFIX,figma.com,WORK_TOOLS
  - DOMAIN-SUFFIX,figmausercontent.com,WORK_TOOLS
  - DOMAIN-SUFFIX,miro.com,WORK_TOOLS
  - MATCH,DIRECT

上のホスト名は固定的な完全リストではありません。サービス側の構成変更や地域別配信によって、別のCDN、認証ホスト、ファイルストレージが接続先になることがあります。実際にNotionの画像が表示されない場合は、ページ本体のドメインだけでなく、接続ログから画像リクエストのホストを探します。Figmaでは画像やアセットの配信先、Miroではボードデータやリアルタイム更新に使われる接続先が別に記録されることがあります。見つけたホストを一度だけ追加し、問題が解消したかを再読み込みで確認するのが安全です。

Notion・Figma・Miroの見分け方

  • Notion：ワークスペースの表示、検索、ページ更新、画像・添付ファイルの取得を別々に確認します。ページの枠だけ表示されて本文や画像が遅い場合は、メインドメインではなくアセット配信先がボトルネックになっている可能性があります。
  • Figma：ファイル一覧、編集画面、画像アセット、コメント、共同編集のカーソルを分けてテストします。編集画面だけ不安定なら、短時間のHTTP通信ではなく長時間接続とノードの切り替えを疑ってください。
  • Miro：ボードの初期表示、付箋や図形の保存、他の参加者の変更反映、コメント通知を確認します。ボードは開けても変更が保存されない場合、ルール対象の不足またはWebSocket経路の問題が考えられます。

ノード選びでは、単発の速度テストだけを基準にしないことが大切です。制作ツールでは数百Mbpsの帯域より、数十分間の編集で切断しないこと、TLS接続が安定すること、急な経路変更が起きないことが優先されます。プロキシグループに複数ノードを登録する場合は、まず手動選択で相性を確認し、その後に自動選択へ戻すと原因を追いやすくなります。

TUNとDNSを調整してアプリの取りこぼしを防ぐ

ブラウザでNotionやFigmaを使うだけなら、システムプロキシとブラウザのHTTP設定で足りることがあります。しかしデスクトップ版Figma、Miroのアプリ、埋め込みブラウザ、アップロード補助プロセスなどは、OSのプロキシ設定を完全には継承しない場合があります。このとき、ブラウザでは動くのにアプリだけ同期しないという差が生まれます。アプリを閉じた状態でClashの接続一覧を確認し、起動後に対象ホストが一件も現れないなら、TUNを検討する段階です。

TUNは仮想ネットワークインターフェースを通じて、システムプロキシを使わないアプリの通信もClashへ渡す方式です。設定の例は次のとおりです。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  strict-route: true

ただし、TUNを有効にしたからといって、すべての通信を同じプロキシへ送る必要はありません。Notion・Figma・Miroのルールを先に置き、社内のプライベートネットワーク、ルーター管理画面、プリンター、会社のVPN関連ドメインは必要に応じてDIRECTまたはバイパスへ設定します。TUNで突然イントラネットへ入れなくなった場合、プロキシノードの問題ではなく、ローカル宛先を外へ出しているルーティングミスが原因かもしれません。

DNSも見落とされやすい部分です。DNSをOSやブラウザに任せたままTUNだけ有効にすると、名前解決と実際の接続経路が分離し、地域判定の違い、IPv6経路の混在、Fake-IPとの不整合が起こることがあります。Clash側でDNSを処理するなら、DNSの有効化、Fake-IPまたはRedir-Hostの選択、ローカルドメインの除外を確認してください。特に社内ドメインを外部DNSへ送ると、名前が解決できないだけでなく、内部ホスト名が外部サービスへ漏れるおそれがあります。

注意：DNS設定を一度に大きく変更しないでください。まず現在の設定を保存し、DNSだけ、次にTUNだけという順番で変更します。切り替え後はブラウザのDNSキャッシュ、OSのネットワーク状態、Clashの接続ログを確認すると、どの変更で症状が変わったか追跡できます。

WindowsとmacOSでの実践手順と切り分け

設定を作ったら、いきなり仕事の本番ファイルで試すのではなく、読み取り中心のテストページや複製したボードを使います。次の手順では、まず対象サービスだけをプロキシへ送り、その後に必要ならTUNを追加します。

  1. プロファイルを複製する：現在動いているYAMLを直接上書きせず、仕事用のテストプロファイルを作ります。購読更新で手動ルールが消えるクライアントでは、拡張設定やオーバーライドの保存場所も確認します。
  2. 専用グループを作る：WORK_TOOLSのようなグループに、安定性を確認したノードを登録します。最初は自動切り替えを避け、手動選択でNotion、Figma、Miroを順番に開きます。
  3. ドメインルールを追加する：DOMAIN-SUFFIXでサービスの主要ドメインを指定し、広域ルールより上に配置します。接続ログに未知のCDNや認証ホストが出たときだけ、影響範囲を確認して追加します。
  4. Windowsで確認する：システムプロキシをオンにし、設定画面のHTTP混合ポートが正しいことを確認します。デスクトップアプリだけが直行する場合は、管理者権限でTUNを有効にし、Windows Defenderや他のVPNソフトが仮想アダプターを遮っていないか調べます。
  5. macOSで確認する：システム設定のネットワーク拡張やVPN構成の許可を確認します。TUNを使う場合は、Clashクライアントのサービスモードとネットワーク拡張が有効になっていること、他のフィルタリングアプリと競合していないことを確認します。
  6. 一項目ずつ再現する：Notionは画像と検索、Figmaはファイル編集とコメント、Miroは共同編集と保存を個別に試します。症状が出た時刻にClashの接続一覧を保存し、ホスト名、プロキシグループ、切断や再接続の有無を記録します。

Windowsでブラウザだけが動く場合は、アプリがシステムプロキシを参照しているか、WinHTTP設定や独自のプロキシ設定を持っているかを確認します。逆に、すべてのアプリが遅くなった場合は、ルールの問題だけでなくTUNのMTU、IPv6、別VPNとの競合を疑います。いったんTUNを無効にしてシステムプロキシへ戻し、症状が消えるかを比較すると判断しやすくなります。

macOSでは、アプリごとにネットワーク拡張の扱いが異なります。Clashのメニュー上では接続済みに見えても、許可ダイアログを拒否したままだと一部の通信が捕捉されないことがあります。また、iCloud Private Relay、会社のMDMプロファイル、別のDNSフィルターが有効な場合、Clashだけを調整しても結果が変わらないことがあります。不要なネットワーク拡張を一時停止し、変更は一つずつ行ってください。

最終的な確認では、体感だけでなく、ページの初期表示時間、画像が現れるまでの時間、コメントや付箋が保存されるまでの時間、30分程度の編集中に接続が切れなかったかを記録します。問題が解決したら、使っていない広域ルールや重複したプロキシ指定を整理し、設定を簡潔に保ちます。ルールを増やし続けるより、接続ログに基づいて必要なドメインだけを残す方が、将来のサービス変更にも対応しやすくなります。

一般的なVPNアプリは全通信を一括で切り替える設計が多く、NotionやFigmaだけを選んで経路変更したい場面では、社内サービスやオンライン会議まで巻き込んだり、アプリごとの例外設定が複雑になったりします。別のプロキシGUIも高機能ですが、Mihomo系ルール、TUN、DNS、接続ログを一つの流れで確認できない製品では、今回のような「ブラウザは動くが同期だけ遅い」問題の切り分けに時間がかかります。Clash 公式サイトならサービス別ルールを段階的に追加し、WindowsとmacOSで同じ考え方のプロファイルを管理しながら、必要な通信だけを安定したグループへ振り分けられます。制作環境を大きく変えずにNotion・Figma・Miroの動作を見直したいなら、まずはClash 公式サイトを無料でダウンロードして、接続ログを見ながら小さく試してみてください。