1 預設閘道與系統代理：先釐清「誰在轉送封包」
預設閘道（default gateway）決定訪客機要把「目標不在區網內」的 IP 封包先丟給哪一台。在 Hyper-V 的內建 NAT／預設交換器情境裡，訪客機拿到的閘道通常本來就是宿主機在虛擬區網上的介面位址：您的對外流量已經由 Windows 做網路位址轉譯後出去。這不代表瀏覽器或 winget 會自動走 Clash，因為 Clash 的系統代理是應用程式讀取 WinHTTP／系統 Proxy 設定後，把流量送到本機的 mixed-port；它與「IP 層預設路由」是兩套機制。
因此，若您只在宿主機開了 Clash 的系統代理，訪客機內的程式不會自動繼承那份設定。您要嘛在訪客機作業系統內再設一次代理（指到宿主機 IP 與埠），要嘛改走「讓宿主機以 TUN 等方式統一攔截離開宿主機的封包」這類較進階、與路由表與防火牆綁得更緊的路徑。許多教學把「把閘道指到宿主機」講得太簡略，實務上在預設 NAT 下閘道往往已經是宿主機；真正缺的是應用層代理位址或宿主機側的透明轉送策略。先把這句話記住，後面兩種配法就不會混在一起。
2 Hyper-V 交換器：NAT 與外部／橋接式網路怎麼影響「宿主機 IP」
內部／預設交換器＋NAT：訪客機位於一個與實體區網隔開的虛擬網段，對外由宿主機轉送。此時在訪客機執行 ipconfig（Windows）或 ip route（Linux），所看到的預設閘道就是宿主機在該虛擬網路上的位址——這台位址也是您設定 http://宿主機IP:埠 時最常填的目標，前提是宿主機上的 Clash 有開 Allow LAN 且防火牆放行。
外部交換器（External virtual switch）：訪客機的網路卡等同直接橋接到實體區網，取得的 IP 往往與路由器、其他電腦同一網段。此時「宿主機」在訪客機眼中，就是區網裡的另一台機器：請在宿主機上查實體或橋接介面的 IPv4（同樣可用 ipconfig），把代理指到那個區網位址。好處是 IP 規則直覺、與實機一致；壞處是訪客機暴露在區網路由政策與公司 802.1X 等環境變數下，需自行評估資安與相容性。
/etc/resolv.conf 裡的 nameserver 對應宿主機 IP。Hyper-V 訪客機則多半直接看預設閘道或區網鄰居即可。若您兩邊都用，可一併參考站內WSL2 與 Windows Clash一文，避免混用指令。
3 實務上如何取得「訪客機連得過去」的宿主機位址
在 Windows 訪客機：開啟命令提示字元或 PowerShell，執行 ipconfig /all，檢視預設閘道那一欄的 IPv4。若您使用預設的 NAT 交換器，該位址通常就是宿主機在虛擬區網上的介面，可作為代理主機名。若您使用外部交換器，請改到宿主機本機查「連到同一區網」的介面位址，並確認訪客機與該位址之間沒有被客體防火牆擋掉連入埠。
在 Linux 訪客機：使用 ip route show default 查看 via 後面的閘道 IP，與 Windows 訪客機同理。若您同時有多張虛擬網卡，請以實際對外連線所走的那張為準。取得 IP 後，請將 Clash 的 mixed-port（常見如 7890，以您的設定為準）串成 http://閘道IP:7890 或對應的 socks5:// 形式，供下一節使用。
ipconfig | findstr /i "Gateway"4 宿主機 Clash：務必開啟 Allow LAN 並確認監聽範圍
訪客機連到的是「區網上的宿主機 IP」，不是訪客機自己迴圈位址上的 127.0.0.1。因此宿主機上的 Clash 必須允許非本機介面連入，也就是圖形介面中的 Allow LAN（或設定檔中等價選項），且實際監聽應涵蓋您要連的介面。若僅監聽 127.0.0.1 又未開區網權限，訪客機會得到連線被拒或逾時，與節點品質無關。
Windows Defender 防火牆可能在首次連入時攔截；若您曾拒絕過規則，需要在「允許的應用程式」中補放行。若您同時啟用 TUN 模式，請一併對照站內防火牆與 TUN專文，避免「宿主機可上網、訪客機却連不到宿主機埠」的假性故障。尚未完成 Windows 側安裝與基礎代理設定者，建議先跟Clash Verge Rev Windows 安裝教學對齊埠號與服務模式。
5 配法一：只在訪客機設定系統代理（最直覺、與「改閘道」無衝突）
適合Windows 訪客機內主要使用瀏覽器、Microsoft Store、以及會讀取系統 Proxy 的程式。步驟概念是：在訪客機「設定 → 網路和網際網路 → Proxy」中，開啟手動 Proxy，位址填上一節取得的宿主機虛擬區網或實體區網 IP，埠填 Clash 的 HTTP／混合埠。若您的用戶端同時提供 PAC，亦可改用 PAC，但靜態位址通常最容易排查。
這條路徑不需要手動把預設閘道改成另一個陌生 IP；在 NAT 下維持原本由 Hyper-V 配好的閘道即可。若有人教您「把閘道改成宿主機」卻沒說您早已在 NAT 裡，請先對照 ipconfig，避免重複改寫導致無法連外。系統代理的局限在於：不讀系統 Proxy 的程式（部分遊戲、自架服務、純 raw socket 工具）仍會直連；若您要「訪客機內幾乎全機」一致，請往下看配法二或訪客機內另裝相容 Mihomo 核心的用戶端。
6 配法二：倚賴宿主機 TUN／整機路由（進階，與「閘道」敘事較接近）
當您希望訪客機不要逐台設代理，而是像透明閘道一樣出去，常見做法是讓離開宿主機的 IP 流量先經過 Clash 的 TUN 介面，由規則決定直連或走節點。此時訪客機在 NAT 下對外封包仍會經宿主機轉送；關鍵在於宿主機的路由與 TUN 是否把這些轉送流量一併納入策略。不同版本與驅動組合下，行為可能與「僅本機處理序」略有差異，若遇到訪客機仍直連，請優先回到配法一或在訪客機內安裝代理用戶端，較可預期。
另一種與「閘道」字面更接近、但不是本文預設情境的做法，是把訪客機接到專用內部網段，由宿主機扮演真正的路由器並做 NAT／轉送規則——這已接近軟路由或進階實驗室架構，維護成本高，企業環境還可能牴觸資安政策。對多數桌面使用者，仍建議以配法一為主、TUN 為輔，並用實際測試驗證訪客機出口 IP 是否符合預期。
7 Linux 訪客機：http_proxy、apt 與桌面環境
若訪客機為 Ubuntu、Debian 等發行版，可在 /etc/environment 或使用者 shell 設定檔內匯出 http_proxy、https_proxy、ALL_PROXY，值為 http://宿主機IP:7890（埠請替換）。apt 建議另在 /etc/apt/apt.conf.d/ 寫入 Acquire::http::Proxy，與站內 WSL2 文相同邏輯，只是 IP 來源改為 Hyper-V 閘道或區網宿主機位址。
具備桌面環境時，亦可在「系統設定 → 網路 → 網路 Proxy」填入同一組位址。若僅終端機能連、瀏覽器不行，多半是桌面工作階段未載入環境變數或瀏覽器外掛覆寫了 Proxy，請分開排查。需要純命令列測試時，可用 curl -x http://宿主機IP:7890 -I https://example.com 驗證連通性，再決定是否為 DNS 或憑證問題。
8 常見症狀與排查清單
- 訪客機瀏覽器正常、但
winget或 PowerShell 仍直連：該工具可能不讀系統 Proxy；請查官方文件是否支援 Proxy 環境變數，或暫時改用可指定 Proxy 的下載方式。 - 宿主機瀏覽器正常、訪客機全失敗：優先 ping 或
Test-NetConnection 宿主機IP -Port 7890（埠請替換），確認 Allow LAN 與防火牆，再查 IP 是否隨睡眠／VPN 變更。 - 外部交換器下偶發連不到：確認公司區網是否禁止客體對客體連線，或無線／有線 VLAN 不同；必要時改回內建 NAT 交換器做對照實驗。
- 以為要「改閘道」：先在訪客機列印目前閘道，若已是宿主機虛擬 IP，請改聚焦代理位址與埠，別在路由表上盲目新增靜態路由。
9 總結
Hyper-V 訪客機要走宿主機上的 Clash，核心不是口頭上的「改不改閘道」四字，而是釐清：NAT 下閘道通常已是宿主機，缺的是否為應用程式看得懂的代理位址，以及宿主機是否開了 Allow LAN。多數讀者只要走配法一——在訪客機設定系統代理或環境變數、指到 宿主機IP:mixed-port——就能與宿主機規則對齊。若您追求更接近透明閘道的體驗，再在宿主機研究 TUN 與路由，並以實測出口與規則命中情況為準。
相較在論壇零散複製指令，先對齊交換器類型與代理層級，長期維護成本更低。若您希望用戶端版本與本站教學一致、減少埠號與介面對不起來的摩擦，可從本站下載頁取得 Clash Verge Rev，再依 Windows 安裝、防火牆與 WSL2 等文章逐步銜接。
