VPN接続中にWSLだけ名前解決できない
この記事の結論
Windows側は通信できるのにWSL内のaptやcurlがホスト名を解決できない場合の安全な切り分け手順。VPNのNRPT、企業ファイアウォール、古いNAT DNSプロキシ構成がWSLのDNS要求と競合している可能性がある。設定変更前に現在値を控え、公式機能だけを使って確認する。
一般的な切り分けガイドです。特定の不具合が現在発生しているという告知ではありません。
対象製品・影響範囲
- 製品
- WSL 2
- 対象バージョン・条件
- Windows 11（対応機能はエディションとハードウェア要件を確認）
- 関連するエラーコード・識別子
- DNS
発生する症状
- Windows側は通信できるのにWSL内のaptやcurlがホスト名を解決できない
- 再起動や再試行だけでは同じ状態が続くことがある
原因・発生条件
VPNのNRPT、企業ファイアウォール、古いNAT DNSプロキシ構成がWSLのDNS要求と競合している可能性がある。
作業前の準備
- 開いている文書と作業を保存し、必要ならPCを再起動できる時間を確保する
- 管理者権限が必要な操作は、個人所有PCまたは管理者の許可を得た端末だけで行う
- 診断用コマンド「wsl --version」の結果を保存し、変更前後を比較できるようにする
この操作の注意点
- レジストリ、システムフォルダー、資格情報、記憶域を手作業で一括削除しない
- インターネット上の非公式スクリプトや不明なドライバーを管理者権限で実行しない
使用するツール・公式ページ
この手順の公式要件、画面名、制限事項を確認する。
具体的な操作手順
Windowsで対象サイトが開けるか確認し、WSL内では getent hosts microsoft.com を実行します。企業内ホストだけ失敗する場合はそのホスト名も管理者に伝えます。VPNを切る比較は業務上許可される場合だけ行います。
テスト用の名前は「必要な社内ホスト名」と「普段利用する公開ホスト名」を分けます。公開名だけが成功しても社内システムの復旧を意味しません。Windows側ではResolve-DnsNameなどで同じ名前を確認し、WSL側ではgetent hostsで結果を控えます。名前が見つかるか、返るアドレスが想定範囲か、失敗するのはVPN接続時だけかを並べて記録します。組織の接続先名や内部アドレスを公開相談に載せる必要はありません。外へ共有する場合は伏せ字にし、管理者には正確な情報を別経路で渡します。
Windows側とWSL側で同じホスト名を調べ、VPN接続前後の結果を控えます。Windowsでは解決できWSLだけ失敗するならWSLのDNS経路、両方失敗するならVPNや組織DNSを優先します。名前が解決できるのに接続が失敗する場合は、アプリのポートやプロキシを別に調べます。
Store版WSLを更新し、Windows 11 22H2以降ではDNS tunnelingの利用可否を確認する。
対象ディストリビューション、WSL版、既定バージョンが表示されるか確認します。コマンドが認識されない場合はディストリビューションをリセットせず、WSL機能とStore版WSLの導入状態を確認します。
結果を四つに分けると次の操作が決まります。WindowsもWSLも失敗するならVPNや組織DNS、Windowsだけ成功するならWSLのDNS経路、WSLで名前は解決するがアプリは失敗するならポートやプロキシ、VPNを切った時だけ成功するならVPNの経路やポリシーを調べます。VPNを切って社内サービスへ接続できるとは限らないため、切断時の比較は管理者が許す範囲で行います。ファイアウォールの全停止や公開DNSへの恒久置換は、この比較の代わりになりません。
wsl --versionWSL内で実行中の処理を確認し、ファイルを保存します。wsl --shutdownはすべてのディストリビューションとWSL 2のVMを停止するため、他のWSL作業やコンテナーも停止してよい時間に実施します。
既存の.wslconfigや/etc/resolv.confを確認する場合は内容を控え、どこを手動変更していたかを明らかにします。WSL版とWindows要件を満たすことを確認せず、別環境の記事から設定値だけをコピーしません。設定を反映するためにWSLの停止が必要なら、Linux側の作業とサービスを保存・停止できる時間を確保します。VPNクライアントを更新する場合も、会社指定の版を勝手に置き換えないでください。一つの変更を反映して同じ二つの名前を比較し、改善しなければ変更前の設定へ戻します。
この手順で使う公式リンク
- Accessing network applications with WSL
この手順の公式要件、画面名、制限事項を確認する。
- Accessing network applications with WSL
Windows 11 22H2以降で対応するWSLを使用していることを確認します。エクスプローラーで %UserProfile% を開き、既存の.wslconfigをバックアップします。[wsl2] セクションに dnsTunneling=true を設定し、二重の[wsl2]を作らないで保存します。Linuxの作業を保存して wsl --shutdown を実行し、再度ディストリビューションを開きます。
Linux側の/etc/wsl.confでgenerateResolvConf=falseを設定している場合はDNSトンネリングが動作しないことがあります。過去に変更した構成をバックアップして管理者と確認し、独自のDNS固定設定と混在させないでください。
.wslconfigはLinuxシェルへ入力するコマンドではありません。Windows側でWin+R→ notepad.exe %UserProfile%\.wslconfig を開き、公式記事に記載されたDNS tunneling設定を[ wsl2 ]セクションへ保存してから、ターミナルで wsl --shutdown を実行します。
対応するWindows 11とWSLではDNS tunnelingがVPNとの互換性に役立つ場合があります。公式要件と現在のWSL版を先に確認します。/etc/resolv.confを手動固定している環境は変更前の内容を保存し、公開DNSへの置換で社内名の解決や組織方針を壊さないよう管理者と調整します。
「getent hosts microsoft.com」で状態を確認し、最初に記録した操作を同じ条件で一度実行する。成功した場合も再起動後にもう一度確認し、変更した設定と結果を記録する。
最終確認では必要な社内名の解決と、実際の社内アプリの接続を両方行います。ブラウザーの外部サイトが開くだけでは、WSLから社内APIへ接続できることを確認したことにはなりません。再現がVPN接続直後だけか、スリープ復帰後にも起きるかも控えます。継続する場合はVPN製品名と版、Windows/WSL版、手動DNS設定の有無、同じ名前の比較結果を渡します。復旧手順を保存する際は、社内名をどのDNSで解決する設計なのかも管理者に確認し、偶然動いた設定を恒久運用にしません。
getent hosts microsoft.com
改善したか確認する
- VPN接続中に必要な社内名を解決し、対象アプリまで接続できる
- 確認コマンドの出力が期待する有効・正常・接続済み状態を示す
- Windows再起動後にも同じ操作を再現でき、イベントログに同時刻の新しい重大エラーが増えない
改善しない場合・設定を戻す場合
- VPN製品・WSL版・WindowsとWSLの同一名の解決結果を管理者へ渡す
- ハードウェア要件、組織ポリシー、サーバー側設定が原因なら、クライアント側で回避せず所有者に変更を依頼する
このガイドの適用範囲
対処ガイド — 原因を切り分け、対象機能が正常に起動または接続でき、再起動後も同じ検証を通る状態を目標にする。
掲載内容は2026-10-13の情報確認に基づきます。以降の変更は公式出典でご確認ください。
よくある質問
resolv.confへDNSを固定してよいですか？
企業VPNではDNSサーバーや検索サフィックスが変わるため固定値は壊れやすいです。まずDNS tunnelingを使い、VPN管理者の方針を確認します。
設定変更後も古いDNSが残ります。
`wsl --shutdown` で全ディストリビューションを停止してから再起動し、`getent hosts` で確認します。
microsoft.comが解決すれば直ったと言えますか？
公開名の確認には役立ちますが、社内名はVPN側のDNSや検索ドメインに依存する場合があります。最初に困っていた社内名とアプリで検証し、名前解決と通信の両方が成功したことを確認します。
出典・情報の更新
- 主な出典の更新・解決日
- 公式ページで日付を特定できないため記載していません
- 本サイトの確認日
- 2026-10-13
公式情報を日本語で整理しています。メニュー名は製品の表示言語や版によって異なる場合があります。確認日は障害の発生日を意味しません。編集方針