VM は「別 PC」：なぜ 127.0.0.1 が通用しないか

ゲスト OS の視点では、仮想 NIC は自分のパソコンにある普通の NICと同じです。したがって http://127.0.0.1:7890 のような指定はゲスト自身のループバックへ向き、宿主で動かしている Clash の待受とは別世界になります。この誤りは検索キーワードに「宿主 Clash」と入れている利用者でも起きやすく、根本原因は単に名前空間が分かれているという一点です。クライアントによっては LAN 経由のアクセス許可や TUN が別設定になりますから、宿主側では一度 GUI の状態を確認してからゲストへ進むと手戻りが減ります。

NAT とブリッジで変わる「宿主」の見え方

NAT（共有／共有ネットワーク） の典型パターンでは、ゲストのデフォルトゲートウェイが仮想ルータになり、宿主本体のユーザー空間プロセスには「転送」の形でだけ見える構成が多く、ゲストから「このマシンの実 IP」を推測しづらいことがあります。一方ブリッジにするとゲストも物理 LAN と同じセグメントに出るので、宿主の Wi‑Fi や有線 NIC に割り当てられた実アドレス（例：192.168.x.x）へ、他の LAN 機器と同様に ICMP や TCP で届けやすくなります。LAN 共有とファイアウォールでも触れているように、宿主 OS のパケットフィルタが立っていると、届かないように見えるだけのケースが残ります。どちらのモードでも最終的に必要になるのは「ゲストが TCP で届けられる宿主の IP:ポート」の組です。

ℹ Parallels は「共有」「ブリッジ」、VMware Fusion は「NAT」「ブリッジ」など文言が異なりますが、論点はゲートウェイとして見えるホップが宿主か仮想ルータかだけです。

宿主の LAN IP をゲストから確認するステップ

まずゲスト側でデフォルトルートと DNS を読みます。Linux ゲストなら ip route と resolvectl status／cat /etc/resolv.conf、Windows なら ipconfig /all、macOS ゲストなら「ネットワーク」環境設定でルータ列を確認します。NAT のときゲートウェイとして表示されている IP が、宿主に相当する転送レイヤになるケースがありますが、アプリケーションレベルのプロキシ指定にはそのアドレスをそのまま使えるとは限らないので、並行して宿主側でも ifconfig／設定アプリからLAN に出ている IPv4 を控えます。複数 NIC がある MacBook では、Wi‑Fi と USB‑Ethernet が別アドレスを持ち、仮想化ソフトがどちらへブリッジしているかでゲストから見える宿主が変わる点に注意してください。

宿主 Clash で mixed-port と allow-lan を揃える

ゲストから届けたいポートは通常、Clash で開いている mixed-port（例：7890）です。宿主で mixed-port と listen のバインド が 127.0.0.1 に閉じていないか確認してください。LAN との通信を許すオプション名は実装により allow-lan または GUI の同名トグルになります。また ターミナル／コンテナ経由での mixed-port 利用と発想が近く、宿主が「ひとつの HTTP／SOCKS 入口」になりますので、ポート番号のメモだけはゲスト側にも貼っておくと親切です。DNS クエリだけ別穴に逃げるときはMeta 系の DNSの説明と突き合わせ、Fake-IP とゲスト側リゾルバの両方が噛んでいないかを見ます。

⚠ 注意：職場や大学の規約では端末へのプロキシやトンネルを禁じている場合があります。利用可否はネットワーク利用規約と管理者への確認を優先してください。

第一段：ゲスト OS のプロキシ（ブラウザ／設定アプリ）

GUI アプリへの最短ルートは、ゲスト OS のシステム全体のプロキシ設定です。Windows 11 では「設定 → ネットワークとインターネット →プロキシ」から手動サーバーを指定します。Ubuntu ゲストでは「ネットワーク」設定のプロキシ欄へ、宿主の LAN IP と 7890（一例）を入れます。macOS をゲストにしている場合は「詳細 → プロキシ」から HTTP／HTTPS と場合によって SOCKS をオンにします。ブラウザが独自の設定を優先しないよう、Firefox を使うときは別途 Firefox 固有の項目と矛盾がないかも見てください。ここまでで「チャットサイトやニュース」のような通常の HTTPS が安定すれば、少なくともアプリケーションレイヤの出口は宿主の Clash に届いていると判断できます。

SOCKS5 を明示したい構成では、アドレスとポート以外に名前解決をプロキシ側で行わせる必要があるブラウザもあります。HTTP プロキシだけでも多くの用途は賄えるため、迷ったときは最初は HTTP／HTTPS に寄せ、その後 SOCKS を試す順が検証として安全です。接続ログで、ゲストからのリクエストがどのポリシーに載っているかを見ると、設定ミスなのかノード側なのかを切り分けられます。

第二段：http_proxy と SOCKS、DNS の確認

ターミナルの curl、wget、apt／dnf などは、GUI のシステムプロキシを無視することが珍しくありません。そこでシェルに次のような変数を入れて試します（例はプレースホルダです）。 

export http_proxy="http://<HOST_LAN_IP>:7890"
export https_proxy="http://<HOST_LAN_IP>:7890"
export ALL_PROXY="socks5://<HOST_LAN_IP>:7890"
export NO_PROXY="localhost,127.0.0.1,::1"

apt は /etc/apt/apt.conf.d/ に Acquire::http::Proxy を書く方法もあります。Windows の PowerShell では $env:HTTP_PROXY 系をセッションに設定します。SOCKS を ALL_PROXY にまとめるか、HTTP のみにするかは、対象ツールの実装次第です。TUN を宿主で有効にしていると、ゲストのデフォルトルートがブリッジ越しに物理 LAN のまま送られ、プロキシを知らないプロセスまで拾われるケースもありますが、VM ソフトとルーティングの組み合わせで期待とズレることもあるため、本稿の手動二段は再現性の高いベースラインとして残しておく価値があります。

応用：宿主で TUN を使うとゲスト側の手順が楽になることがある

宿主 macOS で Clash の TUN を有効にし、ブリッジ VM が同一 L2 セグメントにいると、理屈上はルーティングと DNS の引き回しが簡素化される場面があります。ただし企業 VPN やセキュリティ製品と競合しやすいので、macOS の TUN と拡張まわりを先に読んでから試すのが無難です。Windows 宿主の場合も、仮想スイッチと Hyper‑V 周辺の構成次第で挙動が変わります。いずれにせよ「TUN ON ＝ ゲスト設定ゼロ」と決めつけず、上記の手動プロキシで一度ベースラインを取ってから比較すると安全です。

うまくいかないとき：ファイアウォールと競合サービス

ゲストから ping が通っても TCP の 7890 が拒否されるときは、宿主 OS のファイアウォールが着信をLAN内からも遮断している可能性があります。Windows Defender ファイアウォールの「詳細設定」で Clash 実行ファイルの受信ルールを確認するか、検証の短時間だけ該当ポートを LAN サブネットに開ける（リスクを理解した上で）のが現実的です。Fake-IP と LAN 到達の話は別軸ですが、ゲストのブラウザでルータの管理 IP が開かないなどの症状が出たら、Clash 側のルールと嗅探の設定も点検します。IPv6 だけ別出口を使っている場合はIPv6 二重スタックの記事と併読してください。

まとめ

Parallels／VMware のゲストから宿主の Clash を使うコアは、(1) ネットワークモードに応じてゲストから届く宿主の IP を特定する、(2) 宿主 Clash に LAN からの接続を許し mixed-port を固定する、(3) GUI はシステムプロキシ、CLI は環境変数または apt の Proxy 設定で二段に切る——の三点です。WSL2 向けのループバック前提の手順とは接続の向き先が違うため、WSL2 の記事と混同しないことが重要です。安定したクライアントをそろえたい場合は、→ Clash を無料でダウンロードし、宿主での listen／allow-lan を確認したうえで、ゲストの IP とプロキシ欄をもう一度だけ突き合わせてみてください。