1 なぜ VMware や Hyper‑V の記事だけでは足りないか
仮想マシンからホスト OS 上の Clashへトラフィックを載せるという目的自体は、Windows 上の VMware Workstation や Hyper‑V、WSL2 の記事と骨格が同じです。ゲストから 127.0.0.1 では届かず、ホスト側の LAN 到達可能 IPv4と HTTP／SOCKS ポートを組み合わせ、Allow LAN でリッスン範囲を広げる、という整理は共通です。ただし Parallels Desktop for Mac は、仮想 NIC の名前もゲストから見えるデフォルトゲートウェイの取り方も、VMware の VMnet8 のような「ホストに見える別名アダプタ」を意識するより、共有ネットワーク（Shared）の仮想ルーター側 IPをまず確認する流れになりやすい点が異なります。
本サイトの VMware × Windows ホスト Clash は、NAT／ブリッジ／ホストのみの三モードを軸に整理しています。Parallels でも「共有」「ブリッジ」「ホストのみ」に相当する選択肢はありますが、メニュー名と既定値、ゲストに割り当てられるアドレス帯はバージョンや Apple Silicon／Intel で差が出るため、記事に書かれた具体 IP（例：10.211.55.1）は出発点として扱い、必ずゲスト OS 側で実測してください。ここを固定観念にすると「記事どおりにしたのに繋がらない」という状態に陥りやすいです。
またホストが macOS のとき、着信を止めがちなのは Windows の Defender ではなく、システム設定のアプリケーション firewall や、初回起動時のプライバシー／ネットワーク許可ダイアログです。Clash 側の設定が正しくても OS がポートを閉じていると、共有ネット越しの TCP テストだけが黙って失敗します。以降の節では、まず経路（ゲートウェイ）、次にClash の LAN 受け入れ、最後にOS の許可と DNSという順で詰めていきます。
3 Clash Verge Rev：Allow LAN・混合ポート・SOCKS
ゲストから見る接続は、Mac 上の Clash にとっては別ホストからの LAN アクセスです。そのため Allow LAN（名称はクライアント版で多少異なりますが「LAN からの接続を許可」系のトグル）をオンにし、リッスンが 127.0.0.1 のみに縛られていないことを確認します。併せて、Verge の設定画面で混合（mixed）ポートや HTTP、SOCKS の実番号をメモしてください。多くのテンプレートでは 7890 が混合、7891 が SOCKS のように並びますが、衝突やカスタムで変わっていることがあるため、UI の表示値を正とします。
アプリによっては HTTP プロキシより SOCKS5 の方が素直に動く場合があります（CLI や一部開発ツール、古めの .NET アプリなど）。このとき URL 形式は socks5://<ゲートウェイ>:<SOCKS ポート> です。逆にブラウザや Windows の「プロキシ設定」画面は HTTP に寄りがちなので、同じポート番号を流用しないよう、混合と SOCKS の役割分担を意識すると混乱が減ります。
Mac 本体のブラウザだけを通したい用途なら、システムプロキシや TUN で完結させる選択肢もありますが、Parallels ゲストはホストの TUN インターフェースの背後にいる別マシンである点に注意してください。ホストで TUN が有効でも、ゲストが自動的に同じトンネルに入るわけではなく、結局は明示プロキシでゲートウェイ IP を指定するパターンに落ち着くことが多いです。TUN 周りの整理は TUN モード解説と併せて読むと、どのトラフィックがカーネルレベルで吸われているかイメージしやすくなります。
4 macOS のファイアウォールと「着信をブロック」系の挙動
Allow LAN をオンにしても不通なとき、次に疑うのがmacOS のアプリケーション firewallです。システム設定の「ネットワーク」または「プライバシーとセキュリティ」まわり（OS バージョンで画面名が変わります）から、該当クライアントに対して着信接続をブロックしていないか確認します。Parallels のゲストから届く TCP は「外部からの接続」に近い扱いになるため、開発用ツールを厳しく閉じているプロファイルだと、ローカルループバックのテストでは気づけず、VM 越しだけ失敗する、というパターンが出ます。
併せて、初回起動時に表示されたネットワークアクセスの許可を拒否したままになっていないかも見直してください。一度誤って拒否すると、設定アプリの一覧から許可へ戻す必要があるケースがあります。社用端末では MDM ポリシーでファイアウォールが強制されていることもあるため、その場合はセキュリティ担当と「VM からホストのローカルポートへ届ける」要件を共有し、例外方針を決めるのが現実的です。
5 ブリッジを選ぶ場面とホスト IP の取り方
共有ネットではなくブリッジを選ぶと、ゲストは自宅やオフィスのルータから直接 DHCP でアドレスを取り、物理 LAN と同じセグメントに並びます。このとき Clash へ向けるべき IPは、共有ネットの仮想ゲートウェイではなく、Mac がその LAN で実際に使っている IPv4です。同一サブネット上の別端末から Mac のポートへ入るのと同型になるため、Allow LAN は引き続き必要で、ルータ側やセグメント内ファイアウォールで端末間通信が禁止されていないかにも注意が要ります。
Wi‑Fi と有線の二刀流 Mac では、ブリッジ先の物理インターフェースを取り違えると、ゲストだけ名前解決が不安定になることがあります。共有ネットに戻すとシンプルに収まる一方、ブリッジでしか満たせない要件（ゲストに公衆から到達可能なポートを開けたい等）があるときだけ、ブリッジの複雑さを引き受ける判断がしやすくなります。
6 DNS がおかしいとき：FakeIP とリゾルバの取り合い
ブラウザはプロキシ経由で名前解決まで Clash に寄せる一方、ゲスト OS の他アプリはゲスト自身の DNS 設定のまま動く、というズレが起きやすいです。ホスト側で fake-ip を使っている構成では、ゲストのリゾルバが返したアドレスと、実際にプロキシが期待する経路が一致しないと「一部だけ接続できる」ように見えます。基本は、DNS／FakeIP のベストプラクティスで述べているとおり、どのレイヤがどの DNS を見るかを図に起こしてから直します。
切り分けとして、(1) ゲストの DNS を一時的に信頼できる公開 DNS（例：運用ポリシーが許す範囲で 223.5.5.5 など）へ固定する、(2) あるいはホストの Clash が公開している DNS ポートへ向ける、といった順で試すと原因が DNS かプロキシ本体かが分かれます。HTTPS は通るが特定ドメインだけ失敗する場合は、ルールより先に名前解決のキャッシュを疑う価値があります。
7 一部アプリだけプロキシが効かない理由
Windows の「設定」アプリでシステムプロキシをオンにしても、WinHTTP のスタックを別経路で使う更新プログラムや、独自にソケットを張るゲームランチャーなどはプロキシを無視することがあります。Linux でも apt や docker は環境変数 http_proxy／https_proxy を見る一方、サービスユニットでは別定義になる、といった差があります。こうしたアプリ個別のプロキシ欄や、開発用の NO_PROXY 例外を確認し、必要なら SOCKS 側へ切り替えて挙動差を減らします。
すべてを一括で SOCKS に載せたい場合は、ゲスト OS 側のプロキフィケーション製品を使う選択肢もありますが、まずはブラウザと curl の両方で同じゲートウェイ／ポートに成功するかを確認し、問題が「OS 全体」か「特定アプリ」かを分けると対策コストが下がります。
8 確認手順（短いチェックリスト）
- Mac で Clash Verge Rev を起動し、Allow LAN と混合／HTTP／SOCKS のポート番号を UI で確認する。
- ゲストでデフォルトゲートウェイ IPv4（共有ネット）または Mac の LAN IPv4（ブリッジ）を特定する。
- ゲストから TCP でその IP・ポートへ接続テストし、失敗なら Mac のファイアウォールと着信許可を見る。
- HTTP と SOCKS の両方で
curlまたは PowerShell のInvoke-WebRequestを試し、Clash の接続ログにドメインが現れるか確認する。 - DNS 起因を疑う段階で、ゲストのリゾルバを一時的に固定し、再度同じ URL を開いて比較する。
9 まとめ
Parallels Desktop の共有ネットワークで macOS 上の Clash Verge Rev をゲストから使うコツは、ゲストのデフォルトゲートウェイ（またはブリッジ時は Mac の LAN IPv4）に対して、Allow LAN 済みの混合ポート／SOCKS を明示的に指定することに尽きます。不通の大半は「127.0.0.1 を書いている」「Allow LAN がオフ」「macOS のファイアウォールが着信を落としている」「HTTP と SOCKS の番号取り違え」「DNS だけゲストに残っている」のいずれかに収束しやすいです。Windows ホストの VMware 記事と対になる理解として VMware 版も参照すると、モードごとの IP の考え方が移植しやすくなります。
クライアントの入手や更新は、配布元を一本化する意味でも当サイトのダウンロードページから行い、ソースコードや Issue 追跡は GitHub を併用する程度に分けると運用が安定します。同じ Mac でホスト側のセットアップからやり直す場合は、macOS 向けインストール記事でメニューバー常駐や権限まわりを先に整えると、VM 側の切り分けに集中できます。
総じて、Parallels は検索上は Windows 仮想化の記事に埋もれがちですが、ゲートウェイ IP の実測とホスト OS の着信許可さえ押さえれば、他プラットフォームと同じ「明示プロキシでホストへ寄せる」モデルにきれいに収まります。ルール品質より前に、TCP が届いているかをログとテストで裏取りすることが近道です。
