Hyper-V 仮想マシンから Windows ホスト上の Clash へ：NAT、既定ゲートウェイ、ファイアウォール放通（2026）

この記事で最後まで分かること

Hyper-V マネージャー で仮想スイッチ（既定のスイッチ、NAT、外部など）に応じた ホスト側 vEthernet の IPv4 を特定し、ゲスト OS から ping や curl で 到達性 を確認する前に、Windows ホスト で Clash の mixed-port または HTTP プロキシ が ループバック専用 になっていないか、allow-lan 相当の設定を見直せます。続けて 受信の規則 で TCP 宛先ポートを開け、Linux や Windows ゲスト 側のシステム プロキシ／環境変数を ホストのその IPv4:ポート に合わせ、ルールログ で 分流 に乗ったかを見比べる流れを把握できます。VMware ユーザー向けの用語の対応関係も末尾で触れます。

Hyper-V の NAT と「ホストに届ける」とは何か

多くの初期構成では、既定の仮想スイッチ か 内部スイッチ＋ ホストの共有 により、ゲストはプライベート帯域の アドレス（例：172.16.～や 192.168.～系）を DHCP で受け取り、デフォルトゲートウェイ には仮想ルーター役の 最初の 1 ホップ が入ります。そのルーター は実体として Windows ホスト上の仮想 NIC に紐づくアドレスであることが多く、ゲストから見た「インターネットの出口の手前」は、抽象化のレイヤーでは ホスト です。ここに注意が要るのは、Clash が 127.0.0.1 だけに bind していると、仮想マシン のパケットはそもそも プロキシの待ち受け に届かない、という点です。ホスト上の ブラウザ は 127.0.0.1:7890 へ届きますが、ゲスト から同じ 127.0.0.1 を指定すると、届く先は ゲスト自身 のループバックであり、Windows 側の Clash とは一致しません。

したがって「ゲストの疎通先」として選ぶのは、vEthernet (Default Switch) 等に表示される ホストの IPv4 です。値は 再ブート や 仮想スイッチ の作り直しで変わることもあるため、手順のたびに ipconfig で正とし、固定したい 場合は 管理者向け の ネットワーク構成 ドキュメントに従います。以降、プレースホルダ HV_HOST でその IPv4 を表します。

なぜ「ホストの Clash は動いているのに仮想マシンだけ不行き」に見えるのか

第一の理由は上記の 127.0.0.1 の意味の違い です。第二に、Hyper-V の 分離 により、ゲストのトラフィックは 意図せず Clash の 透明 な経路（TUN モード や システムプロキシ の自動適用）に乗りません。ホストで TUN をオンにしていても、それは主にホスト OS 向け です。ゲストの 全トラフィック をホスト上の Clash へ流したい場合は、ゲストに明示的にプロキシ を書くか、ルーティング を上級者向けに敷くのが基本です。第三に、到達性 以前に Windows ファイアウォール の パブリック プロファイル や vEthernet 用 の扱いで 受信 が弾かれ、Test-NetConnection HV_HOST -Port 7890（ホスト自身から）では通るのに、ゲストから だけ タイムアウト という図式が起きます。第四に、プロキシ未設定 のまま「きっとホストの ゲートウェイ 経由で抜けているはず」という思い込みは、HTTP/HTTPS だけをプロキシに乗せたい 目的とはズレることがあり、アプリ が プロキシを無視 すれば、見かけ上 分流 も DNS も揃いません。

ステップ0：ホストで Clash の listen とクライアント基盤を確定する

まだ 仮想マシン 側の話に入る前に、Windows 11 での Clash Verge 初回セットアップ 相当で、システムプロキシ と TUN の役割、購読 の有効性を押さえてください。ここで ミキサー（mixed）ポート を仮に 7890、SOCKS が 7891 等だとしても、数字は 実環境 に合わせます。以降 7890 は例示とします。設定画面で allow-lan または同等の LAN から接続 を有効化し、bind-address が 0.0.0.0 または ホスト上の仮想 NIC を含む形 になっているかを確認します。ここは スマートフォンが同一 LAN から PC の Clash を使う 記事と同じ層の話です。違いは、今回の「クライアント」は スマートフォン ではなく、Hyper-V ゲスト である、という点だけです。

ステップ1：仮想スイッチ越しのホスト IPv4（HV_HOST）を控える

ホストで コマンド プロンプト または PowerShell から ipconfig /all を実行し、vEthernet (Default Switch)、vEthernet (WSL) と併存するなら、仮想マシン が接続している スイッチ名 に対応する行の IPv4 を探します。複数 仮想スイッチ がある ラボ構成 では、該当 VM の接続先スイッチ を Hyper-V マネージャー の 設定 で再確認し、取り違え を防ぎます。既定のスイッチ を使っているだけなら、多くの場合 1 本の vEthernet 名で足りますが、手動 で 内部／外部 を作っている場合は、VM のネットワーク アダプター に表示された名前と ipconfig の見出しを照合します。

ゲストが Windows なら ipconfig で デフォルト ゲートウェイ の行、Linux なら ip route や ip -4 route で default の via を見ると、ゲストがどの hop を外に出す入口とみなしているか が分かります。ここに表示される 最初の 1 ホップ は、プライマリ DNS ではなく、次の層 のルーティング用アドレスです。うまくいっていないとき、ホスト上の HV_HOST を誤ると、以降すべてが空振りするため、まず HV_HOST の特定に時間を使う価値 があります。

ステップ2：allow-lan と「どのアドレスで listen するか」

Clash の YAML または GUI で、allow-lan: true 相当の有効化を行います。無効のままだと、ループバック 以外からの 接続 を弾きます。bind-address が 127.0.0.1 のままの記述例は、仮想マシン シナリオでは不適合です。一方で、0.0.0.0 に bind 範囲を広げると、同一セグメント上の他端末からも届きやすくなるため、自宅 LAN のみ、など 運用の制約 とセットで考えます。

Docker Desktop からホスト Clash へ揃える 記事でも述べたとおり、仮想化 スタックはホスト Windows とは 別名空間 ですが、「ホストの HV_HOST:7890 に TCP で届くか」という 検証単位 は 共通 です。

ステップ3：Windows Defender ファイアウォールの受信規則

受信 で 7890（実際の mixed ポート）向け 規則 を追加します。スコープに 仮想スイッチのプレフィックス を絞ると安全側に振れますが、切り分け 初期は一時的に 広め にして、通ったあと で絞るのも手です。GUI では「受信の規則」の新規、TCP、特定のローカル ポート、プロファイル（プライベート／ドメイン／パブリック）に注意し、Hyper-V 用 vEthernet が パブリック 扱いになっていると、プライベートのみ許可 では 拾われない ことがあります。

高度なセキュリティ ウィンドウ で、該当プロファイルの 有効／ブロック を ログ 付きで確認し、弾いている識別子 をメモするやり方は、スマホ LAN 向け 同記事 と 同型 です。企業 MDM や グループ ポリシー により、管理者以外 は規則追加できない 端末 もある点は先に断ります。

ステップ4：ゲスト OS でプロキシを「HV_HOST:ポート」に合わせる

Windows ゲスト では、設定 → ネットワークとインターネット → プロキシ から 手動プロキシ をオンにし、アドレス に HV_HOST、ポート に 7890 等を入れます。ローカル イントラネット の バイパス リストに 社内帯 を入れて、不要な往復 を減らす運用は 方針次第 です。

Linux ゲスト では、デスクトップ 環境の システムプロキシ に同じ HTTP/HTTPS を入れるか、シェル で http_proxy／https_proxy／all_proxy を http://HV_HOST:7890 に 合わせます。ブラウザだけ試すなら、拡張機能 型の プロキシ もありますが、ターミナル の curl まで揃えたいなら 環境変数 の方が一貫しやすいです。DNS や fake-ip 周りの違和感は、チュートリアル の DNS モード 説明と併せて、接続ログ 上の ルール当たり を確認します。

ステップ5：ping が通らないのに、プロキシは生きる場合がある

ICMP（ping）は Windows ファイアウォール で ブロック されがちで、疎通の正 には なりにくい です。代わりに、ゲスト から curl -v --connect-timeout 5 http://HV_HOST:7890 のように HTTP 層 で接続（実際の応答は 400 前後でも）し、TCP 確立 まで辿るか、PowerShell の Test-NetConnection -ComputerName HV_HOST -Port 7890 相当を ゲスト版 ツールで行います。ここで 失敗 なら、まだ ファイアウォール か allow-lan か、取り違えた HV_HOST の層に戻れます。逆に、ping だけ通っても 7890 が 閉じていれば プロキシは使えません。

ステップ6：TUN や「ゲストの default gateway を Clash に」という誤解

ホストで TUN を使う主目的は、Windows ホスト上のアプリ を対象にしやすいことです。ゲスト OS まで自動で巻き込まれる、と期待すると ハマり やすいです。ゲストの default gateway を いじらず、HTTP/HTTPS プロキシ を 明示 する 現実的なルート が、多くの 読者 のゴールに合います。もちろん ルーティング や 透明 プロキシに寄せる構成も可能ですが、Hyper-V 管理者 向けの 別文書 レベルです。

また「仮想マシン のトラフィックがプロキシを経由しないのは 分流 のせいだ」と短絡しがちですが、先に プロキシ未設定 や ポート不達 を潰し、Clash のルール は 接続がコアに到達したあと の話であることを整理します。そうして初めて、GeoIP や DOMAIN の順番、漏れ を疑えます。参考として Clash Meta の sniffing と DNS も、ホスト上の 診断 には役立ちます。

VMware Workstation 利用者向け：用語の対応

本稿は Hyper-V を 主 に書きましたが、VMware の ブリッジ／NAT／ホストオンリー でも、「ゲストの外に出る直前の hop」 と 「ホストの Clash に届けるための、ホストの IP とポート」 という 二層 は同型です。VMware 側の 仮想アダプター 名は異なりますが、ipconfig／ifconfig／ip addr の読み方は同じです。ここを押さえれば、他の仮想化 プロダクトのドキュメントへも 写像 しやすいです。

上から順に使えるチェックリスト

（1） ホストの ipconfig で、該当 vEthernet の HV_HOST を特定したか。（2） Clash で allow-lan 相当と bind を確認したか。（3） ゲストから HV_HOST:7890 へ TCP が生きるか（ping ではない）。（4） ファイアウォール 受信でブロックが残っていないか。（5） ゲスト OS の 手動プロキシ または 環境変数 を HV_HOST に合わせたか。（6） ブラウザ拡張や no_proxy で意図せず 直結 していないか。（7） ホスト Clash ログに 当該接続 が現れるか。ここまで揃うと、仮想マシン から 分流 込みの挙動を、再現性 ある形で扱えます。

まとめ

Hyper-V の 仮想マシン から Windows ホスト 上の Clash を使う本質は、NAT 背後 の アドレス空間 を意識し、127.0.0.1 ではなく HV_HOST:ポート へ層を揃えることです。そのうえで allow-lan、ファイアウォール、ゲストの手動プロキシ を順に潰し、ICMP ではなく TCP で 到達性 を確かめます。スマートフォン向け LAN プロキシ や、WSL2 向け Git／npm の文と併せると、自宅 Windows 一台を中心に、端末の種類に応じた 揃え方 を選びやすくなります。クライアントの導入と更新は、本サイトのダウンロードページ を主に参照し、ルールで見える化 できる プロキシ として、長期運用のしやすさを実感しやすいはずです。

まだ Hyper-V ゲスト の前に、ホスト Windows 側の挙動が曖昧なら、初回セットアップ から戻ると、mixed-port の番号や ログ の開き方まで含め一貫します。

→ Clash を無料ダウンロードし、仮想マシンとホストの代理経路を試す