1 VMware と Hyper-V、ネットワークの前提が違う
Windows 上で Hyper-V を有効にすると、多くの環境で VMware Workstation／Player と共存できません（どちらか一方のみ、という制約が公式にも説明されています）。本稿は VMware 側の仮想化を選んだ読者向けで、仮想 NIC の名前も vEthernet (...) ではなく、通常は VMware Network Adapter VMnet1（ホストのみ）や VMnet8（NAT）など、「VMware Virtual Ethernet Adapter」系としてホストに現れます。仮想マシンのネットワーク接続を「NAT」「ブリッジ」「ホストのみ」に切り替えると、ゲストが属するサブネットと、ゲストから ping や TCP で届けるホスト側の IPv4が変わる、という点は Hyper-V の「内部 NAT／外部スイッチ」と発想は似ていますが、アダプタ名とデフォルトのサブネット番号は VMware の仮想ネットワークエディタ側の設定に依存します。
ホストで Clash を初めて置く場合は、ポートと UI の位置を先に押さえてください。Windows 向けインストール記事で混合ポートや設定画面の所在を確認してから読み進めると、以降の「どの IP に繋げばよいか」が素直に理解できます。
2 どのモードでも共通：ループバックでは届かない
ゲスト OS 内のブラウザやターミナルから、ホストで動いている Clash の HTTP／SOCKS ポート（例：7890）へ接続するとき、アドレスに 127.0.0.1 を書いてもゲスト自身のループバックを指し、ホストの Clash には届きません。必要なのは、ゲストからルーティング上到達できる「ホスト側インターフェースの IPv4」です。モードごとにその IP がどのアダプタに付くかが変わるため、以降の各節で分けて説明します。また、ゲストはホストにとって 別マシンからの接続（LAN 越し）に相当するため、Clash／Mihomo 側で Allow LAN（LAN からの接続を許可）をオンにし、リッスンが 127.0.0.1 だけになっていないことを確認してください。オフのままだと接続は拒否されます。
3 NAT モード：既定のプライベートセグメントと VMnet8
NAT は VMware の初期プリセットとして最もよく使われるモードです。ゲストには通常プライベート IPv4 が割り当てられ、外向き通信はホストが NAT します。Windows ゲストなら ipconfig、Linux ゲストなら ip addr や ip route で、デフォルトゲートウェイの IPv4 を確認してください。多くの構成では、そのアドレスはサブネットの .1 など、ホスト側 NAT 用アダプタ（しばしば VMnet8 側）と同じセグメントの「仮想ルーター側」として振る舞います。プロキシの宛先として使う IPは、しばしばこのデフォルトゲートウェイと同じ値になります（環境によってはホストの VMnet8 に付いた別アドレスを明示する必要がある場合もあるため、ipconfig で VMware Network Adapter VMnet8 の IPv4 をホスト側でも照合すると確実です）。
設定の手順のイメージは次のとおりです。ホストで Clash を起動し、Allow LAN と実際の混合／HTTP ポート番号を確認する。ゲストでシステムプロキシ（Windows）または http_proxy／https_proxy（Linux）に http://<上記で特定したホスト側IP>:<ポート> を指定する。ブラウザで HTTPS サイトを開き、Clash の接続ログにドメインが現れるか確認する。NAT ではゲスト同士の通信はデフォルトでは期待できない構成もあるため、複数 VM を連携させたい場合はブリッジやカスタム VMnet の検討が別途必要になります。
ip route show default | awk '{print $3}' | head -n1表示されたアドレスが、プロキシ設定のホスト名としてそのまま使えることが多いです。
4 ブリッジモード：物理 LAN と同じセグメント
ブリッジ（Bridged）では、ゲストは物理スイッチ／ルータから直接 DHCP でアドレスを取得し、ホストの他の PC と同じ L3 セグメントに並びます。このとき Clash へ向けるべき IP は、VMnet8 ではなく、ホストが実際にその LAN で使っている IPv4（例：自宅ルータ配下の 192.168.1.x）です。同一サブネット上の「別端末からホストのプロキシポートへ TCP で入る」という見方になるため、Allow LAN は引き続き必要です。社内ネットワークでは、端末間の通信やプロキシポートのリッスンがポリシーで制限されている場合があるため、運用ルールにも注意してください。
Hyper-V の「外部スイッチ（ブリッジ相当）」の節で述べたことと同型ですが、VMware ではどの物理 NIC をブリッジにするかを仮想マシン設定側で選べる点が実務では重要です。Wi-Fi と有線が両方あるノート PC では、想定と違う NIC にブリッジしており、ゲストだけ名前解決や経路がおかしい、というケースもあります。
5 ホストのみ：VMnet1 と「外に出ない」検証環境
ホストのみ（Host-Only）は、ホストとゲストだけが接続された閉じたスイッチに相当し、通常は VMware Network Adapter VMnet1 のようなアダプタがホスト側に現れます。ゲストからインターネットへ直接出す用途には向きませんが、ホスト上の Clash だけにプロキシで接続して試す、マルウェア解析や社内検証のように外向きを絞りたい、という用途ではむしろ分かりやすいです。プロキシの宛先 IP は、ホストで ipconfig し、該当する「ホストのみ」用 VMnet アダプタの IPv4を使います。ゲストのデフォルトゲートウェイがホストのみセグメントの .1 になっていることが多いので、NAT のときと同様に、ゲートウェイ IP とホスト側 VMnet の表示を突き合わせると迷いが減ります。
6 Allow LAN をオンにするタイミング
Allow LAN は「同一マシン内の 127.0.0.1 だけでなく、LAN 上の他ホスト（＝この文脈では仮想マシン）からの接続を受け付ける」ための設定です。NAT・ブリッジ・ホストのみのいずれでも、ゲストからホストの Clash に接続するなら基本的にオンが必要です。オフのまま 127.0.0.1 のみリッスンだと、ゲストからは常に接続拒否になります。信頼できないネットワークにホストをつないで作業している場合は、作業後に Allow LAN を戻す、仮想マシンを停止する、といった運用を検討してください。ファイアウォールが着信を遮っている場合は、Defender と Clash の記事の考え方も参照し、該当ポートの許可を確認します。
7 「ポート競合」と DNS：何が起きやすいか
ポート番号の混乱について、よくある誤解は「ゲスト内で 7890 を使っているからホストの Clash と競合するのでは」というものです。ホストとゲストは別の OS インスタンスなので、同じ番号をゲスト内の別サービスが LISTEN していても、ホスト側の 7890 と直接ぶつかるわけではありません。問題になりやすいのは、(1) ホスト側で同じポートを別アプリが既に使用している、(2) VMware のポートフォワーディングや別ツールが、意図せず同じポートにマッピングしている、(3) ブラウザ拡張やプロキシチェーンが、別のポートへ誤転送している、といったケースです。設定変更後に不通になったら、まずホストで Clash のリッスン表示と、ゲストのプロキシ URL のホスト名・ポートを再確認してください。
DNS の異常では、ブラウザだけ Clash 側の名前解決（FakeIP 等）を使い、ゲスト OS のシステムリゾルバはそのまま、という状態だと挙動差が出ます。名前解決まわりでつまずいたら DNS／FakeIP の記事を参照し、ゲスト側の DNS をホストに合わせるか、ルールとログで切り分けます。ブリッジモードではルータが配る DNS と、Clash が返す応答の組み合わせ次第で、期待と違う経路に見えることもあります。
8 切り分けと確認手順
- ホストで Clash を起動し、Allow LAN と混合／HTTP ポートを確認する。
- ホストで
ipconfigし、使用中のモードに対応する VMnet または実 LAN の IPv4 を特定する。 - ゲストにプロキシを設定し、HTTPS サイトを開いて Clash のログを見る。
- Linux ゲストなら
curl -I --proxy http://HOST:PORT https://example.comで CLI を確認する。 - 不通ならファイアウォール、競合 VPN、ブリッジ先 NIC の取り違えを疑う。
9 まとめ
VMware の仮想マシンから Windows ホストの Clash を使うとき、モードごとに変わるのは「ゲストから見たホストの到達可能 IPv4」です。NAT／ホストのみでは VMnet 系アダプタのアドレス、ブリッジでは実 LAN 上のホストアドレスを指します。いずれも Allow LAN と正しいポート番号が前提で、127.0.0.1 は使えません。ポートの「競合」はホストとゲストで同一 OS 上の衝突ではなく、ホスト側の別プロセスや転送設定を疑うと切り分けが速いです。DNS は FakeIP やゲスト／ブラウザの解決経路の差がつまずきやすく、必要に応じて Mihomo の DNS 設計を見直します。
Hyper-V を使う構成とは検索語と仮想 NIC の名前が異なるため、本稿を Hyper-V 向けの記事とあわせて読むと、どちらの仮想化でも同じ「明示プロキシ＋ホスト側 IP」の骨格に戻せます。クライアントの入手は当サイトのダウンロードページから行い、検証や更新情報の参照に GitHub を併用する程度にすると、インストール経路が一本化されて運用しやすくなります。
同様の用途で軽量 VM の代わりに WSL2 を使う場合は、ネットワークの前提がまた異なるため、WSL2 × Clash の記事と混同しないよう、自分が今どの仮想 NIC に乗っているかを意識してください。
