WSL2でGit／npmがプロキシを無視？WindowsのClashと共有する手順（2026）

この記事で最後までできるようになること

Windows 側で Clash が WSL から到達できるアドレスで listen しているか（127.0.0.1 だけでは足りないケースを含む）を確認し、WSL2 から ホスト IPv4 を安定して取得する方法を選べます。シェルに http_proxy／https_proxy／all_proxy と no_proxy を載せ、必要なら Git の git config、npm の npm config まで揃えたうえで、curl・小さな clone・軽いパッケージ取得で層別に検証できます。あわせて DNS、fake-ip、Windows 11 の ネットワーク構成（いわゆる混合／ミラーリングまわり） が変わったときに、どのレイヤを疑うかの道しるべも持ち帰れます。

なぜ「Windows で Clash が動いているのに WSL2 だけ別世界」に見えるのか

第一に、WSL2 は仮想 NIC 上の Linux です。Windows のエクスプローラが示す「この PC」と、WSL の「localhost」は同じ実体ではありません。WSL から 127.0.0.1:7890 のように叩くと、届く先は Linux 側のポートであって、Windows 上の Clash が開いているポートではない——これが「設定したはずなのに接続拒否／直結のまま」という体験の典型です。

第二に、Windows のシステムプロキシ設定は主に Win32 側アプリ向けで、bash や zsh から起きたコマンドが自動で同じ設定を継承する保証はありません。第三に、出口が揃っても 名前解決の経路が食い違う と、「ブラウザは快適・ターミナルだけおかしい」が起きます。Clash の fake-ip とアプリ側リゾルバの組み合わせ、WSL の /etc/resolv.conf の自動生成などが絡むため、プロキシ以前に DNS を疑う段階が必要になります。

ステップ1：Windows 側の listen アドレスとポートを確定する

Clash Verge Rev や Mihomo 系クライアントで、実際に有効な mixed-port または HTTP プロキシの番号をメモします。設定が 127.0.0.1 のみに bind されていると、WSL はそこへ届きません。スマホと PC を共有するときと同様、LAN 側から届く必要があるなら allow-lan 相当のオプションと、必要に応じた bind-address の意味合いを確認してください。具体例は LAN プロキシとファイアウォール の記事が近いです。

合わせて、WSL 仮想サブネットからの 受信 が Windows Defender ファイアウォールに阻まれていないかも見ます。プロファイルが「パブリック」のままだと「プライベートのみ許可」の規則では拾えず、場所によって挙動が変わることがあります。ポートが Linux から見えてから Git 設定に進むと、徒労が減ります。

ステップ2：WSL2 から Windows ホストの IPv4 を得る

よくある方法は、/etc/resolv.conf の nameserver を眺めることです。既定の WSL では、そこに書かれたアドレスが 仮想スイッチ上の Windows ホスト側 を指すことが多く、HTTP プロキシのホストとしてそのまま使える場合があります（環境や WSL の世代で変わるため、自分のファイルを正とする）。代替として、Windows の ipconfig で「vEthernet (WSL)」などの IPv4 を拾う、WSL 内で ip route show default のデフォルトゲートウェイを見る、といった手もあります。

Windows 11 で ネットワークのミラーリング／混合 系の機能を有効にしていると、古い記事の IP の取り方とズレることがあります。resolv.conf とルート表が食い違うときは、実際にポートへ TCP で届く方を採用してください。以降、この IPv4 をプレースホルダ WIN_HOST と呼びます。127.0.0.1 をホストの Clash に向けるのは、明示的なポートフォワードなどを別途敷いていない限り避けた方が安全です。

ステップ3：WSL 内のプロキシ環境変数（まずは現在のシェルで試す）

mixed ポートを 7890 と仮定します（実数に置き換えてください）。bash／zsh では例えば次のようにします。

export HOST_PROXY="http://WIN_HOST:7890"
export http_proxy="$HOST_PROXY"
export https_proxy="$HOST_PROXY"
export all_proxy="$HOST_PROXY"
export no_proxy="localhost,127.0.0.1,::1"

WIN_HOST には前ステップの IPv4 を入れます。no_proxy はローカル開発サーバをわざわざ回さないための保険です。社内ネットや Docker ブリッジなど、直結したい帯域があればカンマ区切りで足してください。検証には環境に応じて curl -I https://example.com など、許可された宛先で構いません。

恒常化は ~/.bashrc や ~/.zshrc に書けますが、国内ミラーもすべて海外出口に流れる副作用が出やすいので、オンオフ用のシェル関数や、direnv でプロジェクト単位に載せる運用の方が事故が少ないです。用語の整理は チュートリアルページ も併読ください。

ステップ4：Git——環境変数だけで足りるか、git config が要るか

HTTPS リモートであれば、近年の Git は http_proxy／https_proxy を尊重することが多いです。それでも挙動が変なときは明示します。

git config --global http.proxy  http://WIN_HOST:7890
git config --global https.proxy http://WIN_HOST:7890

解除するときは次です。

git config --global --unset http.proxy
git config --global --unset https.proxy

SSH（[email protected]:...）は、HTTP プロキシの環境変数だけでは自動では同じ経路になりません。ProxyCommand と nc や connect などを組み合わせるか、HTTPS に切り替えるか、方針を分けてください。Windows 側のルールで github.com や githubusercontent.com が期待どおりのグループに入っているかは、開発者向け GitHub 分流の記事 を土台に確認してから、WSL のターミナルに戻ると切り分けが速いです。

ステップ5：npm、pnpm、Yarn と registry

npm は環境変数で多くの場合足ります。過去にグローバル設定した proxy が古い IP のまま残っていないか、npm config list で確認してください。ピン留めするなら例えば次です。

npm config set proxy  http://WIN_HOST:7890
npm config set https-proxy http://WIN_HOST:7890

国内ミラー（npmmirror など）だけを使うワークフローでは、ミラー宛てはプロキシを外した方が速い場合もあります。ログに出る tarball の実 URL が GitHub Releases や別 CDN なら、ホスト名単位で Clash ルールが足りないケースが多く、npm 自体の故障と混同しないでください。

pnpm や Yarn も、基本はシェルの HTTPS_PROXY 系を継承します。公式ドキュメントの優先順位に沿って、グローバル設定や .npmrc の重ねがけを確認します。どのマネージャでも、まず WIN_HOST:PORT へ TCP が通ることを先に固定するのがコツです。

ステップ6：DNS、fake-ip、「解けているのに繋がらない」

Clash で fake-ip を使う構成では、コアが接続フェーズで実ホスト名を把握する設計になります。アプリが先に自前で解決してから接続する経路と噛み合わないと、一部分だけ不安定に見えます。WSL で dig や getent hosts を見た結果と、Windows クライアントのログに出る宛先がズレていたら、DNS レイヤを疑います。嗅探まわりで挙動が変わる場合は Clash Meta の sniffing と DNS の記事も参照してください。

WSL の /etc/resolv.conf が自動生成のままなら、アップデート後に挙動が変わることがあります。Windows と WSL で同一ホストの答えを比べ、Clash の接続ログでどのルールに当たったかを見ながら、プロキシ設定だけをいじり続けないことが重要です。

ステップ7：混合ネットワーク、ファイアウォール、企業ポリシー

Windows 11 では WSL のネットワークモデルが進化しており、デフォルトゲートウェイや localhost の共有の意味が更新で変わることがあります。以前動いていたスクリプトが急に壊れたら、まずリリースノート側を当たり、安易に 127.0.0.1 に戻さない方が安全です。MDM やグループポリシーで仮想 NIC 間通信が制限されている環境では、WSL からホストのポートがそもそも開かないこともあり、その場合は技術より組織のガイドラインが先です。

チェックリスト（上から順に）

（1）Windows のブラウザ経路は期待どおりか、Clash ログにルールヒットがあるか。（2）WSL で nc -vz WIN_HOST 7890（ポートは実値）が通るか。（3）現在のシェルに http_proxy が export されているか。（4）Git リモートは HTTPS か SSH か。SSH を HTTP プロキシと同一視していないか。（5）npm の registry とミラー設定が混線していないか。（6）fake-ip とリゾルバが衝突していないか。（7）ファイアウォールのプロファイルが今のネット種別を覆っているか。

セキュリティとコンプライアンス

listen をループバック以外に広げると、同一セグメント上の他端末からも見える可能性があります。カフェの Wi‑Fi では allow-lan を閉じる、不要な受信規則は消す、といった運用をセットにしてください。購読 URL やトークンをスクショに写さないことは言うまでもありません。本文は自宅や自社端末でのデバッグの話に限定し、違法な迂回は扱いません。

まとめ

WSL2 と Windows で Clash を共有するときの肝は、「127.0.0.1 が同じマシンを指していない」ことを最初に押さえ、到達可能なホスト IP と正しいポートで Git・npm・環境変数を揃えることです。そのうえでログと簡単な接続試験で層を切れば、再インストールのループを避けられます。Windows 初回セットアップ、LAN 共有、GitHub 分流の各記事とつなげれば、ブラウザから Linux CLI まで一連の開発経路を整理できます。

まだ Windows 上でクライアントを安定稼働させていない場合は、先に システムプロキシと TUN の選び方 を済ませてから本稿に戻ると手戻りが減ります。ビルドの入手先は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすく、ルール型プロキシの可観測性を活かした運用にも向きます。ターミナルでコードと依存関係を引きたい開発者にとって、経路を明示的に揃えられるクライアントは長く付き合いやすい道具です。

→ Clash を無料ダウンロードし、WSL2 開発環境のプロキシを試す