Windows 虛擬機不走宿主機 Clash？橋接網卡與混合埠實測

一、先對齊現象：為什麼「宿主通了，虛擬機卻像沒代理」

這類問題在社群裡常被描述成「Clash 開著，但虛擬機還是直連」。實務上，宿主上的 Clash 預設只處理進入本機監聽位址與埠號的連線；而虛擬機器是另一台（邏輯上的）主機，有自己的 IP、自己的預設閘道與路由表。除非客體主動把 HTTP／HTTPS／SOCKS 流量送到宿主在某一張網卡上可連到的 IP 與 mixed-port，或您在建置上採用更高階的閘道／TUN 拓樸，否則客體的瀏覽器與指令列工具會照 DHCP 給的閘道往外走，與宿主 Clash 無關。

另一個常見誤解是：開了「系統代理」就以為全機含虛擬機都會跟著走。系統代理通常只影響宿主 Windows 上遵守該設定的應用程式；Hyper-V 客體、VMware 客體內的作業系統不會自動繼承宿主工作階段的代理設定。因此要在客體內另行設定代理環境變數、作業系統代理，或改網路拓樸，才能讓流量進宿主 Clash。

若您尚未釐清訂閱與監聽埠，可先對照《Clash 常見報錯解決方案》確認核心有載入、埠未被占用；本文假設宿主本機瀏覽器已可透過 Clash 正常上網，專注在虛擬網路與跨主機連線。

二、NAT 與橋接：封包實際從哪張卡出去

NAT（位址轉譯）模式下，客體拿到的是虛擬區段內的私有位址，對外由 hypervisor 模擬的「小路由器」做轉譯；預設閘道通常是該區段的 .1 或 .254 之類的內部位址，而不是您的宿主在實體區網上的 IP。此時客體要連宿主上的 Clash，應使用宿主在該虛擬網段上可連線的那個 IP——在 VMware Workstation 常見情境裡，可在宿主執行 ipconfig，找到對應 VMware Network Adapter VMnet8（NAT）或您自訂 vmnet 的 IPv4，例如 192.168.x.1；客體內把代理指到 http://192.168.x.1:混合埠（實際埠以設定檔為準）。

橋接（Bridged）模式則讓客體像直接插在與宿主同一台實體交換器上：由區網 DHCP 配發與宿主同網段的位址，預設閘道通常是家裡或公司路由器。此時客體對外預設不會經過宿主，除非您把代理明確設成宿主在區網上的 IP（例如 192.168.1.50）加 mixed-port。橋接的好處是客體與手機、NAS 等同層設備互連較直覺；壞處是您必須在路由器／防火牆政策允許的前提下，讓區網內其他裝置能連到宿主上的代理埠——這正是 allow-lan 與防火牆入站規則要處理的部分。

Hyper-V 的「預設交換器」與「外部／內部／私人」虛擬交換器組合，概念上可類比：外部交換器接近橋接到實體網卡；NAT 則有獨立位址空間。客體內用 ip route 或 Windows 的 route print 看預設閘道，通常一眼就能判斷您現在是「與宿主同區網」還是「躲在虛擬 NAT 後面」。

三、宿主該填哪一個 IP？實測檢查清單

無論 VMware 或 Hyper-V，請在宿主先確認下列三點，再在客體填代理位址。

1. 在宿主 PowerShell 或命令提示字元執行 ipconfig /all，列出所有介面。找出「客體理論上連得到」的那一個 IPv4：橋接時多半是實體 Wi‑Fi 或乙太網路卡上的區網位址；NAT 時則是對應該 vmnet 的宿主介面位址。
2. 在客體內對該 IP 做探測：Linux 可用 ping（若 ICMP 未被擋）、Windows 客體可用 Test-NetConnection 宿主IP -Port 混合埠 或 curl -v 試連 HTTP 代理。若連埠都無法建立 TCP，先不要怪規則，而是防火牆或監聽位址尚未對外開放。
3. 確認 Clash／Mihomo 的 mixed-port（或分開的 port／socks-port）與您在客體填的埠一致；客體 curl 若走 HTTPS，常需加 -x http://IP:埠 或搭配 HTTPS_PROXY，視核心與工具而定。

站內《區網裝置與 allow-lan》一文對「區網內其他機器連宿主代理」有共通觀念，可與本文並讀；差別在於虛擬機的「區網」可能是 vmnet 虛擬段，而不是實體路由器下的 DHCP。

四、mixed-port、allow-lan 與 bind-address

Clash 混合埠指同一埠同時接受 HTTP 與 SOCKS 類連線（依核心版本與設定略有差異），客體瀏覽器設 HTTP 代理、終端機設 ALL_PROXY=socks5://... 時可共用同一數字埠，減少記多個埠的負擔。若您只開了單一協定埠，請在客體環境變數與應用程式內對應到正確協定。

allow-lan 設為 true 後，核心才會接受來自非本機迴圈的來源 IP 連線（仍須監聽在 0.0.0.0 或具體區網介面，視設定而定）。若只監聽 127.0.0.1，區網與虛擬網段一律連不進來，客體會得到連線拒絕或逾時。部分圖形用戶端把這兩項包在「允許區網連線」開關內，但實際寫入 YAML 時仍建議核對 allow-lan 與 bind-address。

Windows Defender 防火牆可能阻擋入站 TCP 到混合埠。實測時可暫時為 Clash 或所用核心程式新增「允許連入」規則（限制在私人／區網設定檔較安全），或在確認連線後再收斂為僅允許特定子網路。若您不願開放入站，可改採客體內僅出站連宿主——實際上仍是客體主動連向宿主 IP:埠，防火牆需允許該入站工作階段在宿主側成立，這與「從網際網路任意位置連進來」風險等級不同，可依環境調整範圍。

五、客體內怎麼設：瀏覽器、apt 與 curl

在 Linux 客體，可將下列環境變數寫入 ~/.bashrc 或 systemd 使用者單位（範例埠請改成您的 mixed-port）：

# Example — replace HOST_IP and port with your values
export http_proxy="http://HOST_IP:7890"
export https_proxy="http://HOST_IP:7890"
export ALL_PROXY="socks5://HOST_IP:7890"
export no_proxy="localhost,127.0.0.1"

接著執行 curl -I https://www.example.com 或您常用的探測 URL；若仍失敗，用 curl -v 看是 TCP 連不上還是 TLS／HTTP 層被拒。部分發行版 apt 需另行設定 Acquire::http::Proxy，與 shell 環境變數分離，請一併檢查。

在 Windows 客體，可到「設定 → 網路和網際網路 → Proxy」填入本機 HTTP 代理為 宿主IP:埠，或用支援 SOCKS 的第三方工具；PowerShell 亦可設 $env:HTTP_PROXY 再測 Invoke-WebRequest。

若您希望客體內幾乎所有 TCP都進宿主 Clash，而不逐一套代理，可研究在宿主啟用 TUN 模式並搭配合適路由，或把宿主做成閘道；複雜度與風險較高，入門仍建議先跑通「明確 HTTP／SOCKS 代理」路徑。TUN 觀念可參考《Clash TUN 模式開啟方法》。

六、和 WSL2、Docker 有什麼不同

WSL2 使用虛擬化網路堆疊，與本機迴圈、區網 NAT 的關係又與 VMware 客體不同；站內《WSL2 使用宿主 Clash：apt、Docker》專注在該堆疊下的 IP 取得與 resolv.conf 等細節。若您同時使用 WSL2 與傳統虛擬機，請避免把兩邊的「宿主 IP」抄錯：WSL2 常見是動態的內部位址，VMware NAT 則常落在固定的 vmnet 段。

Docker Desktop 在 Windows 上亦可能再掛一層虛擬網卡；容器內要連宿主代理時，有時用 host.docker.internal（依版本與後端而異）。與本文 VMware／Hyper-V 客體相比，關鍵仍是「客體路由表＋能連到監聽位址」。

七、實測驗證：從連線日誌反查

當客體 curl 已能通，請回到宿主 Clash 的連線日誌或即時連線列表，確認來源是否為客體 IP、策略是否命中預期群組。若完全沒有新連線，代表流量仍沒進核心；若連線出現但網站打不開，再回頭查規則、DNS 與 fake-ip。這種「先證明封包有進 Clash，再談規則」的順序，比在客體盲目換 DNS 或換節點更有效率。

下列簡表可列印出來在實驗桌旁勾選（實際 IP 與埠請替換成您的環境）。

八、安全與維運提醒

對區網或 vmnet 開放代理埠，等同在該範圍內提供一個可轉送流量的服務；請勿在不受信任的公共 Wi‑Fi 上長期開放 0.0.0.0 監聽，並定期更新核心與訂閱來源。若環境為公司資安政策嚴格之企業網路，請先與管理單位確認是否允許二層代理或閘道行為，避免誤觸規範。

九、小結

Windows 虛擬機不走宿主 Clash，多半不是魔法失效，而是網路拓樸與監聽範圍沒對齊：先分清 NAT 與橋接網卡，在宿主找到客體該連的那個 IP，打開 mixed-port 與 allow-lan，必要時放行防火牆，再在客體設好代理或環境變數。與 WSL2、區網分享稿搭配，您幾乎能涵蓋 Windows 上所有「第二套作業系統」場景。若您希望用圖形介面減少手寫 YAML 的疏失，可優先選擇與 Mihomo 整合良好的用戶端，並從本站取得安裝包後再依上文逐步驗證。→ 立即免費下載 Clash，開啟流暢上網新體驗