この記事で整理すること

Windows 上で Clash(mihomo 系クライアントを含む)を起動し、Edge や Chrome では問題なく海外サイトへ出られる。ところが WSL2 の Ubuntu に入って sudo apt updatecurl https://... を叩くと、遅い・失敗する・社内ポリシーではなく単にタイムアウトする——という相談は、開発者向けフォーラムでも定番です。

原因は「プロキシが無い」のではなく、WSL2 が Windows のユーザー空間とは別の仮想ネットワークにいる ことにあります。ブラウザは Windows 側のプロキシ設定や TUN/ルールに乗りやすい一方、WSL 内のプロセスは、明示しない限り Windows の Clash が listen しているアドレスに届きません。とくに 127.0.0.1 は WSL から見ると「自分自身」であり、ホストの混合ポートとは別物です。

本稿では、Windows 側の Clash が既に動いている前提 で、WSL2 全体から 混合ポート(mixed port) へ HTTP プロキシとして接続する再現手順をまとめます。ネイティブ PowerShell の Git/npm だけを対象にした記事は Windows 端末と混合ポートの記事 に譲り、ここでは Linux ディストリビューション全体の出図 に焦点を当てます。TUN やドライバの深掘りは TUN トラブルシューティング を参照してください。

なぜ WSL2 の apt と curl は「直結」に見えるのか

WSL2 は軽量 VM に近い動き方をし、独自の Linux カーネルとネットワークスタックを持ちます。Windows の「インターネット設定」やクライアントの「システムプロキシを反映」は、原則として Windows プロセス に効きます。WSL 内の aptcurl は Linux プロセスなので、環境変数や apt の設定ファイルを通じて 明示的にプロキシ URL を渡さない限り、海外ミラーへそのまま SYN を投げに行きます。

また、たとえ Windows 側で TUN モードを有効にしていても、WSL2 の既定構成ではホストの仮想アダプタ越しの経路と相性 が環境依存になります。確実に試せるのは「WSL から見える Windows ホストの IP アドレス」と「そのホスト上で listen している混合ポート番号」を突き合わせ、HTTP プロキシとして接続するやり方です。ルールや DNS は Clash 側に任せ、WSL は 上流プロキシの URL だけ を知っていればよい、という分離が切り分けにも向きます。

ヒント

まず Windows の PowerShell で curl.exe http://127.0.0.1:混合ポート番号 のように ループバック直叩き が通るか確認し、次に WSL から ホスト IP 経由 で同じポートへ届くかを見ると、どこで詰まっているかがはっきりします。

Windows ホスト側:混合ポート番号と allow-lan

手順の最初に、Clash の設定 YAML か GUI で mixed-port の値を確認してください。例として 7890 と書きますが、実機の数値に置き換えてください。HTTP(S) 向けの環境変数では、原則として http://ホスト:7890 の形式でスキームを付けます。

WSL からホストへ接続するとき、Clash が 127.0.0.1 のみに bind していると 外部インタフェース(WSL ブリッジ側)からの SYN が届きません。その場合は bind-address: '*' 相当(クライアント表記は製品ごと)で 0.0.0.0 に広げるか、LAN 共有向けの allow-lan を有効にする必要があります。細かいファイアウォール手順は LAN 共有とファイアウォールの記事 と同系統ですが、今回の宛先はスマホではなく 同一 PC 上の WSL2 です。

Windows Defender ファイアウォールが「パブリックネットワーク」扱いのプロファイルで受信を弾いていると、ホスト IP 経由の接続だけ失敗することがあります。Clash の実行ファイルに対する受信許可、または該当ポートの受信規則を一時的に追加して切り分けてください。

WSL2 から Windows ホスト IP を取得する

代表的な方法は二つあります。一つ目は cat /etc/resolv.conf に出てくる nameserver の行です。多くの環境で、これが Windows ホスト側の内部アドレス を指します。二つ目は ip route show default | awk '{print $3}' のように、default gateway を読む方法です。どちらも環境や WSL の世代で微妙に異なるため、取得した IP に対して ping -c 1 で生存確認してから使うと安心です。

近年の WSL では .wslconfig[wsl2] ブロックで networkingMode=mirrored などの実験的・拡張オプションが選べる場合があります。ミラード構成では 127.0.0.1 がホストと共有されるケースがあり、この記事の「ホスト IP を別途求める」手順が簡略化されることがあります。ただし企業端末では無効化されていることも多いので、まずは従来のゲートウェイ IP 方式をマスター にしておくのが安全です。

シェル環境変数:curl・wget・多くの CLI へ一括で効かせる

ホスト IP を WIN_HOST と置くと、Bash では例えば次のように書けます(ポートは環境に合わせて置換)。

export WIN_HOST=$(ip route show default | awk '{print $3}')
export HTTP_PROXY="http://${WIN_HOST}:7890"
export HTTPS_PROXY="http://${WIN_HOST}:7890"
export ALL_PROXY="http://${WIN_HOST}:7890"
export NO_PROXY="localhost,127.0.0.1,::1"

HTTPS_PROXY にも http:// スキームを使うのは一般的です。CONNECT を挟む HTTP プロキシとして混合ポートを使うイメージです。ALL_PROXY はツールによって解釈が分かれるため、副作用が気になる場合は外しても構いません。

永続化するなら ~/.bashrc~/.profile に追記しますが、社内ミラーやプライベートレジストリまで海外ノードに流してしまう リスクがあるため、NO_PROXY の設計は必須です。Windows 側の PowerShell だけ整えたい場合は、先に挙げた Git/npm 向けの記事 と併せて読むと、変数命名や大文字小文字の癖を揃えやすいです。

apt だけ確実に通す:Acquire::http::Proxy

apt は環境変数を拾う場合もありますが、配布版やラッパー次第でブレるため、APT 専用の設定ファイル を置く方法が確実です。例として /etc/apt/apt.conf.d/95clash-proxy を root で作成し、次のように書きます(ホスト IP は実測値に置換)。

Acquire::http::Proxy "http://172.x.x.x:7890/";
Acquire::https::Proxy "http://172.x.x.x:7890/";

末尾のスラッシュの有無はバージョンで好みが分かれることがあるため、失敗したら付け替えて試してください。設定反映後に sudo apt update を実行し、取得元のログにプロキシ経由の挙動が出ているかを確認します。不要になったらファイルを削除すれば元に戻せます。

企業プロキシの下で NTLM 認証が必要なようなケースは、Clash の上流設計そのものが別論点になります。本稿のスコープは 同一マシン上のローカル混合ポート に限定します。

動作確認のすすめ方

まず WSL 内で curl -I https://www.google.com のように軽い HTTPS ヘッダ取得を試し、Clash の接続ログに該当フローが出るかを見ます。次に sudo apt update でミラーへの到達性を確認します。DNS 切り分けが必要なら、一時的に curl -v で名前解決先を追い、Clash 側の DNS 設定や fake-ip の影響を読み解いてください。

IPv6 優先で奇妙な経路になる場合は、一時的に curl -4 で IPv4 に固定して比較するのも有効です。ホスト IP が変わるたびに設定を直すのが煩わしい場合は、小さなシェルスクリプトでゲートウェイを再取得してから export し直すと運用が楽になります。

注意

プロキシ URL を恒久化すると、意図せず社内リポジトリや社内 API まで外向きのノードに流れる可能性があります。NO_PROXY と apt の例外設計を必ずセットで考えてください。

まとめ

WSL2 の Ubuntu が Windows の Clash を「見えない」主因は、ループバックの意味が WSL とホストで一致しない ことと、OS 横断でプロキシ設定が共有されない ことです。混合ポートの番号を確認し、必要なら bind を広げて allow-lan を有効にしたうえで、WSL からは 実測したホスト IPhttp://…:ポート を向けます。CLI には環境変数、apt には Acquire::http::Proxy 系が堅実な組み合わせです。

クライアントの種類やビルドを揃えたい場合は、OS 向けパッケージを ダウンロードページ から選ぶと、GUI とコアの対応関係を追いやすくなります。オープンソースのリポジトリは挙動確認に役立ちますが、実行ファイルの入手は配布ページを主な入口にすると迷いが減ります。ルールの見える化やコアの一貫性の観点では、Clash 系は同種ツールと比べても運用しやすいことが多いでしょう。→ 無料で Clash をダウンロードし、快適な接続体験を試す