1 先纠正一个误区：默认网关不等于「已经过 Clash」
在 Hyper-V 最常见的默认交换机（Default Switch）场景里，虚拟机拿到的默认网关通常就是宿主机在那一小段 NAT 网络上的接口地址。它的职责是：把虚拟机发出的 IP 包做地址转换，再送到物理网卡出去。换句话说，你「本来就有网关」，而且往往已经指向宿主机侧负责 NAT 的那一侧。
但 Clash 或 Mihomo 在宿主机上监听的是应用层代理端口（混合端口、HTTP 端口或 SOCKS），并不会因为你「ping 得通网关」就自动把虚拟机的 HTTP/TLS 流量改写成分流策略。宿主机的 TUN 模式主要接管宿主机本机的转发路径；虚拟机作为另一台独立客户机，其流量默认仍按虚拟机自己的路由表走 NAT 出口，除非你在虚拟机内显式配置代理，或在宿主机上做更复杂的转发与策略路由（这已经超出普通「装个客户端就想全家桶走节点」的范畴）。
因此，搜索「Hyper-V 改网关 走 Clash」时，要先问自己：你要的是浏览器和认系统代理的应用稳定出国，还是虚拟机里每一个 IP 包都强制经过某台上游？前者用代理/PAC 通常足够；后者在 Windows 宿主机上成本高，一般不如在虚拟机内再跑一份 Clash 或使用路由器式透明代理。
2 NAT 默认交换机与外部桥接：宿主机 IP 怎么理解
默认交换机 + NAT：虚拟机与宿主机不在你家路由器的同一网段，虚拟机拿到的是 Hyper-V 内部分配的私有地址。此时「能代表宿主机、且虚拟机可达」的 IP，通常是该 NAT 网段上的宿主机端地址，在 Windows 上常显示为名为 vEthernet (Default Switch) 或类似描述的适配器。你在虚拟机里看到的默认网关往往与它一致或同网段相邻——这是正常设计，不是故障。
外部网络桥接（External vSwitch）：虚拟机与宿主机都桥到同一块物理网卡，虚拟机可能直接拿到与路由器同网段的地址（例如 192.168.1.0/24）。这时「宿主机」在虚拟机眼里就是局域网里的另一台机器，应使用宿主机在该网段上的 IPv4 地址作为代理目标，而不是去猜 NAT 内网段。若你的 Clash 只监听 127.0.0.1，虚拟机永远连不上，必须配合下文所述的 Allow LAN 或等价「监听所有接口」设置。
若你同时使用多块网卡、Wi‑Fi 与以太网切换、或公司网络有客户端隔离，虚拟机到宿主机的直连可能被策略挡住——这时即使 IP 填对，也要在交换机与安全软件两侧一起排查。
3 在虚拟机里找到「该填进代理地址栏」的宿主机 IP
以Windows 客户机为例，可在 PowerShell 中查看默认网关，它往往就是 NAT 场景下宿主机的候选地址之一（请以你机器输出为准）：
Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric | Select-Object -First 1 NextHop
在Linux 客户机上，可类比使用 ip route 查看默认路由下一跳。桥接模式下，更直接的做法是在宿主机上执行 ipconfig（或「设置 → 网络」），读出当前正在上网的那块网卡的 IPv4，再在虚拟机里 ping 或 curl 探测该地址的代理端口是否开放。
务必区分：127.0.0.1 在虚拟机内部永远指向虚拟机自己，不是宿主机。除非你做端口转发或特殊网络拓扑，否则不要把代理写成 127.0.0.1:7890 还抱怨「宿主 Clash 已经开了」。这一点与 WSL2 里常见踩坑是同一逻辑，本站《WSL2 下 Ubuntu 走 Windows Clash》一文也可以对照阅读。
4 宿主机 Clash / Mihomo：端口、Allow LAN 与防火墙
在动虚拟机之前，请先在宿主机客户端确认三件事，否则后面怎么改网关都徒劳。
- 混合端口或 HTTP 入站端口：记下实际数字（例如界面中的
7890，以你客户端为准），虚拟机里填写的协议要与该入站类型一致（HTTP 代理填http://IP:端口；若单独启用 SOCKS，再使用socks5://）。 - Allow LAN / 允许局域网连接：开启后，进程通常监听
0.0.0.0:端口，虚拟机网段才能连入。若仅监听环回地址，局域网与 Hyper-V NAT 另一侧都会被拒绝。 - Windows Defender 防火墙：对「专用网络」放行你的 Clash 主程序与内核进程；若入站仍被拒绝，可参考《Windows 11 防火墙放行 Clash》中的思路做最小放行（仅在可信网络环境下操作）。
若宿主机主要依赖系统代理开关让本机浏览器跟随，请记住：虚拟机的「系统」是另一套注册表与 WinHTTP 配置，不会继承宿主机的 PAC 或手动代理设置，必须到虚拟机内重复配置或使用组策略/脚本下发。
5 配法一（推荐优先尝试）：虚拟机内系统代理与浏览器
适用场景：你需要 Edge、Chrome、依赖 WinINET 的客户端、以及部分遵循环境变量的开发工具稳定走节点；不要求虚拟机里每一个后台进程都强制翻墙。
在 Windows 虚拟机中，打开「设置 → 网络和 Internet → 代理」，选择手动设置，地址填上一节得到的宿主机 IP，端口填 Clash 的 HTTP/混合入站端口。若使用 PAC 文件，可把代理规则指向同一宿主机上的 HTTP 端口（具体 PAC 语法略，核心是别把主机名写成 localhost）。
对仅认 WinHTTP 的工具（某些旧版 CLI、系统组件），可能还需要在提升权限的 CMD 中执行 netsh winhttp set proxy 与 Clash 文档建议的复位命令；这与《Windows UWP 与系统代理》里讨论的本机侧问题同源，只是现在「代理服务器地址」变成了宿主机 IP。
Linux 虚拟机则通常在 /etc/environment、shell 配置或桌面环境的网络代理页中填写 http_proxy / https_proxy；与 WSL 教程相同，apt 往往要单独写 Acquire::http::Proxy，不要假设环境变量能覆盖所有包管理器。
6 配法二：什么时候才需要动「默认网关」
在默认交换机 NAT 下，随意把网关改成别的地址很容易直接把虚拟机断网：要么不再指向正确的 NAT 出口，要么指向一台并不会为你做转发的机器。除非你明确知道下一跳设备会替你转发（例如旁路网关、路由器透明代理），否则不要把「改网关」当成首选按钮。
若你的目标是「虚拟机所有 TCP 连接都经过宿主机上某服务」，常见工程化做法反而是：在宿主机启用路由与远程访问、配置 NAT/ICS，或在虚拟机里单独安装 Clash 系客户端，让它本机接管 TUN。这与消费级「宿主机开一个 Clash 就想 Hyper-V 全自动分流」的想象有距离，却是网络分层上更干净的做法。
桥接模式下，若你把虚拟机网关改成局域网内一台真正的路由器地址，那是正常的上网方式，但依然不保证流量经过 Clash——除非那台路由器本身做了透明代理，或你在虚拟机内使用代理。简言之：网关解决「包往哪送」，Clash 端口解决「HTTP/SOCKS 由谁做策略」，两件事可以相关，但绝不是同一个开关。
7 验证步骤与常见失败原因清单
建议按顺序做，避免同时修改多处后无法归因。
- 在虚拟机内 ping 宿主机候选 IP（若环境禁 ICMP，可跳过）。
- 在虚拟机 PowerShell 或 Linux 终端执行
curl -v，显式指定--proxy http://HOST:PORT访问一个测试 URL，确认 TCP 与 TLS 是否成功。 - 打开宿主机 Clash 日志，观察是否有来自虚拟机网段的入站记录；若无，仍是监听地址、防火墙或 Allow LAN 问题。
- 对照规则集，确认测试域名没有被错误直连或 REJECT；DNS 异常时可结合《DNS 防泄漏》思路检查虚拟机侧解析是否绕开预期。
高频原因包括：未开 Allow LAN；端口号抄成 SOCKS 却用 HTTP 协议连接；宿主机 IP 变更后虚拟机仍写死旧值；公司 Wi‑Fi 客户端隔离导致虚拟机无法访问宿主机；以及仅设置了浏览器插件代理、系统其他组件仍直连。
8 和 WSL2 并列看：虚拟化场景下的共同口诀
WSL2 与 Hyper-V 客户机都是「宿主机里还有一套网络栈」的典型场景：127.0.0.1 永远指错对象；Allow LAN 是跨网段访问 Clash 的前置条件；系统代理与包管理器/WinHTTP 要分开配置。你已经搞定 WSL 的话，把「宿主机 IP + 端口」这条线原样映射到 Hyper-V 虚拟机即可；尚未安装 Windows 客户端的用户可先完成《Clash Verge Rev Windows 安装》再继续。
9 总结
Hyper-V 虚拟机要走宿主机上的 Clash，核心不是「有没有网关」，而是虚拟机能否访问宿主机上对外监听的代理端口，以及你选择在应用层（系统代理、环境变量、浏览器）解决，还是愿意承担路由层改造的成本。默认交换机 NAT 下，默认网关往往已经指向宿主机侧的 NAT 角色；此时再乱改网关，不如先开 Allow LAN、放行防火墙，在虚拟机里把代理地址写成可达的宿主机 IP。
桥接模式下，把宿主机当作局域网内的一台普通机器看待，使用其在物理网段上的地址即可；协议与端口仍要与客户端配置一致。把这两类拓扑分清楚之后，排查会快很多。
相比在虚拟机里反复试错路由表，一款在 Windows 上日志清晰、端口与局域网开关一目了然的 Clash 系客户端，能显著降低「到底连没连上宿主机」的不确定性；在规则与 DNS 已经理顺的前提下，桌面与虚拟机之间的协同也会更省心。
相比其他同类工具，Clash 系在规则可读性、社区文档与 Mihomo 内核演进上的综合体验仍然更均衡；把宿主机监听与 Hyper-V 客户机的代理地址对齐之后，日常在虚拟机里浏览与开发会顺畅很多。
