Windows 11 で Clash と WSL2 を併用するときの断線：既定ルート・仮想 NIC・MTU を順に直す

この記事で扱う症状

Windows 11 上で Clash（Mihomo／Meta 系コアを載せた GUI 含む）を、システムプロキシや TUN モードで動かしたまま WSL2 のシェルやコンテナ開発を続けていると、次のような「片方だけおかしい」症状に出くわすことがあります。ブラウザや Store アプリはホスト側で普通に開けるのに、wsl 内の curl や apt だけがタイムアウトする。逆に、TUN をオンにした瞬間からホストと WSL の両方が数分おきに落ちる。VPN や別のフィルタドライバを併用しているときだけ再現する、などです。

こうした不具合の多くは「購読 URL が壊れた」より先に、既定ルートと仮想ネットワーク アダプタの優先度、DNS の参照先、MTU のいずれかでパケットが途中で詰まっているケースに偏ります。本稿では、現場で手戻りが少ない順番でチェックリスト化しました。クライアントのメニュー名は製品ごとに違いますが、考え方は共通です。

なぜ Clash と WSL2 が衝突しやすいか

WSL2 のゲストは、ホストとは別の軽量 VM として動いており、ホスト側には Hyper-V 由来の仮想 Ethernet（例：vEthernet (WSL) や vEthernet (Default Switch)）が現れます。一方、Clash の TUN はカーネル側で仮想インターフェースとルーティングテーブルを追加し、既定ルートやインターフェース メトリック（優先度）を変えます。システムプロキシだけの構成でも、一部アプリはプロキシを無視するため、結果として「ホストのブラウザは通るが WSL は直出しで詰まる」という見え方になります。

さらに、Windows 11 のバージョンによっては WSL のネットワークがホストとミラーされたり、従来型の NAT 構成のままだったりと挙動が分岐します。同じ「WSL2」と言っても、ビルドごとに /etc/resolv.conf の中身や既定ゲートウェイの見え方が変わるため、検索で拾った古い記事のコマンドがそのまま当てはまらないことも珍しくありません。まずは自分の環境のルート表と DNS を実測してから手を入れるのが安全です。

用語：本稿の「分流」は、Clash のルールによってトラフィックを直結（DIRECT）とプロキシ経由に振り分けることを指します。WSL や Docker のブリッジ用プレフィックスを誤ってプロキシ側へ送ると、期待しない経路で黒穴化することがあります。

ステップ 1：ホストと WSL で「どこで詰まるか」を分ける

管理 PowerShell で route print または Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric を実行し、0.0.0.0/0 がどのインターフェースに付いているかを確認します。Clash TUN を有効にしていると、ここに TUN アダプタ名が載り、メトリックが小さい（優先）ことが多いです。続いて WSL 内で ip route と ip addr を見て、既定ゲートウェイがホスト側の仮想ブリッジを指しているかを把握してください。

名前解決だけ失敗している場合は、WSL で cat /etc/resolv.conf を確認します。ミラーモードではホストと同じリゾルバを見る構成になりやすく、従来構成ではホストの仮想アドレスが書かれている例が多いです。ping で IP 宛には通るのにホスト名だけ失敗するなら、DNS レイヤーを疑うのが早いです。逆に IP 宛でも不通なら、ルートまたは MTU を先に見ます。

ステップ 2：物理 NIC と仮想 NIC のメトリック

Windows は複数の既定ルート候補があるとき、メトリックが小さいインターフェースを優先します。Wi-Fi と有線、さらに Hyper-V の vEthernet と Clash TUN が同時に存在すると、意図しないアダプタが「出口」として選ばれ、WSL から見た経路だけが不安定になることがあります。設定アプリの「ネットワークとインターネット」→ アダプタの詳細オプション、または PowerShell の Set-NetIPInterface -InterfaceAlias '...' -InterfaceMetric <値> で、実際にインターネットへ出たい物理インターフェースを相対的に優先し、使わない仮想アダプタ側のメトリックを大きくする、という調整が有効なことがあります。

操作の前に、どのアダプタが実際のデフォルトゲートウェイかを tracert 1.1.1.1 などで押さえておくと迷いにくいです。社用端末ではグループポリシーで固定されている場合もあるため、権限がなければ IT 部門への相談が必要です。メトリック調整は一時的な切り分けとして試し、効果が確認できたら理由をメモしておくと後日の再発に強くなります。

ステップ 3：Clash は TUN か、システムプロキシか

TUN はアプリ横断でトラフィックを吸い上げられる反面、仮想インターフェースとルートを増やすため WSL／Docker と相性問題が出やすいです。開発中の Linux だけ直出ししたい場合は、TUN を一旦オフにしてシステムプロキシ＋ルール分流に切り替え、WSL 側のトラフィックがホストのプロキシ設定の影響を受けないかを切り分けるのが有効です。詳しいモードの違いは、当サイトの TUN モードの解説とあわせて読むと整理しやすいです。

GUI によっては「サービスモード」や管理者権限が必要な TUN ドライバがあり、UAC やセキュリティソフトが挙動を変えることもあります。Windows 側の初期セットアップの流れは Clash Verge Rev のチュートリアルに沿って確認し、本稿のネットワーク切り分けに進むと理解が速いです。

ステップ 4：WSL の DNS と Windows の連携

WSL2 で名前解決だけが壊れているとき、/etc/resolv.conf が自動生成されているか、手動で固定しているかを確認します。自動生成を上書きしていると、ホスト側の仮想 IP が変わったあとに追従できず、Clash を再起動したタイミングだけ詰まる、というパターンがあります。.wslconfig で [experimental] 系のネットワークオプションを触っている場合も、ビルド差で挙動が変わるため、一度最小構成に戻して再現するか試す価値があります。

Clash 側で Fake-IP や独自の DNS フォワードを使っている場合、ホストのリゾルバと WSL の期待がずれ、見かけ上だけ「Linux から特定ドメインが死ぬ」こともあります。切り分けとして、WSL 内で dig や nslookup を使い、どのサーバーに聞いているかを実測してください。ルールの書き方全般は 分流ガイドで補完できます。

ステップ 5：MTU の切り分け（PPPoE・VPN・TUN の組み合わせ）

暗号化や追加ヘッダの分、パス MTU が小さい回線では、とくに PPPoE や企業 VPN と TUN を重ねた環境で ICMP Fragmentation Needed が期待どおり返らず、大きなパケットだけ黙殺されることがあります。症状としては「小さいレスポンスは返るが、HTTPS のフルロードが固まる」「SSH が途中で切れる」などが典型です。WSL から ping -M do -s <サイズ> 例のIP（環境によりコマンドは異なります）のように DF 付きでサイズを変えながら試し、しきい値付近で失敗するかを見ます。

ホストの vEthernet（WSL）や Clash が作る TUN に対して MTU をやや小さめ（例：1280 や 1400 付近）に下げるトラブルシュートは、恒久対策というより切り分けと暫定回避の意味が強いです。回線や VPN の仕様が変わると最適値も変わるため、「下げたら安定した」という事実だけをメモし、ルーターや VPN 側の MTU 設定とあわせて後から整理するのがよいでしょう。

ステップ 6：分流ルールで WSL 向けプレフィックスを直結へ

Clash のルールが広すぎると、本来ローカルでよい宛先までプロキシ経由に送られ、ノード側のポリシーで落ちることがあります。ホストの仮想スイッチや社内ラボの RFC1918 帯を IP-CIDR で DIRECT に寄せる、WSL のブリッジプレフィックスを明示的に直結する、といった整理が有効です。書き方の骨格は ルール分流の記事に譲りつつ、自分の ip route に出てくる宛先をそのままルールに写すと再現性が高まります。

開発用コンテナや Kubernetes のローカルクラスタまで含めると組み合わせは複雑になるため、一度 Clash をオフにした状態で期待どおり動く経路をメモし、オンにしたあとにどこで変わるかを差分で見る方法が安全です。「とりあえず再インストール」で直る問題もありますが、ルートと DNS が原因の場合は数日後に同じ姿勢で再発します。

運用メモ：チームで WSL イメージを共有している場合、個人の .wslconfig や Clash プロファイルの差分が蓄積し、同じ手順でも結果が分かれます。トラブル再現時には Windows のビルド番号、WSL のカーネル／ディストリ版、Clash が TUN かプロキシか、をセットで記録しておくと共有がスムーズです。

YAML の細部や DNS の挙動は、当サイトのドキュメント集も参照してください。クライアントの入手経路が分岐しやすいため、説明の一貫性の観点ではダウンロードページを主な導線にすると取り違えが減ります。

まとめ

Windows 11 で Clash と WSL2 を併用するときの不通・断続的な切断は、まずホストと WSL の既定ルートを並べて比較し、続けて仮想 NIC のメトリック、DNS、MTU、分流ルールを順に疑うと効率的です。TUN は便利ですが仮想インターフェースを増やすため、開発用 Linux と競合しやすい点を理解しておくと切り分けが速くなります。

同種の用途でも、Clash／Mihomo はルールとログの見え方が明快で、GUI と設定ファイルの両方から状態を追いやすいのが長所です。ホスト側の経路を一度整理したうえでプロファイルを磨くと、再発時の手戻りを大きく減らせます。

各 OS 向けの推奨クライアントはダウンロードページにまとめています。本稿のチェックリストでホストと WSL の差分が把握できたら、安定したビルドへそろえて運用すると安心です。→ Clash クライアントを無料でダウンロードし、Windows と WSL の開発環境を整える