1. なぜ WSL2 では 127.0.0.1 がそのまま使えないのか
WSL2 は軽量 VM のような分離されたネットワーク名前空間を持ちます。Linux ディストリビューション内の 127.0.0.1 は「その Linux 自身のループバック」であり、Windows ホストで Clash が開いている 127.0.0.1:7890 とは別物です。ドキュメントやブログで「ミックスドポートは 7890」とだけ書かれていると、つい export https_proxy=http://127.0.0.1:7890 を貼り付けてしまいがちですが、これが最大の落とし穴のひとつです。
解決の方向性は二通りあります。ひとつは「WSL から見たホスト側の到達可能アドレス」にプロキシを向けること。もうひとつは、Windows の機能で localhost を相互転送する設定（利用可能なら）を有効にし、運用ルールを一本化することです。後述するように、2026 年時点でもディストリビューションと .wslconfig の組み合わせで最適解は微妙に異なるため、実際に ping や curl で確認する癖を付けるのが安全です。
netstat -ano | findstr :7890 のように、Clash が本当に LISTEN しているかと、127.0.0.1 だけか 0.0.0.0 かを確認してから WSL 側に進むと、迷子になりにくくなります。
2. Windows 側：Clash の待受アドレスとポート
Clash 系クライアントでは ミックスドポート（HTTP と SOCKS をまとめるリスナー）を 7890 前後で開く構成が一般的です。ここで重要なのは、GUI の「システムプロキシをオン」が 127.0.0.1 を指していても、外部（LAN や WSL）から同じポートに乗るには、コアが 0.0.0.0 あるいはホスト全体で待ち受けている必要がある点です。Allow LAN や allow-lan: true、bind-address の組み合わせはクライアントごとにラベルが違いますが、意味するところは「ループバック専用で閉じるかどうか」です。
同一 PC 上の WSL2 から見ると、厳密には LAN 越しではありませんが、待受が 127.0.0.1 のみだとパケットが届かない、という挙動は LAN 共有のときと同じです。ミックスドポートとファイアウォールの許可、バインドの確認手順は Windows 11 でのミックスドポートと LAN 共有の記事で詳しく扱っています。WSL 連携の前に、ホスト単体で「広いインターフェースで LISTEN しているか」を押さえておくと、その後の DNS 調査がはかどります。
ファイアウォール
稀に Windows Defender ファイアウォール が、ローカルからの接続であっても特定ビルドのクライアントに対し受信を弾くケースがあります。症状が「WSL からだけ不通」であっても、受信規則に TCP のミックスド番号を明示しておくと切り分けが楽です。企業端末ではポリシーでブロックされていることもあるため、その場合は Clash 以前の制約として扱う必要があります。
3. WSL から見た「ホスト」の IP アドレスを取る
クラシックな方法は、WSL のシェルから cat /etc/resolv.conf を開き、先頭の nameserver に書かれているアドレスを「既定でホスト側を指すゲートウェイ」として扱うことです。多くの環境ではこれが実際にホストへ到達可能な IPv4 です。ただし systemd-resolved やストア版 WSL の更新で、/etc/resolv.conf が自動生成であり、中身が 127.0.0.53 のようなローカルスタブになっている場合があります。そのときは「nameserver の行をそのままプロキシ先にしない」ことが重要です。
別の確実なやり方として、PowerShell で ipconfig し、vEthernet (WSL) に相当するアダプタの IPv4 をメモして WSL から直接叩く、という手もあります。どちらを使うにせよ、curl -v --proxy http://<ホストIP>:7890 https://example.com のようにプロトコルとポートを固定して試すと、プロキシ経路の成否が切り分けやすくなります。
/etc/resolv.conf を手編集する場合、自動生成に上書きされる設定のままだと再起動で元に戻ります。恒久対応にはディストリビューション推奨の方法（wsl.conf や resolved の設定）を使ってください。
4. http_proxy など環境変数でプロキシを指す
多くの CLI ツールは http_proxy・https_proxy・HTTP_PROXY・HTTPS_PROXY・all_proxy を参照します。大文字小文字の揺れに弱い実装もあるため、両方セットしておくと安心です。no_proxy には社内ドメインや localhost、場合によっては .local を入れ、不要なループを避けます。
シェル起動時に毎回 export するのが煩わしければ、~/.bashrc や ~/.zshrc に追記しますが、オフのときにコメントアウトしやすい形にしておくと、後から「なぜか全部遅い」という事態を防げます。Git だけ別ポートを使いたい場合は git config --global http.proxy も検討しますが、基本は環境変数に揃えた方が他ツールとの整合が取りやすいです。
あわせて、Clash の設定・運用の全体像を押さえておくと、ルールで DIRECT に落ちているのか、プロキシに乗る前に DNS で詰まっているのかをログから読み解きやすくなります。
5. DNS：名前解決がボトルネックになるパターン
プロキシ設定は正しくても、DNS がホストの期待するリゾルバに届いていないと、Could not resolve host で止まったり、タイムアウトまで極端に長く感じたりします。Clash 側で仮想 DNS や redir-host 系の挙動を使っている場合、Windows のブラウザでは問題なくても、WSL 内の glibc が別経路で問い合わせている、というズレが起きます。
切り分けの第一歩は、WSL で dig や resolvectl status（利用可能なら）を実行し、実際にどのサーバへ問い合わせているかを確認することです。/etc/resolv.conf がスタブの場合、上流は systemd-resolved や NetworkManager の設定に従います。ホストの Clash が提供する DNS ポート（例：1053 や 7874 など、クライアントのデフォルト値）を指す構成もありますが、そのポートが 127.0.0.1 のみで待っていると、やはり WSL からは届きません。ミックスドポートと同様、バインドとファイアウォールをセットで見ます。
実務では「まずはホストの到達可能 IP 経由で、既知のパブリック DNS（例：1.1.1.1）にだけ問い合わせが通るか」を切り、次に Clash の DNS 設定へ寄せる、という二段階が安全です。いきなり複数オプションを同時に変えると、どこで直ったか追えなくなります。
6. systemd-resolved とスタブリゾルバ
Ubuntu 22.04 以降を WSL で動かしている場合、systemd 有効化の有無によって systemd-resolved の実体が変わります。resolved が動いていると、/etc/resolv.conf はシンボリックリンクで stub-resolve を指し、中身の 127.0.0.53 は「このマシン内のキャッシュデーモン」です。ここを誤って「ホスト IP」と解釈してプロキシに流し込むと、当然つながりません。
対処の基本は、(1) ディストリビューション公式の手順に沿って resolv.conf の管理方法を選ぶ、(2) WSL 用の /etc/wsl.conf で自動生成をオフにするかどうかを決める、(3) 変更後に wsl --shutdown から再起動して確認する、の三段です。どの設定も「セキュリティと更新のしやすさ」のトレードオフがあるため、職場ポリシーがある環境ではインフラ担当と相談してください。
7. ネットワークモード：NAT とミラード（mirrored）
新しい WSL では、.wslconfig で networkingMode=mirrored を指定し、ホストとゲストの境界を薄める選択肢が議論・提供されています（利用できる Windows バージョンと WSL の組み合わせはリリースノートを確認してください）。ミラードモードでは localhost の相互到達がしやすくなる一方、既存の「resolv.conf の nameserver＝ホスト」という暗黙知が当てはまらない場合があります。
どちらのモードでも変わらないのは、Clash の待受がループバック限定かどうか、と DNS クエリがどこへ出ているか、という二点です。モードを切り替えたら、本章のチェックリストを頭から短時間でもう一度踏むのがおすすめです。
8. TUN モードと WSL の関係
Windows 側で Clash の TUN を有効にすると、ホストのルーティングやファイアウォールが大きく変わります。ゲームやブラウザ全体をトンネルに載せたいときは便利ですが、不具合時は「TUN を一度オフにしてミックスド＋手動プロキシだけに戻す」と原因がアプリ側かカーネル近辺かが切り分けやすくなります。詳細は TUN モードのトラブルシュート記事を参照してください。
WSL 内のトラフィックまで自動で TUN に吸い込まれるわけではなく、結局「WSL → ホストのプロキシ／ゲートウェイ」という経路設計が必要になるケースがほとんどです。TUN を疑う前に、本章の 1〜5 をクリアしているかを確認すると時間の節約になります。
9. 症状と原因の対照表
| 症状 | よくある原因 | まず試すこと |
|---|---|---|
Connection refused（WSL からプロキシ） |
ホストが 127.0.0.1 のみ待受 |
Allow LAN／0.0.0.0 バインド、正しいホスト IP |
| タイムアウトのみ | ファイアウォール、別セキュリティ製品 | TCP 受信規則、一時的にオフで再現テスト |
| 名前解決できない | DNS がスタブ／ホスト未到達 | resolv.conf、dig、DNS ポートのバインド |
| ブラウザは速いが apt だけ遅い | 環境変数未設定、プロキシ無視リスト | apt.conf の Proxy、sudo -E の要否 |
| 設定を変えても元に戻る | 自動生成の resolv.conf | wsl.conf、distro 公式手順 |
sudo apt を使うとき、環境変数が引き継がれないことがあります。sudo -E や root のプロファイルに同じ export を書くなど、運用に合わせて選んでください。セキュリティ上、root に常時プロキシを焼き付けるのが好ましくない組織もあるため、その場合は apt 専用の設定ファイルに限定する方法を検討します。
10. まとめ
WSL2 と Windows 上の Clash を組み合わせるときの要点は、127.0.0.1 の同一性を疑い、ホストの待受とWSL からの到達経路を数字で確認すること、そして DNS がスタブリゾルバ経由になっていないかを resolv.conf と実クエリの両面から見ることです。ミックスドポートの番号や Allow LAN は GUI の一言説明より、netstat と curl -v の方が真実を教えてくれる場面が多いです。
同種のプロキシツールのなかでも、Clash 系はログとルールの対応が追いやすく、試行錯誤のたびに「どのホストが DIRECT でどこが PROXY か」を画面で確認しやすい傾向があります。Windows 側の疎通が安定していれば、WSL 側は環境変数と名前解決を揃えるだけで開発体験がかなり滑らかになります。