なぜ WSL2 だけプロキシが効かないのか

WSL2 は軽量な仮想マシン上で Linux カーネルが動く構成です。Windows の「システムプロキシ」やタスクトレイのクライアント設定は、原則として WSL2 内のプロセスには自動では伝わりません。そのため Edge や Chrome では快適でも、Ubuntu のシェルでは直結で詰まる、というギャップが起きやすいです。

さらに、WSL2 から見た 127.0.0.1 は「Linux 側のループバック」であり、Windows 上で 127.0.0.1:7890 のように待ち受けている Clash とは別物です。ここを誤ると「アドレスは合っているはずなのに接続拒否」になりがちです。解決の鍵は、Windows ホスト側の実 IP（WSL から到達できるアドレス）を使い、Clash がそのインターフェースで待ち受けられるようにすることです。

Windows 本体で Clash を初めてセットアップする場合は、先にClash Verge Rev の入門ガイドでクライアントと購読の流れを押さえておくと、本稿の「ポート番号」と「Allow LAN」の意味が掴みやすくなります。

ステップ 1：WSL2 から Windows ホスト IP を取得する

代表的な方法は二つあります。どちらもターミナルで確認できます。

デフォルトゲートウェイを見る：WSL2 から Windows ホストは、多くの環境でデフォルトルートの次ホップになります。

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

/etc/resolv.conf の nameserver：WSL2 では、名前解決用にホストを指す設定が入っていることがあります（ディストリビューションや WSL バージョンで挙動差はあります）。

grep nameserver /etc/resolv.conf | awk '{print $2}'

取得したアドレス（例：172.x.x.1）をメモし、以降の http://<HOST>:<PORT> に使います。社内 VPN や複数仮想アダプタがある環境では値が変わることがあるため、接続できなくなったら再取得してください。

ステップ 2：Clash で Allow LAN（LAN からの接続）を有効にする

WSL2 は Windows と別のネットワーク名前空間にいるため、Clash が 127.0.0.1 のみで待ち受けていると、子システムからは届きません。クライアント設定で Allow LAN（名称は製品により「LAN に公開」「Allow LAN」など）をオンにし、HTTP または MIXED ポートが LAN 側からも開く状態にします。

ポート番号は環境により 7890（HTTP）や 7891（SOCKS）、MIXED 用の別番号などが使われます。ダッシュボードや設定画面で実際の値を確認し、ファイアウォールがブロックしていないかも合わせて見てください。同じマシン内の別 OS から届ける話なので、LAN プロキシを有効にする Windows 向けの整理とも思想が近いです（本稿は WSL2 専用の切り口です）。

ステップ 3：シェル環境変数で apt・npm・git などを通す

多くの CLI ツールは http_proxy / https_proxy（大文字版も）を参照します。WSL の ~/.bashrc または ~/.zshrc に、ホスト IP とポートを埋めた行を追加します（例ではプレースホルダを使用します）。

export HOST_IP=$(ip route show | grep -i default | awk '{ print $3}')
export http_proxy="http://${HOST_IP}:7890"
export https_proxy="http://${HOST_IP}:7890"
export ALL_PROXY="socks5://${HOST_IP}:7891"
export NO_PROXY="localhost,127.0.0.1"

SOCKS を使う場合は Clash 側の SOCKS ポートに合わせ、ツールが SOCKS5 を解釈できるか確認します。git は環境変数でも通りますが、恒久的にするなら git config --global http.proxy も選択肢です。

apt 向けには、環境変数に加えて /etc/apt/apt.conf.d/ 以下に Acquire::http::Proxy などを書く方法もあります。プロキシなしの内部リポジトリも混在する場合は、取得元ごとに例外を設けるなど運用ルールを決めると安全です。

設定後は source ~/.bashrc などで読み直し、curl -I https://example.com のように軽い HTTPS で到達性を試すとよいです。DNS までプロキシ経由にしたい要件がある場合は、クライアント側の DNS 設定や fake-ip の理解が必要になるため、必要に応じてTUN モードの解説も参照してください。

ステップ 4：Docker Desktop（WSL2 バックエンド）でのプロキシ

Docker Desktop を使う場合、コンテナの外向き通信は「Docker のネットワークスタック」側の話になり、WSL のシェルに export しただけでは docker pull に効かないことがあります。次のような順で確認します。

GUI のプロキシ設定：Docker Desktop の Settings に HTTP/HTTPS プロキシ欄がある場合、Windows ホストの Clash へ向けるのではなく、WSL から見た ホスト IP と Clash ポート（例：http://172.x.x.1:7890）を指定するのが一般的です。会社ポリシーでプロキシ認証が必要な場合は、その資格情報の扱いに注意してください。

Docker Engine の設定 JSON：高度なユーザーは proxies ブロックを daemon.json に書く方法もあります。編集後は Docker の再起動が必要になることが多いです。誤った JSON はデーモン起動失敗につながるため、バックアップを取ってから変更してください。

ビルド時のみプロキシが要る場合：docker build に --build-arg http_proxy=... を渡す、BuildKit のシークレットを使う、といったパターンもあります。本稿では「まずホスト経由で pull が通るか」を優先して切り分けると早いです。

よくある落とし穴と切り分け

127.0.0.1 を指定してしまう

WSL2 内の 127.0.0.1 は Linux 自身です。Clash が Windows 上で動いている限り、原則としてホスト IP を使います。

Allow LAN を忘れて接続タイムアウト

ファイアウォール許可とセットで、Clash が LAN インターフェースで待ち受けているかを確認します。

DNS は通るが TLS で失敗する

プロキシは生きているが SNI やルールでドロップされているケースがあります。Clash のログとルール順を見て、対象ドメインが期待するポリシーに乗っているか確認します。

シェルは通るが Docker だけダメ

環境変数と Docker Desktop の設定のどちらが効いていないかを分離して試験します。docker run --rm curlimages/curl ... のような最小コンテナで検証すると原因が絞りやすいです。

追加の切り分けはトラブルシューティング記事も併用してください。

セキュリティと運用上の注意

Allow LAN は同一ネットワーク上の他端末からもプロキシに届く可能性があります。自宅の単一 PC で WSL2 と Windows を行き来する用途なら実害は小さめですが、共有 Wi‑Fi では VPN やファイアウォールルールで Clash のポートを絞るなどの対策を検討してください。職場マシンでは情報システムの方針に従うことが前提です。

プロキシ URL をシェル履歴やスクリーンショットに残さない、一時的な検証ならセッション限定の export にとどめる、といった習慣も推奨します。

まとめ

WSL2 と Windows の二重生活では、「どのループバックがどちらの OS か」を意識できるかどうかで設定の成否が決まります。ホスト IP を正しく取り、Clash で LAN 待ち受けを許可し、ツールごとに HTTP か SOCKS かを合わせる——この三点がそろえば、apt や npm、git、Docker の取得系トラブルは大きく減ります。

Windows 側で安定したクライアントとコアが揃っていれば、WSL2 からの共用も単なる「アドレスの話」に落ち着きます。GUI での管理やコア更新をまとめて済ませたい場合は、同種ツールと比べても操作性に優れた Clash 系クライアントの価値が実感しやすいはずです。→ Clash を無料ダウンロードして、ホストと WSL2 の両方で快適に使う