深度解析：OpenClash Fake-IP 模式下 Hyper-V 虚拟机 Docker 镜像拉取超时问题

摘要

在开发环境中，OpenClash（基于 OpenWrt）与 Hyper-V 是常见的组合。然而，当 OpenClash 开启 Fake-IP (TUN) 模式，且 Hyper-V 虚拟机使用默认的 Default Switch (NAT) 网络时，Docker 镜像拉取常会出现 dial tcp 198.18.x.x:443: i/o timeout 错误。

本文将从网络协议栈的角度，分析该问题的成因，并提供基于“外部虚拟交换机（External Switch）”与“网卡独占”的架构级解决方案。

---

1. 故障现象

在 Hyper-V 托管的 Linux 虚拟机（如 Rocky Linux）中执行 docker pull 命令时，操作挂起并最终报错。

环境拓扑：

• 网关： OpenWrt Router (OpenClash 运行于 Fake-IP 增强模式)
• 宿主机： Windows 10/11 Professional
• 虚拟化层： Hyper-V
• 虚拟机网络： Default Switch (NAT 模式)

错误日志：

Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp 198.18.8.165:443: i/o timeout

---

2. 根因分析 (Root Cause Analysis)

该问题的本质是 OpenClash 的 DNS 劫持机制 与 Hyper-V 的 NAT 转换机制 在链路层逻辑上发生了冲突。

2.1 神秘的 IP：198.18.0.0/15

日志中的 198.18.8.165 并非 Docker Hub 的真实 IP。根据 RFC 2544，198.18.0.0/15 被保留用于网络基准测试。但在 Clash 生态中，该网段被复用为 Fake-IP 池。

Fake-IP 工作流程：

1. 客户端发起 DNS 请求（如 registry-1.docker.io）。
2. Clash 拦截请求，立即返回一个保留 IP（如 198.18.8.165），并在内部维护一个映射表：198.18.8.165 <-> 真实 IP。
3. 客户端向 198.18.8.165 发起 TCP 连接。
4. Clash 捕获该流量，根据映射表将目标重定向到真实 IP，并进行代理转发。

2.2 链路中断点：NAT 的破坏性

问题出在第 3 步与第 4 步之间。

• Hyper-V Default Switch 强制对虚拟机流量进行 NAT（网络地址转换）。
• 当 Docker 发出目的地址为 198.18.8.165 的包时，数据包在离开宿主机物理网卡前，源 IP 被修改为宿主机的 LAN IP。
• 路由器视角： 路由器收到了来自“宿主机”的流量，目标是 198.18.8.165。
• 冲突发生： OpenClash 的 Fake-IP 映射通常依赖于源设备的上下文。由于 NAT 掩盖了真实的请求源（虚拟机），且流量经过了二次封装，Clash 无法正确匹配回话，或者该特殊网段流量在路由器的防火墙转发链（Forward Chain）中被丢弃。

结果：TCP 握手包有去无回，导致 i/o timeout。

---

3. 解决方案：架构重构

要彻底解决此问题，必须打破 NAT 带来的网络不透明性。最科学的方案是将虚拟机网络层级提升，使其在局域网中拥有独立身份。

方案 A：标准外部交换机 (External vSwitch)

原理： 创建一个桥接物理网卡的虚拟交换机。虚拟机将直接从路由器 DHCP 获取与宿主机同网段的 IP。 优点： 兼容性好，宿主机与虚拟机共享物理网卡带宽。

方案 B：物理网卡独占模式 (Exclusive Network Adapter)

推荐场景： 宿主机拥有多张网卡，且对虚拟机网络性能要求较高。 原理： 利用 Hyper-V 的特性，将一张物理网卡完全“过继”给虚拟交换机，宿主机操作系统将失去对该网卡的访问权。

配置步骤：

1. 物理连接： 确保宿主机有第二张已连接网线的物理网卡（或 USB 网卡）。
2. 创建虚拟交换机：

• 打开 Hyper-V 管理器 -> 虚拟交换机管理器。
• 新建 外部 虚拟交换机。
• 选择目标物理网卡。

3. 实施独占 (关键步骤)：

• 取消勾选：[ ] 允许管理操作系统共享此网络适配器 (Allow management operating system to share this network adapter)。
• 此操作将把物理网卡从 Windows 网络堆栈中解绑，专供虚拟交换机使用。

4. 虚拟机配置：

• 修改 Rocky Linux 虚拟机的网络适配器，指向新建的独占交换机。

---

4. 验证与收益

配置完成后，重启虚拟机网络服务或重启 VM。

1. IP 验证： 在虚拟机中执行 ip addr，应看到类似 192.168.1.x 的局域网 IP，而非 172.x.x.x 或 192.168.137.x。
2. Docker 拉取测试：

docker pull hello-world

此时，Docker 获取到的 Fake-IP (198.18.x.x) 流量将直接以虚拟机的 MAC 地址发送至路由器。OpenClash 能精准识别流量来源，正确转发至 Docker Hub。

总结

通过放弃 Hyper-V 默认的 NAT 网络，转而使用 外部交换机（特别是网卡独占模式），我们将网络拓扑扁平化。这不仅解决了 OpenClash 的 Fake-IP 穿越问题，还带来了以下副作用收益：

• 性能提升： 减少了一层 NAT 转换开销。
• 管理便利： 虚拟机在路由器中可见，可单独设置静态 IP 或流控策略。

---

附录：如果不修改网络架构的临时方案 若无法更改 Hyper-V 网络，可在 Linux 虚拟机内部强制 Docker 走 HTTP 代理，绕过 DNS 解析环节：

# /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://ROUTER_IP:7890"

注：此法治标不治本，建议优先采用网络架构调整方案。