WSL2 で名前解決できずインターネットに接続できない
ping 8.8.8.8 は通るのにホスト名が引けないなら DNS の問題。/etc/resolv.conf は WSL が自動生成するため手で書いても消える。
固定するには /etc/wsl.conf で自動生成を止める。
公開: 更新:
ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 20 Sep 29 10:06 /etc/resolv.conf -> /mnt/wsl/resolv.conf
2026-09-29 に local host (Windows 11 Home, Docker 29.8.0)（Node.js 22.14.0 / npm 10.9.2） で実際に打って取った出力。検証環境の詳細
要約
WSL2 でパッケージの取得やネットワークアクセスが失敗するとき、原因の多くは経路ではなく名前解決である。
/etc/resolv.conf は WSL が起動のたびに自動生成する。
手で書き換えても次の起動で上書きされるため、設定を残したいなら /etc/wsl.conf で自動生成そのものを止める必要がある。
実行例
WSL2 の Ubuntu（/etc/wsl.conf に systemd=true がある状態）で generateResolvConf = false を追記し、/etc/resolv.conf を消してから wsl --terminate で再起動すると、/etc/resolv.conf は systemd-resolved のスタブを指すリンクに置き換わり、ping 8.8.8.8 は通るのに ping example.com だけが Temporary failure in name resolution で失敗した。
そのリンクを rm -f で消してから nameserver 1.1.1.1 を書き込むと /etc/resolv.conf は通常のファイルになり、同じ ping example.com が応答を返している。
$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 20 Sep 29 10:06 /etc/resolv.conf -> /mnt/wsl/resolv.conf$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 10.255.255.254$ ping -c 1 example.com
PING example.com (172.66.147.243) 56(84) bytes of data.
64 bytes from 172.66.147.243: icmp_seq=1 ttl=56 time=20.3 ms
--- example.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.252/20.252/20.252/0.000 ms$ printf '\n[network]\ngenerateResolvConf = false\n' >> /etc/wsl.conf$ cat /etc/wsl.conf
[boot]
systemd=true
[network]
generateResolvConf = false$ rm -f /etc/resolv.conf$ wsl --terminate Ubuntu
この操作を正しく終了しました。$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Sep 29 10:06 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf$ ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=19.0 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 19.039/19.039/19.039/0.000 ms$ ping -c 1 example.com
ping: example.com: Temporary failure in name resolution$ rm -f /etc/resolv.conf$ printf 'nameserver 1.1.1.1\n' > /etc/resolv.conf$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 19 Sep 29 10:07 /etc/resolv.conf$ ping -c 1 example.com
PING example.com (104.20.23.154) 56(84) bytes of data.
64 bytes from 104.20.23.154: icmp_seq=1 ttl=56 time=18.6 ms
--- example.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 18.638/18.638/18.638/0.000 ms— 2026-09-29 時点の出力
検証環境Node.js 22.14.0 / npm 10.9.2 / Git 2.48.1.windows.1 / 2026-09-29 検証（ほか 1 件）
- 検証日
- 実行環境
local host (Windows 11 Home, Docker 29.8.0)- バージョン
- Node.js 22.14.0
- npm 10.9.2
- Git 2.48.1.windows.1
- Docker 29.8.0
この記事の「実行例」は、上記の環境で実際にコマンドを実行して得られた出力をそのまま掲載しています。 再現手順はリポジトリの検証スクリプトとして管理し、定期的に再実行して出力を更新しています。
解決策
1. DNS の問題か切り分ける
ping -c 1 8.8.8.8
ping -c 1 example.com前者だけ通るなら経路は生きており、名前解決だけが失敗している。
2. resolv.conf の自動生成を止める
sudo tee /etc/wsl.conf > /dev/null << 'CONF'
[network]
generateResolvConf = false
CONFgenerateResolvConf を false にすると WSL は /etc/resolv.conf を自動生成しなくなる（公式ドキュメント（新しいタブで開く））。
ただし tee は /etc/wsl.conf を丸ごと上書きする。wsl --install で入れた現行の Ubuntu には最初から [boot] セクションの systemd=true が書かれており（systemd の公式ドキュメント（新しいタブで開く））、上書きすると再起動後に systemd が PID 1 でなくなる。
既にファイルがあるときは、エディタで開いて [network] セクションを追記する。
3. DNS サーバを書く
sudo rm -f /etc/resolv.conf
sudo tee /etc/resolv.conf > /dev/null << 'CONF'
nameserver 1.1.1.1
CONF自動生成を止めた後に書けば、この内容が保持される。
既存の /etc/resolv.conf はシンボリックリンクのことがあるため、先に削除しておく。
4. ディストリを再起動する
wsl --terminate UbuntuPowerShell から実行し、該当ディストリを立ち上げ直して設定を反映させる。/etc/wsl.conf はディストリごとの設定なので、そのディストリだけを止めれば読み直される。
ディストリ名は wsl --list --verbose で確認できる。
wsl --shutdown でも反映されるが、こちらはすべてのディストリと WSL2 の仮想マシンごと落とす。
Docker Desktop のように WSL を土台にしているアプリがあると巻き添えで止まるため、まずは --terminate で対象を絞る。
VM 全体に効く .wslconfig（次の項目の dnsTunneling など）を変えたときは wsl --shutdown が必要になる。
5. VPN 環境では DNS トンネリングを確認する
Windows 11 22H2 以降では .wslconfig の [wsl2] にある dnsTunneling が既定で有効になっており、ネットワークパケットを送らずに Windows 側へ DNS 要求を渡す。
VPN 併用時の名前解決が不安定なら、この設定の状態を確認する。
よくある原因
- 自動生成による上書き:
/etc/resolv.confを直接編集したが、WSL が再生成して元に戻した。 - VPN や企業ネットワーク: Windows ホストへの DNS 問い合わせが遮られる構成になっている。
- 反映漏れ:
/etc/wsl.confを書いたが WSL を再起動していない。 - 構成の複雑さ: 複数の仮想アダプタや独自 DNS が絡み、問い合わせ先が定まらない。