ClashでNotion・Figma・Miroを快適化する仕事用設定ガイド
NotionやFigmaの表示が遅い、Miroの共同編集が安定しないときは、Clashの分流を見直しましょう。仕事で使うサービスだけを適切に経由させ、国内通信を維持する設定を具体的に説明します。
仕事用にClashを調整する理由
Notionのページを開くまでに時間がかかる、Figmaのファイル一覧は表示されるのにキャンバスだけが読み込まれない、Miroのボードで共同編集するとカーソルや付箋の反映が遅れる。この3つの症状は、単純な回線速度だけでなく、サービスごとに異なる通信経路、DNS応答、WebSocket接続、静的ファイル配信の違いによって発生します。
Clashのグローバルモードで全通信を同じノードへ送ると、海外サービスは開きやすくなる一方、国内の社内ツール、プリンター、ファイルサーバー、ビデオ会議サービスまで遠回りになります。仕事用の設定では、Notion・Figma・Miroの関連通信だけを専用のプロキシグループへ送り、それ以外は既存の国内分流を維持する構成が扱いやすいでしょう。
ここで重要なのは、トップページのドメインだけをプロキシに入れれば終わり、と考えないことです。ログイン、画像、フォント、ファイルの読み込み、コメント通知、リアルタイム編集は別のホスト名やCDNを利用する場合があります。そのため、最初は対象サービスの通信を広めに捕捉し、ログで確認した後に不要な通信を整理する手順が安全です。
先にバックアップを作成する
設定ファイルを直接編集する前に、現在使用中のプロファイルを複製してください。プロファイル提供元の更新で手動編集部分が上書きされることもあるため、可能であればローカルのオーバーライド機能、または設定のマージ機能を使って追加ルールを管理します。
サービス専用プロキシグループを用意する
まず、仕事用サービスをまとめて送るポリシーグループを作ります。グループ名は後でルールから参照するため、英数字の短い名前にしておくとクライアント間で移行しやすくなります。例えば WORK という選択式グループを作り、仕事用ノード、低遅延ノード、予備ノードを登録します。
proxy-groups:
- name: WORK
type: select
proxies:
- Work-Primary
- Work-Backup
- DIRECT
select は利用者がノードを選ぶ方式です。候補の応答速度を自動測定したい場合は url-test を使えますが、測定先が単一サービスに偏ると、実際のFigmaやMiroの体感と一致しないことがあります。業務中に勝手にノードが切り替わるとWebSocketが切断される可能性もあるため、安定性を優先するなら最初は select が無難です。
既存の設定にすでにプロキシグループがある場合は、新しいグループを増やさず、そのグループを利用しても構いません。ただし、仕事用サービスの通信量や接続状態を個別に確認したい場合は専用グループの方が原因を追いやすくなります。ノード選びでは、速度の数値だけでなく、TCP接続の安定性、長時間接続の維持、混雑時間帯の遅延を確認してください。
対象ドメインを広げすぎない考え方
Notion、Figma、Miroはいずれも、画面本体とAPI、認証、アセット、リアルタイム通信が分離される構成を取ることがあります。公式ヘルプや管理者向け資料に掲載された接続先を基準にし、サービス名を含むという理由だけで無関係なドメインを一括プロキシにするのは避けます。特に分析、広告、埋め込みコンテンツまで同じ条件で送ると、通信量と待ち時間が増えます。
- 画面が表示されない場合は、HTML本体だけでなくAPIと静的アセットの接続を確認する。
- ログインできない場合は、認証用ホストと時刻、Cookie、ブラウザの拡張機能を確認する。
- 共同編集だけが不安定な場合は、WebSocketまたは長時間のHTTPS接続を確認する。
- ファイルのアップロードだけ失敗する場合は、ストレージ用の接続先が別扱いになっていないか確認する。
Notion・Figma・Miroを分流するルール
ルールは上から下へ評価され、最初に一致した行で処理が終了します。したがって、仕事用の明確なドメインルールを国内全体の GEOSITE,cn,DIRECT や GEOIP,CN,DIRECT より前に置く必要があります。後ろに追加すると、国内IPへ解決された対象が先にDIRECTへ入ることがあります。
rules:
- DOMAIN-SUFFIX,<Notionの公式接続先>,WORK
- DOMAIN-SUFFIX,<Figmaの公式接続先>,WORK
- DOMAIN-SUFFIX,<Miroの公式接続先>,WORK
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
上の山括弧部分には、契約サービスや公式ドキュメントで確認した実際の接続先を入力します。これは特定サービスの全サブドメインを無条件に推奨するものではありません。利用環境によって認証基盤、企業テナント、ファイル保管先が異なるため、ブラウザの開発者ツールやClashの接続ログで不足分を追加してください。
ドメイン名が完全に分かっている場合は DOMAIN、サブドメイン全体を対象にする場合は DOMAIN-SUFFIX を使います。DOMAIN-KEYWORD は文字列を含むだけで一致するため、会社名やサービス名が他のサイトにも現れる場合に誤爆しやすく、仕事用分流の基本ルールには向きません。IPアドレスを固定して IP-CIDR で指定する方法もありますが、CDNやクラウドサービスではアドレスが変化するため、保守負担が大きくなります。
ルールプロバイダーの更新に注意
外部のルールプロバイダーを使う場合、更新後に同じドメインが別のプロバイダーのDIRECTルールへ先に一致しないか確認してください。ルールの内容だけでなく、プロバイダーを読み込む順番も結果を左右します。変更後は設定を保存し、プロファイルを再読み込みしてから接続ログを確認します。
DNSとTUNを仕事用通信に合わせる
分流が不安定なときは、ルールだけでなくDNSの経路を確認します。OSのDNSが返したIPをもとに先に国内ルールへ一致すると、プロキシへ送るべきサービスがDIRECTになることがあります。mihomoではfake-ipとルール連動を組み合わせることで、ドメイン名を保ったまま判定しやすくなります。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
respect-rules: true
tun:
enable: true
stack: mixed
auto-route: true
dns-hijack:
- any:53
respect-rules: true はDNS問い合わせにも分流ルールを反映させるための設定です。使用中のクライアントやカーネルがこの項目に対応していない場合は、設定エラーにならないか確認してください。fake-ipで問題が出るアプリは、fake-ip-filterへ追加して redir-host 相当の扱いにする方法がありますが、除外を増やしすぎるとDNS経路の一貫性が失われます。
TUNを有効にすると、システムプロキシを使わないデスクトップアプリやUDPを利用する通信も取り込めます。Windowsでは管理者権限、macOSではネットワーク拡張やヘルパーの許可が必要です。AndroidではVPN接続の許可とバッテリー最適化の除外を確認します。TUNと別のVPNを同時に動かすとルーティングループや接続失敗が起きるため、検証時は他のVPN、セキュリティソフトのWeb保護、ブラウザ内蔵のプロキシ機能を一度停止してください。
表示速度と共同編集を検証する手順
設定を入れた直後に「速くなった」と判断せず、同じネットワーク、同じノード、同じブラウザで変更前後を比較します。ブラウザキャッシュの影響を避けるため、最初の確認ではプライベートウィンドウを使い、2回目以降は通常ウィンドウで再現性を確認します。
- Clashのプロファイルを再読み込みし、
WORKグループで安定したノードを選択します。モードはRuleにし、グローバルにはしません。 - Notion、Figma、Miroを順番に開き、画面本体、画像、コメント、検索、ログイン状態が正常か確認します。
- Figmaではファイルのサムネイル、キャンバスのズーム、画像配置、保存表示を確認します。Miroでは付箋の作成、移動、他ユーザーのカーソル表示を確認します。
- Clashの接続ログで対象通信が
WORKに一致しているか、DNS問い合わせが想定外のDIRECTへ流れていないか確認します。 - ノードを別の地域へ切り替えて、改善がノード依存かルール依存かを切り分けます。切り替え後は既存のボード接続を閉じて再接続します。
| 症状 | 確認する場所 | 優先する対策 |
|---|---|---|
| トップ画面は開くが画像や一覧が遅い | 接続ログのアセット・API通信 | 不足している公式接続先をWORKへ追加 |
| 編集画面が開くが反映が止まる | 長時間接続、WebSocket、TUNログ | TUNを確認し、ノードを固定して再接続 |
| ログイン画面でループする | 認証接続、Cookie、時刻 | 認証用接続先とシステム時刻を確認 |
| 国内サイトまで遅くなった | ルール順序とMATCH | 国内・LANのDIRECTルールを再確認 |
安定運用のための見直しポイント
仕事用の分流は、一度作ったら放置する設定ではありません。サービス側の構成変更、会社のネットワーク変更、サブスクリプション更新によって通信先やノード品質が変わります。月に一度、接続ログに現れる新しいホスト名、ルールの一致結果、実際の編集操作を確認すると、障害を早く発見できます。
- ノードを頻繁に自動切り替えせず、会議や共同編集の前は安定したノードを選ぶ。
- 国内の社内アドレス、LAN、プリンターは
IP-CIDRとno-resolveを適切に使い、DNS解析まで外部へ送らない。 - 設定変更は一度に一項目だけ行い、変更前後の接続ログと操作結果を記録する。
- Subscription更新後に、手動追加したルールやグループが消えていないか確認する。
- 仕事用アカウントの認証情報やサブスクリプションURLをログ、画面共有、設定ファイル公開に含めない。
最終的な目標は、すべての通信をプロキシへ送ることではありません。必要なサービスだけを適切な経路へ送り、国内通信と社内ネットワークは短い経路で維持することです。Clashの接続ログで「どのドメインが、どのルールに一致し、どのグループへ送られたか」を確認できれば、Notion・Figma・Miroの不具合を感覚ではなく手順で切り分けられます。
Clash クライアントをダウンロード
通信振り分けを行うには、まずクライアントが通信を引き継ぐ必要があります。ダウンロードセンターでお使いのプラットフォームのクライアントを選び、チュートリアルに戻ってシステムプロキシまたは TUN の引き継ぎを完了させてください。