症状の整理：何が起きているか

代表例は次の通りです。(1) 宿ホストの Edge／Chrome では接続できるサイトが、ゲスト内の Firefox や Chromium ではタイムアウトまたは証明書エラーの前に止まる。(2) Linux ゲストで apt update がミラーに届かないが、同じ回線の物理マシンでは問題ない。(3) ゲストで curl -v https://example.com を打つと、意図したプロキシを経由していないか、127.0.0.1:7890 へ向けたつもりが接続拒否になる。

ここで重要なのは、ゲストから見た「自分自身のループバック」（多くの場合 127.0.0.1）に Clash の HTTP／SOCKS ポートを指定しても、実際のプロセスは宿ホスト上で待ち受けているため、到達できない、という点です。WSL2 と同様、到達可能な L3 アドレス（宿の LAN またはブリッジ上の仮想アダプタのアドレス）に向ける必要があります。

NAT と橋接：ゲストの「出口」とゲートウェイ

NAT（共有／ホストオンリー系）の典型的な挙動は、ゲストがプライベート帯（例：VMware の vmnet8、Hyper-V 既定の内部スイッチ）を持ち、インターネット向けのデフォルトルートが「仮想ルータ＝宿側の翻訳機」に向くことです。このときゲストのデフォルトゲートウェイをいじらず、ブラウザだけ手動で宿の IP と Clash ポートを指定すれば、出口は従来どおり NAT 経路のまま、HTTP レイヤーだけプロキシに流せます。

一方、橋接（Bridged）では、ゲストの仮想 NIC が実ネットワーク上のスイッチに同列に乗る扱いになり、ゲストはルータから自席の 1 台分として DHCP されることが多いです。この場合、宿ホストは「同じサブネット上の**別ノード**」なので、Clash は 0.0.0.0 など LAN にバインドし、allow-lan 相当をオンにしなければ、宿IP:混合ポート に TCP が届きません。橋接にすると、WSL2 のような「WSL 専用の 172.x 空間」ではなく、自宅ルータ配下の普通の一台に近い姿になる、と捉えると判断が速いです。

ステップ 1：ゲストから宿ホストの IP を求める

まず、ゲスト OS で到達性のある宿の IPv4 を一本に決めます。橋接なら、ゲストのデフォルトゲートウェイ（多くの環境で自宅ルータ）と、宿の有線／無線の IP が同じサブネットに見えるはずなので、宿の IP を ipconfig（Windows ゲスト）や ip route／GUI で確認し、他の同サブネット端末と同じ距離感で到達するか ping します。NAT の場合、Linux なら ip route show default の next hop が多くの環境で宿を指し、宿で ipconfig した仮想アダプタ（例：「VMware Network Adapter」）の IPv4 がそのアドレスになることが多いです。

Hyper-V では、Default Switch と、明示に作った内部／外部仮想スイッチで、ゲストに見せる上りルートの意味が違います。外部にブリッジした vSwitch を使う場合、ゲストは物理 LAN と同じ帯域に出ます。Default Switch 単体のときは、Microsoft の実装差もあるため、実際のルート表と DNSをゲスト上で都度確認するのが安全です。

ここで得た HOST_IP（例：192.168.1.23 や 172.16.x.x）を、以降のプロキシ URL にそのまま埋めます。変わったら（VPN 起動、Wi-Fi 切替）、プロキシ設定も**合わせて**更新する習慣をつけてください。

ステップ 2：Clash 側（allow-lan、混合ポート、バインド）

Clash 系のクライアントは、HTTP ポート、SOCKS ポート、混合ポート（mixed port）のいずれかを、ゲストから指定します。Mihomo 系では一つの混合ポートにまとまっている構成も多く、ゲストのブラウザや apt の Acquire::http::Proxy には、例として http://HOST_IP:7890 の形で渡すのが素直です（実際の番号はダッシュボードで確認）。

重要なのは Allow LAN（名称はクライアントにより「LAN から接続可」等）をオンにし、リッスンが 127.0.0.1 だけに閉じていないかを見ることです。同じ Windows 上の仮想 NICから来る接続も「LAN 扱い」なので、オフのままだとゲストから connection refused やタイムアウトになりがちです。bind-address を * 相当にし、TUN モードをゲストではなく宿だけに使う、という分離も、トラブルが少ない典型です。ゲストが Linux でグローバルにプロキシしたくないリポジトリがある場合は、NO_PROXY や apt の例外を併用します。

ステップ 3：Windows ファイアウォールの穴あけ

Clash のポートに対し、プライベート プロファイル上で着信をブロックしていないか確認します。橋接でゲストが同セグメントにいると、仮想スイッチが「プライベート」扱いになる例が多く、ルール一つで通ることも多いのですが、ドメインネットワーク扱いのままブロックが残るケースもあるため、クライアント名またはポート番号で着信の許可を明示すると切り分けが早いです。公共 Wi‑Fi では Allow LAN 自体のリスクが上がるため、用途に合わせて一時的に抑える、などの判断も合わせて行ってください。

手順 A：アプリのプロキシに HOST_IP:混合ポート を入れる

最も衝突が少ないのは、ゲスト内でシステムプロキシまたはアプリ個別に、http://HOST_IP:PORT を与える方法です。Windows ゲストなら「設定 > ネットワークとインターネット > プロキシ」、Linux なら export http_proxy=...、~/.bashrc、apt.conf.d など、既に WSL2 向けで書いた表現と同型です。ここで 127.0.0.1 を入れていないかだけ、もう一度確認します。

検証は curl -x http://HOST_IP:PORT -I https://www.example.com や、ブラウザで HTTPS の他サイトの表示テスト、が素早いです。Clash の接続ビューにゲストの SYN が見えたら、経路の大半は揃いました。DNS までプロキシ越しに揃えたい場合は、Mihomo の DNS 設定とゲストの systemd-resolved などの関係に注意し、トラブルシューティングの DNS 章も併用してください。

手順 B：デフォルトゲートウェイを「プロキシを噛ませる宿」に乗せる（上級者向け）

全トラフィックを一括で任意の中継点に出したい場合、ゲストのルート表でデフォルトを宿に向ける、あるいは仮想ルータを挟むといったトポロジもあり得ます。ただし、Windows 上の単一 Clash を事実上の第二ゲートウェイにするのは、ARP／ICMP 挙動や、宿がスリープする環境、VPN 併用時に**想定外の非対称ルート**を生みやすいです。多くの読者にとっては、手順 A の「HTTP/HTTPS だけプロキシ」で足り、手順 B は自宅内で実験用のサブセグメントを作っている人向け、と割り切るのが安全です。OpenWrt ルータで Clash を立てる構成は、OpenWrt 旁ルートの稿が本筋です。

VMware Workstation 特有の補足

仮想ネットワーク エディタで vmnet0 橋接先の**物理アダプタ**が、実際に使っている Ethernet／Wi-Fi と一致しているかを確認します。切り違いがあると、ゲストの IP 帯が意図とズレ、宿 IP の推測を誤る原因になります。ホストオンリーと NAT、橋接の**どれでゲストを置いたか**で、HOST_IP の解釈が変わる、というより到達性テストの相手を変えよ、という点を押さえてください。VMware Tools が入っていても、**プロキシの自動学習**は自明ではありません。必ず上で述べた手動 URL を前提にします。

Hyper-V 特有の補足

起動中の仮想スイッチは、外部を選ぶと物理 NIC と橋的につながり、ゲストは LAN の一員になります。一方、内部はホスト＋指定ゲストだけの分離帯で、HOST_IP は Hyper-V 仮想イーサネットの IPv4 になり、物理ルータのゲートウェイをゲストのデフォルトにしたまま、プロキシだけ宿へ向ける、という分離が行いやすいです。職場で Hyper-V ポリシーが厳しい場合は、仮想スイッチの新規作成自体が制限されるため、社内手順に従うことが最優先です。

動作確認のチェックリスト

次を順に満たせば、VM 周りの筋は通っています。(1) 宿で Clash の同じ番号に、同一 LAN 上の別端末（スマホ等）からテスト的に到達するか、またはゲストで curl の -x が 200/301 を返す。(2) Clash ログにゲスト源の接続行が出る。(3) ゲストの SUBNET/MASK が想定通り（橋接なら自宅帯、NAT なら vm 定義帯）。(4) VPN や他セキュリティ製品が同一ポートを占有していない。ここで詰まる場合は、まず**番号**と**Allow LAN**の二点に戻ると早いです。

まとめ

Windows 上の仮想マシンを Clash 配下に乗せる要諦は、ゲスト空間の 127.0.0.1 をホストのプロキシと混同しないこと、橋接か NAT かで「宿」の見え方を混ぜないこと、allow-lan と混合ポート、ファイアウォールをセットで通すこと、の三つです。Hyper-V と VMware の違いは仮想スイッチの作り方に出ますが、IP とポートを一貫して指定するという意味では手順は同型です。GUI クライアントで接続行が読みやすいものを選べば、テストのたびに思い出しやすく、導入時の入門手順からの流れも自然につながります。

仮想マシンと WSL2、Docker ホスト、同一 LAN のスマートフォンとを横断しながら一つの Clash スタックを運用するなら、ルールの見え方の揃いやすさと、LAN 越し疎通の安定度の面で、同系クライアント群に軍配が上がる場面は少なくありません。→ 無料で Clash クライアントを入手し、宿と仮想マシン双方で同じ出口設計を試す