#0240（2025/09/10）WSLネットワーク：mirrored modeの実践

WSLネットワーク：mirrored modeの実践とNAT比較

「mirrored modeとは、WindowsとWSLが“同じネットワークに直結した仲間”として振る舞い、双方向アクセスや名前解決をシンプルにする設定である。」

前提と全体像

ここで扱う“mirrored mode（ミラード）”は、WSL2のネットワーク動作をNAT（仮想ルーター越し）ではなく、ホストと同等のL2セグメントへ直接つなぐ発想だ。結果として、WSLのディストリビューションがLAN上で実機のように見えやすくなり、社内ネット、VPN、同一Wi‑Fi上の端末などからの到達性が改善する。逆に、NATはWSLがプライベートな仮想ネットワーク内にいて、WindowsがNATルーター役を担うモードだ。開発用途ならどちらも選択肢になりうるが、要件（到達性、セキュリティ姿勢、運用負荷）で使い分けるのが筋がよい。

“同じネットワーク”と言っても、IPを共有するわけではない。多くの環境でWSL側に独立したIPが払い出される（DHCPまたはそれに準じた仕組み）。これにより、LAN上の別端末から http://wsl-ip:ポート で直接アクセスできるようになる。一方でWindows側の防火壁や企業ネットワークのポリシー、ドライバー構成、VPNの分離設定などによって、期待通りにならない場面もある。そこを丁寧に切り分けていくのがこのガイドの狙いだ。

mirrored modeの意味と挙動

mirrored modeの狙いは、開発中のサービスを「外から普通に見える」状態で動かすことにある。主な特徴は次の通り。

• 到達性：WSLがLAN上の“ひとつのマシン”として扱われる。mDNSやL2ブロードキャスト、IPv6、マルチキャストを必要とするミドルウェアの動作が安定しやすい。
• ポート公開：WSL内のプロセスが 0.0.0.0（全IF）で待ち受けていれば、同一ネットワークからそのポートへ直接アクセスできる。127.0.0.1 に束縛すると外部から届かないのは従来どおり。
• 名前解決：WindowsとWSLが共有／連携するDNS設定の影響で、host.docker.internal 的な名前や社内DNSのレコード解決がスムーズになるケースがある。社内DNSが分割されている環境ではプロファイルごとに検証すること。
• ファイアウォール：到達性が高くなる分、Windows側・WSL側の双方でポート開放の責任が増す。開放ルールは“必要最小限・期間限定”が基本。
• hostAddressLoopback：[experimental] hostAddressLoopback=true を使うと、Windows自身のアドレス宛のアクセスをWSL側へループバックさせる挙動が有効になる。開発中に“WindowsのIPに対するアクセス＝WSLのサービス”に寄せたいとき便利だ。false なら逆向き（WSL→Windows）を優先する理解で良い。

設定手順（.wslconfig）

最小構成は次のとおり。%USERPROFILE%\.wslconfig を新規作成／編集し、WSLを再起動する（wsl --shutdown の後に再起動）。

[wsl2]
networkingMode=mirrored

[experimental]
hostAddressLoopback=true

再起動後の確認手順はシンプルだ。

1. アドレス確認：WSLで ip addr。eth0（環境により名称は異なる）にLANと同系統のIPが付いているかを見る。
2. 疎通確認：別端末から ping <WSLのIP>。ICMPが塞がれている組織では、代わりに curl http://<WSLのIP>:ポート など、TCPでの到達を検証する。
3. 名前解決：nslookup／dig で社内ドメインの解決が想定どおりか確認。必要なら /etc/resolv.conf の自動生成や固定化を調整する。
4. ポート検査：WSLで ss -lntp、Windowsで netstat -ano を用い、バインド先IFとポート競合をチェック。

よく使う追加オプション

• ignoredPorts：Windows側で使っているポートをWSLに回さない指定。競合時に役立つ。
• dnsTunneling：DNSの扱いを安定化。社内VPNと組み合わせると効くケースがある。
• autoProxy：Windowsのプロキシ設定をWSLへ伝播。パッケージ取得や社内レジストリ利用時に便利。

NATモードとの違い（要点）

同じ階層のものを比較するために、要点を表にまとめる。

観点	mirrored mode	NATモード
IP付与	LAN側から直接払い出し（多くはDHCP）	仮想ネットワーク内のプライベートIP
外部到達性	高い：LAN内・VPN越しからの直接到達が期待できる	低い：原則Windows経由、ポートフォワードが前提
mDNS/ブロードキャスト	通りやすい	通りにくい／個別対応が必要
IPv6	有効化しやすい	構成次第。NAT64/Teredo系は別途検討
セキュリティ境界	広がる（露出が増える）	狭い（WSLが内側に守られる）
ポート競合	WindowsとWSLの競合に注意	競合は少なめだがフォワード設定が必要
企業VPN	分割トンネルやACLに左右される	多くは“Windowsから出る通信”として扱いやすい
使いどころ	実機同等の疎通検証、モバイル/IoT/産業系、多人数試験	単体開発、ローカル限定の検証、素早い隔離

具体例：よくある開発シナリオ

• フロントエンド開発：WSLでViteやNext.jsを --host 0.0.0.0 で起動。LAN上のスマホで http://<WSLのIP>:5173 を開き、実機検証を素早く回せる。NATではWindowsのポートフォワードが必要になりがち。
• WebAPIの社内検証：QAチームが別PCからWSL上のAPIへ直接叩ける。“Windows PCがゲートウェイ”という説明が不要になるので手戻りが減る。
• マイクロサービス／mDNS：サービス発見（Avahi等）やgRPCの双方向通信、マルチキャスト前提の基盤の稼働確認がやりやすい。
• Docker/コンテナ：Docker Desktop でもWSL内Dockerでも、0.0.0.0 バインドでLANに露出できる。外からの疎通試験を“ほぼ本番”のトポロジで試せる。

落とし穴と対処

• ポートが捕まれない：Windowsのセキュリティ製品や“予約済みポート”が邪魔をしていることがある。別番号へ逃がす／ignoredPorts を使う／バインドIFを限定する。
• VPNで途切れる：スプリットトンネル（宛先ごと振り分け）か全面トンネルかで挙動が変わる。VPNクライアントの設定とルーティングテーブルを一度必ず観察。
• Wi‑FiのAP分離：同じSSIDでもAP分離が有効だとLAN内相互通信が遮断される。別の帯域や有線を試す。
• IPv6/名前解決の罠：IPv6優先で名前だけ引けて実体は別ネット、という事故がある。ping -4/-6、curl -4/-6 で切り分ける。
• localhost問題：127.0.0.1 で待受けていると外からは届かない。外部疎通前提なら 0.0.0.0 へ変更する。
• WSL再生成：/etc/resolv.conf の自動生成や、Systemd有効化の影響で起動順序が変わることがある。疑わしいときは一旦初期状態に戻して差分だけを適用。

シナリオ別の設定レシピ（抜粋）

レシピ1：とりあえず“外からつながる”を最短で

[wsl2]
networkingMode=mirrored
[experimental]
hostAddressLoopback=true

• 再起動後、WSLで python -m http.server 8000 --bind 0.0.0.0 を実行。別端末から http://<WSLのIP>:8000 にアクセス。

レシピ2：Windows側のポート予約と競合を避けたい

[wsl2]
networkingMode=mirrored
[wsl2.networking]
ignoredPorts=80,443,3000,5173

• 開発でよく使うポートを競合から守る。必要に応じて範囲指定や別の番号を使う。

レシピ3：社内DNSとプロキシを丸ごと引き継ぐ

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

• apt や pip の取得、社内レジストリやミラー利用を安定化。

mirroredとNATの運用判断フロー（簡易）

1. 外部端末から直接叩きたいか？ → はい：mirrored優先。いいえ：次へ。
2. mDNS/ブロードキャスト/IPv6は必要か？ → はい：mirrored。いいえ：次へ。
3. 露出を極力減らしたいか？ → はい：NAT。いいえ：どちらでも可。チーム標準に合わせる。
4. 企業VPNの制約が強いか？ → 強い：NATから始め、必要ならmirroredへ昇格。弱い：mirroredで一気に整える。

hostAddressLoopbackの使い分け（比較表）

到達方向の切替は同じ階層の論点なので、表で簡潔にまとめる。

設定	ベクトル	主目的	注意点
true	Windows→WSL	「WindowsのIPでアクセス＝WSLのサービス」に寄せる	Windows側の同ポートと競合しやすい。防火壁例外の調整も必要
false	WSL→Windows	WSLからWindows上のサービスへ寄せる	外部端末からはWSLに届かない想定で設計すること

まとめ

mirrored modeは「到達性」と「現実のネットワークに近い検証容易性」を提供する一方、露出増や企業ネットの制約というコストを連れてくる。NATは安全側の初期値として優秀だが、外向き検証や複数端末実機検証では煩雑になりやすい。求める開発体験とセキュリティ境界のバランスを見極め、.wslconfig を小さく保ったまま必要十分のオプションだけを足す――それが中級者にとっての正攻法だ。