WSL2でaptとgitをWindowsのClashへ通す：プロキシ環境変数とミラーネットワーク設定

典型例：Windowsは通るのにWSL2のapt・gitだけ「プロキシ無し」

EdgeやChromeはシステムプロキシやTUNに乗りますが、WSL2内のUbuntuは軽量VM＋仮想スイッチの背後にいます。「localhostに繋げばWindowsと同じ」という直感は通用しません。 export https_proxy=http://127.0.0.1:7890 と書くと、接続先はLinux側のループバックであり、WindowsでListenしているClashではありません。タイムアウトやConnection refused、あるいは想定外の直結が起きやすくなります。

さらにaptとgitはシェル変数だけでは追従しません。sudoで環境が落ちる、aptは/etc/apt/apt.conf.d/を読む、gitはhttp.proxyを使う——到達先IP・Listen範囲・永続設定の三つを揃えて初めて安定します。

127.0.0.1は誰のループバックか

従来のWSL2 NATでは、Linuxは独自スタックを持ち、127.0.0.1はそのLinux自身です。Windows上のClashへ届けるには、WSLからルーティング可能なホスト側IPが必要です。多くの環境ではip route show defaultのゲートウェイや、/etc/resolv.confのnameserverが手掛かりになります（WSLやWindowsの更新後は再確認を）。以下ではそのアドレスを<WIN_HOST>と書きます。

設定を広げる前に curl -v --proxy http://<WIN_HOST>:<PORT> https://example.com でプロキシ経路だけを切り分けると早いです。ここが通らないのにpingだけ通るなら、ClashのバインドやAllow LAN、Windows Defenderの受信規則を疑います。

Windows側Clash：mixedポート・Allow LAN・バインド

<WIN_HOST>が分かっても、Clashがループバック専用ListenでLAN拒否ならWSLからは弾かれます。GUIのAllow LAN相当を有効にし、必要ならファイアウォールでTCPポートを許可してください。mixedポートならHTTP CONNECTとSOCKSをまとめられ、ALL_PROXY設定が簡潔になります。

WindowsでTUNを使っていても、WSL内のプロセスが自動で透明プロキシされるわけではありません。明示的にHTTP/SOCKSでClashへ送るモデルです。モード比較はTUN記事を併読ください。

シェル：http_proxy、HTTPS_PROXY、ALL_PROXY、no_proxy

大小ペアで揃えるとトラブルが減ります。https_proxyの値でもプロキシURLスキームはhttp://が一般的です（CONNECTでTLSトンネル）。SOCKSが必要ならsocks5h://でDNSまで上流へ。社内Gitやローカルregistryはno_proxyに入れ、Node系と併用する場合はCursor/npm分流記事のNO_PROXY思考をWSLにも適用します。

# <WIN_HOST> と <PORT> を置換（例: mixed 7890）
export HTTP_PROXY="http://<WIN_HOST>:<PORT>"
export http_proxy="$HTTP_PROXY"
export HTTPS_PROXY="$HTTP_PROXY"
export https_proxy="$HTTP_PROXY"
export ALL_PROXY="socks5h://<WIN_HOST>:<PORT>"
export NO_PROXY="localhost,127.0.0.1,::1"

apt：sudoとAcquire::http::Proxy

ユーザーshellにexportしてもsudo apt updateでは消えることがあります。/etc/apt/apt.conf.d/95proxyのような断片にAcquire::http::ProxyとAcquire::https::Proxyを書くのが堅実です。ミラーと海外源の振り分けはClashのルール側に寄せ、DNS挙動はfake-ip/redir-host記事と合わせて確認します。

# 例: /etc/apt/apt.conf.d/95proxy
Acquire::http::Proxy "http://<WIN_HOST>:<PORT>/";
Acquire::https::Proxy "http://<WIN_HOST>:<PORT>/";

git：http.proxyとSSHの境界

HTTPSリモートにはgit config --global http.proxyとhttps.proxyをhttp://<WIN_HOST>:<PORT>に。SSH（[email protected]:）は自動ではhttp_proxyを使いません。ProxyCommand等が別途必要です。

# HTTPS リモート向け
git config --global http.proxy  http://<WIN_HOST>:<PORT>
git config --global https.proxy http://<WIN_HOST>:<PORT>

ミラーネットワーク：127.0.0.1を揃える選択肢

新しいWSLでは%UserProfile%\.wslconfigにnetworkingMode=mirroredを置くと、ループバックの見え方がWindowsに近づき、http://127.0.0.1:<PORT>で済む場面があります。公式ドキュメントの最新仕様を確認し、変更後はwsl --shutdownを。VPNや他仮想NICと干渉する場合は従来の<WIN_HOST>方式に戻します。

# .wslconfig 断片（正式名称はMSドキュメントで確認）
[wsl2]
networkingMode=mirrored

検証の順序

(1) <WIN_HOST>への疎通、(2) curl --proxyでHTTPSヘッダ取得、(3) 通常ユーザで環境変数確認、(4) sudo apt updateまたはapt.conf.d反映後の更新、(5) git ls-remoteでHTTPS Git——の順が扱いやすいです。ブラウザだけ通る場合は「システムプロキシは効いているがシェルは別」という別問題です。

チームで手順を配布するなら、Windowsのビルド番号・WSLのカーネル版・Clashクライアント名を一行メタ情報として書き添えると、後から「うちではミラーがまだ無効」といった差分の説明がしやすくなります。再現性はバージョンとセットで残すのがコツです。

症状早見表

まとめ：WindowsのClashをWSL2の明示的上流にする

ブラウザの挙動をそのまま期待せず、WSL2のツールからClashのインバウンドへ能動的に送る——この整理ができれば、同じポリシーグループとDNS設計をデスクトップと開発環境で共有しやすくなります。ルールの深掘りはYAMLルールガイドへ。インストーラはダウンロードページを優先してください。

ほかの記事は技術コラム、一般的な案内はヘルプを参照してください。