WSL2: ネットワーク構成と NAT およびミラー モードの高度なガイド

最終更新： 2月2026
著者： テクノデジタル
  • WSL2 は、NAT またはミラー モード経由で構成可能で、Hyper-V によって管理される独自のネットワークを持つ仮想マシンを使用します。
  • wsl.conf と .wslconfig を組み合わせることで、自動マウントや systemd からメモリ、CPU、ネットワーク ポリシーまですべてを調整できます。
  • dnsTunneling、autoProxy、Hyper-V ファイアウォールなどの機能により、Windows 11 の VPN、プロキシ、セキュリティとの統合が向上します。
  • 慎重に構成することで、WSL2 は開発、コンテナー、安全なセルフホスティングのための堅牢なプラットフォームになります。

WSL2でのネットワーク構成

WSL2は、LinuxとWindowsの統合方法、特にネットワーク関連のあらゆる面で大きく変革しました。独自のネットワークスタック、IPアドレス、そして個別のアクセスルールを備えた軽量な仮想マシンが実現したのです。これにより、開発、テスト、コンテナ、そしてセルフホスティング環境において多くの可能性が広がりましたが、WSL1の時と同様に、サービスにアクセスできなくなるという懸念も生じています。

WSL2のネットワーク構成、NATモードとミラーリングモード、.wslconfigとwsl.confの使用方法、そしてファイアウォール、VPN、Docker、Tailscaleなどのツールとの連携方法を理解することは、トラブルを回避する上で非常に重要です。この記事では、このセットアップ全体の仕組み、WindowsとLANへのサービス公開方法、適切なIPアドレスを取得するために使用するコマンド、そして環境を微調整して安定性とセキュリティを確保するための高度な構成オプションについて、段階的に解説していきます。

WSL2でネットワークが実際にどのように動作するか

WSL2はWSL1のようにホストネットワークスタックを共有しなくなりました代わりに、各LinuxディストリビューションはHyper-Vによって管理される小さな仮想マシン内で実行されます。その仮想マシンには独自の仮想アダプタ（通常は eth0) および内部仮想スイッチによって割り当てられたプライベート IP アドレスです。

デフォルトモードでは、WSL2はNATベースのアーキテクチャを使用します。 (ネットワーク アドレス変換)。Windows はルーター/ホストとして機能し、Linux ディストリビューションは、通常は範囲内のプライベート サブネット上に存在します。 172.16.0.0/12このサブネットは、再起動または WSL の再起動後に変更される可能性があり、静的ファイアウォール ルールを構成するときに複数の人が困惑しています。

実用的な観点から言うと、これはWSL2ディストリビューションのIPアドレスがWSL1のように安定しておらず、LANから直接アクセスできないことを意味します。デフォルトでは、WindowsとWSL2間の接続はリダイレクトルールとNATを介してのみ行われ、ローカルネットワークへの公開には追加の手順またはミラーリングモードの使用が必要です。

この基本アーキテクチャに加えて、Windows 11 22H2以降のバージョンでは新しいネットワーク機能が追加されています。 （ミラーモード、dnsTunneling、autoProxy、Hyper-Vファイアウォールなど）グローバルファイルから制御される .wslconfigLinux内の特定のオプションは、 /etc/wsl.conf.

WSL2でIPアドレスを識別する

WSL2 を使用する際には、2 つの IP シナリオを明確に区別する必要があります。1 つは Linux ディストリビューションの IP アドレスが必要な場合、もう 1 つは Linux から見た Windows ホストの IP アドレスが必要な場合です。それぞれ異なるコマンドで処理します。

シナリオ 1: Windows から WSL2 ディストリビューションの IP アドレスを知りたい場合。ホスト上のアプリケーション (クライアント、ブラウザ、テストツールなど) が Linux 内で実行されているサービスに接続できるようにするためです。これを行うには、Windows (CMD または PowerShell) で次のコマンドを実行します。

wsl.exe --distribution <DistroName> hostname -i

デフォルトのディストリビューションを使用する場合は、ディストリビューション パラメータを省略できます。 そして電話するだけ wsl.exe hostname -iバックグラウンドでは、このコマンドはLinuxで起動します hostname --ip-addresses インスタンスのIPアドレスを返します。典型的な結果は次のようになります。

172.30.98.229

シナリオ2：Linuxディストリビューションから、WindowsホストのIPアドレスを知る必要があります。たとえば、WSL2アプリケーションがWindows上でネイティブに実行されているサーバー（Node.js、SQL Server、Caddyなど）に接続できるようにするためです。Linuxシェル内では、以下のコマンドを使用できます。

ip route show | grep -i default | awk '{ print $3 }'

出力はWSL2 VMのデフォルトゲートウェイであり、Linuxから見たWindowsホストのIPアドレスに対応します。例えば、次のようになります。

172.30.96.1

その値（例えば、 172.30.96.1）はLinuxクライアントが指すべきアドレスです クラシック NAT モードで Windows ホスト上で実行されているサービスにアクセスする場合。

NATモード: WSL2ネットワークのデフォルトの動作

WSL2は初期設定のままNATモードで動作し、多くのシンプルな開発環境ではそれで十分です。重要なのは、何が「そのまま」動作し、何が動作しないかを理解することです。そうすれば、無駄な時間を費やすことなく問題を解決できます。

localhost を使用して Windows から Linux サービスにアクセスするWSL2ディストリビューションでネットワークアプリケーション（Node.jsサーバー、Flaskサーバー、Linux上のSQL Serverなど）を実行する場合、Windowsから次のようにアクセスできます。 localhost:puertoWindows は、着信接続を WSL2 VM の内部 IP アドレスに自動的に転送します。

Linux から Windows 上で実行されているサービスにアクセスする場合：ここで状況が変わります。WSL2 からホスト上のネットワーク アプリケーション (Windows 上の Node.js サーバー、SQL Server、Caddy など) にアクセスするには、デフォルトの path コマンドで取得した、Linux から見たホストの IP アドレスを使用する必要があります。

ip route show | grep -i default | awk '{ print $3 }'

そのIPアドレスを使用すると、Linuxからホスト上の任意のサービスに接続できます。例えば http://172.30.96.1:3000 Windows サーバーがすべてのインターフェースでポート 3000 をリッスンしている場合。

リモート IP (ローカルホストではない) を使用して接続すると、アプリケーションはそれを LAN 接続として認識します。これは、多くのサーバーがリッスンするように設定する必要があることを意味します 0.0.0.0 代わりに 127.0.0.1たとえば、Flask を使用すると次のように起動できます。

  Windows 版 Fedora 42: PC に Fedora をインストールして使用するために必要なすべての情報

app.run(host='0.0.0.0')

この変更によりアクセシビリティは向上しますが、セキュリティには細心の注意を払う必要があります。なぜなら、デバイス自体からの接続だけでなく、ローカルネットワークからの接続も許可することになるからです。

NAT を使用してローカル ネットワーク (LAN) から WSL2 にアクセスする

WSL1からWSL2への移行で最も厄介な変更点の1つは、ディストリビューションがLANから直接アクセスできなくなったことです。WSL1では、Windowsシステムがネットワーク上で可視であれば、ディストリビューションのサービスもほぼ自動的にその公開状態を継承していました。

WSL2では、仮想マシンは独自のプライベートIPアドレスを持ち、LAN上に自動的に公開されません。NATモードで以前の動作と同様の動作を実現するには、Hyper-V仮想マシンと同様に、Windowsでポートプロキシを作成する必要があります。

Windows には、このための古典的なツールが含まれています。 netsh interface portproxyホスト ポートを WSL2 IP/ポートにリダイレクトする一般的なコマンドは次のようになります。

netsh interface portproxy add v4tov4 listenport=<puertoHost> listenaddress=0.0.0.0 connectport=<puertoWSL> connectaddress=(wsl hostname -I)

実際には、マーカーを特定の値に置き換えます。例えば、次のようになります。

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

ここで listenaddress=0.0.0.0 これは、Windows がホストのすべての IPv4 アドレスをリッスンすることを示します。ポート4000経由で受信したものを転送します 192.168.101.100:4000これは次のようにして取得される WSL2 IP アドレスになります。

  • wsl hostname -I WSL2 VM内のLinuxディストリビューションのIPアドレスがわかります
  • cat /etc/resolv.conf WSL2 から Windows Vista ホストの IP アドレスを明らかにします。

この手法を使えば、Windowsファイアウォールが許可し、ホストではなく仮想マシンのサービスを公開していることが明確であれば、WSL2上で実行されているサービスをLAN上のどのコンピュータからもアクセス可能にすることができます。

IPv6と最新のネットワーク機能

WSL2はIPv6にも対応しており、これは特に現代の環境、VPN、企業ネットワークにおいて重要です。アドレスを管理するためのLinuxの基本的なコマンドは、IPv4の場合と同じです。

  • wsl hostname -i WindowsからWSL2ディストリビューションのIPアドレスを確認する
  • ip route show | grep -i default | awk '{ print $3 }' LinuxからWindowsホストのIPアドレスを取得する

IPv6とVPNサポートにおける真の飛躍的な向上は、Windows 11 22H2以降のバージョンで利用可能なミラーリングネットワークモードにあり、これについては後ほど詳しく説明します。

ミラーリングされたネットワークモード: Linux で Windows インターフェースをミラーリングする

Windows 11 22H2以降を搭載したコンピューターでは、 WSL2で「ミラーリング」ネットワークモードを有効にすることができます。これにより、従来のNATとは異なり、LinuxはWindowsのネットワークインターフェイスを反映されたものとして認識します。

有効にするには、ファイルを編集する必要があります .wslconfig ユーザーの、にあります %UserProfile%\.wslconfig管理者権限を持つ PowerShell からは、次のコマンドで開くことができます。

notepad $env:USERPROFILE\.wslconfig

内部で、[wsl2] セクションを追加（または変更）してミラーモードを有効にします。

[wsl2]
networkingMode=mirrored

ファイルを保存したら、変更を有効にするためにWSL2を再起動する必要があります。例えば、以下のようにします。

wsl --shutdown

再起動すると、WSLは新しいミラーリングネットワークアーキテクチャを使用するようになり、これによりいくつかの強力な利点が得られます。

  • ネイティブ IPv6 サポートと企業ネットワークおよび VPN との統合の改善
  • LinuxからWindowsサービスに接続する機能 127.0.0.1 directamente （許可されていないが） ::1 （IPv6ループバックなど）
  • Windows-Linux統合におけるマルチキャストサポートの改善
  • netsh portproxy を必要とせずに LAN から WSL に直接アクセスするWindowsマシン自体のIPアドレスを使用する

このモードを有効にすることで、WSL2のNATに関する多くの典型的な問題が解決され、最新のWindows 11を使用できるほとんどの最新の開発環境やセルフホスティング環境で推奨されるオプションです。

WSL2 での DNS トンネリングとプロキシの使用

Windows 11 22H2 以降のバージョンでは、WSL2 からの名前解決も大幅に改良されました。鍵となるのは、 .wslconfig: dnsTunneling y autoProxy.

選択 dnsTunneling [wsl2] セクションではデフォルトで有効になっています。 これにより、LinuxのDNSリクエストは通常​​のネットワークパケットとして送信されるのではなく、仮想化機能を介して処理されるようになります。これにより、VPNやホスト上の複雑なネットワーク構成との互換性が大幅に向上します。

その部分については、 autoProxy=true WSLにWindows HTTPプロキシ設定を使用するように強制しますホストが企業プロキシまたはセキュリティ プロキシの背後にある場合、WSL2 は環境変数を手動で操作しなくてもそれを自動的に継承します。

例えば、次のようなものを .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

これにより、WSL2ネットワークがホスト構成と一貫して動作することが保証され、特に厳格なネットワークおよびフィルタリングポリシーを持つ企業にとって有用です。

Hyper-V ファイアウォールとセキュアサービス公開

最新の環境では、WSL2 ネットワークも専用のファイアウォールを経由します。Windows 11 22H2 上の WSL 2.0.9 以降では、Hyper-V ファイアウォール機能がデフォルトで有効になっており、VM トラフィック (WSL2 トラフィックを含む) に対するフィルタリングのレイヤーが追加されています。

ミラーリングモードで作業していて、WSL2サービス（API、ダッシュボード、セルフホスティングサービスなど）をLANに永続的に公開したい場合は、ファイアウォールルールでそれが許可されていることを確認する必要があります。

管理者権限を持つPowerShellから、プライベートネットワーク用のHyper-Vルールを作成するという合理的なアプローチがあります。

  最高のネットワーク監視ツール

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

何らかの理由でその特定の Hyper-V 保護を無効にしたい場合(あまり推奨されませんが)、次の方法を使用できます。

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

基本的な考え方は、可能な限りファイアウォールをアクティブに保ち、ルールをプライベートネットワークと本当に必要なポートのみに限定し、一括無効化は最終手段としてのみ行い、すべてが正常に動作するようになったらすぐに設定を再び強化するというものです。

WSL2 ネットワーク アーキテクチャ、X11、172.16.0.0/12 の範囲

WSL2ネットワークの詳細を明らかにする典型的な例として、X11を介したグラフィカルアプリケーションの使用が挙げられます。例えば、Windows上でXmingを起動し、DISPLAYを介してLinuxアプリケーションを送信する場合などです。

WSL1 から WSL2 にアップグレードすると、多くのユーザーは X が動作しなくなることに気づきます。 ネットワークは「共有」されなくなり、次のような範囲を持つ仮想NATネットワークになるからです。 172.16.0.0/12これは、Windows または WSL を再起動するたびに変更されることもあります。

WSL2 から Xming を使用して X を再び動作させるには、通常、以下の方法で Linux から認識される Windows の IP アドレスを取得します。

ENS

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

並行して、そのNATサブネットからのX11トラフィックを許可するようにWindowsファイアウォールを調整する必要がある。典型的なアプローチは、Xmingルールを編集して範囲を追加することです。 172.16.0.0/12 TCP+UDP 6000で。

多くの人は、オプションでXming認証を無効にすることになります -acこれは事実上、そのネットワークから接続してくるすべてのクライアントXに対して「扉を開く」ことになります。確かに機能しますが、セキュリティの観点からはかなり疑問があるため、より限定的なソリューションを検討するか、Windows 11のWSLg（統合GUIアプリケーション）の使用を検討する価値があります。

wsl.conf と .wslconfig: 高度な WSL2 構成

WSL には、VM の動作と各ディストリビューションの動作の両方を制御する 2 つの主要な構成ファイルが用意されています。: /etc/wsl.conf （ディストリビューションによる）および %UserProfile%\.wslconfig (すべての WSL2 ディストリビューションにグローバル)。

wsl.conf Linuxディストリビューション内では、 /etc/wsl.confこれは、そのディストリビューションのローカルオプションを設定するために使用されます：自動マウント、 hosts y resolv.confWindows、デフォルトユーザー、systemd などとの相互運用性。

.wslconfig Linux 外部の Windows ユーザー プロファイルに保存されます。 (C:\Users\<Usuario>\.wslconfig) であり、WSL2 を動かす VM のグローバル パラメータ (メモリ、CPU、カーネル、ネットワーク モード、ファイアウォール、DNS、仮想ディスク サイズ、GUI サポートなど) を制御します。

興味深い点の1つは、設定を変更する際の「8秒ルール」です。これらのファイルを変更する場合は、WSL VMが実際にシャットダウンしていることを確認する必要があります。ディストリビューションウィンドウを閉じても、数秒間メモリ上に残る可能性があるためです。

サブシステムを強制的に再起動するには、以下を使用できます。

  • wsl --list --running アクティブなディストリビューションがあるかどうかを確認する
  • wsl --shutdown すべての配布を一度に終了する
  • wsl --terminate <distroName> 特定のディストリビューションを停止する

WSLをオフにして再起動した場合にのみ、設定変更が実際に適用されます。多くの人がこの点を見落とし、「設定が機能していない」と思い込んでいます。

セクション別の主な wsl.conf オプション

ファイル wsl.conf これは、セクションとキーを備えた古典的な.ini形式に触発されています。主なセクションは [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Linux内でWindowsドライブをマウントする方法を制御できます （通常は低い） /mnt):

  • enabled (ブール値、デフォルトはtrue)trueの場合、C:/、D:/などが自動的にマウントされます。 /mnt/c, /mnt/d...
  • mountFsTab (ブール): 真の場合、処理されます /etc/fstab ディストリビューションを起動するとき。
  • root （鎖）: ドライブがマウントされるルートディレクトリ。例: /windir/ 持っている /windir/c.
  • options （カンマ区切りのリスト）: DrvFs固有のパラメータ、例えば metadata, uid, gid, umask, fmask, dmask o case.

DrvFsは、WindowsとLinux間のブリッジファイルシステムであり、WSLからNTFSにアクセスし、アクセス許可の制御、メタデータ、大文字小文字の区別を行うように設計されています。

セクション内 [network] ネットワークファイルの自動生成を調整します:

  • generateHosts: trueの場合、WSLは自動的に生成します /etc/hosts.
  • generateResolvConftrueの場合、WSLは /etc/resolv.conf レガシー DNS を使用します。
  • hostname: ディストリビューションが使用するホスト名。

セクション [interop] Windowsとの相互運用性を制御:

  • enabled: WSL から Windows プロセスを起動する機能を有効または無効にします。
  • appendWindowsPath: Windowsパスを追加するかどうかを決定します $PATH Linux。

En [user] ディストリビューションを起動するときにデフォルトで使用されるユーザーを指定できます:

  • default: WSL でデフォルトで起動されるユーザー名。

セクション [boot] Windows 11とServer 2022で特に役立ちます WSL 内で Docker などのサービスを自動的に起動するには:

  • command: WSL の起動時に実行するコマンド文字列。例: service docker start.
  • protectBinfmt: systemd が有効な場合に systemd ユニットの生成を保護します。

次のようなセクションもあります [gpu] （LinuxからWindows GPUへのアクセスを有効にする）、および [time] Windowsとタイムゾーンを同期するこれにより、夏時間への変更時や旅行時の問題を回避できます。

.wslconfig: WSL2 仮想マシン制御

wsl.conf は各ディストリビューションの動作を細かく調整しますが、.wslconfig を使用すると、すべての WSL2 ディストリビューションで共有される VM を細かく調整できます。このファイルは、WSL1 ではなく、WSL2 として実行されているディストリビューションにのみ関係します。

以内 .wslconfig メインセクションは [wsl2]主要なパラメータを定義する場所:

  • kernel y kernelModules: Windows からカスタム Linux カーネルとそのモジュールへの絶対パス。
  • memory: VMのメモリ制限（デフォルトはホストRAMの50%） 4GB.
  • processors: VM に割り当てられた論理プロセッサの数。
  • localhostForwarding: WSL2の開いているポートにWindowsからアクセスできるようにする localhost.
  • swap y swapFile: VM のスワップ ファイルのサイズとパス。
  • guiApplications: GUI アプリケーション サポート (WSLg) を有効または無効にします。
  • dnsProxyNAT モードの場合、Linux DNS サーバーがホストの NAT インスタンスになるか、Windows DNS のコピーになるかを決定します。
  • networkingModeここで以下から選択します none, nat, bridged （廃止）、 mirrored o virtioproxy.
  • firewall, dnsTunneling y autoProxy: WSL ネットワークを Windows ポリシーとより適切に統合するために説明したオプション。
  • defaultVhdSize: ディストリビューションのファイル システムが保存される VHD の最大サイズ (既定値は 1 TB)。
  DOCとDOCXの違い：どちらを使うべきか、そしてその理由

セクションもあります [experimental] テストで機能が有効になる場所 として：

  • autoMemoryReclaim: 自動メモリ回復設定 (無効、段階的、dropCache)。
  • sparseVhd: スペースを節約するためのスパース仮想ディスクの作成。
  • bestEffortDnsParsing y dnsTunnelingIpAddress: DNS トンネリングの微調整。
  • ignoredPorts: ミラー モードのときに Windows で使用されていても Linux アプリが使用できるポート。
  • hostAddressLoopback: ミラーモードでホストのローカル IP アドレスを使用してホストとコンテナが接続できるようにします。

.wslconfig を適切に設定することで、リソースを大量に消費する仮想マシンと、Windows やネットワークとうまく連携する最適化された環境との違いが生まれます。特に、負荷の高いワークロード、コンテナ、または複数のディストリビューションを同時に扱う場合は、この点が重要になります。

Tailscale を使用したセルフホスティングのための WSL2、Docker、ネットワーク

非常に実用的な例としては、Windowsサーバー（Windows Server 2025を含む）上でWSL2をセルフホスティングプラットフォームとして使用し、WSL2上のUbuntu、Docker Engine（Docker Desktopなし）、Tailscale、そしてCaddyのようなリバースプロキシを組み合わせて、n8nやSupabaseなどのサービスを公開する方法が挙げられます。

目標は、WSL2 内で安定した Docker 環境を構築し、サーバー上の Docker Desktop の問題を回避することです。Docker Engine を Ubuntu (WSL2) に直接インストールすることで、コンテナのネットワークは WSL2 ネットワークに依存し、さらに WSL2 ネットワークは .wslconfig で定義された NAT またはミラーリング モードに依存します。

WSL2にTailscaleをインストールすると、ルーターのポートを開放することなくメッシュVPN上でサービスを公開でき、Caddyをリバースプロキシとして使用してTLS証明書、ルーティング、コンテナ間の軽量ロードバランシングを一元管理できます。

クリーンで予測可能かつ安全なネットワークを維持するためには、以下のことをお勧めします。

  • 単一の一貫したネットワークモード（NATまたはミラーリング）を選択し、それを文書化する
  • WindowsとWSL2間のポート競合を回避する、頼りに ignoredPorts ミラーリングを使用する場合
  • TailscaleまたはCaddy経由でのみサービス公開を制御ファイアウォールで「デフォルトで」ポートを開く代わりに
  • Docker、Tailscale、Caddyの起動を自動化 [boot] wsl.conf内 より生産に近い環境を実現する

このアーキテクチャにより、WSL2は単なる開発ツールではなくなり、その制限（Hyper-Vによる仮想化、追加のネットワーク層など）を受け入れ、慎重に設定すれば、かなり本格的なセルフホスティングプラットフォームになり得る。

開発とテストのための WSL2 ネットワークのベスト プラクティス

微調整以外にも、 IPアドレス、ポート、ファイアウォールといった問題に常に悩まされることなく、WSL2ネットワークを快適に操作するためのガイドラインがいくつかあります。

開発サービスには、高いポート番号（1024以上）を使用し、特権ポートや使用頻度の高いシステムポートは避けてください。これにより、競合を最小限に抑え、追加の特権が不要になります。

コードとデータが Linux ファイル システム内に存在していることを確認します。 （あなた ~/ または内部ルート）に直接作業するのではなく、 /mnt/cWSL から NTFS にアクセスすると速度が遅くなり、I/O を集中的に使用するサービスに悪影響を与える可能性があるためです。

スクリプトを使用してネットワーク設定とリダイレクトルールを自動化する PowerShell および Bash の場合: たとえば、WSL2 の起動時にそれを構成するスクリプト。 netsh portproxy (NAT を続行する場合) またはミラーリングを使用するときにファイアウォール ルールを確認します。

IPの変更に頼らない 内部仮想スイッチによって生成される。可能な限り、 localhost、ホスト名またはエントリ /etc/hosts サービスの IP を変更してもテスト インフラストラクチャの半分が壊れることがないようにします。

プロフェッショナル環境や準実運用環境では、WSLの自動転送に盲目的に頼るのは避けるべきです。ポート、プロキシ、ファイアウォールルールを明示的に設定して、何がどこに公開されるかを正確に把握しましょう。

適切に設定すれば、WSL2は隔離された柔軟なネットワークを提供し、高度な開発、APIテスト、コンテナ作業、分散環境のシミュレーションに最適です。重要なのは、ネットワークモード（NATとミラーリング）、wsl.confファイルと.wslconfigファイル、ファイアウォールやスタック内のツール（Docker、Tailscale、リバースプロキシ）との連携をマスターすることです。これにより、ポートの競合やセキュリティの侵害なしに、WindowsとLinuxを同じマシン上で実行できます。