この記事で分かること
Notion、Figma、Miro は、議事録の整理、UI デザイン、オンラインホワイトボードを一つの仕事環境で完結できる便利なサービスです。一方で、海外のクラウドサービスへ接続するため、ページの読み込みが遅い、画像やフォントの取得だけ失敗する、共同編集の更新が止まる、ログイン画面から先へ進めないといった問題が起きることがあります。ブラウザ全体を常にプロキシへ通せば解決する場合もありますが、国内の業務サイトや社内システムまで遠回りさせると、かえって速度や安定性が落ちることがあります。
本稿では、Clash のルール分流を使って、Notion・Figma・Miro など必要な海外サービスだけをプロキシ経由にし、国内通信は DIRECT のまま維持する考え方を解説します。単にドメインを並べるだけではなく、ノードの選び方、システムプロキシと TUN の使い分け、DNS や WebSocket の確認、ログを使った漏れの見つけ方まで、仕事で再現しやすい順番に整理します。
なお、これらのサービスはログイン、API、画像 CDN、フォント、コメント通知など複数のホストへ接続します。そのため「トップページは開くのに編集画面だけ動かない」という現象も珍しくありません。最初からすべての通信をプロキシへ送るのではなく、Clash の接続ログを見ながら必要な範囲を少しずつ追加することが、安定性と管理しやすさを両立するポイントです。
Notion・Figma・Miroで起きやすい通信の問題
クラウド型の仕事ツールは、単一のサーバーだけで機能しているわけではありません。Notion でページを開くときは、認証、ワークスペース情報、本文データ、画像、ファイルプレビュー、通知などが別々の接続になることがあります。Figma ではデザインファイル本体だけでなく、画像素材、コメント、カーソル位置、フォント情報を取得します。Miro もボードの初期表示後に、付箋、図形、コメント、参加者の操作をリアルタイムで同期します。
この構造を理解しないまま一つのドメインだけを PROXY にすると、ログインは成功しても次のような症状が残ります。
- Notion：ワークスペースは表示されるが、ページ本文や画像が読み込まれない。編集内容の同期に時間がかかる。
- Figma：ファイル一覧は開くが、キャンバスが白いままになる。コメントや共同編集者のカーソルが更新されない。
- Miro：ボードの枠だけ表示され、付箋や画像が遅れて現れる。操作後の保存やリアルタイム反映が不安定になる。
- 共通：ログインのリダイレクト、認証トークン、CDN、WebSocket のどれかが別経路へ流れ、成功と失敗が交互に発生する。
最初に確認したいのは、アプリそのものの障害と経路の問題を分けることです。同じサービスをスマートフォンのモバイル回線で開き、会社や自宅のネットワークだけで再現するかを確認します。複数の端末で同じ時間帯に障害が出ているならサービス側の可能性がありますが、Clash を有効にした端末だけで失敗するなら、ルール、DNS、ノード、またはローカルのプロキシ設定を優先して調べます。
また、ブラウザの開発者ツールを使える場合は、Network タブで赤くなったリクエストのホスト名とステータスコードを確認します。接続タイムアウトや名前解決エラーなら経路を疑い、401 や 403 が返る場合は認証・Cookie・アカウント権限の問題も考えます。すべてを「Clash が遅い」と決めつけず、どの通信が止まっているかを特定することが重要です。
Clashの分流ルールを設計する
ルールモードでは、上から順番に条件が評価され、最初に一致したポリシーへ通信が送られます。そのため、Notion や Figma を PROXY にしたい場合は、広い範囲の DIRECT や GEOIP より前に専用ルールを置く必要があります。ルールが正しく見えても、実際には下のルールへ先に一致していることがあるため、設定後は必ず接続ログで確認してください。
プロファイルを直接編集できる環境では、まず代表的なサービスのドメインを独立したルールとして記述します。実際のドメイン名や構成はクライアント、地域、サービスの更新によって変わるため、次の例は考え方を示す最小構成として扱ってください。
rules:
- DOMAIN-SUFFIX,notion.so,WORK
- DOMAIN-SUFFIX,notion.site,WORK
- DOMAIN-SUFFIX,figma.com,WORK
- DOMAIN-SUFFIX,miro.com,WORK
- MATCH,DIRECTWORK は、安定したノードをまとめたプロキシグループの名前です。実際のプロファイルでグループ名が Proxy、手動選択、Auto などになっている場合は、その名前に置き換えます。Notion の共有ページを独自ドメインで公開している場合や、Figma の素材を別 CDN から取得している場合は、ログに現れたホストを確認して追加します。ただし、広い CDN ドメインを無条件にプロキシへ送ると、国内サイトまで対象になることがあるため、最初は必要なサブドメインだけに限定する方が安全です。
会社のポータル、勤怠、銀行、行政サービス、プリンター管理画面などは、原則として DIRECT に残します。これらを海外ノード経由にすると、IP 制限、二段階認証、社内アクセス制御、地域判定に影響する可能性があります。自分で追加したルールには用途が分かるコメントを付け、後から見たときに「なぜ PROXY にしたのか」を説明できる状態にしておくと、チームで設定を共有するときにも役立ちます。
ノード選択とシステムプロキシ・TUNの使い分け
分流ルールが合っていても、ノードの混雑や相性によって共同編集の体感は変わります。Notion の文章編集だけなら短いリクエストが多いため、単純な速度テストの数値が高くなくても安定したノードが使いやすい場合があります。一方、Figma の画像素材や Miro のボードは転送量が増えやすく、速度だけでなく長時間接続が切れにくいこと、TLS 接続が頻繁に再確立されないことも重要です。
ノードを選ぶときは、次の順番で比較すると判断しやすくなります。
- 遅延：接続開始が速いか。ただし、ICMP の数値だけで Web サービスの実速度を判断しない。
- 継続性：十数分の編集作業中に接続が切れないか。共同編集では瞬間的な速度より安定性が重要です。
- 転送速度：Figma の画像や Miro の添付ファイルを開いたときに待ち時間が長くならないか。
- 地域との相性：近い地域のノードが必ず最速とは限らないため、実際のサービス操作で比較する。
通常は Clash Verge や Mihomo 系クライアントのシステムプロキシを有効にし、ブラウザで Notion、Figma、Miro の動作を確認します。システムプロキシは多くのブラウザや一般的なアプリに適用されるため、初期確認に向いています。ただし、アプリが独自の通信方式を使っている場合、システムプロキシを見ないことがあります。その場合だけ TUN モードを検討します。
TUN は、アプリ側にプロキシ設定がなくても OS のネットワーク層から通信を取り込める強力な方法です。しかし、企業 VPN、セキュリティソフト、Docker、仮想マシン、別の VPN クライアントと競合することがあります。TUN を有効にする前に、現在の VPN と仮想ネットワークの状態を記録し、問題が起きたときに元へ戻せるようにしてください。業務端末では管理者ポリシーに反する場合もあるため、会社の規約を優先します。
特に注意したいのは、TUN を有効にしただけで全通信が適切に分流されるわけではない点です。DNS の処理方式、IPv6 の経路、ループバック除外、LAN 通信の許可が不適切だと、国内サービスまで遅くなったり、ローカルの共有フォルダに接続できなくなったりします。まずシステムプロキシで成功した設定を基準にし、TUN は一つずつ変更を加えながら試すのが安全です。
ログと実測で設定を仕上げる
設定後は、トップページが表示されたことだけで成功と判断しないでください。Notion ではページを開いて本文を編集し、別の端末または同僚の画面に変更が反映されるか確認します。Figma では画像を含むファイルを開き、コメントの追加、ズーム、共同編集者のカーソル表示を試します。Miro では付箋、図形、画像、コメントを一通り操作し、ページを再読み込みして内容が保持されているか確認します。仕事で実際に行う操作を短いテストシナリオにしておくと、ノード変更後の比較も簡単になります。
Clash の接続ログでは、対象ホスト、使用された规则、ポリシーグループ、接続の成否を確認します。Notion の同期だけ失敗するなら、ログイン用ホストではなく同期や API のホストが DIRECT に落ちていないかを調べます。Figma のキャンバスだけ表示されない場合は、画像 CDN や WebSocket に相当する通信を確認します。Miro の操作が固まる場合は、短い HTTP 通信ではなく、長時間維持される接続がノードやネットワーク機器によって切断されていないかを見ます。
ルールを追加するときは、一度に大量のドメインを登録しないことが大切です。変更前にプロファイルをバックアップし、代表ページを開き、ログで漏れているホストを一つ追加し、再び同じ操作を行います。この手順なら、追加したドメインが本当に必要だったか、別のルールが誤って広い通信を拾っていないかを確認できます。ルールを編集した後は、プロファイルの再読み込みや Clash コアの再起動が必要な場合もあります。
それでも接続できない場合は、次の項目を順番に確認します。
- 現在選択しているプロファイルが、編集したプロファイルと一致しているか確認する。
- プロキシグループが停止中のノードや期限切れのノードを選んでいないか確認する。
- ブラウザに残った Cookie、拡張機能、別の VPN 設定が通信へ影響していないか確認する。
- DNS の名前解決結果が環境ごとに大きく異なっていないか確認する。
- ログのルール名を読み、想定した PROXY ではなく DIRECT や REJECT に一致していないか確認する。
複数人で使う設定では、個人の認証情報や購読 URL をプロファイルへ直接埋め込まないでください。購読 URL はノード情報を取得できる重要な情報です。共有用のルールと個人用の接続情報を分け、設定ファイルを Git やチャットへ貼る場合は URL、トークン、秘密鍵を削除します。また、会社のデータを扱う場合は、プロキシ事業者のログ方針や社内の情報管理規程も確認してください。
ブラウザ拡張だけで切り替える方法は手軽ですが、アプリごとに設定が分散し、Figma や Miro のデスクトップ版、通知サービス、ファイル同期まで同じ経路に揃わないことがあります。反対に全体 VPN は設定が単純でも、国内通信まで遠回りになり、社内サイトや地域制限のあるサービスに影響しやすいという欠点があります。その点、Clash はドメイン単位のルール、ノードグループ、接続ログ、システムプロキシと TUN の切り替えを一つの画面で管理でき、Notion・Figma・Miroだけを安定した経路へ送る構成を作りやすいのが実務上の強みです。