1 為什麼要單獨談 VMware：VMnet 與「交換器」不是同一套名詞
Hyper-V 以「內部／外部／預設交換器」描述虛擬交換，而 VMware Workstation／Player 在 Windows 上則透過 VMware Network Adapter（例如 VMnet1、VMnet8）對應到僅主機與NAT網段。多數使用者直覺會把兩邊都稱作「NAT」，但訪客機看到的預設閘道、宿主機在該網段上的介面位址，在 VMware 裡仍須依您選的網路類型重新對一次表，不能沿用 Hyper-V 文章裡的截圖與指令。
與本站 Hyper-V 與宿主機 Clash專文並讀時，請記住共通點：系統代理／環境變數與IP 層預設閘道仍是兩件事；宿主機開了 Clash，訪客機不會自動繼承。您要在訪客機內明確指到「可從訪客機連到的宿主機 IP」加上 Clash 的 HTTP／Socks／混合埠，並在宿主機開 Allow LAN（或設定檔中等價選項），防火牆放行連入。
2 NAT 模式：最常見、閘道通常就是宿主機在 VMnet8 上的位址
在 VMware 裡選擇 NAT 時，訪客機會拿到與NAT 虛擬交換器（預設常對應 VMnet8）同網段的私人位址，對外流量由宿主機做位址轉換。此時在訪客機執行 ipconfig（Windows 訪客）或 ip route（Linux 訪客），預設閘道所指向的 IPv4，通常就是宿主機在該 VMnet 上的介面——也就是您填寫 http://<宿主機在 NAT 網段的 IP>:<mixed-port> 時最常用的「代理主機位址」。
實務上請到 Windows 宿主機開啟「網路連線」或 PowerShell，確認 VMware Network Adapter VMnet8 的 IPv4（常見如 192.168.x.1，實際以您的「虛擬網路編輯器」為準）。訪客機代理設定指到這個位址，而非訪客機自己的 127.0.0.1。若您曾修改過子網路或啟用多組自訂 VMnet，請以編輯器中的 NAT 網段為準，避免抄到舊教學的固定數字。
ipconfig | findstr /i "Gateway"3 橋接模式：訪客機與實體區網同一層，宿主機是「隔壁電腦」
Bridged（橋接） 讓訪客機像區網內的另一台實體機：可能由路由器配發 DHCP，也可能手動設固定 IP。此時「宿主機」在訪客機眼中不是 NAT 閘道那個 .1，而是與您有線／無線網卡同一網段的某個 IPv4。請在宿主機用 ipconfig 查目前連線到路由器的那張介面（或橋接後顯示的位址），把代理指向該區網 IP。
橋接的優點是概念直覺、與區網內其他裝置互動方便；缺點是訪客機暴露在與宿主機相同的區網政策下（公司網路、802.1X、訪客 Wi‑Fi 隔離都可能影響連線）。若您發現「訪客機 ping 不到宿主機 IP」或「同網段卻被路由器隔離」，請先改回 NAT 或 僅主機做對照實驗，再論代理設定。
4 僅主機（Host-Only）：與外網隔離，只留宿主機與訪客機互通
Host-Only 典型對應 VMnet1：訪客機只能與宿主機及同一僅主機網段上的其他 VM 通訊，預設不經 VMware NAT 上外網（除非您另外架設路由或共用宿主機轉送）。若您的目標是「訪客機所有對外流量都走宿主機 Clash」，在純僅主機下須確保：要嘛由宿主機提供對外轉送路徑，要嘛在訪客機內只把需要代理的應用指到宿主機代理埠，並理解「僅主機沒有獨立上網」時，部分更新程式會失敗——這不是 Clash 規則問題，而是網路拓樸限制。
實驗室常用做法是：訪客機僅主機網卡用來 SSH／管理，另加一張 NAT 網卡負責上網；此時請分清楚哪張網卡走預設路由，代理仍指到能連到宿主機 Clash 的那個 IP（多半是 NAT 網段上的宿主機介面）。多網卡情境下，誤把 Proxy 設到僅主機 IP 卻讓預設路由走別張卡，會出現間歇性連線失敗。
5 何時一定要開 Allow LAN（或設定檔中的等價選項）
只要訪客機連線目標是「區網上的宿主機 IP」而非 127.0.0.1，宿主機上的 Clash 就必須允許區網介面連入監聽埠——圖形介面通常稱為 Allow LAN。若僅監聽本機回環位址，訪客機會連線被拒或逾時，與節點品質無關。若您同時啟用 TUN 模式，請一併參考Windows 防火牆與 TUN專文，避免誤判成「規則沒命中」。
6 避免「虛擬機與宿主機搶埠號」：混合埠、儀表板與第二套 Clash
常見摩擦是：宿主機 Clash 已佔用 7890（混合埠）、9090（外部控制器）等，訪客機內又安裝了另一套代理或開發伺服器，也選了相同埠——導致訪客機本機服務與「要連到宿主機的代理」混淆。請固定一套約定：宿主機監聽埠以用戶端設定為準；訪客機內不要再佔用您打算指向宿主機的同一數字作為本機服務埠，或在測試時暫時改動其中一側。
若您在訪客機內也跑 Mihomo／Clash 系服，請將「對外出口」指到宿主機代理時，使用不同埠號區間區分本機入站與「轉給宿主機」的目標，並在設定檔註解中標明，日後才不會在升級用戶端時被還原覆蓋。尚未完成 Windows 側安裝者，可先對齊Clash Verge Rev Windows 安裝教學的埠號與服務模式。
7 DNS 異常：Fake-IP、訪客機解析與「看起來像節點壞掉」
宿主機 Clash 若啟用 fake-ip 或自訂 DNS，訪客機不會自動沿用同一套解析行為。當訪客機仍使用路由器或公共 DNS 時，可能出現「瀏覽器偶發打不開、但換成 IP 直連又正常」的現象。建議在訪客機內明確設定 DNS（例如指向可信的上游，或依公司政策走內部 DNS），再搭配代理規則；若您讓訪客機 DNS 直連境外上游，又期望流量全走代理，請確認DNS 查詢本身是否也被規則涵蓋（視您使用的模式與用戶端而定）。
Linux 訪客機請留意 systemd-resolved、NetworkManager 與手動 /etc/resolv.conf 的優先順序；Windows 訪客機則檢查「介面 DNS 後綴」與是否啟用按介面路由。這類問題與「代理埠不通」不同，用 curl -v 看 DNS 解析階段往往一眼能區分。
8 訪客機內怎麼填：Windows 系統代理與 Linux 環境變數
Windows 訪客機：在「設定 → 網路和網際網路 → Proxy」啟用手動 Proxy，位址填上一節取得的宿主機 IP，埠填 Clash 的 HTTP／混合埠（以您的設定為準）。不讀系統代理的程式需另設環境變數或程式內選項。
Linux 訪客機：可匯出 http_proxy、https_proxy、ALL_PROXY 為 http://<host-ip>:<port>，或使用 socks5:// 形式指向 Socks 埠。apt 可另設 Acquire::http::Proxy。驗證時建議先用 curl -x 測通，再開圖形介面瀏覽器，避免多層設定互相覆寫。
9 驗證與排查清單
- 訪客機連不到宿主機埠：先確認宿主機 Allow LAN、Defender 防火牆入站，再用訪客機對宿主機 IP 與埠做連線測試（Windows 可用
Test-NetConnection）。 - NAT 下改壞路由：多數情況不必手動覆寫預設閘道；缺的是代理位址與埠，請先對照
ipconfig。 - 橋接下偶發失敗：檢查區網隔離、訪客 Wi‑Fi、有線／無線是否不同 VLAN。
- 僅主機卻要全機上網：確認是否需第二張 NAT 網卡或宿主機轉送，否則應接受「僅管理網」限制。
- 埠號衝突：宿主機與訪客機分別列出監聽埠，避免同一數字被兩邊服務佔用。
10 總結
VMware 訪客機要走宿主機 Clash，關鍵是依 NAT、橋接、僅主機 選對「訪客機看得見的宿主機 IP」，再搭配 Allow LAN 與正確埠號；與 Hyper-V 相比，名詞與 VMnet 對應不同，但「應用層代理位址」與「IP 閘道」分離的邏輯一致。日常最穩的路徑仍是在訪客機內設定系統代理或環境變數，必要時再研究宿主機 TUN 與路由進階情境。
相較零散複製指令，先畫清網路模式與連線目標 IP，長期維護成本更低。若希望用戶端版本與本站教學一致、減少埠號與介面不一致的摩擦，可從本站下載頁取得 Clash Verge Rev，再依 Windows 安裝與防火牆文章逐步銜接。
