WSL2 インストール直後に直す 7 つのこと — .wslconfig、systemd、DNS、ディスク回収、VS Code 統合、ミラーネットワーク。

Windows 初期セットアップで WSL2 をインストールしたら、次のステップはチューニングだ。デフォルトのまま使うとメモリが暴走し、再起動後に DNS が壊れ、ディスクが肥大化し、systemd が使えない。このガイドでは 7 つのチューニングを一括で適用する — 一度やれば毎日恩恵を受ける。

対象：Windows 11（22H2 以上）+ WSL2 + Ubuntu（または systemd 対応ディストリ）。

TL;DR

チューニング	ファイル	効果
1. `.wslconfig`	`%USERPROFILE%\.wslconfig`（Windows）	RAM/CPU/swap の上限 + GUI・ミラーネットワーク
2. `wsl.conf` systemd	`/etc/wsl.conf`（WSL 内）	systemd を有効化 → snap・docker・systemctl が使えるようになる
3. DNS の安定化	`/etc/wsl.conf` + `/etc/resolv.conf`	VPN / 再起動後の DNS 切断を防止
4. I/O パフォーマンス	ワークスペースの場所	`/mnt/c/...` ではなく WSL ネイティブ（`/home/...`）を使う
5. ディスク回収	export/import	肥大化した vhdx を縮小（数十 GB 回収可能）
6. VS Code Remote-WSL	拡張 1 本	WSL のファイルをネイティブ速度で編集
7. ミラーネットワーク	`.wslconfig` `networkingMode=mirrored`	VPN / 社内ネット対応（Win11 22H2 以上）

前提条件

Windows 11 22H2 以降（一部機能は 23H2 以降推奨）
WSL2 インストール済み + systemd 対応ディストリ 1 つ以上（Ubuntu など）
- 未インストールの場合：管理者 PowerShell で wsl --install
.wslconfig 自体はユーザープロファイルにあるが、wsl --shutdown には管理者権限推奨

1. `.wslconfig` — RAM/CPU/swap の上限

デフォルトでは WSL2 が Windows RAM の約 50% まで確保できる — 大きな Node のビルドで Windows 自体がスワップに追い込まれることがある。明示的な上限を設定する。

1.1 テンプレート

.wslconfig

# PowerShell
Invoke-WebRequest -Uri https://devalice.jaceclub.com/assets/windows/wsl-tuning/wslconfig-template.txt -OutFile $env:USERPROFILE\.wslconfig
Get-FileHash $env:USERPROFILE\.wslconfig -Algorithm SHA256
# expected: BFBDAF7AE486916D8AA4E792F9845416E1B6B6EA535F84E1BBCCA2BE9ACCB3C4
# (lowercase: bfbdaf7ae486916d8aa4e792f9845416e1b6b6ea535f84e1bbcca2be9accb3c4)

1.2 主な設定

# %USERPROFILE%\.wslconfig
[wsl2]
memory=8GB             # ホスト RAM の 50〜75%
swap=4GB               # ディスクスワップ（0 = 無効）
localhostForwarding=true
guiApplications=true   # Linux GUI アプリ（Win11 デフォルト）
# processors=8         # CPU コア数の明示的な上限（オプション）

1.3 適用

wsl --shutdown   # すべての WSL インスタンスを停止
wsl              # 次回起動時に .wslconfig が読み込まれる

1.4 確認

WSL 内で：

free -h          # メモリ上限の確認（例：8GB）
nproc            # CPU 数
swapon --show    # スワップが有効か

16GB ホストマシンでは memory=10GB が適切。32GB マシン：memory=16GB。

2. systemd の有効化 — `/etc/wsl.conf`

WSL2 のデフォルト init は systemd ではない。最近のパッケージ（docker、snap、postgresql サービスなど）は systemd を前提とする。

2.1 有効化

# WSL 内（sudo 必要）
sudo nano /etc/wsl.conf

内容：

[boot]
systemd=true
 
[user]
default=me          # デフォルトユーザー（オプション）

保存後：

# Windows PowerShell
wsl --shutdown
wsl

2.2 確認

ps -p 1            # PID 1 == systemd → 成功
systemctl status   # systemd の情報が表示される → OK

sudo systemctl start docker などが正常に動作するようになる。

起動時間が 1〜3 秒増えるが、代わりに本格的なサービスマネージャー・ジャーナルログ・タブ補完が手に入る。

3. DNS の安定化

WSL2 のデフォルト DNS は Windows NAT ブリッジを経由するが、VPN の接続 / 切断後や再起動後によく壊れる。症状：curl github.com は通るが apt update は通らない、またはその逆。

3.1 オプション A — 自動 DNS を無効にして静的リゾルバーを設定

sudo nano /etc/wsl.conf

追記：

[network]
generateResolvConf=false

保存 → wsl --shutdown → 再起動。

WSL が /etc/resolv.conf の自動書き換えを停止する。手動で設定：

sudo nano /etc/resolv.conf

nameserver 1.1.1.1
nameserver 8.8.8.8

社内ネットワーク / VPN では IT 部門が提供する内部 DNS を追加する。

3.2 オプション B — ミラーネットワーク（Win11 22H2 以上、推奨）

セクション 7 で WSL が Windows の DNS を自動的に共有するようになる。社内 VPN で最も安定している。

4. I/O パフォーマンス — 作業場所の選定

最もよく見落とされるチューニング。場所によってパフォーマンスが大きく異なる：

場所	パス	ビルド速度（例：`npm install`）
WSL ネイティブ	`/home/me/project`	✅ 高速（Linux ext4）
Windows マウント	`/mnt/c/Users/me/project`	❌ 5〜10 倍遅い（9p プロトコル）

ルール：WSL の作業は WSL ディスク内に置く。Windows が同じファイルにアクセスする必要がある場合は、VS Code Remote-WSL（§6）または Syncthing（ファイル同期参照）で両側にコピーを保持する。

4.1 良いパターン

# WSL 内
mkdir -p ~/work
cd ~/work
git clone git@github.com:org/repo.git
cd repo
npm install              # 高速

4.2 アンチパターン

# Windows でクローン、WSL でビルド
cd /mnt/c/Users/me/Documents/project   # クロスマウント
npm install                             # 遅い（数十分かかることも）

4.3 クロスマウントが必要な場合

Windows 専用ツールが同じフォルダを開く必要がある場合（Photoshop など — まれ）
Windows IDE での編集 — VS Code Remote-WSL で解決可能

5. ディスクサイズ — vhdx の圧縮

WSL の .vhdx 仮想ディスクは自動的に縮小しない。30GB のキャッシュをビルドして削除しても、ファイルは 30GB のままだ。

5.1 現在のサイズを確認

# PowerShell
Get-ChildItem -Path "$env:LOCALAPPDATA\Packages" -Recurse -Filter "ext4.vhdx" | ForEach-Object {
  "{0,-60} {1:N2} GB" -f $_.Directory.Name, ($_.Length / 1GB)
}

5.2 オプション A — スパース VHD（Win11 22H2 以上）

.wslconfig（§1.1 のテンプレートにコメントアウト済みで含まれている）：

[experimental]
sparseVhd=true

wsl --shutdown で有効化。未使用領域が段階的に回収される。

5.3 オプション B — 手動圧縮（`diskpart`）

WSL 停止中に：

wsl --shutdown
 
diskpart
# diskpart>
select vdisk file="C:\Users\me\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_*\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

数十 GB 回収可能。遅い — 夜間に実行すること。

5.4 オプション C — エクスポート / インポート（最もクリーン）

完全バックアップ + 再作成。新しい vhdx は最適なサイズで開始する。

wsl --shutdown
wsl --export Ubuntu C:\backup\ubuntu.tar
wsl --unregister Ubuntu
wsl --import Ubuntu C:\WSL\Ubuntu C:\backup\ubuntu.tar

オプション C は最も効果的だが、インスタンス ID / インストールメタデータが再作成される。systemd 設定・デフォルトユーザーなどを再適用する必要がある。計画的な移行時に行うのが最適。

6. VS Code Remote-WSL

WSL のファイルを Windows VS Code でネイティブ速度で編集する。クロスマウント問題の標準的な解決策。

6.1 インストール

Windows VS Code マーケットプレイスで：

Remote - WSL（ms-vscode-remote.remote-wsl）

またはコマンドラインから：

code --install-extension ms-vscode-remote.remote-wsl

6.2 使い方

WSL 内で：

cd ~/work/repo
code .

→ Windows VS Code が開き、左下に WSL: Ubuntu と表示される。ファイルシステム・ターミナル・拡張がすべて WSL 内で動作する。

または Windows VS Code で：コマンドパレット → WSL: Connect to WSL → フォルダを選択。

6.3 WSL 側にインストールする拡張

初回接続時、一部の拡張が「WSL にインストールしますか？」と聞いてくる。推奨のものは Yes：

ESLint / Prettier
Python / Pylance
Go / Rust-Analyzer
Docker

7. ミラーネットワーク（Win11 22H2 以上）

§3 よりもエレガントな修正。WSL が Windows のネットワークインターフェースを直接ミラーする — VPN、社内ネット、DNS、localhost がホストと同一の動作になる。

7.1 有効化

.wslconfig に：

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

wsl --shutdown して再起動。

7.2 効果

VPN — WSL が自動的に VPN 経由になる
社内プロキシ — Windows の IE/Edge プロキシが自動的に適用される
localhost — Windows ↔ WSL が双方向（localhostForwarding 不要）
DNS — Windows と同一、最も安定

7.3 注意点

一部の Docker Desktop ビルドと競合する — 問題が発生した場合は一時的に無効にする
高度なコンテナネットワーキングの一部が異なる動作をする — 深いコンテナ作業をする場合は検証する

確認

5 つのチェック：

WSL 内で free -h が .wslconfig の上限を表示する（例：8.0Gi）
ps -p 1 が systemd を表示する
curl -sS https://www.google.com -o /dev/null && echo OK → OK（DNS / ネットワーク）
cd ~ && touch test.txt && ls と cd /mnt/c/Users/$USER && touch test.txt && ls の両方が動作する（速度だけが異なる）
VS Code から code . で左下に WSL: Ubuntu が表示される

トラブルシューティング

`.wslconfig` の変更が適用されない

wsl --shutdown を忘れた。すべての WSL インスタンスが完全に停止してから次の起動で読み込まれる。
場所は %USERPROFILE%\.wslconfig（ユーザーのホーム）であること。%LOCALAPPDATA% ではない。
ファイル名は .wslconfig（先頭にドット、拡張子なし）でなければならない。

systemd を有効にするとブートに失敗する

よくある原因：/etc/wsl.conf の構文ミス（例：[boot] ヘッダーの欠落）。
回復方法：PowerShell から wsl -u root -d Ubuntu でルートとして入って /etc/wsl.conf を修正する。

`apt update` が DNS エラーを返す

§3.1（手動 /etc/resolv.conf）を適用するか、§7 のミラーネットワークに切り替える。
VPN 上では社内 DNS が追加されているか確認する。

`npm install` が耐えられないほど遅い

§4 — /mnt/c/... から作業している。~/work に移行する。

VS Code Remote-WSL が接続できない

code が PATH にない。Windows で VS Code を開く → コマンドパレット → Shell Command: Install 'code' command in PATH。
WSL 内で code -v で確認する。

Docker Desktop がミラーネットワーク後に壊れる

Docker Desktop が NAT モードを前提としていた。WSL 統合を再設定するか、Docker 使用中はミラーモードを無効にする。

vhdx が縮小しない（§5）

diskpart の compact vdisk はフラグメンテーションに制限される。オプション C（エクスポート / インポート）が最もクリーンだ。

参考リンク

更新履歴

2026-05-12 — 英語翻訳初稿（devAlice M2 i18n シード）

WSL2 チューニング — メモリ・systemd・DNS・I/O を一括で