なぜWSL2だけ「システムプロキシの外」に出るのか
WSL2は、軽量VMに近い別のLinuxネットワーク名前空間で動きます。Windows側で「システムプロキシ」をオンにしても、それは主にWin32のスタックやブラウザ向けの話であり、WSL内のcurl・git・npmが自動的に同じ設定ファイルを読むわけではありません。開発者が感じる「Edgeは通るのにターミナルだけ直結」は、この分離がそのまま現れた症状です。したがって対策の骨子はシンプルで、Windows上でListenしているClashのHTTP/SOCKSポートに、WSL2から到達可能なIPアドレスとポート番号を明示して向けます。UWPのLoopback問題とは別軸ですが、どちらも「OSがネットワーク境界を切っている」という点では似ています。Windowsデスクトップ側の初期設定はClash Verge RevのWindows向けガイドで押さえておくと、以降のポート番号の読み取りが楽になります。
localhostと127.0.0.1の落とし穴
多くのドキュメントがhttp://127.0.0.1:7890のように書きますが、WSL2の中から見た127.0.0.1は「WSL自身」です。WindowsホストでClashが127.0.0.1だけにバインドしている場合、パケットはWSL内でループし、ホストのリスナーに届きません。設定で「LANからの接続を許可」し、実際の接続先をWindowsホスト側のプライベートIP（例：192.168.x.xやWSLが自動で書く/etc/resolv.confのnameserver）に置き換える、という二段構えが定石です。Windows 11の新しいネットワークオプション（ミラー型など）を有効にしている環境では挙動が変わることがあるため、最終的にはcurl -vでどこにTCPが張れているかを見るのが確実です。
覚えておくとよい対応関係：ブラウザ＝Windowsのプロキシ設定、WSL2のCLI＝自分でhttp_proxy等を書くか、シェル設定管理ツールで注入する、が基本形です。
Windows側Clashで先に確認すること
ポート番号（mixed-port / HTTP / SOCKS）
Clash系クライアントでは、mixed-portでHTTPとSOCKSをまとめて受ける構成が一般的です。実際の番号はプロファイルとGUIの「接続情報」に依存するため、7890固定とは限りません。ここを誤ると、WSL2側の設定をいくら直しても接続拒否のままです。まずWindows上でクライアント表示のローカルポートをメモし、以降の例では7890をプレースホルダとして読み替えてください。
Allow LAN（LANからの接続）
WSL2からWindowsのポートへ届けるには、多くの場合ループバック以外のインターフェース宛ての接続になります。Clash側で「Allow LAN」相当のオプションがオフだと、ホストは外部（名前空間としてのWSL含む）からのSYNを拒否します。オンにしたうえで、必要ならWindows Defenderファイアウォールでその実行ファイル／ポートの受信許可を確認します。企業端末ではポリシーでブロックされていることもあるため、その場合は情報システムの許可が前提になります。
WSL2からWindowsホストのIPを取る
定番はcat /etc/resolv.confしてnameserver行を見る方法です。多くの既定構成では、そこに書かれたアドレスがWSL2から見たWindowsホストを指します。ただしカスタムwsl.confや将来のWSL更新で挙動が変わる例もあるため、併せてip route show | grep defaultでdefault経路のゲートウェイを確認する癖を付けると安心です。得られたIPをWIN_HOSTのように環境変数へ入れ、シェルやCIスクリプトから再利用するとミスが減ります。
# Example: read Windows host IP seen from WSL2 (verify on your distro)
grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}'
シェル全体に効かせる：http_proxy 系
aptやcurl、多くのCLIは大文字・小文字のプロキシ環境変数を参照します。HTTPプロキシがhttp://WIN_HOST:7890のとき、典型的には次のようにします（ポートは環境に合わせて変更）。no_proxyには社内Gitやローカルnpmミラーのホスト名を入れ、不要なトラフィックだけプロキシを迂回させます。
# Example: ~/.bashrc or ~/.zshrc (replace WIN_HOST and port)
export HOST_IP=$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}')
export http_proxy="http://${HOST_IP}:7890"
export https_proxy="http://${HOST_IP}:7890"
export no_proxy="localhost,127.0.0.1,::1"
SOCKSが必要なツールはALL_PROXY=socks5://...を別途足します（ポートはクライアント表示に合わせる）。Gitとnpmは後述の専用設定と併用すると挙動が読みやすくなります。環境変数だけに頼ると、サブシェルやGUI起動の子プロセスで抜けることがあるため、チーム開発ではdirenvやコンテナ内のENVで揃えると再現性が上がります。
Gitのhttp.proxy / https.proxy
Gitは環境変数を見ることもありますが、リポジトリやグローバルにhttp.proxyを明示しておくと、HTTPSのcloneやfetchの切り分けがしやすくなります。社内でgit@（SSH）のみ許可されている場合は、この節は当てはまりません。HTTPSでGitHub等へ行く場合、プロキシURLはhttp://HOST:PORT形式が一般的です（プロキシ自体がHTTPでも、CONNECTでTLSを張れます）。
# Example: Git proxy (replace host:port)
git config --global http.proxy http://192.168.12.1:7890
git config --global https.proxy http://192.168.12.1:7890
# To clear later:
# git config --global --unset http.proxy
# git config --global --unset https.proxy
証明書検証エラーが出る場合は、企業のSSLインスペクションや独自CAが絡んでいないかを先に確認してください。安易にsslVerify falseで逃げるとリスクが高いです。ルール面でどのドメインをプロキシに流すかは、Cursor・GitHub・npm向け分流記事の考え方をそのまま流用できます。
npm（およびpnpm / yarn）のプロキシ
npmはnpm config set proxyとhttps-proxyでHTTPプロキシを取り込みます。レジストリがhttps://registry.npmjs.orgでも、プロキシスキームはしばしばhttp://...のままです。逆に社内ミラーへ直結したい場合は、noproxy相当のホストを環境変数側に足すか、npmの設定をリポジトリ単位で分けます。pnpmやyarnも、HTTPSクライアントとして同じホストへ向かうため、同様のプロキシ設定か環境変数で揃えるのが早いです。
# Example: npm proxy (replace host:port)
npm config set proxy http://192.168.12.1:7890
npm config set https-proxy http://192.168.12.1:7890
npm config delete proxy
npm config delete https-proxy
うまくいかないときはnpm config list -lでどの設定ファイルが効いているかを確認し、ユーザー設定とプロジェクト.npmrcの優先順位を整理します。巨大なモノレポでは、プロキシ経由の帯域よりレジストリの地理的距離がボトルネックになることもあり、その場合はミラー戦略とセットで検討してください。
動作確認：curlと接続ログ
設定後は、WSL2内でcurl -v --proxy http://WIN_HOST:7890 https://www.google.comのように明示プロキシで一度通し、次に環境変数任せのcurl https://example.comを試すと、段階的に切り分けられます。Clashの接続ログにWSL由来のフローが載るかも併せて見てください。載らない場合は、まだWindowsホストに届いていない（ファイアウォール、Allow LAN、誤IP）可能性が高いです。DNSがWSL側で別解決になっていると、プロキシまで行っても想定外の宛先IPに繋がることがあります。メタコア利用者はDNSリーク防止ガイドとあわせて、ルールと名前解決の整合を確認すると安心です。
ファイアウォールとセキュリティ製品
Windows Defender ファイアウォールの「受信の規則」で、Clashの実行ファイルまたは対象ポートがブロックされていないかを確認します。サードパーティのエンドポイント製品がWSLブリッジを別扱いする場合、GUIだけ許可してもWSL2からのパスが閉じたままということがあります。テストとして一時的にオフにできる環境なら、切り分け後に元へ戻す運用が安全です。職場端末ではポリシー違反になり得るため、自己判断ではなく手順書に従ってください。
代替策：Windows側でTUNを使う場合
ポート転送の手間を減らしたい場合、WindowsホストでTUNモードを有効にし、そこでトラフィックをまとめて捕捉する構成もあります。ただしTUNは権限や競合の話が増えるため、まずは本稿のような明示プロキシでWSL2を安定させてから検討するのが学習コスト対効果的です。手順の詳細はClash Verge RevのTUNモードガイドに譲ります。
うまくいかないときのチェックリスト
- Clashが起動し、Allow LANがオンか。
- WSL2から参照しているIPが、実際のWindowsホストを指しているか（
resolv.confとip routeの両方）。 - ポート番号がmixed-port等と一致しているか。
- ファイアウォールが受信を許可しているか。
git configとnpm configに古いプロキシが残っていないか。- プロキシ不要な社内ホストを
no_proxyに入れ誤って全通信を迂回していないか。
注意：プロキシや迂回は利用規約・法令および組織のネットワークポリシーに従ってください。許可されていない環境での設定は行わないでください。
クライアントの入手について
Windows用の実行ファイルは、リリースノートと対応関係が追いやすい本サイトのダウンロードページから入手するのがおすすめです。公式ダウンロードページでビルドを選び、初回構成はインストール記事と併せて進めてください。ソースコードの閲覧やIssue報告は各プロジェクトのGitHubが向いていますが、日々のインストーラ入手はサイト側の導線に寄せると混乱が少なくなります。
まとめ
WSL2でGitとnpmをWindowsのClashに乗せる要点は、システムプロキシの自動継承に期待しないこと、127.0.0.1ではなくホストIP＋Allow LANでリスナーに届けること、そして環境変数とツール個別設定で二重に穴を塞がないことです。境界が増えるほどトラブルは面白いように増えますが、curl -vとクライアントログをセットで見る癖が付けば、2026年現在も同型の問題は短時間で片付けやすくなります。ブラウザだけWindows、開発CLIだけLinux、という現場でも、プロキシポートの一本化はチーム全体の再現性に効きます。