VMware・Parallels の仮想マシンから、ホスト上の Clash へトラフィックを流す
WSL2 向けの「ミラーネットワークとポート」は別稿で整理済みですが、フル機能のゲスト OS（VMware Workstation／Fusion や Parallels Desktop 上の Windows／Linux など）では、仮想 NIC のモードごとに「ホストの 127.0.0.1 が誰のことか」が変わります。本記事では ブリッジ・NAT／共有・ホストのみの違いを踏まえ、ゲストから ホストで動いている Clash の HTTP／SOCKS 入口（多くの場合 mixed-port）へ向ける手順と、システムプロキシ・環境変数・TUN の役割分担を整理します（自宅の許可された機器・購読・法令と利用規約の範囲内での利用を前提）。
WSL2 ではなく「本物の VM」で詰まる理由
コンテナ寄りの WSL2 は、ホストとゲストのループバックや仮想スイッチの見え方が特殊です。「WSL2 と Windows 上の Clash」では、localhost の取り違えとポート転送が中心でした。一方、VMware／Parallels のゲストは独自の IP スタックを持ち、デフォルトゲートウェイは仮想ルータ側に付きます。Clash の TUN インターフェースはホスト OS のカーネル側に載るため、ゲスト内のブラウザや apt が自動ではホストの TUN を通りません。ゲスト全体をプロキシ出口に載せたい場合は、ゲストからホストの LAN 到達可能なアドレス＋ Clash の待受ポートへ明示的に向けるのが基本形です。
- ゲストのデフォルトルートは多くの場合「NAT 側の仮想ルータ」へ。そこからインターネットへ出ます。
- ホストの Clashは、LAN からの接続を受け付ける設定（Allow LAN 相当）が無いと、ゲストから
connection refusedになりがちです。 - TUN をホストで有効にしても、ゲストのパケットは別 NIC なので、ホスト TUN だけではゲストの挙動は変わりません。
ブリッジ、NAT（共有）、ホストのみの早見
製品ごとにメニュー名は違いますが、考え方は共通です。ゲストから「ホスト OS 上のプロセス（Clash）」へ TCP で届けるには、ホスト側 IP がゲストのルーティング／ファイアウォールで到達可能である必要があります。
| モード | ゲストから見たホスト | Clash 連携の観点 |
|---|---|---|
| ブリッジ（Bridged） | LAN 上の別マシンと同列の IP。同一セグメントの他機器と同じようにホストへ到達しやすい。 | ホストの実 IP（有線／Wi‑Fi）へ mixed ポートを向けやすい。ゲストもそのセグメントの DNS をそのまま使うことが多い。 |
| NAT／共有（Shared） | ゲストはプライベート側アドレス。デフォルト GW は仮想 NAT。ホストはしばしば *.1 や専用ゲートウェイ IP。 |
ゲストからホストへは「NAT の内側からホストへ」経路。ホストのファイアウォールがブロックすると失敗する。IP は VM ソフトのドキュメントと実測で確認。 |
| ホストのみ（Host-only） | インターネットに出ない閉じたセグメントが典型。ホストとのみ通信可の構成が多い。 | 外向きのブラウジング自体は別 NIC が必要なことも。Clash だけホスト経由にしたい検証環境向き。 |
実務のコツ
名前より実際の経路を確認します。ゲストで ip route（Linux）や route print（Windows）、macOS ゲストならネットワーク設定のルータ欄を見て、デフォルト GW とホスト到達用のインターフェースを把握してから Clash のアドレスを決めます。
ホスト側 Clash：Allow LAN と待受アドレス
ゲストから接続する時、Clash は 127.0.0.1 だけで聞いていると届きません。LAN にバインドするか、0.0.0.0 で mixed／HTTP／SOCKS を開き、OS のファイアウォールで必要ポートだけ許可する構成が一般的です。詳細な項目名はクライアントによりますが、「LAN から mixed-port へ」の整理と同じ発想です。
ホストで確認すること（例）
- Allow LAN（または同等）を有効にし、ゲストから届くインターフェースで待受ける。
- mixed-port（HTTP＋SOCKS 兼用）または別々のポート番号をメモし、ゲストのプロキシ設定と一致させる。
- Windows なら Defender ファイアウォール、macOS なら「incoming」で該当ポートをブロックしていないか確認。
Windows ホストの初期セットアップは 「Clash for Windows」、macOS は 「Clash Verge Rev」を先に完了させると、以降の VM 作業が単純になります。
ゲストからホスト IP を特定する
ブリッジなら、ホストはしばしばゲストと同じサブネット上の「近所の機器」です。Windows ホストの場合、ipconfig で該当アダプタの IPv4 を控え、ゲストのプロキシ設定でそのアドレスを指定します。NAT／共有では、VMware のデフォルトではゲートウェイ IP（しばしば x.x.x.1 や x.x.x.2）がホスト側のエンドポイントとして振る舞うことがありますが、バージョンと「ネットワーク変換」の実装で差があるため、ゲストから ping や curl で実測してください。Parallels の「共有ネットワーク」でも同様に、ドキュメントのデフォルト GW と実ルートを照合します。
# Linux guest — example: trace default gateway
ip route | head -5
# Then test HTTP proxy reachability (replace HOST and PORT)
curl -x http://HOST:PORT -I https://www.example.com
Windows ゲストなら「設定 → ネットワーク」でゲートウェイを確認し、PowerShell から Test-NetConnection HOST -Port PORT でポート開放を見ます。
ゲスト OS 側のプロキシ設定
ブラウザと OS の更新プログラム、パッケージマネージャは別チャネルです。GUI の「システムプロキシ」はブラウザや一部アプリが追従しますが、apt／dnf／git／docker pull は環境変数や独自設定が必要なことが多いです。「ターミナル・Git・HTTP プロキシ」の表を VM 内でもそのまま流用できます。ポイントは、HTTP_PROXY／HTTPS_PROXY のホスト部分を 127.0.0.1 ではなくホスト実 IP にすることです。
ループバックの取り違え
ゲスト内の 127.0.0.1 はゲスト自身です。ホストの Clash へ向けるには ホストの到達可能 IP を必ず使います。WSL2 の記事と混同しないよう注意してください。
TUN はホストで「出口を揃える」、ゲストでは別問題
ホストで TUN をオンにすると、ホスト上のアプリのトラフィックを Clash ルールに載せやすくなります。VM のゲストは別マシン同然なので、ゲストの通信を Clash ルールで分流したい場合は、(1) ゲスト → ホストプロキシ → Clash、(2) ゲスト自身にプロキシ／VPN クライアントを入れる、のどちらかです。多くの開発用途では (1) で十分です。ホスト TUN とゲストのシステムプロキシを同時に有効にして二重にトンネルが掛かると遅延だけが増えるので、どこで出口を決めるか一箇所に寄せます。
DNS：ゲストの解決先と fake-ip
プロキシに HTTP CONNECT を載せる場合でも、名前解決がゲストのローカル DNS に向かうと、期待と違う IP が返り Clash 側のルールと噛み合わないことがあります。Clash の fake-ip や DoH をホストで使っている場合、ゲストは「プロキシ経由で名前解決まで任せる」設定（プロキシ対応クライアント）か、意図的にホストと同系の DNS を指すかを揃えます。切り分けが難しい時は 「接続できるのに開けない：DNS と fake-ip」を参照し、VM 内でも変数を一つずつ変えてください。
VMware と Parallels の細かい差
VMware（Workstation／Fusion）
仮想ネットワークエディタ（Windows）や Fusion のネットワークプリファレンスで、NAT セグメントとブリッジ対象の物理 NIC を確認します。複数プロファイルを切り替えた直後は、ゲストの DHCP リースが古いままになることがあるため、再接続や dhclient の更新でホスト IP の認識を合わせます。企業 Wi‑Fi でブリッジが禁止されている環境では、共有／NAT に落とすしかなく、その場合こそ「ゲートウェイ＝ホスト近傍」というモデルで mixed ポートを探ることになります。
Parallels Desktop（macOS ホスト）
ネットワークモードはウィンドウのデバイス欄から変更できます。Mac ホストの IP は「共有」では仮想スイッチ越しに見えるアドレスが決まり、ブリッジにするとホストの Ethernet／Wi‑Fi と同じ論理セグメントに乗ります。macOS のファイアウォールや Little Snitch 系のツールが入っていると、ゲストからの着信だけ黙って落ちるので、拒否ログを確認します。
よくあるつまずき
ゲストからポートだけ拒否される
Clash が LAN で聞いていない、またはホスト FW がブロックしている典型です。Allow LAN とバインド先を再確認し、ホスト自身から 127.0.0.1:PORT、別端末から HOST_IP:PORT の順で切り分けます。
ブリッジにしたら遅くなった
物理 NIC の省電力やオフィス VLAN のポリシーで、ブリッジパスが不安定になることがあります。外向き帯域よりレイテンシが重要なら、NAT のままホストプロキシだけ使う構成に戻して比較します。
HTTPS の中間者警告
通常の HTTP／SOCKS プロキシは TLS を終端しません。警告が出る場合は別のセキュリティソフトや誤った透明プロキシ設定を疑います。
チェックリスト
- VM の NIC モード（ブリッジ／NAT／ホストのみ）を決め、ゲストのデフォルトルートをメモする。
- ホストで Clash の LAN 待受と mixed ポートを有効化し、FW を通す。
- ゲストからホスト IP へポート疎通を確認する。
- システムプロキシとターミナル用環境変数をホスト IP に揃える。
- DNS の挙動をホストの Clash 設定と照合する。
まとめ
フル VM は WSL2 とは「誰の 127.0.0.1 か」が違うだけでなく、仮想ルータと NIC モードがそのまま到達性に効きます。ブリッジならホストの実 IP へ、NAT ならゲートウェイ側の取り決めを実測で押さえ、ホスト Clash は必ず LAN から届く姿勢にします。これでゲスト内の開発・イメージ取得・ブラウザを、ホストと同じ購読ルールの出口に載せられます。