MENU

WSLミラーネットワークとVPN問題をBuild 28000.2605で改善｜確認・対処手順

Windows11

VPNへ接続した途端、WSLから社内サイトを開けない、名前解決だけ失敗する、Gitやパッケージ管理ツールが通信できなくなる。このようなWSLのミラーネットワークとVPNの組み合わせに対し、MicrosoftはWindows 11 version 26H1のOS Build 28000.2605で互換性を改善したと案内しています。

ただし、Build 28000.2605はWindows InsiderのRelease Preview Channel向けです。さらに該当項目は段階的ロールアウトに含まれるため、同じビルドでも端末によって反映状況が異なる可能性があります。業務PCでは「更新すれば完全に直る」と判断せず、DNS、ルーティング、プロキシ、ファイアウォールのどこで通信が止まっているかを切り分けることが重要です。(Microsoft Learn)

目次

WSLミラーネットワークとVPNの互換性をBuild 28000.2605で改善

Microsoftが2026年7月20日に公開したWindows 11 Insider Release Preview Build 28000.2605のリリースノートには、WSLについて「VPN使用時のミラーネットワークモードの利用を改善する」という内容が記載されています。

公開情報から確認できる内容は次のとおりです。(Microsoft Learn)

項目内容
対象OSWindows 11 version 26H1
OSビルド28000.2605
配信チャネルWindows Insider Release Preview Channel
公開日2026年7月20日
WSLの変更内容VPN使用時におけるミラーネットワークモードの利用を改善
配信方法段階的ロールアウト
VPN製品の指定公開情報では指定なし
詳細な原因公開情報では説明なし

ここで注意したいのは、Microsoftの表現が「特定の不具合を完全に修正した」ではなく、「利用を改善した」となっている点です。

次のような情報は公開されていません。

  • 影響を受けていたVPNクライアントの製品名
  • DNS、ルーティング、フィルタードライバーのどこを変更したのか
  • VPN再接続時だけ発生する問題も対象なのか
  • すべてのVPN構成で問題が解消するのか
  • 修正内容を個別に有効化する機能IDや設定項目

そのため、Build 28000.2605を導入しても、VPNに関連するすべてのWSL通信問題が解消するとは限りません。

26H1は一般提供済みだが、28000.2605はプレビュー版

Windows 11 version 26H1そのものは、2026年2月10日からGeneral Availability Channelで提供されています。ただし、26H1は主に2026年初頭に登場した新しいデバイス向けであり、既存の24H2や25H2搭載PCに対する通常の機能更新としては設計されていません。(Microsoft Learn)

一方、今回のWSL改善を含むBuild 28000.2605はRelease Preview Channel向けです。2026年7月23日時点で、Microsoftが一般提供チャネルの最新ビルドとして掲載している26H1はBuild 28000.2525です。したがって、26H1自体は一般提供済みでも、Build 28000.2605に含まれるWSL改善は一般提供版へ反映済みとはいえません。(Microsoft Learn)

利用環境判断
26H1 Build 28000.2605 Release Preview改善内容を検証できる可能性がある
26H1 Build 28000.2525以前今回の改善が含まれているとは確認できない
24H2または25H2の一般利用PC26H1への強制移行ではなく、今後の更新情報を確認する
本番業務PC改善だけを目的としたInsider参加は慎重に判断する
検証専用PCVPN接続前後の比較テストを実施しやすい

Build 28000.2605のWSL項目は段階的ロールアウトです。そのため、OSビルド番号が一致していても、端末ごとに改善の反映タイミングが異なる可能性があります。(Microsoft Learn)

WSLのミラーネットワークとは

WSL 2の標準ネットワーク方式はNATです。NATモードでは、Windowsとは別の仮想ネットワーク内でWSLが動作します。

ミラーネットワークモードでは、Windows側のネットワークインターフェイスをWSL側へ反映する新しいネットワーク構成を使用します。Windows 11 version 22H2以降で利用でき、VPNとの互換性向上、IPv6、マルチキャスト、WindowsとWSL間のlocalhost接続などを目的としています。(Microsoft Learn)

比較項目NATモードミラーネットワークモード
WSLの標準設定標準明示的な有効化が必要
ネットワーク構成独立した仮想NATWindowsのインターフェイスをWSLへ反映
WSLからWindowsへの接続通常はWindowsホストのIPアドレスを使用127.0.0.1を利用可能
IPv6構成によって制約あり対応
VPNとの互換性VPNによって問題が起きる場合がある互換性向上を目的としている
マルチキャスト制約あり対応
LANからWSLへの接続ポート転送などが必要直接接続に対応。ただしファイアウォール設定が必要な場合がある

ミラーネットワークはVPN対策だけの機能ではありません。ただし、Windows側で作成されたVPNインターフェイスや通信経路をWSLへ反映しやすくするため、企業ネットワークでの開発作業には特に関係が深い機能です。

Build 28000.2605を入れても直らない可能性がある理由

VPN接続時の通信は、単純に「インターネットへ接続できるか」だけでは判断できません。少なくとも次の要素を分けて確認する必要があります。

確認対象主な役割問題がある場合の症状
DNSドメイン名をIPアドレスへ変換するIPアドレスでは接続できるが、ホスト名では失敗する
ルーティング通信をVPN経由または通常回線へ振り分ける社内ネットワークだけ到達できない
HTTPプロキシWeb通信を組織の中継サーバーへ送るブラウザーは動くが、curlやaptが失敗する
証明書TLS通信の信頼性を確認する接続はできるが証明書エラーになる
ファイアウォール通信の許可と拒否を制御する特定ポートやWindowsとWSL間の通信だけ失敗する
VPNクライアント経路、DNS、通信フィルターを適用するVPN接続中だけWSLが通信できない

ミラーネットワークの改善が適用されても、社内プロキシの設定不足やLinux側の証明書不足まで自動的に解消されるわけではありません。

最初にWindowsとWSLの状態を確認する

WindowsのOSビルドを確認する

Windowsキー + Rを押し、次のコマンドを実行します。

winver

表示されたバージョンとOSビルドを確認してください。

今回の改善対象は次の環境です。

Windows 11 version 26H1
OS Build 28000.2605
Release Preview Channel

Build 28000.2525など、末尾のリビジョン番号が異なる場合は、Build 28000.2605と同じ状態ではありません。

WSLのバージョンと実行方式を確認する

PowerShellまたはコマンドプロンプトで、次のコマンドを順番に実行します。

wsl --version
wsl --status
wsl --list --verbose

wsl --list --verboseでは、対象ディストリビューションのVERSIONが2になっていることを確認します。

.wslconfigのネットワーク設定はWSL 2へ適用されます。WSL 1を使用しているディストリビューションには、ミラーネットワーク設定は適用されません。(Microsoft Learn)

WSL自体を更新する

WSLコンポーネントは次のコマンドで更新できます。

wsl --update

ただし、wsl --updateで更新されるのはWSLコンポーネントです。WindowsのOSビルドをBuild 28000.2605へ変更するコマンドではありません。

今回の改善はWindows 11のリリースノートに掲載されているため、対象ビルドへの更新にはWindows Update側の更新が必要です。WSLコンポーネントとWindows OSの両方を分けて確認してください。(Microsoft Learn)

ミラーネットワークの設定を確認する

Microsoftは現在、手動で.wslconfigを編集するよりも、スタートメニューの「WSL Settings」から設定を変更する方法を推奨しています。画面構成はWSLのバージョンによって異なるため、設定項目が見つからない場合は.wslconfigを確認します。(Microsoft Learn)

.wslconfigは次の場所にあります。

%UserProfile%\.wslconfig

PowerShellから開く場合は、次のコマンドを使用できます。

notepad.exe "$env:USERPROFILE\.wslconfig"

ミラーネットワークを利用する基本設定は次のとおりです。

[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true

各設定の意味は次のとおりです。

設定役割
networkingMode=mirroredミラーネットワークモードを有効にする
dnsTunneling=trueWSLのDNS要求をWindows経由で処理する
autoProxy=trueWindows側のHTTPプロキシ情報をWSLへ反映する

dnsTunnelingはVPNや複雑なネットワーク構成との互換性向上を目的とした機能です。autoProxyは、Windowsで設定されているHTTPプロキシ情報をWSL側で利用するための機能です。(Microsoft Learn)

設定変更後は、次のコマンドでWSLを完全に終了します。

wsl --shutdown

その後、Ubuntuなどのディストリビューションを再度起動します。

wsl --shutdownを実行すると、すべてのWSLディストリビューションとWSL 2の仮想マシンが終了します。実行中の処理やコンテナがある場合は、先に保存または停止してください。(Microsoft Learn)

VPN接続前後で通信を比較する手順

問題を正確に特定するには、VPNへ接続していない状態と、接続した状態で同じテストを行います。

Windows側で確認する

PowerShellで、社内システムのFQDNを指定して実行します。

Resolve-DnsName <社内システムのFQDN>
Test-NetConnection <社内システムのFQDN> -Port 443

例として、社内Gitサーバーがgit.example.localの場合は次のように実行します。

Resolve-DnsName git.example.local
Test-NetConnection git.example.local -Port 443

WSL側で確認する

WSLでは次のコマンドを実行します。

getent hosts <社内システムのFQDN>
curl -vI --max-time 10 https://<社内システムのFQDN>/
ip route
cat /etc/resolv.conf
env | grep -i proxy

確認するポイントは次のとおりです。

  • getent hostsでIPアドレスが返るか
  • curlがDNSエラー、タイムアウト、証明書エラーのどれで止まるか
  • ip routeに社内ネットワーク向けの経路があるか
  • /etc/resolv.confが想定したDNS構成になっているか
  • HTTP_PROXYやHTTPS_PROXYが必要な環境で設定されているか

pingだけで判断するのは避けてください。企業ネットワークではICMPが拒否されていても、HTTPSやSSHは正常に利用できることがあります。実際に使用するポートで確認する方が確実です。

症状から原因を切り分ける

次の表は原因を断定するものではなく、調査を始める位置を決めるための目安です。

検証結果疑う箇所次に確認すること
Windowsでは名前解決できるが、WSLでは失敗するWSL側のDNSdnsTunneling、resolv.conf、手動DNS設定
WindowsとWSLの両方で名前解決できないVPNまたは社内DNSVPN接続プロファイル、DNSサーバー、VPN障害
名前解決は成功するが、WSLだけタイムアウトするルートまたは通信フィルターip route、Windowsのroute print、VPNの分割トンネル
公開サイトは開けるが、社内サイトだけ開けない社内向けDNSまたはルート社内FQDN、社内サブネットの経路
ブラウザーは開けるが、aptやcurlが失敗するプロキシまたは証明書autoProxy、環境変数、Linuxの信頼済みCA
証明書エラーだけ発生するTLS検査またはCA証明書組織のルート証明書をLinuxへ登録
VPNを再接続すると失敗するネットワーク状態の再反映VPN接続後にwsl --shutdownして再起動
WindowsとWSLのlocalhost通信だけ失敗する待受アドレス、ポート、ファイアウォールアプリのバインド先とHyper-Vファイアウォール
VPN未接続でも失敗するVPN以外のWSL設定WSL、Linux、アプリ側の設定を確認

特に、curlの結果が証明書エラーの場合は、通信経路そのものは成立している可能性があります。この場合、ネットワーク設定を繰り返し変更するよりも、Linux側の信頼済みCA証明書を確認する方が適切です。

検証目的であっても、curl -kによる証明書検証の無効化を恒久的な対策にしないでください。

改善されない場合に試す対処方法

VPNへ接続してからWSLを起動する

VPN接続後のインターフェイスや経路がWSLへ反映されていない可能性を切り分けるため、次の順番で再起動します。

  1. WSL内の作業を保存する
  2. Dockerや開発サーバーを停止する
  3. VPNを切断する
  4. PowerShellでwsl --shutdownを実行する
  5. VPNへ再接続する
  6. WSLを起動する
  7. DNSとHTTPS通信を再確認する

これで改善した場合は、VPN接続や再接続のタイミングとWSLのネットワーク状態に関係している可能性があります。ただし、恒久的な修正を意味するものではありません。

NATモードへ一時的に戻して比較する

ミラーネットワーク固有の問題かどうかを判断するには、一時的にNATモードへ戻して比較します。

[wsl2]
networkingMode=nat

変更後に次のコマンドを実行します。

wsl --shutdown

NATでは正常に動作し、ミラーネットワークでは失敗する場合、ミラーネットワークとVPNの組み合わせに原因がある可能性が高まります。

ただし、NATへ戻すと、WSLからWindowsへ接続する際にWindowsホストのIPアドレスが必要になるなど、通信方法が変わります。また、VPNの構成によってはNATでもDNSや社内ルートの問題が発生します。(Microsoft Learn)

手動で固定したDNS設定を確認する

過去のWSLトラブル対策として、/etc/resolv.confへパブリックDNSを固定している場合があります。

しかし、社内ドメインの名前解決には、VPNから配布される社内DNSが必要です。例えば、次のようなDNSだけを固定していると、社内FQDNを解決できない可能性があります。

nameserver 8.8.8.8
nameserver 1.1.1.1

以前の設定を消す前に、次のファイルをバックアップしてください。

sudo cp /etc/wsl.conf /etc/wsl.conf.backup 2>/dev/null
sudo cp /etc/resolv.conf /etc/resolv.conf.backup

/etc/wsl.confに次の設定がある場合は、DNSの自動生成を意図的に無効にしていないか確認します。

[network]
generateResolvConf=false

企業VPN環境では、パブリックDNSを固定するよりも、Windows側のDNS情報を利用するdnsTunnelingの方が適する場合があります。(Microsoft Learn)

Windowsのプロキシ設定を確認する

企業ネットワークでHTTPプロキシを使用している場合、Windowsのブラウザーだけ正常に通信でき、WSL内のツールが失敗することがあります。

WSLで次を実行します。

env | grep -i proxy

何も表示されず、組織でプロキシが必須の場合は、.wslconfigの次の設定を確認します。

[wsl2]
autoProxy=true

設定変更後はwsl --shutdownでWSLを再起動してください。

なお、プロキシ情報が反映されても、社内のTLS検査で使われるルート証明書はLinuxへ自動登録されない場合があります。証明書エラーが出るときは、組織の管理者から正式なCA証明書と導入手順を入手してください。

ファイアウォールを無効化しない

ミラーネットワークでは、Windows Defender FirewallやHyper-VファイアウォールのルールがWSL通信へ関係します。特にLANやVPN側からWSL内のWebサーバーへ接続する場合、受信規則が必要になることがあります。(Microsoft Learn)

ただし、問題の切り分けを目的としてWindows Defender FirewallやVPNのセキュリティ機能を恒久的に無効化するのは避けてください。

次の点を確認します。

  • WSL内のサービスが目的のポートで待ち受けているか
  • 127.0.0.1だけで待ち受けているのか
  • LANやVPN側から接続する場合に適切なアドレスへバインドしているか
  • Windows側で同じポートを別のアプリが使用していないか
  • Hyper-Vファイアウォールで対象ポートが拒否されていないか

WSL内の待ち受け状態は次のコマンドで確認できます。

ss -lntp

Release Previewで検証する場合のチェック項目

本番PCへ展開する前に、検証端末で次の動作を確認します。

テスト項目合格条件
公開DNS公開FQDNを正常に名前解決できる
社内DNSVPN接続時に社内FQDNを解決できる
公開HTTPScurlやパッケージ管理ツールが通信できる
社内HTTPSGit、API、社内ポータルへ接続できる
SSH社内GitやLinuxサーバーへ接続できる
localhostWindowsとWSL間の開発サーバー通信が動作する
VPN再接続切断と再接続後も通信を継続できる
スリープ復帰復帰後にDNSとルートが維持される
Docker利用コンテナの外部通信とポート公開が動作する
複数ディストリビューションUbuntuやDebianなど利用対象がすべて動作する

.wslconfigは、個別のディストリビューションではなく、WSL 2で動作するすべてのディストリビューションへ適用されます。1つのUbuntuだけを確認して展開を決めず、実際に業務で使用しているディストリビューションとツールを一通りテストしてください。(Microsoft Learn)

業務PCでは一般提供版への反映を待つ判断も必要

Build 28000.2605はRelease Preview Channel向けであり、WSLの改善も段階的ロールアウトです。業務で使用しているPCを、今回の改善だけを目的としてInsider Programへ参加させるのは慎重に判断する必要があります。

本番環境では、次の順序が現実的です。

  1. DNS、ルート、プロキシ、証明書のどこで失敗しているかを確認する
  2. wsl --updateでWSLコンポーネントを最新化する
  3. dnsTunnelingとautoProxyの設定を確認する
  4. VPN接続後にWSLを完全再起動して比較する
  5. NATモードとのA/Bテストを行う
  6. 検証端末がある場合のみBuild 28000.2605を試す
  7. 一般提供版の更新履歴に同じ改善が掲載されるまで監視する

VPN製品のサポート窓口へ問い合わせる場合は、次の情報を揃えると調査しやすくなります。

  • WindowsのバージョンとOSビルド
  • wsl --versionの結果
  • 使用しているLinuxディストリビューション
  • .wslconfigの内容
  • VPNクライアントの製品名とバージョン
  • VPN接続前後のip route
  • WindowsとWSLそれぞれのDNS結果
  • 接続できないホスト名とポート
  • VPN初回接続時と再接続時の違い
  • NATでは成功し、ミラーネットワークでは失敗するか

まとめ

Windows 11 version 26H1のRelease Preview Build 28000.2605では、VPN使用時のWSLミラーネットワークが改善されています。ただし、Microsoftが公開しているのは「利用の改善」という概要のみで、対象VPN、原因、修正範囲は明らかにされていません。

また、26H1自体は一般提供されていますが、Build 28000.2605と今回のWSL改善はRelease Preview段階です。該当項目は段階的ロールアウトであるため、ビルド番号が同じでも端末によって結果が異なる可能性があります。

現在問題が発生している場合は、更新だけに頼らず、次の順番で確認してください。

  1. WindowsとWSLのバージョンを記録する
  2. ミラーネットワークが有効か確認する
  3. WindowsとWSLのDNS結果を比較する
  4. 社内ルート、プロキシ、証明書を確認する
  5. wsl --shutdown後にVPNへ再接続する
  6. NATモードと比較する
  7. 本番展開前にVPN再接続やスリープ復帰まで検証する

一般提供版を使用する業務PCでは、無理にRelease Previewへ移行せず、回避策を適用しながら、今後の一般提供版の更新履歴を確認するのが安全です。

Windows11
Windows 11 VPN WSL ミラーネットワーク

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次