想定環境とゴール
本稿の読者像は、Windows 上で Clash 系クライアント（従来の Clash for Windows 系 UI や、その後継・派生を含む）を常駐させ、日常のブラウザやアプリはすでにそこ経由で安定している一方、WSL2 内の Ubuntu で apt、git、curl などの CLI がまだ直結のまま／不安定、というギャップを埋けたい方です。ゴールは単純で、WSL2 側から見た「出口」が Windows ホストのローカルプロキシ（多くの配布設定で mixed-port が束ねる HTTP と SOCKS）に揃い、必要なら no_proxy で社内やローカルだけを除外できる状態にすることです。
Linux 本体に systemd でコアを載せる流れは、別稿の Ubuntu＋systemd ガイドが軸になります。ここではクロス OS の境界、つまり「仮想 NIC とポート待受と名前解決」が絡む部分に絞って書きます。Windows 側クライアントの画面操作の基礎は Clash for Windows 系チュートリアルと併読するとスムーズです。
Windows 側：ポートと待受アドレスを先に確認する
WSL2 から接続できるかどうかの第一関門は、Clash が どのアドレスにバインドしているかです。127.0.0.1（ループバック）だけに限定されていると、それは「Windows 自身のローカル」であり、WSL2 の別カーネル空間からは原則として届きません。多くの GUI では「Allow LAN」「LAN に公開」や、設定ファイル上の allow-lan: true、あるいは明示的に 0.0.0.0 側へ寄せるオプションがこの意味を持ちます。実務的には、まず Windows 側で mixed-port（または分離している port / socks-port）の番号をメモし、続けて「WSL2 から見える形で待ち受けているか」を確認します。
LAN 公開とファイアウォールの例外、セキュリティ上の注意点は LAN 公開とファイアウォールの整理が参考になります。ポイントは、便利さと露出のトレードオフを理解したうえで、不要ならバインド先を絞る、Secret 付きの外部コントローラを安易に 0.0.0.0 にしない、といった基本線を守ることです。
WSL2 から Windows ホストへ：localhost では届かない理由
WSL2 の Linux から 127.0.0.1 を叩くと、到達先は「その Linux インスタンス自身」です。Windows ホストで動いている Clash に届かないのは正常挙動です。ホスト側プロキシへ向ける代表的な方法は次のような階段になります。環境やビルドにより細部は変わるため、まずは手元で実測値を取るのが確実です。
ひとつは、/etc/resolv.conf に書かれている nameserver のアドレスです。WSL2 ではこれが Windows ホスト側の仮想アダプタに対応することが多く、多くのユーザー環境で「ホストへの近道」として機能します。別のやり方として、デフォルトゲートウェイ（ip route で default の次ホップ）を読む手もあります。さらに、Windows 11 系では $(hostname).local 形式で名前解決できる場合もありますが、名前と実体の対応が崩れると一気に混乱するので、最初の疎通では IP を明示してポートに繋がるかを先に固めるのがおすすめです。
環境変数：HTTP_PROXY / HTTPS_PROXY / ALL_PROXY と no_proxy
CLI ツールの多くは大文字の HTTP_PROXY と HTTPS_PROXY、場合によっては ALL_PROXY（SOCKS を指すことが多い）を参照します。WSL2 のシェルで、たとえばホスト IP を WIN_HOST に入れたうえで http://WIN_HOST:7890 のように指定するのが素直です。git は git config --global http.proxy でも同趣旨の指定ができますが、シェル全体で揃えるなら環境変数の方が再利用しやすいことが多いです。
no_proxy は「プロキシを噛ませたくないホスト／サフィックス」の列挙です。社内 Git、ローカルのレジストリ、イントラの API など、意図的に直結させたい宛先をここに入れておかないと、ルール上は DIRECT でもアプリが先にプロキシへ CONNECT を投げてしまい、逆に詰まることがあります。カンマ区切りの慣習と、先頭のドット付きサフィックスマッチの挙動はツール差があるため、詰まったら該当コマンドのドキュメントを当たってください。
apt と git：プロキシ以外の落とし穴
apt は HTTP(S) プロキシ環境変数を解釈しますが、ミラーの選択や IPv6 優先、古いキャッシュなどで「プロキシは通っているのに遅い／特定リポジトリだけ失敗」が起きます。まずは通常の update がエラーなく完走するか、ログに TLS 手前で止まっていないかを見ます。git は SSH リモートの場合、HTTP プロキシとは別経路になる点に注意してください。SSH 越しの取得をプロキシ下で安定させるには、ProxyCommand や connect 系の手当てが別途必要になるケースがあります。
DNS が直結のまま：名前は引けるのに期待と違う／引けない
アプリケーションが HTTP プロキシ経由でも、名前解決だけローカルリゾルバに任せたままというパターンは珍しくありません。結果として、企業ネットや地域によっては「解決結果が意図とズレる」「フィルタ下で NXDOMAIN になる」「プロキシ側の仮想 IP 戦略と食い違う」などが表面化します。Clash 側で fake-ip や redir-host、あるいは専用の DNS 設定を使っている場合、Windows ブラウザと WSL2 の getaddrinfo の見え方が一致しないと、curl だけ失敗するといった現象に繋がります。
切り分けのコツは、まず curl -v で「DNS で止まっているのか」「TCP 接続で止まっているのか」「TLS で止まっているのか」を分離することです。名前解決の段階で詰まるなら、WSL2 の /etc/resolv.conf をホスト側の挙動と揃える必要があるか、あるいは一時的に公開 DNS を試すなど、リゾルバ経路そのものを疑います。アプリがプロキシの「リモート DNS」を使えるかどうかは実装依存なので、ツールごとに仕様を確認してください。
curl での自己確認：段階を踏んで証拠を残す
まずプロキシ無しでエンドポイントに届くかを見て、次に -x http://HOST:PORT を付けて比較します。verbose 出力では、接続先の IP、プロキシとのハンドシェイク、TLS の SNI が期待どおりかを確認できます。HTTPS を試す場合は、中間者警告が出ないこと、ステータスコードが想定内であることも合わせて見ます。さらに、小さな JSON を返す公開テスト URL などで地理や出口のざっくりした確認をしてもよいでしょう。ここで大事なのは、ブラウザでは成功しているのに WSL2 だけ失敗するときに、環境変数のスペル、ポート番号、ホスト IP の取り違え、IPv6 経路の差分といった「地味なズレ」を一つずつ潰すことです。
# Example: replace WIN_HOST and PORT with your values
export HTTP_PROXY="http://WIN_HOST:PORT"
export HTTPS_PROXY="http://WIN_HOST:PORT"
curl -vI https://example.comファイアウォールと「届かない」最後の一歩
設定は正しくても、Windows Defender Firewall が着信を落としていると WSL2 からは常にタイムアウトです。Private プロファイルでの許可ルール、既存のセキュリティ製品、会社ポリシーによるブロックを疑い、イベントログや一時的なルール追加で切り分けます。開発用端末でのローカル到達性の確認と、不要な WAN 公開は混同しないことが大切です。
まとめ
WSL2 の Ubuntu から Windows ホストの Clash を使う要点は、「ループバックの見え方が OS ごとに違う」「待受を LAN 側に広げるかどうかで到達性が決まる」「HTTP プロキシを通しても DNS だけ別ルートのまま、というズレがありうる」の三つに集約されます。順序としては、Windows 側のポートとバインド、WSL2 からホスト IP への TCP 接続、環境変数または git の設定、最後に curl の verbose でレイヤを特定、が再現性高く詰まりどころを潰せます。
同種の汎用プロキシと比べたとき、Clash エコシステムはルールと DNS を一体として設計しやすく、GUI とコア設定の両方から挙動を追いやすいのが強みです。Windows で一度整えたプロファイルを、WSL2 の CLI にきれいに引き込めれば、開発作業の文脈切り替えも格段に楽になります。
Clash を無料ダウンロードして試す → 各 OS 向けの案内と合わせて、本記事の手順を起点に最初の疎通まで進められます。