Clash TUN で Windows が繋がらない？6手順でルートとFW確認（2026）

こんなときに読む記事です

サブスクリプションは取り込めていて、ダッシュボード上ではノードの遅延テストも通る。それでも Clash TUN を有効にした直後、あるいは「システムプロキシだけ」から「TUN モード」へ切り替えた直後に、ブラウザもストアの更新も含めて Windows 全体がインターネットに出られなくなる——そんな症状は、コミュニティの質問でもかなりの頻度で挙がります。

原因は単一ではなく、システムプロキシ と仮想インターフェースの ルート競合、別製品の VPN／フィルタドライバ、ファイアウォール、あるいは TUN の スタック（system / gVisor など） の組み合わせで起きることが多いです。ここでは「上から順に潰す」形で 6 つの確認ステップ を整理します。GUI の名称は Clash Verge Rev や他の mihomo 系クライアントで多少異なりますが、考え方は共通です。基本操作は Clash Verge Rev の導入ガイドとあわせて読むとスムーズです。

手順 1：システムプロキシと「二重かけ」を疑う

TUN はカーネル近くでトラフィックを取り込みます。一方、システムプロキシ は WinHTTP／IE 由来の設定で、ブラウザや一部アプリが参照します。クライアントが「システムプロキシを自動設定」と「TUN を同時にオン」にしていると、環境によっては ループや意図しない経路 が発生し、一見すると「全部死んだ」ように見えることがあります。

まずはクライアント側で TUN をオンにするときはシステムプロキシをオフにする、あるいはその逆を試し、挙動が変わるかを見ます。Windows の設定アプリから「プロキシ」を開き、手動プロキシやスクリプトが残っていないかも確認してください。企業端末ではポリシーで固定されている場合もあり、その場合は管理者向けドキュメントと衝突しないかを確認します。

コマンドで WinHTTP のプロキシ状態を見る場合は、管理者でない通常ユーザーでも netsh winhttp show proxy で現在値を確認できます。ここに不要なローカルプロキシが残っていると、TUN 切替のタイミングで挙動がぶれることがあるため、クライアントの「システムプロキシを復元」や OS 側のリセットとセットで整理します。

手順 2：他の VPN・フィルタ・仮想 NIC を止める

WireGuard、OpenVPN、各社の商用 VPN、広告ブロッカーの TUN、Hyper-V の仮想スイッチなど、別の仮想アダプタやフィルタドライバ が同時に有効だと、デフォルトルートやメトリックの奪い合いが起きます。Clash の TUN をオンにした瞬間だけ全滅する場合は、まず 他方を一時停止 して切り分けてください。

特に「常駐はしているが普段は意識していない」タイプのセキュリティスイートや、ゲーム用のネットワーク最適化ツールが重なると、イベントログには何も出ないまま通信だけが落ちることがあります。疑わしい場合は、タスクマネージャーとネットワークアダプタの一覧を見て、不要な仮想 NIC を無効化 するのが早いです。

ヒント

「TUN をオフにすると戻る」「他 VPN を落とすと戻る」なら、競合が本命です。どちらを常駐させるかを決め、もう一方の自動起動をオフにすると再発を防ぎやすくなります。

手順 3：ルートテーブルとデフォルトゲートウェイを見る

TUN を有効にすると、通常は より優先度の高いルート が追加され、トラフィックが仮想インターフェース側へ流れます。ここで メトリックの逆転 や 二重デフォルト が起きていると、パケットがどこへも行けない状態になり得ます。

管理者権限の PowerShell で Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric, ifIndex のように一覧し、デフォルト（0.0.0.0/0）がどのアダプタに付いているかを確認します。古典的な方法として route print でも構いません。Clash が作るインターフェース名（例：Meta、あるいは Wintun 系）が想定どおりか、物理 NIC のデフォルトが異常に残っていないかを見ます。

一時的に TUN をオフにした状態のルートと、オンにした状態のルートを 並べて比較 すると差分が掴みやすいです。ここで「明らかにおかしい」ルートが見つかった場合は、クライアントの サービスモード や 管理者権限での起動、設定の auto-route 周りを見直します。

手順 4：TUN の stack とインターフェース検出を確認する

mihomo／Clash Meta 系では、TUN セクションに stack（例：system、gvisor、mixed）や auto-detect-interface、strict-route などがあります。環境によっては 特定のスタックだけ不安定 という報告があり、ノート PC のドッキング／Wi-Fi 切替の多い環境では インターフェースの自動検出 が外れると経路が壊れることがあります。

設定の詳細は YAML・DNS・Fake-IP の解説記事とセットで読むと全体像が掴みやすいですが、切り分けとしては「まず別の stack に変えて再起動」「物理 NIC 名が変わった直後は一度クライアントを再起動」が現実的な手です。ログに TUN の作成失敗やインターフェース関連のエラーが出ていないかもあわせて確認してください。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  strict-route: false

注意

strict-route を強くしすぎると、ローカルサブネットや社内 VPN への経路まで意図せず変わることがあります。業務端末では変更前にバックアップと影響範囲の確認を行ってください。

手順 5：Windows ファイアウォールとサードパーティ製品

仮想 NIC を新たに作るたびに、Windows Defender ファイアウォール が「パブリック／プライベート」のプロファイルでブロックを掛けることがあります。Clash 本体やコア実行ファイル、サービスに対して 受信・送信の許可 が付いているかをセキュリティ画面で確認します。ドメイン参加 PC ではグループポリシー側で上書きされることもあります。

サードパーティのファイアウォール／EPP（エンドポイント保護）は、未知の実行ファイルを黙ってブロックするタイプが多く、ログイン直後だけ通信が通るが TUN 有効後に止まる というパターンも起こり得ます。テストのため一時的に「学習モード」や除外パスを設定できるか、製品のマニュアルに沿って Clash のインストールディレクトリを例外にできるかを確認してください。

手順 6：ログと DNS（名前解決が先に死んでいないか）

「ブラウザは開くが何も解決できない」ように見える場合、実際には ルートではなく DNS が詰まっていることがあります。TUN 有効時に dns-hijack や dns セクションの設定が、社内 DNS やセキュリティ製品のフィルタと衝突していないかをログで追います。

クライアントのコアログに、DNS タイムアウト、TLS の失敗、ルールにヒットしない直結などが大量に出ていないかを確認します。Fake-IP を使っている場合は、特定ドメインだけ fake-ip-filter に入れる必要が出ることもあります。詳細は前述の YAML 記事の DNS 節を参照してください。

まとめ：順番を守ると早い

Clash TUN は強力ですが、システムプロキシ・他 VPN・ルート・スタック・ファイアウォール・DNS のどこかが噛み合わないと、一瞬で「全体オフライン」に見えます。本稿の 6 手順は、その 当たり所を上から順に潰すためのチェックリスト です。すべてを一度にいじらず、変更ごとに「今は何が変わったか」をメモしながら進めると、後から設定を戻しやすくなります。

安定したビルドから試したい場合は、OS に合わせたパッケージをクライアントのダウンロードページから揃えると、コアと GUI の対応関係を確認しやすくなります。オープンソースのリポジトリは仕様確認や Issue 検索に有用ですが、実行ファイルの入手は配布ページを主な入口にすると迷いが減ります。→ 無料で Clash をダウンロードし、快適な接続体験を試す