1 なぜ WSL2 だけ不通になりやすいか
WSL2 の Linux は、軽量 VM のような独自のネットワーク名前空間を持ち、既定では Windows の「システムプロキシ」設定をそのまま継承しません。ブラウザは Windows 上で動くため Clash が書き込んだプロキシを見る一方、WSL 内の apt や curl は、明示的に HTTP_PROXY を渡すか、プロキシ無しで外向きへ出ようとします。さらに、Clash 側で FakeIP や独自 DNS を使っていると、WSL が参照する /etc/resolv.conf の名前解決結果と、実際の TLS 接続先との関係がわかりにくくなり、「接続は張れるのに証明書が合わない」「特定ドメインだけ解決できない」といった症状に見えることがあります。
したがって対策は大きく三層に分かれます。第一に、WSL から Windows 上の Clash の HTTP ポート（多くは 7890 前後）へ届く経路を確保する。第二に、シェルと apt の双方に、必要なら別々にプロキシを宣言する（apt は環境変数だけでは足りない場合がある）。第三に、DNS が Clash の設計と矛盾していないかを、resolv.conf とクライアントの DNS セクションから突き合わせる、という順で切り分けると迷いが減ります。Windows 側の初回セットアップはインストールガイドを先に済ませておくと、ポート番号と「Allow LAN」の位置づけが掴みやすいです。
2 Windows 側 Clash の前提（LAN からの到達）
WSL2 からは、Windows のループバック 127.0.0.1 がそのまま「ホストの Clash」に届くとは限りません（後述のミラーモードを有効にした場合は例外）。多くの構成では、Windows の LAN 側アドレス（例：192.168.x.x や仮想アダプタの 172.x.x.x）へ向けて HTTP プロキシを叩きます。そのため Clash 側では Allow LAN（または同等の「LAN からの接続を許可」）をオンにし、リッスンアドレスが 0.0.0.0 側に開いているかを確認します。混合（mixed）ポートを使う場合は、HTTP と SOCKS のどちらを apt が使うかを決め、まずは HTTP プロキシ URL で統一するのが扱いやすいです。
セキュリティ上、LAN 公開は信頼できるネットワーク内に限定し、不要なら作業後に Allow LAN を戻す運用も検討してください。社内ポリシーでホストのファイアウォールが WSL サブネットからの着信を弾いている場合は、Windows Defender ファイアウォールの受信規則で該当ポートを許可する必要があります。
3 ミラーネットワークと従来の NAT モード
Windows 11 の新しい WSL では、.wslconfig に networkingMode=mirrored を指定するミラーネットワークが選べます。これが有効だと、ゲストから見た接続特性がホストに近づき、127.0.0.1 上の Windows サービスへアクセスしやすくなるケースがあります。Clash の HTTP ポートが localhost で待ち受けている構成では、追加の「ホスト IP 探索」が簡略化される可能性があります。一方、既定の NAT モードでは、WSL は仮想スイッチ越しに Windows と通信し、デフォルトゲートウェイとして現れるアドレスが「Windows ホストを指す窓」になります。どちらのモードかで curl の書き方が変わるため、まず wsl.exe --version やドキュメントで環境を確認し、自分のマシンがミラー対応かを押さえておくとよいです。
4 Windows ホスト IP の求め方
NAT モードでよく使われるのは、デフォルトルートのゲートウェイを表示する方法です。例として次のようなコマンドで、既定ルートの次ホップ（多くの環境で Windows ホスト側）を取得できます。
ip route show | grep -i default | awk '{ print $3}' | head -n1
過去には /etc/resolv.conf 内の nameserver 行が Windows ホストを指す運用が紹介されることもありましたが、WSL の世代や設定で中身が変わり得ます。取得した IP に対し、Windows 側で Test-NetConnection <IP> -Port 7890（PowerShell）などでポート開放を確認してから WSL に戻ると、試行錯誤が減ります。ミラーモードで 127.0.0.1:<port> がそのまま使えるなら、環境変数も http://127.0.0.1:7890 の形で足りることが多いです。
5 環境変数、Git、curl
多くの CLI は大文字の HTTP_PROXY／HTTPS_PROXY と小文字の http_proxy／https_proxy の両方を参照します。~/.bashrc または ~/.profile に、ホスト IP または 127.0.0.1 を埋め込んだ行を追加し、source ~/.bashrc で反映します。Git だけ別経路にしたい場合は git config --global http.proxy と https.proxy を明示してもよいですが、まずは環境変数で揃え、curl -I https://example.com が期待どおりプロキシログに載るかを確認する流れが素直です。
コンテナや Python の仮想環境を WSL 上で動かす場合、親シェルの環境変数が引き継がれないことがあるため、CI 用のスクリプトや direnv でプロジェクト単位に固定する方法もあります。TUN でホスト全体を透過的に扱う話とはレイヤが異なりますが、Linux 単体で Mihomo を動かす場合はLinux 向け Mihomo 記事の構成とも比較できます。
6 apt 専用：Acquire::http::Proxy と HTTPS
sudo apt update は、環境変数だけでは拾わない、または sudo により環境が切り詰められることがあります。確実なのは /etc/apt/apt.conf.d/ 以下に小さな設定ファイルを置く方法です。例として、HTTP プロキシ経由でリポジトリにアクセスする場合は次のような記述になります（ポートは手元の Clash に合わせてください）。
Acquire::http::Proxy "http://YOUR_HOST_IP:7890/";
Acquire::https::Proxy "http://YOUR_HOST_IP:7890/";
HTTPS リポジトリ URL でも、apt はプロキシ経由で CONNECT を使うケースが多く、上記のように http:// スキームのプロキシを指す書き方が一般的です。社内ミラーを DIRECT に回したい場合は、設定の分割や Acquire::http::Proxy::archive.ubuntu.com のようなホスト別指定も検討されます。設定後は sudo apt update を再実行し、Clash の接続ログにリポジトリのドメインが現れるかを見ます。
sudo -E apt update で環境を引き継ぐ手もありますが、運用ポリシーによっては非推奨です。apt.conf.d 方式は意図がファイルに残り、チーム共有もしやすいです。
7 /etc/resolv.conf と DNS（FakeIP との整合）
WSL は起動時に /etc/resolv.conf を自動生成することが多く、手編集は /etc/wsl.conf で generateResolvConf = false にするなどの対応が必要になる場合があります。Clash 側で FakeIP を有効にしていると、ブラウザは Clash の DNS レイヤで名前を解決しますが、WSL 内の getaddrinfo は別経路になり、同じホスト名でも答えが食い違うことがあります。症状が「プロキシに届く前の名前解決で失敗」に見えるときは、DNS と FakeIP の実務記事で、Clash の dns セクションと fallback の設計を確認し、WSL からはパブリック DNS（例：8.8.8.8）を明示する、あるいはホストのリゾルバに合わせる、といった整理が有効です。
「とりあえず動けばよい」段階では、WSL の resolv.conf が指す nameserver で dig や nslookup が期待どおりかを確認し、Clash ログのドメインと突き合わせます。ルールは合っているのに TLS だけ失敗する場合は、SNI と証明書の話に進み、Sniffer 記事で扱う HTTPS 経路の修正も視野に入ります。
8 動作確認のすすめ方
- Windows で Clash が稼働し、Allow LAN とポートが意図どおりか。
- WSL でホスト IP（または
127.0.0.1）へcurl -v --proxy http://...:7890 https://www.cloudflare.com/cdn-cgi/traceなどで到達性を確認。 - 環境変数を入れたうえで
git ls-remoteや小さなgit cloneを試す。 apt.conf.dを設定しsudo apt updateが完走するか。- 名前解決だけ怪しいときは
resolv.confと Clash の DNS 設定をセットで再点検。
トラフィックを仮想 NIC レベルで揃えたい場合は、Windows 側で TUN モードを検討する手もありますが、WSL2 との相性は環境依存のため、本稿のような「HTTP プロキシ明示」の方が切り分けは簡単です。
9 まとめ
Windows で Clash を動かし WSL2 の Ubuntu を併用するとき、プロキシの入口は「Windows のシステム設定」ではなく、多くの場合 WSL から見たホストの IP とポートとして明示する必要があります。ミラーネットワークなら 127.0.0.1 一本で済むこともあり、NAT モードならデフォルトゲートウェイからホストを特定し、Allow LAN とファイアウォールを開けます。apt は Acquire::http::Proxy 系で確実に、DNS は resolv.conf と Clash の FakeIP／DoH を突き合わせて一貫性を取る——この三点を押さえると、apt update・Git・curl の「どれかだけ不通」という典型的なパターンをかなり短時間で潰せます。
長期的には、ルールとログが読める Clash 互換クライアントの方が、開発用 WSL とブラウザの挙動を同じ設計思想で扱いやすいです。インストールパッケージはダウンロードページから取得し、GitHub Release 直叩きだけに依存しない運用をおすすめします。
