同時利用で壊れやすい理由：レイヤの取り合い
Cisco AnyConnect のような 企業 VPN は、認証サーバ、ゲートウェイ、クライアント証明書、分割トンネル設定など、社内ポリシーに強く依存します。一方 Clash は、システムプロキシや TUN を通じて「どのパケットをどの出口へ送るか」を広く握れます。二つが同居すると、デフォルトルート、DNS の返答、特定プロセスの取りこぼしのいずれかで、VPN 側が「途中で暗号化チャネルが立たない」「立ってもすぐ落ちる」「社内 10.x に ICMP すら返らない」といった症状に見えます。根っこは製品バグというより、経路設計の衝突であることが多いです。
切り分けのコツは、まず「AnyConnect のプロセス／仮想インターフェースが作るトラフィック」を DIRECT に寄せられるかを見ることです。ルールの書き方と評価順は ルール分流のベストプラクティス が近い文脈ですが、本稿はストリーミングより職場 VPN と社内帯域に焦点を当てます。一般論として「VPN＝プロキシの上位互換」ではなく、Clash と従来 VPN の比較 で整理されるように、目的とレイヤが異なる二つの仕組みを同じ OS 上で順序立てて折り合い付ける作業だと捉えてください。
ステップ 1：ポリシーグループとルール順（分流ホワイトリスト）
まず ルールの上から順に、AnyConnect が触るドメインや IP が意図せず MATCH より前で別ポリシーへ流れていないかを確認します。典型は「広い DOMAIN-SUFFIX が先に当たり、VPN 管理サーバのホスト名まで海外出口へ行く」「社内証明書検証用の OCSP／CRL だけ別経路になる」などです。ポリシーグループの切り替えと死活監視の考え方は ポリシーグループ URL-TEST とフォールバック と併読すると、VPN 用に安定した出口を一本化しやすくなります。
具体的には、社内ポータル、認証 IdP、AnyConnect のプロファイル配布元、証明書検証に使う公開ホストを、いったんすべて 同一の DIRECT 束ねポリシーに寄せて再現性を潰します。そのうえで必要なドメインだけを細かく戻すほうが、最初から例外だらけにするよりトラブルが減ります。ルールセットの肥大化は ベストプラクティス で触れている順序の原則と衝突しやすいので、社内系は明示的に先頭へ持ってくる発想が安全側です。
ステップ 2：TUN とシステムプロキシの優先度を揃える
TUN は OS 全体の仮想インターフェース経由でトラフィックを取り込みます。AnyConnect もカーネル近傍でインターフェースとルートを触るため、どちらがデフォルトルートを握るかが衝突点になります。症状が「VPN 接続直後に Clash をオンにすると即切断」なら、まず TUN を一時オフにしてシステムプロキシのみで同じ操作を試し、逆の組み合わせも試します。Windows では Windows 11 での Clash Verge と TUN の手順が、GUI からの切替イメージを掴むのに向きます。macOS では TUN とシステムプロキシの衝突 が近い論点です。
ここでのゴールは「どちらが正義か」を決めることではなく、VPN が必要なトラフィックが TUN の外側／内側のどちらを通っても破綻しない状態を作ることです。TUN を使うなら、次節の IP レンジ DIRECT をセットで入れないと、VPN クライアントが握るトンネル内の再ループや MTU 問題が表面化しやすくなります。
ステップ 3：社内向けセグメントを DIRECT に固定する
社内ファイルサーバや管理系は 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 など RFC1918 に収まることが多く、VPN 接続後にその帯域へ物理インターフェース側ではなくトンネル側へ向けるのが本来の姿です。Clash がこれらを誤って出口ノードへ送ると、「VPN には繋がったのに中身が空」「社内 URL がタイムアウト」になります。まずは広めの IP-CIDR を DIRECT に置き、必要なら社内ドキュメントの実レンジだけに絞り込みます。LAN 共有やバインド先の整理は LAN 共有とバインド先 が補助線になります。
Windows でプロセス単位の切り分けがしたい場合は PROCESS-NAME 系のルールも有効ですが、VPN クライアントは複数バイナリに分かれることがあるため、IP ベースの DIRECT を土台にしてから足すほうが再現性が高いです。IPv6 二重スタック環境では v4 だけ直しても残るので、IPv6 と DIRECT を同時に整える も参照してください。
ステップ 4：OS のルート表で AnyConnect と競合を見る
Clash をオンにした瞬間に 0.0.0.0/0 の次ホップが仮想アダプタへ付け替わっていないかを、VPN 接続前後で比較します。Windows なら route print、macOS なら netstat -rn などで十分です。AnyConnect の分割トンネルが有効でも、競合製品や古いルートが残っていると「表では split に見えるのに実パケットは別口」という状態が起きます。VPN 切断後にルートが戻らない場合は、Clash 終了後のプロキシ／TUN 掃除 の観点も重なります。
ここで見るべきは「正しさの証明」ではなく、Clash を入れたときに何が一つ変わったかです。メトリクスやインターフェース索引が変わると、VPN が選ぶ経路セットと矛盾することがあるため、変更は一つずつ戻しながら確認します。
ステップ 5：DNS（fake-ip／hijack）が VPN を潰していないか
VPN のセットアップは「名前解決が社内リゾルバを向いていること」が暗黙条件になっていることがあります。Clash 側で fake-ip や強い DNS hijack を有効にすると、AnyConnect が期待する A レコード／SRV／HTTPS レコードの組とズレて、TLS ハンドシェイク前に失敗したように見えることがあります。Clash Meta の DNS 実測 で、nameserver／fallback／fake-ip の関係を押さえたうえで、VPN 関連ホストを real-ip で解かせる、あるいは一時的に fake-ip をオフにして再現が消えるかを見ます。
ブラウザの Secure DNS（DoH）と Clash の DNS を二重にかけると、さらに挙動が読みにくくなります。切り分け中はどちらか一方だけに寄せ、社内ポータルが開く最小構成から広げるのが安全です。
GlobalProtect など別 SSL VPN への当てはめ
Palo Alto GlobalProtect も、クライアントが作る仮想 NIC とポータル／ゲートウェイの名前解決という点では AnyConnect と同型です。本稿のステップ 1〜5は製品名を置き換えてそのまま適用できます。ゼロトラスト系エージェントと併用している場合は、同一マシンに複数のフィルタドライバが積み上がり、許可リストの衝突が起きやすい点だけ注意してください。
チェックリスト（コピー用）
- AnyConnect のプロファイル配布元・認証 IdP・OCSP／CRLが同一 DIRECT 束に入っているか。
- RFC1918 など社内レンジが DIRECT で先に固定されているか（必要なら IPv6 も）。
- TUN とシステムプロキシのどちらを主に使うか決め、もう一方で二重取り込みが起きていないか。
- OS の デフォルトルートが Clash オン時に期待とズレていないか（接続前後で比較）。
- fake-ip／DNS hijack を疑い、VPN 関連ホストで real-ip へ戻すと改善するか。
- ブラウザ DoH と Clash DNS が二重になっていないか。
- 切り分け後に環境を戻す手順を把握しているか（終了後の掃除）。
まとめ
Clash と Cisco AnyConnect の併用トラブルは、単一スイッチの設定ミスより、ルール順・TUN／プロキシ・社内帯域 DIRECT・DNSの四層が同時に絡むことが多いです。上から順に潰していけば、「握手が始まらない」「数秒で落ちる」「社内だけ届かない」といった見え方の違いも、同じ根っこに還元できるはずです。GlobalProtect など他 SSL VPN でも観点は同じです。
仕事用 VPN は可用性が命です。個人用の快適さより先に、許可された範囲で安定経路を確保し、そのうえで残りのトラフィックだけを分流する——この順序を守ると、長期運用でもメンテナンスが楽になります。クライアント選びは クライアントの選び方 も参考に、GUI での切替とログの見やすさを基準にすると再発時が楽です。
→ 方針が固まったら、Clash を無料ダウンロードし、社内ルールに沿ったプロファイルで試してください。企業 VPN の安定性を損なわない前提で、個人向けの出口整理に使えます。