症狀與預設：為什麼「宿主正常、訪客卻像沒網路」？
多數使用者會先確認：宿主上 Clash Verge Rev 等客戶端已連線、規則與訂閱無誤，瀏覽器開啟測試頁也正常。 接著在 VMware 訪客裡打開相同網址，卻長時間轉圈或直接顯示無法連線。 若訪客採 NAT，預設仍可透過 NAT 裝置做位址轉譯上網；若連「一般直連網站」都不通，請先檢查訪客的預設閘道、DNS、以及宿主實體網路本身是否斷線，而不是急著改代理。
另一種常見情況是：直連國內或一般站點正常，但需要代理的出口站點失敗。
這代表 NAT 本身沒壞，而是訪客沒有走宿主 Clash。
宿主「系統代理」只影響尊重該設定的程式；訪客 OS 內的 Chrome、Edge、終端機裡的 curl／apt，預設完全不會讀宿主註冊表或 macOS 網路服務裡的代理欄位。
因此必須在訪客內手動設定代理，或改採橋接後由區網另一裝置提供閘道（進階，本文以前者為主）。
NAT 與橋接：閘道、網段與「宿主 IP」怎麼看？
NAT（建議新手從這裡開始）：訪客取得虛擬區網位址（常見如 192.168.x.x），預設閘道指向 VMware 的虛擬路由器（例如 .1 或 .2，依版本與平台而異）。
對訪客而言，「要連到宿主上聽著的 Clash」時，目標 IP 必須是宿主在該 NAT 區網上的介面位址，而不是訪客自己的 127.0.0.1。
橋接（Bridged）：訪客像區網內另一台實體機，向路由器拿 DHCP。
此時宿主在區網中也有自己的 IP；訪客要把代理指到宿主在區網上的那個 IP，並確保 Clash 的監聽位址對該網段可達（見下文 Allow LAN）。
橋接的好處是心智模型與「手機連同一台電腦的代理」相近，可與 區網共享 Mixed 埠與防火牆 一併閱讀。
小結：先在訪客內用 ipconfig（Windows）或 ip route／ip addr（Linux）確認閘道與本機 IP，再對照 VMware 虛擬網路編輯器中的子網設定，推導宿主應使用的位址。
1宿主機 Clash：Mixed 埠、Allow LAN、監聽位址
在宿主開啟 Clash 客戶端，記下Mixed Port（或分開的 HTTP／SOCKS 埠），下文以 7890 為例。
關鍵是Allow LAN（允許區域連線）：若代理只綁在 127.0.0.1，訪客從另一張網卡連過來會被拒絕。
開啟後，監聽通常會落在 0.0.0.0:7890，讓同一台機器上的其他介面（含虛擬機網卡）能連入。
若您使用 Windows 宿主，還需在防火牆允許該埠在「私人網路」入站（第三方安全軟體亦可能攔截）。
macOS 上若仍連線失敗，可暫時以「另一裝置或訪客內 curl」對宿主 IP 做探測，排除是本機沙箱規則。
尚未完成桌面端基礎安裝的讀者，可先對照 Clash Verge Rev Windows 安裝與設定 或 macOS 相關教學，把宿主端跑穩再進虛擬機。
安全提醒：Allow LAN 會讓同一區域網路上的其他裝置有機會使用您的代理埠；請僅在信任環境啟用，並了解風險。
2在訪客內解析「宿主 IP」與連通性測試
Windows 訪客：在命令提示字元執行 ipconfig /all，查看預設閘道與 IPv4 位址；閘道通常即 NAT 裝置，而宿主作為 NAT 後的一方，其在 vmnet 上的介面位於同一子網——實務上常見宿主 IP 為 192.168.zzz.1 類型（請以您環境為準，勿硬抄）。
Linux 訪客：使用 ip route show default 看預設閘道，再以 ping 測試宿主 IP；若 ping 被防火牆擋住屬正常，可改以代理埠測試。
將確認後的宿主位址記為 HOST_IP。在訪客內執行（Linux／macOS 訪客範例）：
curl -v --connect-timeout 5 http://HOST_IP:7890
看見連線建立或回應標頭（即使是錯誤頁）通常代表埠可達；若直接 timeout，請回到 Allow LAN、防火牆與 IP 是否誤用 127.0.0.1。
3訪客內設定 HTTP／SOCKS 代理
瀏覽器
在 Chrome／Edge／Firefox 的代理設定中，將 HTTP 與 HTTPS（或「使用同一個代理伺服器」）指向 HOST_IP，埠 7890。
若 Clash 對 SOCKS 另開埠，也可在瀏覽器選擇 SOCKS5 並填同一宿主 IP。
設定後以境外測試站與 Clash連線日誌交叉確認封包有進核心。
終端機與套件管理（Linux 訪客範例）
對 apt、curl、wget 等工具，可匯出環境變數（依 shell 調整；埠請換成您的實際值）：
export http_proxy="http://HOST_IP:7890"
export https_proxy="http://HOST_IP:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export ALL_PROXY="socks5://HOST_IP:7890"
export NO_PROXY="localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
若 Mixed 埠不提供 SOCKS，請將 ALL_PROXY 改為與 http_proxy 相同，或改填 Clash 介面顯示的 SOCKS 埠。
NO_PROXY 用於避免內網與本機流量誤送代理；若您要代理區網內特定服務，請自行縮小排除清單。
DNS、FakeIP 與訪客解析
訪客內的 DNS 請求若未經代理，可能拿到被污染的結果，導致「以為是代理問題，其實是解析錯位」。 實務上可讓瀏覽器走系統／安全 DNS，或暫時改用可信 DoH，並在宿主 Clash 端對齊 DNS 與 FakeIP 設定。 若您啟用 Fake-IP，請一併檢視 fake-ip-filter 與區網放行，避免內部網域名稱在訪客與宿主兩側行為不一致。
何時需要 NAT 埠轉發？
本文主軸是訪客主動對外連線時，把應用程式指向宿主 Clash。
埠轉發（Port Forward）較常用在從區網或外網連進訪客內某服務（例如訪客內跑了一個 Web 伺服器），與「訪客要上網」方向相反。
若您要在宿主瀏覽器打 localhost:某埠 轉到訪客服務，才需要檢查 VMware 的埠對應設定；單純讓訪客瀏覽器出網，通常不必先做轉發表。
macOS（VMware Fusion）與 Workstation 的細節差異
概念相同：先確認虛擬網路介面與 NAT 子網，再讓訪客連 HOST_IP:Mixed埠。
Fusion 與 Workstation 的選單名稱不同，但「虛擬網路編輯器／網路介面卡類型」能找到對應子網。
macOS 宿主若開啟內建防火牆，請允許 Clash 或相應埠的連入測試。
仍不通時的排查順序
- 宿主 Clash 是否正常、Mixed 埠號是否與訪客設定一致。
- Allow LAN 是否開啟，監聽是否為
0.0.0.0而非僅127.0.0.1。 - 訪客使用的
HOST_IP是否為虛擬網路語意下的宿主位址，而非訪客本機或錯子網。 - 防火牆與安全軟體是否擋下
TCP連入宿主埠。 - 是否誤把 HTTP 流量指到 SOCKS 埠或相反。
- 規則是否將測試目標直連／拒連；以 Clash 日誌查看實際策略與節點。
驗收清單
- 訪客內
curl經--proxy http://HOST_IP:7890可取得預期出口。 - 瀏覽器代理指向同一組 IP 與埠後，測試頁與宿主行為一致。
- Clash 連線日誌可見來自訪客網段的連線紀錄。
- 關閉代理後，訪客恢復「僅直連」行為，便於對照。
開源資訊與安裝包取得方式
Clash 生態核心與圖形介面多為開源專案，可於公開倉庫查閱授權與變更紀錄。 客戶端安裝檔建議優先從 本站下載頁 取得；原始碼與 Issue 追蹤可作為技術參考，與日常安裝路徑分開看待即可。
結語
VMware 訪客與宿主共享鍵盤滑鼠，卻不自動共享代理語意：NAT 或橋接決定了封包從哪裡出去，而 Clash 仍在宿主的使用者空間或核心驅動裡等著被連線。 把訪客的 HTTP／SOCKS 指到正確的宿主 IP 與 Mixed 埠，並開好 Allow LAN 與防火牆，就能把「宿主已通、訪客不通」收斂成可複現的網路題，而不是盲目換節點。
與在子系統或第二台實體機上操作類似，虛擬機場景同樣受益於同一套規則與訂閱：維護宿主上的 Clash 即可讓訪客沿用，省去在訪客內再裝一套客戶端的負擔。 若您希望規則與 DNS 更進階，可延續本站 Meta 核心相關長文做增量調校。