1 前提とコンプライアンス
企業 VPN は、社内リソースへの安全な到達と、端末の一元的な出口制御のために導入されます。利用規約で「分割トンネル禁止」「個人プロキシ禁止」とされている場合、本記事の技術的内容を実装してもポリシー違反になり得ます。まず社内ヘルプデスクやセキュリティ部門の方針を確認し、許可された範囲でのみ読み替えてください。ここに書くのは一般的な OS のルーティングの説明であり、特定組織への推奨や違反行為の助長を意図したものではありません。
許可されたシナリオの例としては、開発者向けに「社内 Git と社内 API だけ VPN、パブリックパッケージ取得はローカル回線」といった公式にスプリットが開いている構成や、検証用端末での限定運用などがあります。逆に、フルトンで全トラフィックをゲートウェイに集約するポリシーのとき、手元で無理にデフォルトを奪い返すのは監査ログと整合しないため避けるべきです。
2 なぜ企業 VPN と Clash が衝突するか
Clash 系クライアントは、大きくシステムプロキシとTUN 仮想アダプタのどちらか（または両方）でトラフィックを取り込みます。一方、GlobalProtect や AnyConnect は接続時にルートテーブルへ多数のエントリを追加し、しばしばデフォルトルート（0.0.0.0/0）のネクストホップを VPN インターフェース側へ向けます。この状態では、ブラウザが「インターネットへ行くパケット」をまず VPN トンネルに載せてしまい、手元の 127.0.0.1 の HTTP プロキシや、TUN が期待する取り込み順序と食い違うことがあります。
症状としては、「VPN を切ると Clash は動くが、VPN を入れると突然遅い／繋がらない」「社内サイトは開くが、特定の開発用ドメインだけ別ノードに出したいのに反映されない」などが挙がります。これは多くの場合、アプリケーション設定ではなく経路の優先順位の問題です。YAML の RULE を増やす前に、route print や PowerShell の Get-NetRoute で「パケットがどのインターフェースから出ているか」を押さえると切り分けが早くなります。
3 フルトンネルとスプリットトンネル
フルトンネル（全トラフィック VPN）は、インターネット宛ても含めて原則 VPN 集中装置へ送る設計です。スプリットトンネルは、社内プレフィックス（例：10.0.0.0/8 の一部）だけを VPN に載せ、残りはローカル ISP やオフィス回線へ直接出す設計です。どちらになるかは、多くの場合VPN ゲートウェイ側のポリシーで決まり、クライアントのチェックボックスだけでは変えられないこともあります。
利用者ができることは大きく二つです。一つは、管理コンソールやポータルで分割の可否や除外リストが提供されていないか確認すること。もう一つは、許可されている端末で、Windows により具体的なプレフィックス向きの静的ルートを足し、意図したインターフェースへトラフィックを流すことです。後者はメトリックと競合するため、VPN 再接続で上書きされることもあり、運用前提を理解したうえでのみ行ってください。
4 Windows における経路優先のざっくりした法則
Windows は、宛先プレフィックスが一致するルートのうち最長一致（longest prefix match）を選び、同長さでは一般的にメトリックが小さい方が優先されます。VPN クライアントは、しばしばインターフェースのメトリックを積極的に下げ、デフォルトルートを自分側へ寄せます。Clash の TUN は別アダプタを追加し、そこへ流し込むため、既にデフォルトが VPN に固定されていると、期待した順でトラフィックが取り込まれないことがあります。
実務的には、「社内に行くべきアドレス空間」は VPN 側のルートに任せ、それ以外のより細かい宛先や明示的なホストルートをローカルゲートウェイ側へ張る、という発想になります。ただし企業ポリシーで禁止されている場合は無効です。また、メトリック調整は他アプリの通信にも影響するため、検証は業務外時間や専用端末で行うのが安全です。
5 経路表の確認（route / PowerShell）
まずは VPN 接続前後でスナップショットを取り、どのエントリが追加・変更されたかを比較します。コマンドプロンプトでは次のように表示できます（出力は環境依存です）。
route print -4
PowerShell では Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric, DestinationPrefix のように並べ替えると、競合しそうなデフォルトや大きめのプレフィックスが見つけやすいです。インターフェースのインデックス（if 列）は、後述の route add で IF を指定するときの手掛かりになります。
静的ルート追加のイメージ（例示のみ）
管理者権限が必要な場合があります。プレフィックス・ゲートウェイ・IF は自環境の値に置き換えてください。検証後は route delete で元に戻せます。
route add 198.51.100.0 mask 255.255.255.0 192.0.2.1 metric 5 if 42
永続化したい場合は -p オプションや netsh interface ipv4 add route なども使われますが、VPN が再接続のたびにルートを再配布する環境では一時的な検証に留める方が無難です。
6 「例外経路」で何を守り、何を逃がすか
典型的な分割の考え方は次のとおりです。社内 DNS・社内ファイルサーバ・社内認証など、企業ネットワークにしか存在しない宛先は VPN 経路を尊重します。一方、パブリッククラウドのドキュメント、パッケージレジストリ、学習用の外部サイトなど、業務上ローカル回線や手元プロキシの方が合理的な宛先を社内ポリシーが許す範囲で切り出します。このとき Clash 側では、DOMAIN や IP-CIDR ルールでプロキシ／ダイレクトを決めますが、OS が既に VPN へ送ってしまっているとルール以前の話になります。
したがって順序としては、① VPN 接続後のルート表で実際の出口を確認する、② 許可されているなら静的ルートやスプリット設定で出口を物理／ローカル側に戻す、③ そのうえで Clash のシステムプロキシまたは TUN を有効にし、接続ログで想定ノードに乗っているかを見る、が安定しやすいです。TUN モードの詳細は別稿で手順を追えるので、VPN 併用時はまず経路表とセットで読むことをおすすめします。
7 GlobalProtect／AnyConnect で現場で起きやすいこと
Palo Alto GlobalProtect は、ポータル設定によりトンネルモードや除外ネットワークの扱いが変わります。クライアント UI に「分割」らしき表示がなくても、バックエンドで相当するルートが配られていることがあります。Cisco AnyConnect も同様に、グループポリシー単位で許可プロファイルが決まります。利用者側でできるのは配布されたルートの確認と、許可されている場合に除外ドメインや分割対象の申請です。無許可でクライアント設定ファイルを改変するのは、サポート対象外になるだけでなく規程違反になり得ます。
セキュリティ製品が「常時オン VPN」を要求する場合、一時的に Clash を止めるしかないケースもあります。そのような環境では、Windows への Clash Verge Rev 導入自体が禁止されている可能性もあるため、導入前に文書で確認してください。
nslookup や DoH の有無もセットで確認してください。
8 Clash 側：システムプロキシと TUN の使い分け
VPN がデフォルトを握っているとき、システムプロキシのみにすると、プロキシ対応アプリは 127.0.0.1 の mixed ポートへ向かいますが、経路としては依然としてホストから VPN スタックを経由するケースがあり、挙動は環境依存です。TUN はカーネル近くで取り込むため、VPN ドライバとの順序によっては片方が効かない、またはパフォーマンスが不安定になることがあります。検証では、まずシステムプロキシでブラウザのみ通し、問題なければ TUN を試す、のように段階を踏むと原因切り分けがしやすいです。
アプリ単位で経路を変えたい場合は、プロセス名に基づく分流も有用ですが、やはり前提として OS がそのプロセスのパケットをどこへ送るかが一致している必要があります。WSL2 や仮想マシンを併用する場合は、WSL2 とホスト Clash の経路も別レイヤになるため、VPN 接続下では追加でリッスンアドレスやミラーモードの確認が必要になることがあります。
9 起動順と再接続のコツ
「先に VPN、後から Clash」か「その逆」かは一概には言えませんが、多くの現場ではVPN を先に確立し、ルートが落ち着いたあとに Clash を起動した方がログが読みやすいです。VPN が短時間で再接続する設定だと、Clash の TUN が一瞬で無効化されたように見えることがあります。その場合は、再接続イベントのたびに route print を取り、どのエントリが消えたかを追うと原因が特定しやすくなります。
クライアントの自動起動を OS に登録している場合、VPN ログオン直後に Clash が立ち上がりすぎて競合することがあります。業務ポリシーが許す範囲で、手動起動に変える、数十秒遅延のタスクスケジューラにする、などの運用も選択肢です。いずれにせよ安定性よりコンプライアンスを優先してください。
10 切り分けチェックリスト
- 社内規程で分割トンネルや個人プロキシが許可されているか確認したか。
- VPN 接続前後で
route print -4を比較し、デフォルトと社内プレフィックスの変化を把握したか。 - 問題の宛先に対して、OS レベルで期待するネクストホップになっているか（Get-NetRoute）を確認したか。
- Clash を一度オフにし、VPN のみで再現するか／Clash オンでだけ壊れるかを分離したか。
- システムプロキシと TUN を切り替え、挙動差を記録したか。
- DNS が企業リゾルバに固定されていないか、Split DNS の影響を疑ったか。
- 静的ルートを試した場合、VPN 再接続で消えないか、他業務に副作用がないか確認したか。
このリストは「YAML を増やす前に OS を疑う」ためのものです。企業 VPN は意図的に出口を一本化していることが多く、その前提を外す操作はセキュリティインシデントに分類される場合があります。
11 まとめ
Windows で企業 VPN と Clash を同時に使うときの本質は、どの宛先をどのインターフェースから出すかという OS のルーティングと、取り込んだあとどのプロキシへ送るかという Clash のルールの二段構えです。フルトン環境では後者だけをいじっても期待どおりにならないことが多く、スプリットトンネルや例外経路、DNS の扱いまで含めて設計する必要があります。手順を知っていても、規程に反するなら実装してはいけません。
技術的には、ルート表の観察から入り、許可された範囲で静的ルートやクライアント設定を調整し、その上でシステムプロキシや TUN、必要ならプロセス分流を載せるのが安全な順序です。同種のクライアントの中でも、ログの見やすさと Mihomo コアの互換性から Clash Verge Rev を選ぶ方は多く、他ツールに比べて経路が変わったあとも接続ログで追いやすいという実感を得やすいでしょう。安定性と運用のしやすさは、企業回線とセットで評価するのが現実的です。
インストール手順から環境構築まで一気に進めたい方は、公式のダウンロードページから入手し、Windows 向けガイドと併せて読み進めてください。ソースコードや Issue は GitHub で公開されていることが多いですが、パッケージの主な入手経路は本站のダウンロードページに置くのがおすすめです。
