Notion・Figma・Miroを快適に使うClashルール設定と仕事効率化ガイド

Notion・Figma・Miroを使うリモートワーク環境では、サービスごとに通信先や必要な接続先が異なります。Clashのルールで仕事用サービスを安定したプロキシへまとめ、国内サイトは直接接続するようにすると、すべての通信を同じ経路へ流すよりも状況を切り分けやすくなります。ここではmihomo系コアを使うクライアントを想定し、ドメインルールの組み方、既存設定との統合、動作確認の方法を説明します。

仕事用通信の経路を先に決める

Clashのルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。そのため、Notion・Figma・Miroを専用のプロキシグループへ振り分ける場合は、一般的な国内通信のルールや最後の MATCH より前に配置してください。仕事用ルールを末尾に追加しても、その前の広い条件に一致すれば到達しません。

最初に、どの通信をどの経路へ流すかを決めます。仕事用サービスを専用グループへまとめる方法は、あとから経路を一括で切り替えられるため、接続不良の比較に便利です。安定性を重視する日は低遅延のノード、社内VPNや認証の都合で直接接続が必要な環境ではDIRECTを選ぶなど、運用条件に合わせて切り替えられます。

通信の種類	基本方針	確認する点
Notion・Figma・Miro	専用の仕事用プロキシグループへ振り分け	ログイン、編集、画像や添付ファイルの読み込み
国内の一般サイト	環境に応じてDIRECT	組織のネットワーク規則やアクセス制限
社内システム・社内VPN	会社が指定する経路を優先	プロキシ利用の可否、認証方法、名前解決
その他の通信	既存の最後のルールへ委ねる	`MATCH` の宛先グループと現在のモード

Notion・Figma・Miroのドメインルールを書く

ドメインルールは、通信先のホスト名に応じて経路を選びます。サービスの画面だけでなく、API、画像、添付ファイルなどが別のドメインから配信される場合があるため、トップレベルのドメインだけで必要な通信をすべて捕捉できるとは限りません。一方で、関連ドメインを推測だけで大量に追加すると、無関係な通信までプロキシへ送る可能性があります。

次はルール部分の例です。すでにある rules: の配列へ追加し、同名のキーを重ねて作らないでください。ルールを実際のYAMLへ入れる際は、ハイフンの位置とインデントをそろえます。

rules:
  - DOMAIN-SUFFIX,notion.so,Work-Proxy
  - DOMAIN-SUFFIX,notion.site,Work-Proxy
  - DOMAIN-SUFFIX,notionusercontent.com,Work-Proxy
  - DOMAIN-SUFFIX,notionstatic.com,Work-Proxy
  - DOMAIN-SUFFIX,api.notion.com,Work-Proxy
  - DOMAIN-SUFFIX,figma.com,Work-Proxy
  - DOMAIN-SUFFIX,figmausercontent.com,Work-Proxy
  - DOMAIN-SUFFIX,miro.com,Work-Proxy
  - DOMAIN-SUFFIX,mirostatic.com,Work-Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Your-Default-Group

この例は、利用中のサービスがこれらのホスト名を使う場合の出発点です。サービス側の構成は変わることがあり、アカウント、機能、組織の設定によって必要な接続先も異なります。画面が表示されても、アップロードや共同編集が完了するとは限りません。失敗した操作がある場合は、Clashの接続一覧やログで実際の宛先を確認し、必要性を確かめたうえでルールを追加してください。

DOMAIN-SUFFIX,figma.com のようなルールは、そのドメインそのものとサブドメインを対象にします。たとえば api.figma.com も一致するため、広いドメインルールとAPI用ルールを重ねる必要は通常ありません。例に含めた api.notion.com は notion.so とは別のドメインなので、使っている環境で必要なら個別に指定します。ルールは広いドメインほど対象範囲が大きくなる点に注意してください。

既存のrulesと順序を合わせる

サブスクリプションの設定には、すでに GEOIP、GEOSITE、ルールプロバイダー、または複数の MATCH が含まれていることがあります。すべてを置き換えるのではなく、現在のルール一覧をバックアップしてから、仕事用のルールを適切な位置へ挿入します。たとえば、既存の GEOSITE,cn,DIRECT より後ろに仕事用ルールを置くと、先に一致した国内ルールが適用される可能性があります。

サービスのドメインルールは、広い国内・海外ルールや既定ルールより前に置きます。
最後の MATCH は通常1つだけにし、現在使っている既定のグループ名を維持します。
GEOSITE,cn,DIRECT は、コアのgeodata設定やルール形式が利用中の環境に合っている場合に使います。
GEOIP,CN,DIRECT,no-resolve はIPアドレスに対するルールです。ドメインルールの代わりにはならず、名前解決の挙動も確認が必要です。

国内サイトをDIRECTにする際の注意

国内サイトを直接接続する方法としては、特定ドメインの DOMAIN-SUFFIX ルール、mihomoのgeositeデータを使う GEOSITE,cn,DIRECT、IPの国情報を使う GEOIP,CN,DIRECT などがあります。どれを使うかは、設定ファイルとコアの対応状況、必要な精度で決めます。geositeのルールはドメイン分類に基づき、GEOIPは接続先IPの情報に基づくため、同じ対象を指す仕組みではありません。

仕事用サービスのルールを国内判定より先に置く理由は、サービス側のドメインが分類データ上でどのように扱われるかに左右されず、指定グループへ送れるようにするためです。特定のサービスをDIRECTにしたい場合は、対象のドメインを明示したルールを追加します。ルールの並びを変えたときは、Clashの接続一覧で適用されたルール名と出口を確認してください。

会社のネットワークでは、一般的な「国内はDIRECT」という方針が適さない場合もあります。社内システムがVPN内でしか解決できない、社内プロキシの利用が必須、外部プロキシが禁止されている、といった条件があれば、組織の指定を優先してください。TUNを有効にしている場合は、ブラウザーのシステムプロキシ設定だけでは通信経路を判断できないことがあります。TUNのルーティングやDNS処理を含め、接続ログで確認しましょう。

仕事用プロキシの選び方と切り分け

ノードを選ぶときは、速度測定の数値だけで決めず、実際に使う時間帯と作業を基準に比較します。Notionのテキスト表示が速くても、Figmaの大きなファイルやMiroの共同編集が安定するとは限りません。遅延、パケットロス、サーバーの混雑、ネットワーク側の制限は時間帯でも変わるため、同じ操作を同じ条件で試すのが有効です。

確認すること	試し方	結果の見方
ログインとページ表示	Notion、Figma、Miroを個別に開く	認証ループやタイムアウトがないか確認
ファイル・画像の読み込み	既存の小さな画像やテスト用ファイルで確認	画面は開くのに素材だけ欠ける場合は宛先を調査
共同編集	権限のあるテストページやボードで変更を反映	更新遅延、再接続、同期エラーの有無を比較
国内サイトとの併用	仕事用サービスと一般的な国内サイトを交互に開く	DIRECT対象と仕事用グループが意図どおりか確認

比較時は、最初に利用中のノードを記録し、仕事用グループの出口だけを切り替えます。ルール、DNS、TUNの設定まで同時に変更すると、改善した要因を特定できません。ネットワークが不安定なときは、まず別ノードで同じページを試し、その後に対象ドメインのルールとログを調べます。WebSocketなどの持続接続が関係する機能は、ページを開くだけでなく、共同編集や更新の反映まで確認してください。

反映を確認し、設定を安全に保つ

作業前に現在の設定を複製し、変更前のファイルへ戻せるようにします。
ルールの参照先グループが proxy-groups に存在すること、YAMLのインデントが正しいことを確認します。
クライアントで設定を再読み込みし、コアのログに構文エラーやルール読み込みエラーがないか確認します。
Notion・Figma・Miroを一つずつ開き、接続一覧で宛先、適用ルール、選択されたプロキシを確認します。
国内サイトも試し、DIRECTにする予定の通信が実際に直接接続されているか確認します。

ルールが一致しない場合は、まず接続一覧に表示されるホスト名を確認します。ブラウザーのキャッシュで画面が表示されているだけでは、現在の通信が成功した証拠にならないことがあります。表示、ログイン、ファイルの取得、編集内容の同期を分けて試し、どの段階で止まるかを記録してください。ホスト名が予想と異なる場合は、サービス名からドメインを推測して追加するのではなく、その通信が対象機能に必要かを確かめます。

サブスクリプションの更新で独自ルールが消える環境では、クライアントのルール上書きやマージ機能を使えるか確認し、利用中のバージョンに合わせて設定してください。上書き機能の扱いはクライアントごとに異なるため、YAMLを直接編集する方法と同じだと決めつけないようにします。変更後にコアへ渡される最終設定とログを確認し、更新後もルールが残っていることをテストしましょう。