VMware 與 Parallels 虛擬機裡怎樣走宿主機 Clash？橋接、NAT、共享與代理逐步配置
站內已有 WSL2 與 Windows 上 Clash 的專文，但 完整虛擬機（訪客是另一套作業系統、獨立網路堆疊） 時，要讓上網、套件管理、拉映像、跑瀏覽器與腳本時都經由宿主上已執行的 Clash，還得釐清虛擬網路卡模式、宿主的監聽位址，以及 系統代理／TUN 各自作用在誰身上。本文以 VMware 與 Parallels 常見的橋接、NAT、僅主機、共享情境為主軸，整理可重複的檢查順序，讓訪客 OS 的出口與您預期一致，而不是「宿主能開、虛擬機卻靜音」。
為什麼 WSL2 的解法不能整包搬到完整虛擬機
Windows 上的 WSL2 與子系統之間的邊界，是微軟虛擬化堆疊與「localhost 是否可互通」的議題，解法常包含取得宿主在該一瞬間的內部 IP、鏡像網路、或連接埠轉發，可參考 《WSL2 走不通 Clash？鏡像網路與連接埠轉發》。而 VMware、VirtualBox 或 Parallels 裡的客體，是一張（或多張）完整虛擬網卡＋自己的路由表，預設閘道往往指向虛擬化軟體內建的路由，而不是 Clash 本人。Clash 在宿主上聽的若是 127.0.0.1，訪客從自己的命名空間去連「宿主的 127.0.0.1」通常不會指到您想的那台機器。因此，第一步不是狂改 YAML，而是回答：訪客封包要從哪個路徑到宿主、以及 Clash 的 HTTP／SOCKS／混合埠究竟綁在哪一個位址、是否開放給區網。
心智模型：封包不會自己懂「要去找 Clash」
在宿主安裝 Clash 之後，常見的實作是：系統代理讓有遵循系統代理的應用程式把流量送到 127.0.0.1:埠號；TUN 模式則在該作業系統內攔到更多「不讀系統代理」的流量。但虛擬機裡的應用程式，其實是在訪客 OS 的網路堆疊裡運作。若您沒有在訪客內設定任何代理、也沒有在訪客內掛 TUN，訪客裡的瀏覽器與 curl 會先照虛擬介面的預設路由出門。通常有兩條務實路徑能對齊「都經由宿主 Clash」：其一，讓虛擬子網或橋接後的位址，能以 TCP 連上宿主在區網上開放的代理埠（多數用 HTTP／SOCKS，或在訪客內也跑一層可指到宿主轉送埠的代理）；其二，在上層路由器或虛擬化提供的轉送／透明代理能力處理——這在桌面個人實作裡往往不如「在訪客填代理」來得直接。
先記兩行
宿主 Clash 的 Allow LAN（或僅聽內部網路位址）決定虛擬子網能否連進「混合埠」；訪客內的系統或使用者環境變數，決定 apt、git、docker pull 是否願意走那個 HTTP／SOCKS。
橋接（Bridged）：與實體區網「同一層」
橋接時，虛擬網路卡會透過虛擬化驅動接到您實體網卡所在的上層區段，訪客常會從家裡路由器拿到與實體機同網段的位址。優點是行為最像實體第二台 PC：mDNS、區網內的簡單偵測、或需與內部檔案伺服器同網段的情境較單純。此時，宿主的內部 IP 往往是和訪客同一前綴的一個實體可達位址；若 Clash 在該位址的某個 TCP 埠上聽、且已開 Allow LAN 或在綁定位址上允許連入，訪客可以把系統或應用程式代理指到 http://宿主內部IP:混合或 HTTP 埠，就能讓瀏覽器與多數有遵循系統代理的程式匯到同一條管線。
注意：橋接不代表自動「全機都進入 Clash」——未設定代理的程式仍可能直接從訪客預設閘道（路由器）出網，和宿主 Clash 完全無關。若您堅持訪客內每個程式的出口都與某套規則一致，通常要嘛在訪客內再啟一層全域代理或 TUN，要嘛在較上層網關就做到可信任的預設出口。桌面使用情境下，多數人會在 Linux 訪客設好 http_proxy／https_proxy 與 no_proxy，再針對不讀變數的服務用各工具自己的設定檔或透明轉接。
NAT 與「共享網路」：子網與轉送
NAT 模式是桌面虛擬化最常見的預設值：虛擬化軟體在裡面放一塊小網路，訪客拿到內部位址，對外則由宿主幫您做位址轉譯。此時，訪客要連宿主上的服務，常見的「宿主在虛擬子網內的位址」會出現在說明文件或介面的閘道／連線資訊一欄，例如 192.168.x.1 之類的虛擬介面位址（實際數字以您環境為準，請在兩邊作業系統的網路設定中核對，勿盲抄教學的範例）。在這種情況下，您仍需要讓 Clash 在能從子網連到的那個位址上聽、並開 Allow LAN，否則訪客連過去會在 TCP 層就被拒。若同時有防火牆，要在宿主放行對應埠的連入。完整整理「允許哪些 IP 讀到混合埠」可搭配 《LAN 與混合埠、Allow LAN》專文 中的概念一併讀，避免以為開了系統代理就等於從子網也進得來。
在 Parallels 上，共享（與實體世界共享宿主連線，概念上多為 NAT 類行為）是預設好上手的一種，訪客往往透過內部閘道出網；要從訪客連到宿主，同樣要確認 宿主在該虛擬子網上的可達性與 Clash 的綁定位址。若您曾開啟 macOS 防火牆 或第三方的連線防護，請一併檢查是否阻擋了從子網進到混合埠的 TCP。
| 模式 | 訪客大致如何出網 | 要連宿主 Clash 前通常先想什麼 |
|---|---|---|
| 橋接 | 和家裡其他裝置類似、直接經實體閘道 | 用宿主在「同一區段」的位址＋已開的代理埠＋必要時防火牆 |
| NAT／共享 | 子網路閘道轉到宿主、再出實體介面 | 閘道 IP、虛擬子網路是否與 Allow LAN 相符 |
| 僅主機 | 不經實體外網，只與虛擬內部互通 | 外網拉套件通常需改回 NAT／橋接或上層代理 |
僅主機（Host-Only）：內測、互連，與上網分開想
僅主機網路讓多個虛擬機與宿主彼此可通，卻不負責幫訪客接外網。若訪客此刻只有 host-only 沒有第二張對外虛擬卡，就無法在訪客裡正常從公網拉 Docker 映像或更新套件庫——這和 Clash 好不好無關。要嘛再掛一張 NAT 或 橋接 介面、要嘛在內測專用的場景中改由宿主代拉再傳。若同時有 host-only 與 NAT，請留意訪客內的預設路由與 metric，避免流量誤從不該出網的介面硬擠。Windows 上若您把 Clash 的 TUN 想當成「幫虛擬網內的訪客攔下全部 IP」，在工程上通常不會自動成立，因為 TUN 的邊界在那台已安裝 Clash 的作業系統的驅動層，虛擬化另一側的作業系統不會因為宿主開了 TUN 就變成同一顆核心。
TUN 裝在誰身上？
宿主上的 Clash TUN 主要影響宿主的路徑；訪客內的程式除非您另外在訪客內也安裝並啟用 TUN 類客戶端，否則不會因宿主 TUN 而整桌透明代理完成。
Windows 宿主上的 Clash：聽址、允許區域網路、防火牆
在 Windows 安裝圖形客戶端（例如常見的 Clash 介面產品）時，建議已照 《Clash for Windows 與 TUN 基礎》 完成訂閱與模式切換。針對虛擬機場景，請在設定中同時看三件事：第一，混合埠（或分開的 HTTP、SOCKS 埠）實際數字。第二，是否勾選「允許 LAN」，且理解它代表在不僅限 127.0.0.1 的位址上接受連入。第三，Windows Defender 防火牆 是否針對該執行檔有「專用／公用」網路正確放行；若從子網來的連線看起來像「另一種網路型態」，有時要手動加一條入站規則。完成後，在訪客內以 ping 或 curl -v 小步驗證「能否 TCP 連到 宿主:埠」，比直接開瀏覽器猜錯因更快。
macOS 與 Parallels：權限、與內部位址的對齊
在 macOS 上，若使用 Clash Verge Rev 等圖形介面，可從 《Clash Verge Rev macOS 設定》 一文的脈絡，先完成核心與系統權限，再回到「訪客怎麼連我」。與 Parallels 搭配時，共享網路讓外網從訪客角度常常「已通」，但要讓訪客刻意走宿主上 Clash 的規則，您仍要提供訪客能連的可路由位址:埠，並在 macOS 端確認沒有應用程式層的防火牆把該埠擋在虛擬子網路之外。若同時有 VPN 或其他虛擬介面在宿主上，優先以在訪客內實測的 traceroute 或最短路徑為準，不要假設圖表上的幾何關係。
訪客 OS 內部：系統代理、變數與「不讀變數」的程式
在 Linux 訪客內，常見的作法是：圖形桌面於「網路」設定裡填 HTTP 代理、並在 ~/.profile 或 ~/.bashrc 中匯出 http_proxy 與 https_proxy；若需要排除區網，別忘了 no_proxy 含內部網段，以免內部 API 也硬塞到代理。Windows 或 macOS 訪客則在各自的系統代理頁面填寫。要注意的是：Go、部分容器執行檔、或某些內建 TLS 的程式有時不讀 HTTP_PROXY，需要讀專案文件或用代理鏈。若目標是「讓幾乎所有程序都經同出口」，在訪客內額外安裝一套支援 TUN 的 Clash／Mihomo 類核心是可選的更強一檔，但維運成本是兩層設定的對齊與日誌判讀。
訪客內一輪實用檢查（節錄）
- 在訪客內以指令列確認能連上「宿主:混合埠」。
- 同一指令列在設好
https_proxy後curl -I一個測站。 - 圖形瀏覽器若仍直連，檢查是否套用了「手動代理」或外掛干擾。
- 若只 Docker 不工作，讀取 Docker 自己的代理與
daemon.json說明。
兩層轉接時：與 TUN 與假設 IP 的關係
當訪客已經能連到宿主的 SOCKS5 時，理論上您可以把另一個「僅在訪客內要分流」的客戶端指到 127.0.0.1 上的本機中繼。但在未建那一層之前，不要期待宿主 TUN 把訪客內的封包讀成可規則化的 PROCESS-NAME。若 fake-ip 或 DNS 模式在宿主與訪客各寫一組，有時還會出現「在訪客內看起來能解析、實際連線卻從沒被代理」的錯位；遇到類似跡象，可回到 《連上了卻沒網？DNS 與 fake-ip》 的排查心態，在單一邊先穩定解析與實連。
常見症狀與最可能遺漏的點
訪客能 ping 宿主、但瀏覽器仍不經 Clash
多數是沒設系統代理或只設了變數卻在開 GUI 應用。請分開測 curl 與圖形瀏覽器，確認兩條管線都刻意指向同一位址:埠。
以為開了 TUN 就全家透明
請回到本文明確區分 宿主 TUN 與 訪客內是否另有代理層；兩邊的預期不同是誤解大宗。
混合埠有開、卻從子網路連不進去
先查 Allow LAN 與綁定位址、再查防火牆。三者缺一都會在埠測通時讓您懷疑人生。
可帶走的一頁清單
- 選好虛擬網路模式，並在訪客內寫下閘道、子網路遮罩、以及到宿主的實測可達性。
- 在宿主 Clash 開好混合埠、必要時 Allow LAN，並在宿主防火牆放對行。
- 在訪客內以系統或環境變數讓
apt、git等能走；其餘頑固程式各別設定。 - 分清楚要「方便」還是「全行程透明」：後者常要在訪客內也加一層。
從一個能長期維護的客戶端開始
虛擬化與實體路由千變萬化，能留下來的通常是可重演的檢查順序與在正確的邊界上測通 TCP。當 Clash 在宿主的行為是透明的，從虛擬機接上同一套規則才會是工程而非玄學。若您需要終端與變數的範本句型，可延伸閱讀 《終端、HTTP 與 Git 代理》 一文。