1 既定ゲートウェイとシステムプロキシ、何が違うか
既定ゲートウェイは、ゲスト OS が「このサブネット外へ出るパケットを最初に渡す相手」です。Hyper-V の内部 NAT（既定スイッチなど）では、多くの場合その相手は仮想ルーター役のホスト側インターフェース（しばしば 172.16.x.1 のようなアドレス）であり、ここ経由でインターネットへ NAT されます。システムプロキシは別物で、アプリが HTTP トラフィックを明示的に http://ホスト:ポート へ送るための設定です。ブラウザや「システムプロキシを尊重する」アプリはこちらを見ますが、プロキシ非対応のプロセスは既定ゲートウェイ側へそのまま出ます。したがって「Clash に載せたい」のが Edge や Chrome 中心なら方式 A（システムプロキシ）が第一候補です。ターミナルや winget、一部の .NET アプリまで含めて揃えたいなら、追加で環境変数やツール個別のプロキシ設定が必要になることがあります。
「ゲートウェイをホストの Clash に向ければ全部透過的にプロキシできるのでは」という発想は、ホスト側で IP 転送・iptables／WFP レベルの透過プロキシや TUN を別途構成しない限り、成り立ちません。Clash の既定の HTTP／SOCKS ポートは「プロキシプロトコルで話しかける相手」であり、単に既定ゲートウェイの IP を変えただけでは、TCP セッションが自動でそこへプロキシ形式で流れるわけではないのです。ホストで Clash を初めて置く場合は、Windows 向けインストール記事でポートと UI の位置を押さえてから読み進めると迷子になりにくいです。
2 Hyper-V の NAT と「既定ゲートウェイ」の実像
既定の仮想スイッチ（Default Switch）や内部スイッチ＋ NAT を使う構成では、ゲストはプライベート IPv4 を取り、既定ルートの次ホップがホスト上の仮想 NIC に割り当てられたアドレス（多くはサブネットの .1）になります。これはすでに「ホスト経由で外へ出る」経路が張られている状態です。ここでユーザーがやりたいのは通常、外向き TCP を Clash のローカル混合ポート（例：7890）に HTTP プロキシとして流し込むことなので、ゲートウェイをいじるより、その .1 など「ゲストから届くホスト側 IP」＋ Clash ポートをプロキシ URL に書く方が筋が通ります。Linux ゲストなら ip route の default、Windows ゲストなら route print や ipconfig /all で、デフォルトゲートウェイと自分のインターフェースを確認してください。
逆に、ゲスト側で既定ゲートウェイを手動で別アドレスに変えると、NAT 経路が壊れてインターネット全体が不通になることがあります。どうしてもルーティングをいじる場合は、社内ネットワーク方針と競合しないか、復旧手順（Hyper-V のスイッチ設定に戻す、スナップショット）を用意したうえで検証してください。ホスト側ファイアウォールがゲストサブネットからの着信を拒否しているときは、Defender と Clash の記事の考え方も参考に、該当ポートの許可を確認します。
3 ホスト側 IP（vEthernet）の取り方
ゲストから Clash へ届ける宛先は、ループバックの 127.0.0.1 ではなく、Hyper-V がホストに作った vEthernet (...) アダプタの IPv4 であることがほとんどです。ホストで PowerShell またはコマンドプロンプトから ipconfig を実行し、該当する仮想スイッチ用アダプタの IPv4 アドレスをメモします。ゲストで ping が通るかは、ICMP が許可されていない環境もあるため必須ではありませんが、TCP でプロキシポートが開いているかは確認した方がよいです。Windows ホスト側では Test-NetConnection -ComputerName <ゲストから見たホストIP> -Port 7890 の逆方向確認に相当する操作として、ゲストからブラウザや curl でプロキシ指定の HTTPS リクエストを試します。
Linux ゲストでゲートウェイ IP を素早く取り出す例として、次のように既定ルートの次ホップを表示する方法があります（ディストリビューションにより ip コマンドの有無は共通です）。
ip route show default | awk '{print $3}' | head -n1得られたアドレスが、しばしばプロキシ設定の「ホスト名」としてそのまま使えます。WSL2 ではホスト探索の話題が別文脈になるため、コンテナ風の Linux をHyper-V ゲストで動かしている読者は、WSL2 × Clash の記事と対比しつつ、自分が今「軽量 VM 上の Linux」にいることを意識すると設定ミスが減ります。
4 Clash 側：Allow LAN、リッスンアドレス、ポート番号
ゲストはホストに対してLAN 越しのクライアントになります。Clash／Mihomo 互換 GUI では Allow LAN（LAN からの接続を許可）をオンにし、混合（mixed）ポートまたは HTTP ポートが 0.0.0.0 で待ち受けていることを確認してください。オフのままだと 127.0.0.1 のみリッスンとなり、ゲストからの接続は拒否されます。ポート番号はプロファイルや GUI の表示に合わせ、ドキュメントの例にある 7890 に固執せず、接続タブに実際に出ている値を使います。セキュリティ上、信頼できないネットワークにホストをつないでいるときは作業後に Allow LAN を戻す、ゲストを止める、などの運用も検討してください。
5 方式 A：ゲストでシステムプロキシ（推奨の出発点）
Windows ゲストでは、「設定」→「ネットワークとインターネット」→「プロキシ」から手動プロキシをオンにし、アドレスにホストの vEthernet IPv4、ポートに Clash の HTTP ポートを入力します。古いパネル派なら「インターネット オプション」の LAN 設定でも同様です。Edge／Chrome は多くの場合システムプロキシを参照するため、ここまででブラウザ経由の閲覧は安定しやすくなります。ストアアプリや UWP がループバック制限で悩むのはホスト側の話ですが、ゲスト内で同種の症状が出たらホストのUWP／ループバック記事の切り分けと対比すると理解が速いです。
Linux ゲストでは、デスクトップ環境の「システムプロキシ」設定に同じ URL を入れるか、シェル向けに http_proxy／https_proxy／大文字版を ~/.bashrc などに記述します。sudo 付きコマンドは環境が切り捨てられることがあるため、必要なら sudo -E や /etc/environment、ツール固有の設定ファイルを検討してください。ブラウザ単体なら拡張機能のプロキシ切替でも構いませんが、設定の再現性は OS レベルより劣ることがあります。
6 方式 B：「ゲートウェイを Clash に」と静的ルート——よくある誤解
検索クエリに「既定ゲートウェイ プロキシ」と入ると、ゲートウェイ IP をホストの別 NIC に書き換える手順がヒットすることがありますが、Hyper-V の内部 NAT と Clash のローカル HTTP ポートを同一レイヤで混同しないことが重要です。既定ゲートウェイを変えても、アプリがプロキシプロトコルを話さない限り Clash の混合ポートには自動接続されません。透過的に全トラフィックを吸い上げたい場合は、ホストで TUN モードや企業 VPN との併用など別設計になり、本稿の「ゲストだけプロキシで足す」話とは切り分けた方が安全です。
例外として、特定サブネットだけ別ルートを張る、ホストを経由する複雑な社内構成などルーティング自体が要件のときは静的ルートが有効ですが、その場合も「プロキシとして Clash を使う」のか「パケットをホストに転送しホスト側で別処理する」のかを設計図に分けて記述してください。迷ったら、まず方式 A でブラウザと curl --proxy が通ることを確認してから、ルーティング変更に進むと戻り道が明確です。
7 外部スイッチ（ブリッジ相当）のとき
物理 NIC とブリッジした外部スイッチを使うと、ゲストはルータから直接 DHCP でアドレスをもらい、ホストと同じ L2／L3 セグメントに並びます。このとき Clash へ向ける IP は、vEthernet ではなくホストが実 LAN で使っている IPv4（例：192.168.1.10）になります。Allow LAN は引き続き必要で、社内ポリシーによってはホストのファイル共有ポートと同様、プロキシポートの LAN 公開が禁止される場合もあるため注意してください。ゲストが複数ある場合でも、各ゲストからは同じホスト IP＋ポートを指せばよく、Clash 側のログでクライアントを区別できます。
8 切り分けと確認手順
- ホストで Clash を起動し、Allow LAN と実ポート番号を確認する。
ipconfigで対象vEthernetの IPv4 を特定し、ゲストのプロキシ設定に転記する。- ゲストのブラウザで HTTPS サイトを開き、Clash の接続ログにドメインが出るか見る。
- Linux ゲストなら
curl -I --proxy http://HOST:PORT https://example.comで CLI 経路を確認する。 - 不通ならホスト側ファイアウォール、別セキュリティスイート、競合する VPN クライアントを疑う。
ホスト全体を仮想 NIC レベルでまとめて扱いたいニーズは理解できますが、Hyper-V ゲスト単体の安定運用では、まず本稿の明示プロキシが最も再現性が高いです。ルールやログの見やすさという点では、Mihomo コアを載せた Clash 互換クライアントに軍配が上がる場面が多く、長期利用ではその利点が積み重なります。
9 まとめ
Hyper-V ゲストから Windows ホストの Clash を使うとき、第一歩は「既定ゲートウェイを書き換える」ではなく、ゲストから到達できるホストの IPv4 と混合／HTTP ポートを突き合わせることです。内部 NAT ではそのアドレスがしばしばデフォルトルートの次ホップと一致し、外部スイッチでは実 LAN 上のホストアドレスを指します。Allow LAN を有効にし、ブラウザと OS のシステムプロキシを整えるのが最も素直な方式であり、CLI やパッケージマネージャーは環境変数などで追従させます。ゲートウェイ操作はルーティング要件があるときの上級トピックとして切り離し、透過プロキシまで一気にやろうとするとトラブルシュートが難しくなる点に留意してください。
同じ Windows ホストで開発環境を分けたい場合、WSL2 利用者はWSL2 向けの記事とあわせて読むと、仮想スイッチと WSL の仮想 NIC の違いが腹落ちします。クライアント本体の入手は一貫して当サイトのダウンロードページから行い、リリースノートや検証済みパッケージの確認に GitHub を併用する程度に留めると運用が楽になります。
