症状：ホストは通るのにVMだけ遅い・タイムアウト
体験としては、宿ホストのpingやブラウザは安定している一方、VMwareのゲスト内ではcurlが固まる、HTTPSだけ失敗する、社内直結の10.xは行けるがインターネットだけ出ない、といった具合に偏ります。原因は一つに決まるわけではありませんが、Clash未使用の「素のゲスト」はVMware NATのデフォルトゲートウェイ（多くの場合、192.168.x.2前後）経由で外へ出る設計であり、プロキシを意図的に挿入しない限り、ホスト上のクライアントと同じ出口ポリシーにはなりません。WSL2と同系の「名前空間が違う」話はWSL2向けの稿で詳しく扱っていますが、VMwareも仮想NICのレイヤーが違う点は同じです。
NATで押さえるべき3点：セグメント、ゲートウェイ、誰がNAPTするか
NATモードでは、ゲストは通常プライベートアドレス（例：192.168.56.x、製品版ではVMnet8系の帯域）に割り当てられ、外向きはVMwareの仮想ルータ層がNAPTし、最終的に宿ホストの物理NICから出ます。ここで誤解しがちなのは「ゲストがホストOSのClashの127.0.0.1に勝手に届く」ではない、という点です。ゲストから見た127.0.0.1はゲスト自身であり、HTTPプロキシ欄に127.0.0.1:7890と書いても、多くの場合空振りか意図しないループになります。外向き疎通を作る本筋は、①ゲストのデフォルトルートが生きているか、②外へ出る経路（必要なら仮想マシンのHTTP／SOCKS設定）で宿ホストの到達可能IP＋Clashのリスン番号を正しく指す、の二層に分かれます。
用語の整理：「仮想マシンのゲートウェイ」は、NATではVMware配下の仮想ルータIPが多く、これは「インターネットの出口」を選ぶ第1段です。Clashのプロキシを使う第2段は、ブラウザやOSの「プロキシ指定」、またはアプリの明示設定で乗せます。
宿ホスト側Clash：mixed-port、Allow LAN、バインド
ゲストから宿ホスト上のプロキシへTCPで届けるには、ClashのHTTPやSOCKS、あるいはmixed-port相当の番号を、ループバック専用に閉じたままにしないのが先決です。多くのGUIでは「Allow LAN」「LANから接続」などの名称で、0.0.0.0系へのバインドを許可します。オフのままだ、ホスト上の別名前空間からのSYNが弾かれ、VMからも届きません。番号はプロファイルで変わるため、7890固定と決めつけないでください。Windowsホストの初期導線はWindows向けセットアップ稿で押さえ、実際のリスン値をメモしてから仮想側の設定に進むと戻りが少ないです。スマホと同じLANからPCのプロキシを使う手順の考え方は、Clash Verge RevのLAN共有稿とほぼ同型で、防火壁の受信規則だけVMware帯用に頭を切り替えれば足ります。
宿ホストのIPを、ゲストから「届く」形で取る
Windowsの典型：VMware Network Adapter 周り
VMware Workstation / Playerでは、NATに対応するVMware Network Adapter（例：VMnet8向け）に、ホストが192.168.x.1のように振られる構成が多いです。一方、ゲストはしばしば192.168.x.0/24内の別アドレスをDHCP取得します。ここでゲストのプロキシ先に入れるのは、多くの場合「192.168.x.1＝VMnet上のホスト側」の方が素直で、物理LANのWi-Fi IP（例：10.0.0.15）が必ず正解とは限りません。迷ったら、ゲスト内からip routeやroute -n、Windowsならipconfig /allでデフォルトゲートウェイ近傍の帯域と、到達性のある同一セグメント上の宿ホストIPを照合するのが早いです。
macOS上のVMware / Fusion 利用時
vmnet周りの番号づけは版で差が出るため、固定の1行表よりifconfigや仮想スイッチの接続図の確認を優先してください。心構えは同じで、「ゲストが見る仮想マシンのNICセグメント」と「宿ホストのClashに届ける宛先IP」は一致系である必要があり、ブリッジに切り替えると一気に帯域が物理LANへ寄る点には注意が要ります。
ゲスト内の設定：ブラウザ、OS、ターミナル
Windowsゲストなら、設定の「プロキシ」で手動を選び、HTTPと（必要なら）HTTPSにhttp://HOST_IP:PORT形式を入れます。SOCKS5専用で組んでいるプロファイルなら、別フィールドにsocks5://...を。LinuxゲストはデスクトップのネットワークGUIで同等に書くか、http_proxy／https_proxy、必要に応じてALL_PROXY（SOCKS）をシェルに定義します。先に述べた通り、127.0.0.1にClashのポートを置くのは「ホスト専用」と割り切れない限り不適合です。例外として、ゲストOS内に別のローカルプロキシ（cntlm等）を立て、そこからホストへ中継する二段構えを自分で作った場合は127.0.0.1が再び意味を持ちます。
# Example: Linux guest shell (replace HOST and PORT)
export http_proxy="http://192.168.172.1:7890"
export https_proxy="http://192.168.172.1:7890"
export no_proxy="localhost,127.0.0.1,::1,10.0.0.0/8,192.168.0.0/16,172.16.0.0/12"
# Optional SOCKS in same Clash if profile exposes a SOCKS port
# export ALL_PROXY="socks5://192.168.172.1:7891"
コマンド一発で試すなら、curl -v --proxy http://HOST:PORT https://www.example.comのようにHTTPプロキシを明示し、Clashの接続ログにフローが乗るかを見ると、DNS以前の到達性を切り分けられます。
ブリッジにしたとき挙動が変わる理由
ブリッジは、仮想NICを物理LANの一クライアントに近づけます。ゲストは自宅ルータのDHCPからアドレスを取り、デフォルトゲートウェイはルータ向き。ここで宿ホストのClashを使う意味は、基本的に「同じLAN上のPCのIP＋プロキシポート」か、あるいはTUNやシステムプロキシの設計に寄せるかのどちらかです。NATに比べ、誤った静的ルートの影響を受けにくい反面、ゲストと宿ホストの関係は「同僚マシン同士」に近づきます。社内VLAN隔離下では、ブリッジ自体が使えないことも多い点も押さえておいてください。
「ポートフォワーディング」は外向き必須か？
外向き（ゲスト → インターネット）のHTTP／SOCKS利用だけを目的とする限り、通常はVMwareのポートフォワーディングを新設する必要はありません。入向き（インターネットから仮想サーバの:443に届ける、など）を作る用途がNAT文脈のポートフォワーディング中心です。用語の混線で設定画面を遠回りしないよう、先に目的を「中継を張る（外向き接続）」と「中継を受け止める（入向き公開）」に分けてから触るのが安全です。
直らないとき：防火壁、DNS、FakeIP、IPv6
宿ホストの受信はWindows Defender ファイアウォール等で、Clashの実行体、またはプロキシの待受ポートを許可する必要があります。届かない段階では仮想マシン内からnc -vz HOST PORT（ツール名はディストリで差）でTCP到達性を先に。DNSがゲスト内だけ不整合（DoH二重、FakeIPとOSリゾルバの二重定義）だと、プロキシまで行っても期待しない宛先に出るため、DNSリーク防止の総覧と併せて、ルールと名前解決の整合を見直します。プライベート帯の192.168.x.1等が直結扱いに巻き込まれている場合、fake-ip-filter系の知識が役立ちます。
注意：利用規約・組織のネットワーク方針・所在国の法令を遵守し、未承認の迂回やプロキシ利用を行わないでください。本稿は自宅検証・許可された検証環境向けの技術整理です。
まとめ
VMwareの仮想マシンから宿ホストのClashへ乗らない問題は、多くの場合NATやブリッジのセグメント理解と、127.0.0.1の取り違え、Allow LAN不足のどれかで説明がつきます。HTTPとSOCKSの表記、ゲートウェイ（VMware仮想ルータ向き）とプロキシ（アプリの明示中継先）の役割を分け、まずはcurlの明示代理でパケットがClashのログに現れるところまで持っていくのが、再現性の高い道筋です。クライアントの入手先は、仕様表と併せて本サイトの配布導線に寄せるのが、GitHub直リンクの取り違えを防ぎます。
他ツール同様、安定して仮想マシンとデスクトップの出口ポリシーを揃えられるClash系は、ルール可視性と接続ログの分かりやすさの面で実務的な利点が大きいクライアント群です。まずは同じ方針で端末の代理を一本化し、トラブル時の当たり所を減らすとよいでしょう。