2025年12月中旬から、「Windows 11を更新したらVPN越しの社内リソースにWSLだけ届かない」「sshもgitも突然死んだ」という声が増えました。エラーはだいたい同じで、WSL内に限って「No route to host（ホストへの経路がありません）」が出るパターン。仕事でWSL＋企業VPNを使ってる人ほど、ガツンと刺さります。(BleepingComputer)
ここでは、Microsoftが公式に認めた原因と、いま現場で効きやすい回避策、そして「あなたの環境だとどう？」を集めるフォーラム風の整理でまとめます。
- 何が起きてる？いちばん厄介なのは「WindowsはOK、WSLだけNG」
- 発生日時と該当アップデートとビルド番号
- 公式に確認された原因はARP未応答
- 公式対応状況：いま直ってる？回避策はある？
- 他ユーザーの報告事例：再現条件がけっこう揃ってる
- まず3分で切り分け：あなたが“この不具合”か当てる
- いま現場で効きやすい暫定対処：mirroredを外してNATに戻す
- アップデートのアンインストールはアリ？ナシ？
- ちょい考察：VPN互換性のためのmirroredが、なぜVPNで倒れたのか
- コメント欄をフォーラム化：あなたの環境、書き残してほしい
- まとめ：今日の結論は「mirroredを外して、まず仕事を通す」
何が起きてる？いちばん厄介なのは「WindowsはOK、WSLだけNG」
今回の症状は、Windows側（ブラウザやエクスプローラー、PowerShell等）ではVPN越しに社内へ普通に行けるのに、WSL（Windows Subsystem for Linux／Windows上でLinuxを動かす仕組み）の中から同じ宛先へ行こうとすると失敗する、という分断です。ログや表示としては「No route to host（ホストへの経路がありません）」が代表格。(Microsoft サポート)
つまり、ネットワークが完全に死んでるわけじゃない。だからこそ「VPNクライアント再接続」「DNS変えた」「PC再起動した」みたいな定番が効いたり効かなかったりして、ハマります。
発生日時と該当アップデートとビルド番号
時系列を押さえると、話が一気に見えやすくなります。
まず火種としてMicrosoftが名指ししているのが、2025年10月28日公開のWindows 11 非セキュリティ更新（preview update／任意のプレビュー更新）「KB5067036」です。対象はWindows 11 24H2/25H2で、OSビルドは「26100.7019」「26200.7019」とされています。(Microsoft サポート)
そこから「または、それ以降の更新（or a later update）」でも起きうる、と明記されています。実際に2025年12月9日公開のセキュリティ累積更新「KB5072033」（OSビルド「26100.7462」「26200.7462」）の既知の問題（Known issues／既知の不具合）欄に、この件が載りました。(Microsoft サポート)
Forbesも「Microsoftが確認した」として取り上げています（本文は環境によって閲覧制限が出ますが、報道の軸は“Microsoftが認めた”点）。(フォーブス)
公式に確認された原因はARP未応答
ここ、推測じゃなくてMicrosoftの説明が出ています。
原因は「VPNアプリの仮想インターフェイスがARP（Address Resolution Protocol／アドレス解決プロトコル）の要求に応答しない」こと。その結果、WSLの mirrored networking（mirrored networking mode／ミラー型ネットワーク）で通信が破綻し、「No route to host」が出る、という整理です。(Microsoft サポート)
影響が報告されているVPNとして、Cisco Secure Client（旧Cisco AnyConnect）とOpenVPNが名指しされています。(Microsoft サポート)
そして「一般的なWindows Home/Proの個人利用では起きにくく、企業・管理環境（enterprise or managed IT environments）寄り」とも書かれています。DirectAccess（企業向け常時接続VPN）も文脈に登場します。(Microsoft サポート)
公式対応状況：いま直ってる？回避策はある？
ここは期待しすぎない方がいいやつです。
Microsoftの既知の問題欄では、このWSL mirrored networking＋VPNの件について「調査中（under investigation）」で、追加情報を共有するとされています。 少なくともKB5072033の記載範囲では、万人向けの具体的な手順型ワークアラウンドは提示されていません。(Microsoft サポート)
一方で、同じKBページ内には別件でKnown Issue Rollback（KIR／既知の問題のロールバック）やグループポリシーの案内が出ることもあり、「じゃあ今回もKIRで戻せる？」と期待しがちなんですが、このWSL/VPNの段落そのものは「調査中」止まりです。ここ、混同しないのがポイント。(Microsoft サポート)
他ユーザーの報告事例：再現条件がけっこう揃ってる
「自分だけ？」を切るために、報告の型を見ておくと早いです。
GitHubのWSL公式リポジトリでも、アップデート後に「VPNの向こう側だけ到達できない」報告が上がっています。たとえば issue #13724 では、WSL設定に networkingMode=mirrored を入れていて、更新後にVPN配下へ行けなくなり、アンインストールで戻った、と書かれています。WSL内部ログとして getaddrinfo() failed: -5 や connect() failed: 101 といった失敗も載っています。(GitHub)
別の issue #13850 でも、Cisco AnyConnect Secure Mobility Client 環境で、WSLからVPN宛てが ssh: ... No route to host、ping は Destination Host Unreachable という形で落ち、Windows側のcmdではVPN宛てが通る、という「今回の典型」が再現されています。(GitHub)
「Windowsは通るのにWSLだけ死ぬ」って、地味に精神を削りますよね…。しかもVPN必須の現場だと、数時間で詰む。
まず3分で切り分け：あなたが“この不具合”か当てる
似た症状が多いので、判断を早くします。
(1) Windows側で、同じ宛先にアクセスできるか確認します。社内Web、社内Git、踏み台など。
(2) WSL側で、同じ宛先に ssh や curl 相当のアクセスをすると、「No route to host（ホストへの経路がありません）」が出るか見ます。
(3) WSLの設定で mirrored networking（ミラー型ネットワーク）を使っているか確認します。networkingMode=mirrored が入っていたら、かなり当たり濃厚です。(Microsoft Learn)
いま現場で効きやすい暫定対処：mirroredを外してNATに戻す
ここからは「公式がこう書いた」ではなく、「症状の構造上、被害を止めやすい」応急処置です。mirrored networkingが絡むなら、いったんNAT（Network Address Translation／ネットワークアドレス変換）の挙動へ戻すのが、最短で仕事を通せることが多いです。mirroredは .wslconfig で切り替える設計なので、戻すのも同じ発想。(Microsoft Learn)
手順はこれだけです（やること自体は軽いのに、効くときは即効で効きます）。
(1) Windowsで C:\Users\<ユーザー名>\.wslconfig を開きます（無ければ新規作成）。
(2) networkingMode=mirrored を削除するか、networkingMode=nat に変更します。
(3) PowerShellで wsl --shutdown を実行してWSLを完全停止します。
(4) WSLを起動し直して、VPN宛ての通信を再テストします。
注意として、mirroredを外すと、LANからWSLへ直接アクセスしやすくなる等の「mirroredのメリット」も一部失われます。そこは割り切りです。直ったら、戻すかどうかはあとで考えればいい。いまは仕事が先。(Microsoft Learn)
アップデートのアンインストールはアリ？ナシ？
正直、気持ちは分かります。「更新を戻せば直るなら戻したい」。GitHub報告でも、更新のアンインストールで復旧した例が書かれています。(GitHub)
ただし今回、トリガーになりうる更新にはセキュリティ累積更新（KB5072033）も含まれます。セキュリティ更新を外すのは、企業環境だと監査やリスク評価が絡むので、独断でやると後で面倒になりがち。現実論としては、まずmirroredを外す応急処置で業務をつなぎ、IT部門と「どのリング（段階）で更新を当てるか」を再設計する方が、結果的に楽なことが多いです。(Microsoft サポート)
ちょい考察：VPN互換性のためのmirroredが、なぜVPNで倒れたのか
mirrored networking（ミラー型ネットワーク）は、そもそも「VPNなど複雑なネットワークでも互換性を上げたい」という狙いで設計されています。ところが今回は、そのmirroredがVPNの仮想NIC（ネットワークカード）と“レイヤーの噛み合わせ”で負けた格好です。(Microsoft Learn)
ARP（アドレス解決プロトコル）は、雑に言うと「このIPアドレスの相手って、実際にはどの機械？」を同一ネットワーク内で問い合わせる仕組みです。VPN製品によっては、仮想アダプタの実装や応答の仕方が独特で、そこにmirrored側の期待値が合わないと、WSLの中だけ“次の一歩”が踏めずに落ちます。Windows本体が通るのは、Windows側は別経路でうまく処理できている、あるいは実装が違う、みたいなズレが起きてるイメージです（ここは推測混じり）。(Microsoft サポート)
だからこそ、同じ会社でも「Aさんは死んだ、Bさんは生きてる」が起きます。VPNクライアント、設定（Split Tunnel／分割トンネル等）、Windowsのビルド、WSLのバージョン、全部が絡む。しんどい。ちょっと誤字るとこrでした。
コメント欄をフォーラム化：あなたの環境、書き残してほしい
同じ「No route to host」でも、再現条件がほんの少し違います。ここを集めると、次の一手（たとえば“このVPN設定だと回避できた”）が見えます。
よければ、コメントでこのテンプレの形で投下してください。文章でOK、雑でOK、でも項目だけはあると助かります。
Windows 11のバージョン（24H2/25H2など）とOSビルド：
入れた更新（KB番号）：
WSLのバージョン：
.wslconfigでmirroredを使ってる？（はい/いいえ）：
VPN製品名（Cisco Secure Client/OpenVPNなど）：
症状（WSLだけNo route to host？DNSは引ける？）：
mirroredを外したら直った？（はい/いいえ）：
まとめ：今日の結論は「mirroredを外して、まず仕事を通す」
今回の「No route to host（ホストへの経路がありません）」は、WSLのmirrored networking（ミラー型ネットワーク）と一部VPNの相性問題としてMicrosoftが認めています。 原因は「VPN仮想インターフェイスのARP未応答」で、企業VPNやDirectAccess寄りの環境に刺さりやすい。(Microsoft サポート)
現時点でMicrosoftの記載は「調査中」で、決定打の公式回避策はまだ薄い。だからこそ、いま動ける現実策としては、.wslconfig から networkingMode=mirrored を外してNATに戻し、WSLを wsl --shutdown で再起動して、まず業務を復旧させるのが強いです。(Microsoft Learn)
あなたの環境だと、どのVPNで、どのKBで、どう再現しました？「直った／直らない」だけでもいいので、コメントで教えてください。そこから先、ほんとに話が進みます。
