Notion・Figma・Miroを快適に使うClash仕事術と分割設定

仕事用サービスを「必要な通信だけ」に分ける

Notionで資料を整理し、Figmaでデザインを確認し、Miroでオンライン会議を進める環境では、すべての通信を常時プロキシへ送るよりも、サービス単位で経路を分けたほうが扱いやすい場合があります。Clashのルール設定を使えば、Notion、Figma、Miroのように接続先を指定した通信だけをプロキシグループへ送り、OSのアップデート、社内システム、国内の一般サイトなどは直接接続にできます。

ここで重要なのは、アプリ名だけで振り分けるのではなく、実際にアクセスするドメインと通信方式を確認することです。Notionの画面を開いていても、画像、ファイル、認証、分析用のホストへ別々に接続することがあります。Figmaもデザインデータ本体、画像アセット、フォント、コメント、ログイン処理で複数のドメインを使う場合があります。Miroではボード本体に加えて、リアルタイム更新のWebSocketや画像配信が発生します。代表ドメインだけを登録すると、ログインはできてもファイルが表示されない、コメントが更新されない、ボードの共同編集が遅れるといった状態になりやすいでしょう。

登録するドメインを決める方法

ドメイン一覧は、第三者の固定リストをそのまま貼り付けるより、実際の環境で確認するのが安全です。ブラウザーの開発者ツール、Clashまたはmihomoの接続ログ、クライアントの接続一覧を使い、サービスへログインした直後、ファイルを開いたとき、コメントを追加したとき、会議ボードを共同編集したときに発生する接続を記録します。会社のSSO、VPN、プロジェクト管理ツールを使っている場合は、それらのドメインを業務上必要な通信として別に扱います。

Notion：notion.so と notion.site を中心に確認します。画像やファイルの配信先が別ドメインになることがあるため、接続ログで補完します。
Figma：figma.com を中心に、ログイン、デザインファイル、コメント、画像アセットの通信を確認します。
Miro：miro.com とボード編集時の追加接続を確認します。WebSocketを使う通信では、ブラウザーの画面だけでなく接続ログも見ます。
認証サービス：会社のSSOや多要素認証のドメインを、Notionなどのサービスドメインと混同しないように記録します。

DOMAIN-SUFFIX は対象ドメインとそのサブドメインをまとめて指定する記法です。たとえば DOMAIN-SUFFIX,notion.so,WORK は www.notion.so などにも一致します。一方、単一ホストだけを指定したい場合は DOMAIN を使います。広すぎるドメインを登録すると、業務サービス以外の通信までプロキシへ送るため、まずは公式ドメインと接続ログに現れたホストだけから始めてください。

プロキシグループと直接接続を設計する

ルールを書く前に、プロキシグループの役割を決めます。仕事用サービスをまとめて1つのグループへ送るなら、通常は手動選択用の select グループが分かりやすいでしょう。複数ノードから自動的に応答の速いものを選びたい場合は url-test を使えますが、測定URLへの遅延が低いノードが、Figmaの大きなファイルやMiroのリアルタイム通信でも最適とは限りません。安定性を優先する仕事環境では、最初は手動選択で挙動を確認し、必要に応じて自動選択へ変更します。

mode: rule
mixed-port: 7890
allow-lan: false

proxy-groups:
  - name: WORK
    type: select
    proxies:
      - AUTO
      - DIRECT

  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - Tokyo-01
      - Singapore-01

rules:
  - DOMAIN-SUFFIX,notion.so,WORK
  - DOMAIN-SUFFIX,notion.site,WORK
  - DOMAIN-SUFFIX,figma.com,WORK
  - DOMAIN-SUFFIX,miro.com,WORK
  - MATCH,DIRECT

この例では、Notion、Figma、Miroに一致した通信だけが WORK へ送られ、それ以外は最後の MATCH,DIRECT によって直接接続されます。DIRECT はプロキシを経由しない意味であり、通信内容が暗号化されることや、会社のアクセス制御を回避できることを意味しません。会社のネットワークポリシー、情報管理規則、サービス提供元の利用条件は別途守る必要があります。

ルールの順序で結果が変わる

Clashとmihomoのルールは上から順番に評価され、最初に一致したルールが使われます。先に GEOIP,CN,DIRECT や大きなルールセットを置くと、NotionやFigmaの通信がそのルールで処理され、後ろに書いたサービス専用ルールへ到達しないことがあります。サービスを必ずプロキシへ送りたい場合は、サービス固有の DOMAIN-SUFFIX を広い地域ルールより上に置いてください。

例外として直接接続したい社内ホストを、サービスルールより上に置く。
Notion、Figma、Miroの公式ドメインを、一般的な地域ルールより上に置く。
必要なルールセットを評価した後、最後に MATCH,DIRECT または環境に合った既定ルールを置く。
同じドメインを異なるグループへ送る重複ルールを作らない。

FlClashで分割設定を適用する手順

実際の画面名はFlClashのバージョンや使用する設定形式によって異なりますが、基本の流れは共通しています。まず現在のサブスクリプション設定を複製し、元の設定を直接上書きしない状態で試してください。購読更新によってYAMLが再生成される構成では、手作業で追加したルールが次回更新時に消えることがあります。ローカルオーバーライド、Mixin、設定の拡張機能が利用できる場合は、そちらに分割ルールを保存するほうが管理しやすいでしょう。

FlClashの設定一覧から、普段使っているプロファイルを複製します。
使用中のカーネルがmihomoであることと、設定が正常に解析できることを確認します。
proxy-groups に仕事用の WORK グループを追加します。
rules の上部または既存の優先ルールの位置に、Notion、Figma、Miroのドメインルールを追加します。
設定を保存して再読み込みし、構文エラーや未定義のプロキシグループがないかログで確認します。
システムプロキシを有効にし、各サービスでログイン、ファイル閲覧、編集、コメント、同期を順番にテストします。

YAMLではインデントにタブを使わず、通常は半角スペース2個で階層をそろえます。グループ名を WORK と定義したのに、ルール側で WORK_PROXY と書くと、そのルールは正しく処理できません。ノード名に記号や日本語が含まれる場合も、プロキシグループの proxies 配列に書いた名称と完全に一致させてください。設定を編集する前にファイルのコピーを保存しておけば、失敗時に元のプロファイルへ戻せます。

TUNを使う場合の注意点

FigmaのデスクトップアプリやMiroのアプリがシステムプロキシを参照しない場合、TUNモードが必要になることがあります。TUNは仮想ネットワークインターフェースで端末の通信を取り込むため、ブラウザーだけでなくプロキシ設定を持たないアプリもルール対象にできます。その一方で、DNS処理、ルート設定、IPv6、VPN権限が結果に影響します。TUNを有効にしても通信が変わらない場合は、アプリが独自の名前解決を行っていないか、IPv6通信がルールを別経路で通過していないかを確認してください。

仕事用サービスだけをプロキシへ送る目的なら、まずTUNを無効にした状態でドメインルールを検証し、その後に必要なアプリだけTUNへ切り替えるのが安全です。TUN利用時は、DNSの応答先までプロキシ経由にするか、国内ドメインを直接解決するかを環境に合わせて決めます。DNSが不安定な状態でルールだけを変更しても、ドメイン名をIPアドレスへ変換できず接続失敗になることがあります。

通信結果を確認し、仕事への影響を抑える

設定後は「Webページが開くか」だけで判断しないでください。Notionではワークスペースのログイン、ページ検索、画像表示、ファイルのアップロードを確認します。Figmaではファイル一覧、デザインデータ、コメント、共有リンク、画像の読み込みを確認します。Miroではボードの表示、付箋の追加、他の参加者とのリアルタイム同期、画像の貼り付けを確認します。サービスごとに通信先が異なるため、トップページだけが開いても設定が完全とは限りません。

症状	確認する項目	対処の方向
ログイン画面だけ表示される	認証、SSO、多要素認証の接続先	接続ログで追加ドメインを特定し、同じ経路へ追加する
ページは開くが画像やファイルがない	CDN、アップロード、ファイル配信ホスト	表示時の接続先を確認し、必要なホストだけルールへ追加する
Miroの更新が遅い、共同編集できない	WebSocket、DNS、TUNの取り込み状態	接続ログとTUN設定を確認し、別ノードでも比較する
国内サイトまで遅くなった	広すぎるドメイン指定、ルール順、MATCHの動作	不要なサフィックスを削除し、最後の既定ルールを確認する
アプリだけ接続できない	システムプロキシ対応、独自DNS、TUN権限	システムプロキシとTUNを一つずつ切り替えて原因を分離する

テスト中は、一度に複数の設定を変更しないことが大切です。まずドメインを1つ追加し、設定を再読み込みしてから対象操作を繰り返します。改善した場合は、そのドメインが必要だったことを記録します。改善しない場合は、プロキシノード、DNS、認証状態、アプリ側のキャッシュを順番に確認してください。速度だけでなく、接続の安定性、ファイル同期の失敗、会議中の再接続回数も評価項目に含めると、仕事に適したノードを選びやすくなります。

この構成の目的は、通信を無条件にプロキシへ送ることではありません。Notion、Figma、Miroの業務通信を安定した経路へ振り分けながら、普段の国内通信を直接接続に残し、遅延、帯域、トラブルシューティングの範囲を抑えることです。まずはシステムプロキシと少数のドメインルールで始め、必要性が確認できたサービスだけを追加してください。