WSL2 のターミナルから Windows の Clash へ：ミラー型ネットワークと localhost プロキシの実測（2026）

1. なぜ「127.0.0.1 で Clash に届く／届かない」が話題になるのか

WSL2 のディストリビューション（Ubuntu など）の中で curl や git を叩くと、通信の起点はLinux ゲストの IP スタックです。ここでいう 127.0.0.1 はその Linux 自身のループバックを指し、Windows ホストで 127.0.0.1:7890 のように開いている Clash のポートと、自動的には同一になりません。この取り違えは、「ブラウザではプロキシが効いているのに、WSL のだけ失敗する」という問い合わせの典型原因のひとつです。

逆に、Windows 11 以降で提供されるミラー型ネットワークを有効にした環境では、ゲストとホストの localhost の関係が従来と異なる挙動を示すことがあり、ドキュメントやブログ記事によって「127.0.0.1 でいける」と「ダメでホスト IP が必要」が混在します。OS のビルドと WSL の世代、.wslconfig の設定の有無で結論が変わるので、一度だけ自分のマシンで実測して値を固定するのがもっとも確実です。Clash 側の購読やルールの基礎は サブスクリプション導入ガイド、出口の振り分けは ルールルーティングの解説とあわせて読むと、WSL から出たトラフィックがどの策略に乗るかも追いやすくなります。

2. ミラー型ネットワークとクラシック WSL2 の違い（localhost の意味）

クラシックな WSL2 のネットワークモデルでは、Linux は仮想 NIC 越しに Windows と TCP/IP で隣接しており、WSL 内の 127.0.0.1 は Windows のサービスポートに自動転送されません。このとき Windows 上の Clash に届けるには、WSL から到達可能な「Windows ホスト側の LAN 的アドレス」（後述）とポート番号を組み合わせます。

一方、ミラー型ネットワーク（mirrored）は、Microsoft が WSL のネットワークをホストに近づけるためのモードで、localhost の扱いや IPv6・ファイアウォールまわりの挙動が変わります。有効化すると、開発者体験として「WSL から 127.0.0.1:ポート で Windows のリスナーに触れる」ケースが現実的になることがありますが、万能ではなく、Clash のバインドアドレスや Windows ファイアウォールのルール次第で依然として失敗します。設定はユーザープロファイルの .wslconfig に [wsl2] セクションで networkingMode=mirrored を指定する形が公式ドキュメントで案内されています（詳細は OS のリリースノートを参照）。

# Example fragment for .wslconfig (user profile, not inside distro)
[wsl2]
networkingMode=mirrored

変更後は wsl --shutdown のあとにディストリを再起動して反映を確認してください。ミラー型の有無にかかわらず、「最終的にどのアドレス:ポートに SYN が届いているか」を curl -v や Clash のログで見る習慣が、長期的にはもっとも安全です。

3. Windows 側 Clash の前提：mixed-port・allow-lan・バインド

WSL から向ける先は、多くの構成でHTTP プロキシとして応答している TCP ポートです。mihomo / Clash Meta 系では mixed-port に HTTP と SOCKS を同居させる例が一般的ですが、実際のキー名・既定値はテンプレートと GUI の生成ルールで異なるため、ダッシュボードか設定 YAML で「HTTP として使う番号」を必ず確認してください。以降の例では説明用に 7890 を置きます。

WSL は Windows から見ると別ホストに近いので、Clash が 127.0.0.1 にだけバインドしていると、WSL 側の IP からの接続が拒否されます。LAN 相当の接続を受け付ける allow-lan（または同等の意味の設定）と、バインドアドレス（0.0.0.0 など）を揃える必要があります。公開範囲とセキュリティのトレードオフは LAN 共有と allow-lan の記事で別角度から触れています。初回セットアップ全般は Windows 11 での Clash Verge Rev の初回設定とも補完関係です。

4. WSL2 から見た「Windows ホスト」の IP の求め方

ミラー型を使わない、あるいは 127.0.0.1 経由が期待どおりに動かないときは、WSL がデフォルトゲートウェイとして見ている Windows 側のアドレスを使う方法が定番です。多くの環境では、デフォルトルートの次ホップがホストを指します。例としては次のようなコマンドで確認できます（環境差はあります）。

# Show default gateway inside WSL (example)
ip route show | grep -i default

別の定番として、/etc/resolv.conf に書かれた nameserverが Windows ホストを指している構成があり、これをプロキシのホスト部分に使う、という運用も長く使われてきました。ただし WSL の世代やミラー型の有効化で resolv.conf の生成方針が変わるため、「今の自分のファイルを開いて実値を見る」ことが重要です。自動生成ファイルを直接編集しても再起動で戻る場合があるので、/etc/wsl.conf やディストリ固有の推奨手順で名前解決を固定したい場合は、ディストリのドキュメントもあわせて確認してください。

取得したホスト IP を H とすると、プロキシ URL は概念的に http://H:7890 となります。IPv6 だけが絡む環境では NO_PROXY に ::1 を入れるなど、スタック全体で表記を揃えてください。

5. ターミナルプロキシ：HTTP_PROXY / HTTPS_PROXY / NO_PROXY

apt・curl・git・npm などは、大文字または小文字の HTTP_PROXY / HTTPS_PROXYを解釈します。HTTPS_PROXY が空なら HTTP_PROXY にフォールバックする実装もあります。形式は通常 http://ホスト:ポート で足り、Clash 側が HTTP プロキシとして CONNECT を処理できることが前提です。

NO_PROXY には、社内 Git サーバや localhost 上の開発 API など、プロキシを通すと壊れる宛先を列挙します。ここが空のままだと、私有レジストリまで Clash に流れてタイムアウトする、という症状に見えます。

# Example: append to ~/.bashrc or ~/.zshrc (port is illustrative)
export HTTP_PROXY=http://HOST_OR_LOCALHOST:7890
export HTTPS_PROXY=http://HOST_OR_LOCALHOST:7890
export ALL_PROXY=http://HOST_OR_LOCALHOST:7890  # tools that honor ALL_PROXY only
export NO_PROXY=localhost,127.0.0.1,::1,10.0.0.0/8

npm は HTTP_PROXY 系に加え、npm config set proxy 系の設定が残っていると挙動が分裂することがあります。git も http.proxy / https.proxy が別途入っていると、シェルの環境変数だけでは足りません。どのレイヤの設定が効いているかを git config --list や npm config list で一度棚卸しすると早いです。

Docker コンテナからホストの Clash へ向ける話は、ブリッジ越しのゲートウェイやデーモン側設定など別の落とし穴が多いです。コンテナ主体の構成は Docker をホスト Clash 経由にする記事に譲り、本稿はWSL2 の Linux シェル直下に焦点を絞ります。

6. resolv.conf・DNS・fake-ip を噛み合わせる

プロキシの URL は合っているのに名前解決だけが妙に遅い、あるいは 意図しない IP に繋いでルールが噛み合わないときは、WSL がどの DNS を見ているかと、Clash 側の DNS（fake-ip を含む）がどう設定されているかの両方を疑います。Windows のブラウザと WSL の CLI が別のリゾルバ経路を踏んでいる典型は、「ブラウザでは見えるサイトが、WSL の curl だけ失敗する」パターンです。

対策の方向性は大きく二つあります。WSL 側の /etc/resolv.conf を Clash が提示するローカル DNS に合わせるか、あるいは Clash の DNS 設定とルールを、実際に使っている解決パスに合わせて単純化するかです。fake-ip を使う構成では、「名前 → IP」の評価がどの段階で起きるかがルールマッチに効くため、思い込みで直結ルールだけ足しても改善しないことがあります。DNS と TUN の一般的な整理は TUN モードの解説も参照してください。

7. 切り分け：不通になったときの確認順（実測メモ）

現場では次の順で詰まりどころが見つかりやすいです。① WSL 内からプロキシの TCP ポートに接続できるか（curl -v http://ホスト:7890 や nc 相当）。ここで拒否なら バインド・allow-lan・Defender ファイアウォールを疑う。② HTTPS が失敗する場合は CONNECT がルールで弾かれていないか、Clash ログに TLS エラーが出ていないか。③ 名前解決の違和感は /etc/resolv.conf と dig / nslookup で実経路を確認。④ ツール固有の設定（git config、npm config、コンテナ内の古い HTTP_PROXY）を棚卸し。

さらに踏み込むなら、Windows 側で TUN モードを有効にして、アプリによってシステムプロキシを読まないプロセスまでまとめて捕捉する方法もあります。ただし Hyper-V や仮想スイッチ、別 VPN と競合しやすいので、変更前後でルートと DNS を短時間だけでも記録しておくとトラブル時に楽です。

8. まとめ

WSL2 のターミナルから Windows の Clash にトラフィックを寄せるとき、いちばん大事なのは「127.0.0.1 が何を指すか」を自分の構成で確定させることです。ミラー型ネットワークを使えば localhost 経由が現実的になる一方、Clash の待受アドレスとファイアウォール次第では依然としてホスト IP が必要です。次に HTTP_PROXY 系と NO_PROXY を整え、DNS／resolv.conf と fake-ip のズレを潰せば、apt や npm の「環境だけ不通」はかなり減らせます。

同種のプロキシクライアントのなかでも、Clash / mihomo 系はルールとログの見え方が開発者に馴染みやすい点が長所です。GUI の世代は移り変わっても、購読と策略の考え方は共通なので、一度ベースを固めると WSL や別ツールチェーンを増やしても再現しやすくなります。

利用中の OS に合うビルドを選び、Windows 側でポートと LAN 受け入れを整えたうえで WSL から試すのが最短です。パッケージの入手と各プラットフォーム向け一覧は → 無料で Clash をダウンロードして、快適な接続を試す からどうぞ。