NAT 與橋接：訪客眼中的「宿主」在哪裡？

無論是 Parallels Desktop 還是 VMware Fusion，預設常見兩種虛擬網路：NAT（共享網路）與橋接（Bridged）。 在 NAT 下，訪客與外界之間多經虛擬閘道做位址轉換；該閘道通常就是宿主對訪客可見的一個內部位址（常見形如 10.37.x.1、192.168.56.1 或 VMware 預設閘道等，視虛擬網段而定）。 在橋接下，訪客與宿主同屬實體區域網路的一個子網，此時你應改抓宿主在路由器 DHCP 配發的那個 LAN IP（例如 192.168.1.12），而非任何虛擬介面專用位址。

最常見的誤區，是在訪客裡把 Proxy 設成 127.0.0.1 或 localhost：在訪客 OS 內，迴圈位址只指向訪客自己，不會對到正在宿主跑的 Clash。 和 WSL2 經 Windows 宿主 Clash 相比，WSL2 另有子系統專用 IP；傳統虛擬機則全靠你在網卡設定選了 NAT 還是橋接來決定要 ping 誰、Proxy 要填誰。 若你正在挑圖形客戶端與埠號策略，可先對照 如何選擇適合自己的 Clash 客戶端， 確認 mixed-port、SOCKS 埠在設定檔裡實際是多少，再回訪客填同一組數字。

步驟一：宿主 Clash 允許區網連入並鎖定埠

訪客要連的是「宿主 IP:埠」，因此宿主上的 Clash 必須對區域網路介面監聽，而不是只綁 127.0.0.1。 多數設定裡需開啟 allow-lan（或圖殼等效「允許來自區域網路的連線」），並確認 mixed-port／port／socks-port 真的在宿主防火牆側放行入站 TCP 至該埠。 Windows Defender 防火牆、macOS 應用程式防火牆若擋了入站，訪客會出現連線逾時或直接被拒，表面卻像「Clash 沒開」。

與 Clash 區網共享、防火牆與網段一次查清 同一路思路：手機與虛擬機在網路層都是「另一台主機」；唯虛擬機的網段標籤依 NAT／橋接而變，排錯時請在訪客內執行路由或閘道查詢（例如 Linux 的 ip route、Windows 的 ipconfig），對出預設閘道是否即宿主位址。

建議在宿主先以圖殼或日誌確認 Clash 聆聽於你預期的埠；再到訪客用 ping 測宿主 IP（若 ICMP 被擋仍可能 ping 不通，此時改以 curl 測 HTTP CONNECT 更有意義）。 排程類測試請勿在生產環境 brute-force 掃描他台機器埠號——僅在你有管理權的宿主與訪客範圍內操作。

Guest Linux: default route / gateway hint 
ip route | sed -n '1,5p'
# Often the default via x.x.x.1 — in NAT, that address is a strong candidate for host reachability.

步驟二：訪客系統手動代理與環境變數

在不改閘道、不把 Clash 當預設閘道的前提下，最穩定的作法是應用層顯式代理：瀏覽器與支援系統 Proxy 的程式指向 http://<HOST_LAN_IP>:<mixed-port>，或 SOCKS5 指到 socks5://<HOST_LAN_IP>:<socks-port>。 這與 終端機與容器走 mixed-port／SOCKS5 與環境變數 同一套路，只是把「對端 IP」從本機或 Docker 閘道換成宿主區網 IP。

Linux 訪客可對當前 shell 匯出 http_proxy、https_proxy、all_proxy，必要時補 no_proxy 放行內網與鏡像站；apt 另可設定 Acquire::http::Proxy（各發行版文件略有差異）。 Windows 訪客可在「設定 → 網路和網際網路 → Proxy」手動指定，或僅讓瀏覽器走 Proxy；留意公司 GPO 可能鎖定此頁。 macOS 訪客用「系統設定 → 網路 → 進階 → Proxy」即可與 Clash 的 HTTP／SOCKS 埠對齊。

若宿主開著 TUN，流量在宿主核心已被攔截，但不會自動讓訪客「透明」進 TUN；訪客仍須透過上述 Proxy 路徑，除非你做更上層的閘道或透明轉發（那已接近 Linux 小主機旁路閘道與 nftables 轉發 專文範疇，與本文刻意分開）。 想先搞懂 TUN 在宿主上做了什麼，可讀 Clash TUN 模式深度解析， 避免以為「宿主 TUN 開了，虛擬機會自動跟著」。

Example environment (guest shell, HTTP + SOCKS) 
export http_proxy="http://192.168.1.10:7890"
export https_proxy="$http_proxy"
export all_proxy="socks5://192.168.1.10:7891"
curl -I https://example.com

DNS、TUN 與「不要改閘道」的邊界

只看 HTTP 代理而忽略 DNS，常出現「站開了但規則像沒命中」的錯覺：訪客若仍用公共 DNS 或內建加密 DNS，解析路徑可能未經 Clash。 實務上可在訪客暫改為能連到宿主的解析方式，或讓支援「透過 Proxy 做 DNS」的程式用同一出口；並對齊 Clash Meta 的 nameserver、fallback 與 fake-ip-filter 設定，避免宿主與訪客各解析一套。

另一個邊界是：把訪客預設閘道改成宿主 IP，或手改路由表，在欠缺完整 DNAT／轉發規則時，容易變成半套透明代理或斷網。 本文採手動 Proxy 兩步：先 allow-lan 與防火牆，再在訪客指宿主 IP；多數開發／測試場景已足夠穩定。 若你同時在宿主 macOS 開 TUN，也建議留意 系統延伸與系統代理的衝突， 但那屬宿主 GUI 層，與訪客手動 Proxy 仍可並存。

Parallels 與 VMware 介面備註

Parallels 一般於虛擬機「設定 → 硬體 → 網路」選擇共享、橋接或僅主機；切換後訪客取得的閘道／子網可能整組改變，請在訪客內重新查一次 IP 與閘道再填 Proxy。 VMware Fusion 於「網路介面卡」可選 NAT、橋接、僅主機等；若你自訂多埠轉發或虛擬多網卡，請就以實際承載預設路由的那一張網卡為準。

兩者若啟用實驗性 IPv6 或額外 VPN 介面，可能出現雙棧出口；症狀與 IPv6 雙棧與 DNS 直連 類似，必要時在訪客測試階段暫關 IPv6 對照即可。 實測時亦可從宿主確認虛擬網路介面名稱（例如橋接後對應的實體網卡），避免誤把僅宿主可見的管理網段當成訪客應連的 Proxy 位址。

ℹ 提醒：請在合規且有管理權的裝置與網路上設定代理；公司或校園資產請遵循內部政策。本文說明虛擬機與宿主 Clash 之間的技術對齊，不構成對任何第三方網路之存取指導。

結語

Parallels／VMware 訪客要走宿主 Clash，核心只有兩件事：在宿主讓代理埠對區網可連（allow-lan、防火牆），以及在訪客用宿主區網 IP 配 HTTP／SOCKS，不要誤用 127.0.0.1。 NAT 與橋接決定你該認哪一個「宿主位址」；系統 Proxy 與 http_proxy／ALL_PROXY 則決定應用程式是否買單。 與旁路閘道、全機透明轉發相比，這條路維護成本較低，也方便用日誌逐包確認。

相較只依賴單一瀏覽器外掛，把規則留在 Clash、讓多款工具共用同一 mixed-port，長期更一致。 → 立即免費下載 Clash，開啟流暢上網新體驗，再在虛擬機裡用宿主 IP 對齊埠號即可。