Hyper-V 虛擬機想用 Windows 主機 Clash：NAT、閘道與防火牆放行分步設定（2026）

先搞懂：為什麼 Hyper-V「預設交換器／NAT」跟手機區網不一樣

當您使用 Hyper-V 的預設交換器或內建的NAT類型網路時，虛擬機拿到的通常是獨立私有網段（常見為類似 172.x.x.x），經由網路位址轉換（NAT）進出您的實體網卡；這時「虛擬機看到的預設閘道」多半是NAT 介面在該網段上的內部位址，用途是把 VM 對外流量轉發出去，而不是您在區網路由器 DHCP 列表裡看到的那個「Wi‑Fi IP」。因此實務上若要讓同一台電腦上的 Clash接手 VM 的出口語意，您需要先問：從 VM 裡往外連線時，究竟要把 HTTP／HTTPS／SOCKS 代理指向「哪一個對 VM 而言可達的主機 IP」——通常會落在Hyper-V 對該 NAT 網段分配的宿主側介面 IP或文件／環境中所述之宿主閘道位址上，而不是您在外網路由器底下看到的區網 IP，除非您改用外部交換器把 VM 直接橋進同一 LAN。

這也是為什麼許多人會混淆WSL2：WSL2有自己的虛擬網卡與解析規則（請沿用WSL2 專文），而Hyper-V 來賓 OS是一組獨立的 TCP/IP 堆疊；您不能在 VM 裡假設「Windows 已開系統 Proxy，Linux／Windows 來賓就一定自動繼承」，多半仍需明確設定代理或TUN／透明轉發類策略——本篇先把最常見、也最穩定的「代理埠連回宿主」路徑講清楚。

步驟一：在宿主 Windows 確認 Clash 埠與監聽位址

在動 Hyper-V 設定前，請先在宿主 Windows確認三件事：① Clash／核心已正常啟動且節點可用；② 您清楚mixed（或 HTTP／SOCKS）實際監聽埠（常見例如 7890，請以介面為準）；③ 監聽是否僅綁在 127.0.0.1——若是，來自Hyper-V 虛擬網段的連線會直接被拒絕，等同 VM 永遠連不上代理埠。

請在客戶端設定或設定檔中啟用允許區域網路／Allow LAN語意的選項（常見對應組態為 allow-lan: true），並讓監聽綁定到可在該環境接受的位址（例如綁定 0.0.0.0 或明確包含 Hyper-V 網卡所在網段——依您的客戶端與版本為準）。若您先前照過手機區網共用 Clash調過防火牆輸入規則，這裡的原理類似，只是來源位址範圍換成Hyper-V NAT／虛擬交換器網段。

步驟二：在虛擬機內找出「對 VM 而言的主機 IP」

在來賓 OS（無論是 Windows 或 Linux）開啟終端機／命令提示字元，查看預設閘道與介面 IP：Linux可用 ip route／ip addr；Windows來賓可用 ipconfig /all。請記下VM 所在子網路，並思考：若要連到宿主上的 Clash，下一跳應指向誰？在許多 NAT 設計裡，宿主側會有一個可在該 VM 子網路內 ping／TCP 連線到的位址（視 Hyper-V 版本與交換器類型而定）；若文件指出可使用預設閘道旁的宿主介面或該 NAT 網段的第一個可用宿主位址，請以您環境中實際量測到的為準。

接著請做最小連線測試（仍以代理埠為準）：用 curl、Test-NetConnection（PowerShell）或瀏覽器連線工具，對http://<宿主 IP>:<埠>發起TCP連線（SOCKS／HTTP 代理埠走的是TCP；請勿只用 ping 否定一切——ICMP 可能被防火牆擋）。若 TCP 連不上，請不要立刻改訂閱；優先檢查宿主監聽與防火牆輸入規則。

步驟三：在來賓系統設定「指向宿主 IP:埠」的代理

對整機 VM最常見且好維護的做法，是在來賓 OS 設定系統 Proxy或環境變數（視 OS 而定）：

• Linux 來賓：可由桌面環境「網路 Proxy」設定 HTTP／HTTPS／SOCKS；終端機工具則常用 http_proxy／https_proxy／all_proxy 指向例如 http://<宿主 IP>:7890 或 SOCKS 對應 URI。
• Windows 來賓：可使用「設定 → 網路和網際網路 → Proxy」填入手動 Proxy位址與埠；開發工具亦可沿用環境變數。

請將上游埠對齊您在宿主Clash實際開放的mixed／HTTP／SOCKS埠；若您在同機混用TUN 模式與手動 Proxy，請以TUN 模式深度解析對照透明代理語意——對來賓 VM而言，本文仍以明確 Proxy為預設路徑，因為最易複製與除錯。

步驟四：Windows Defender 防火牆——放行來自 Hyper-V 網段的輸入連線

即使 Clash 已監聽且開啟 allow-lan，若Windows Defender 防火牆對公有／私人設定檔阻擋了來賓網卡／Hyper-V 網段的輸入（Inbound）TCP，VM 仍會看到連線逾時。請以精準放行為原則：只開TCP、只開您的代理埠，並盡量限制遠端 IP 範圍為Hyper-V NAT／虛擬交換器所使用的私有網段（例如您由步驟二量到的前綴），避免將埠暴露在不受信任的區網。

進階使用者可用具有系統管理員權限的 PowerShell 建立規則（下列埠請改成您的 Clash 埠；網段請改成您的VM 所在私有網段）：

New-NetFirewallRule -DisplayName "Clash inbound TCP from Hyper-V NAT (example)" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 7890 `
  -RemoteAddress 172.16.0.0/12

RemoteAddress 請依實際環境收窄或調整；若您不方便固定網段，可先採僅限私人設定檔的原則並搭配來賓網卡類型細調——重點是別忘記：輸入規則缺一角，TCP 連線就會假死。

步驟五：為何 ping 宿主會「不通」，但代理仍可／不可連

ICMP（ping）與TCP 代理連線在防火牆裡是不同規則；許多環境預設允許 ping被關閉，或NAT／進階安全性設定擋 ICMP，因此ping 不通不等於代理埠不通。除錯時請優先看TCP 連線目標埠是否開放，並對照Clash 連線日誌是否有來自來賓 VM送出連線嘗試。

若連線日誌完全沒有對應紀錄，代表問題仍在網路路徑或監聽綁定位址；若有紀錄但規則命中錯誤（例如該域名走到DIRECT而非預期節點），請回到規則順序與分流組，並可比對Clash 使用教學中的規則概念。

步驟六：選「外部交換器」時的主機 IP（與路由器同一 LAN）

若您的 VM 使用外部虛擬交換器並橋接到實體網卡，來賓 OS 會拿到與同一區網路由器相同的 DHCP／路由語境：此時預設閘道通常指向路由器，而非直接把閘道改成宿主 LAN IP；若要使用宿主 Clash，較直覺的做法仍是把代理設為區網上宿主機器的 LAN IP + 埠（並確認路由器／AP未阻擋區網橫向連線——某些訪客網路會隔離）。與NAT／預設交換器情境相比，外部交換器下的「哪個 IP 是宿主」較容易由區網列表判讀，但防火牆仍需放行來自 VM MAC／IP 的輸入 TCP。

分流規則在哪裡生效？仍在宿主 Clash

當 VM 內應用程式把流量送去<宿主 IP>:埠時，TLS／HTTP 語意會進入宿主 Windows 上的 Clash依規則集與代理組決策——這也是為什麼DNS／fake-ip若只在宿主側運作，來賓仍以連線日誌中的主機名為準來調規則。若您在宿主開TUN並期望來賓不需設 Proxy，通常牽涉路由表／轉發與進階網路設計，範疇超出本篇「埠對埠對齊」主線；若您初學或只求瀏覽器／套件管理可走代理，請優先完成本文監聽 → 防火牆 → VM 代理三重對齊。

安全與法遵提醒

開放監聽埠給虛擬網段或區網等同允許該來源的連線進入代理鏈；請只在信任的機器與環境操作，並遵守所在地法令與服務條款。本文僅說明網路對齊與除錯思路；若需查核開源授權或上游原始碼，可自行前往專案頁；一般使用者取得安裝檔仍建議優先遵循本站下載頁。

常見問題

總結來說，Hyper-V底下虛擬機要想共用Windows上的Clash，關鍵不是盲目改預設閘道，而是先把對 VM 可達的宿主 IP、代理監聽與防火牆輸入規則對齊，再用連線日誌驗證規則命中。若您尚未在主機端把客戶端跑穩，可先自本站下載頁取得對應版本，並依Windows 首次設定完成本機驗證後再接到 Hyper-V——實際上手往往比只看設定截圖更快確認節點與規則是否合用。→ 立即免費下載 Clash，開啟流暢上網新體驗。