Hyper-V 虚拟机想用 Windows 宿主机 Clash：NAT、网关与防火墙放行分步设置（2026）

读完本文你能独立完成什么

你可以按顺序完成三件事：一是在宿主机上用 Hyper-V 自带的虚拟交换机与 ipconfig，读出该 NAT 拓扑下宿主在虚拟机侧可达的那个 IPv4（常落在 vEthernet (默认交换机) 或你给交换机起的名字对应的适配器上），而不是盲目填物理网卡的地址。二是对照 Clash 侧是否开启了允许局域网连接与正确的 mixed／HTTP 监听端口，并确认虚拟机内应用指向的是宿主可达地址:端口，必要时区分「仅系统代理勾选」与「虚拟机内应用是否读系统代理」。三是对 Windows 防火墙 做有针对性的放行或诊断：来自 Hyper-V NAT 前缀的入站 TCP到你声明的端口、以及 ICMP 被阻拦时如何避免误判为「虚拟机坏了」。最后你能用虚拟机内的 curl／资源监视器分层验收：NAT链路与宿主分流是否正常配合。

为什么 Hyper-V NAT 虚拟机里填 127.0.0.1 往往会失败

在虚拟机操作系统里，127.0.0.1 永远指向虚拟机自己的环回接口，而不会穿透到 Windows 宿主机上监听 Clash 的那个进程——这与 WSL2 里不要把 127.0.0.1 当成 Windows Clash 的地址是同源问题，只是 Hyper-V 的常见拓扑改成了「Hyper-V NAT 虚拟网 ↔ 宿主虚拟适配器」，而不是 WSL 的 NAT。若你希望宿主 Clash 作为 HTTP／SOCKS 上游，虚拟机内必须填写宿主在该虚拟网络上的 IPv4，再配合正确的端口。NAT模式下虚拟机会通过 DHCP 获得地址，默认网关一般指向宿主在该段上的接口或微软 NAT 分配的网关语义；请以你机器实际的 路由表与 Hyper-V 交换机类型为准逐项核对，而不要抄网上泛化的某一个固定网段。

第一步：厘清虚拟交换机类型与「我该看哪一块网卡」

在「Hyper‑V 虚拟机」这个大类里，网络体验差异首先来自虚拟交换机：外部交换机让虚拟机像是直接接到物理 LAN，其默认网关往往与宿主机一样指向家用路由器；内部／专用交换机则更像隔离实验网，需要你自己规划地址与转发；而 Windows 10／11 常见的默认交换机（Default Switch）走NAT，虚拟机获得私网地址，经宿主对外访问。你若是「家用 PC 开一个 Win／Linux VM 随手上网」，大多数情况下落在NAT／默认交换机这一路，这时的关键不是再给虚拟机写一条「看起来像物理局域网」的假网关，而是要能在宿主上明确看到：哪一张 vEthernet 对应这段 NAT，那张卡上的 IPv4 才是虚拟机里去配置代理或连通性探测时最常用的「HOST_IP」候选之一。

若你为测试改为外部交换机，虚拟机拿到的地址与宿主可能在同一以太网广播域，浏览器或系统代理同样可以指向宿主在 LAN 上的地址，但整体放行思路更像我们在手机共用电脑代理一文里强调的：仍然需要 allow-lan 一类能力与防火墙入站策略，只是「源前缀」从你的手机变成了另一台虚拟机。本文以下步骤以NAT与「虚拟机要主动连宿主监听端口」为主轴；若你为虚拟机桥到物理网并让虚拟机直接把默认网关设为路由器，宿主 Clash 未必还是流量必经之路上的一环，需要先想清楚你想让宿主 Clash 扮演「透明分流中心」还是仅作「可被调用的上游代理」。

第二步：在宿主机读出 Hyper-V 侧的 IPv4 与 Clash 监听方式

在 Windows宿主上以管理员或可观察网络细节的账号打开终端，执行 ipconfig /all，逐项定位名称里含 vEthernet、或为 Hyper‑V 交换机标明的那几块虚拟以太网适配器。把其中与你的 VM 所使用的虚拟交换机名称一致的那一条下面的 IPv4 地址记录下来，暂定记为 HOST_NAT_IP。若同屏出现多块 vEthernet（例如同时还有 WSL、Docker Desktop），务必用虚拟交换机管理层对照：虚拟机连的是哪一个，避免把 Docker 宿主桥或错了对象。

随后回到 Clash 系客户端：mihomo／Clash 核心层需要确认等价于mixed-port／HTTP监听是否绑定在可接受来自非公网监听范围的地址语义上——GUI 常说「仅限本机」与「允许局域网／Allow LAN」，本质是在告诉你：若仅监听127.0.0.1或拒绝 LAN，那么即便是虚拟机通过NAT访问宿主，也会因为并不是「宿主的环回客户端」而无法连上。NAT场景要让虚拟机连通，往往需要开启allow-lan并让端口在宿主侧可被该虚拟网段的私有地址访问。你若刚接触 Windows Clash GUI，可先对照站内Clash Verge 首次安装与系统代理一页，弄清「监听地址／系统代理／TUN」分别影响谁——否则容易在宿主浏览器正常、虚拟机里却始终「端口拒绝连接」之间反复无解。

第三步：虚拟机内配置系统代理还是应用代理

当宿主 Clash已对 HOST_NAT_IP 与mixed／HTTP 端口（例如常见 7890，以你客户端实际显示为准）开放服务时，虚拟机内你有两条常见宿主代理用法：

• 只做应用级：在浏览器／终端里手写 http_proxy／HTTPS_PROXY 或使用某 GUI 工具的独立代理字段，填入 http://HOST_NAT_IP:7890（具体 scheme 以前端显示的 mixed／HTTP为准）。优点是对系统其它流量影响小；缺点是每个应用要记得分别配置。
• 尝试系统代理：在 Linux 虚拟机用桌面环境自带的「网络‑代理」，在 Windows 虚拟机用Internet 选项或新版「代理」面板，全局指向同一地址。但并非所有运行时都读取系统代理；有些仍需单独环境变量。配合宿主 Clash的分流时，要确保你理解虚拟机里产生的连接在宿主侧日志里呈现的源地址与DOMAIN／GEOIP判定是否仍符合直觉。

若你还在同一台宿主上跑着 Docker Desktop 之类的另一层虚拟虚拟机语义，宿主与虚拟机之间谁负责 DNS、宿主 fake‑ip 与虚拟机内解析是否一致，会引入额外变量；可把Docker Desktop 与 Clash一文中「谁是 DNS／谁出外网」的梳理当作并行参考，但仍然以 Hyper‑V 那一段 vEthernet／NAT事实为准逐项验证。

第四步：Windows 防火墙放行（入站从哪里来、到哪里去）

即使 Clash 已监听在宿主「正确接口」上的某个 TCP 端口，Windows Defender 防火墙也可能默认拒绝来自网络（甚至专用配置文件里来自虚拟网）的入站。典型现象是虚拟机里 telnet／Test-NetConnection／curl 报超时或立即失败，而宿主本机curl 127.0.0.1:端口却没问题——这就是强烈的防火墙侧信号，而不是虚拟机「配置错一行」这么简单。

实践上建议使用「高级安全性」控制台为TCP目标端口（你的 mixed／HTTP宿主代理端口）增加一条入站允许规则，适用范围尽量收紧到：来源为 Hyper‑V NAT 那一段常见RFC1918 私网前缀（以你虚拟机实际拿到的为准），而不是对全世界开放。若你希望长期维护更清晰，可把规则命名为可检索的短语，比如在注释里写明「Hyper‑V → Clash mixed」。同时要留意：NAT下的虚拟机对 ICMP 回声请求有时会被宿主或虚拟机自身策略拦住，因此ping 宿主 IP 不通并不等于 HTTP 端口一定不通——更可靠的是TCP 连通性探测或直接 HTTPS 请求对照。

第五步：常见问题与对照排查清单

Ping 通与不通：ping 仅能证明 ICMP链路策略，不能替代对代理端口的证明。宿主若关闭 ICMP 回声回应，虚拟机「ping 不通」也完全可能依然能翻墙访问网页。

宿主浏览器正常、虚拟机里仍直连或被挡：先确认宿主 Clash的连接日志是否在宿主侧看见来自虚拟机网段的源 IP；若压根没有，则说明 TCP 没到 Clash监听层，往回查NAT／防火墙／端口。若已经进入 Clash但未命中预期规则，才回到分流、DNS与用户规则顺序那一层——可参考站内使用教程与 GEOIP／域名类文章做针对性调整而不要一上来就换掉整个订阅宿主代理。

想「虚拟机内局域网互访不受影响，仅出国走宿主」：这本质是路由与规则设计问题：要么在虚拟机内拆分no_proxy／直连段，要么宿主Clash侧对 RFC1918 做 DIRECT 置前。NAT本身并不替你自动完成「境内外分流」，它只是把虚拟机流量接到宿主可用的外网宿主代理出口。分流策略仍须你在宿主或虚拟机两侧明确约定。

公司域控或第三方安全套件：有些环境会重写虚拟网卡的策略或注入过滤驱动，表现形式与Windows 防火墙类似：`ipconfig` 看起来正常，虚拟机侧却偶发收到 RST。此类问题往往需要与企业 IT 的网络边界策略对齐，而不是仅靠客户端菜单能完全覆盖。本文为个人设备上的典型NAT排错，不讨论任何违规规避。

与 VMware／VirtualBox「桥接到物理网」时的差异（一句话）

若虚拟机使用桥接而与手机、智能电视处在同一段局域网，宿主代理的可达地址往往是你物理以太网／Wi‑Fi在路由器 DHCP 池里的那一个 IPv4，思路与上文「读 vEthernet／NAT」不同，但整体仍要满足：allow-lan、正确的监听、以及防火墙对那一段源地址的放行。你可以把虚拟机当作「又一台局域网设备」，与手机共用电脑代理一文的对照心智模型一致。NAT（默认交换机）则一定要先认准默认网关与Hyper‑V虚拟适配器那一段再填地址。

建议在虚拟机内做的验收命令（示意）

以下占位示例中的端口请替换为你的 mixed／HTTP宿主代理端口：宿主侧同时打开 Clash 连接日志更方便对照。

# Guest Linux examples — replace HOST_NAT_IP and 7890 with your values
curl -svo /dev/null --connect-timeout 5 http://HOST_NAT_IP:7890 2>&1 | head

# nc if available — expect "succeeded" or similar when port is reachable
nc -vz HOST_NAT_IP 7890

在 Windows虚拟机可用 PowerShell：Test-NetConnection -ComputerName HOST_NAT_IP -Port 7890。若 TCP 失败而宿主本机访问同一端口成功，优先回到allow-lan与防火墙入站，不要立刻怀疑虚拟机系统本身「坏了」。

小结

Hyper-V 下想让虚拟机复用Windows 宿主机代理，核心顺序是：先按虚拟交换机类型选定「该读哪块 vEthernet」与默认网关语义，再让 Clash 在NAT可达的地址上监听并开启允许局域网，最后用Windows 防火墙对来自Hyper-V私网前缀的入站做收紧放行，并用 TCP／HTTPS 验收替代单纯ping。与 WSL2、手机 LAN、Docker Desktop 等场景相比，整机虚拟机更强调「地址到底填宿主的哪一张卡」与分流在宿主日志里是否被命中。

若你尚未在宿主上把 Clash 跑通，建议先完成系统代理与端口的基础配置，再回到本文对接虚拟机。相比论坛碎片帖，从本站下载页获取安装包并配合使用教程建立固定排错顺序，长期成本更低。规则型代理在可观测性与分流精度上仍具优势；当你需要在Hyper-V里稳定走宿主 Clash时，按本文对齐NAT、网关与防火墙，能明显减少「端口明明开了却完全连不上」的困惑。→ 立即免费下载 Clash，开启流畅上网新体验。