当前位置： 首页 > news >正文

详解WSL（Hyper）网络配置

news 来源：原创 2025/6/30 11:51:11

一、前言

由于微软文档对于wsl的网络配置这里描述的不够详细，这里作者详解一下wsl的网络配置，以便后面忘记了还能查看。

二、WSL支持的网络配置

在这里插入图片描述
这张图片上显示的配置就是wsl支持的所有网络配置，它们的功能作用如下：

一、网络模式选择

1. 网络模式（wsl2.networkingMode）
模式作用适用场景
None完全禁用WSL网络功能离线开发、安全测试
Nat默认模式，通过NAT共享宿主机网络（独立子网，需手动端口转发）日常开发、容器隔离环境
Mirrored镜像模式（共享宿主机网络栈，自动端口转发）Web服务调试（如React/Node.js）
VirtioProxy基于Virtio协议的高性能代理模式（需Hyper-V支持）高吞吐场景（如大数据传输、视频流）

建议：
• 常规开发 → Mirrored（简化端口访问）
• 兼容性优先 → Nat（默认）
• 性能敏感 → VirtioProxy（需确认硬件支持）

二、防火墙与安全控制

2. Hyper-V防火墙（wsl2.firewall）

• 作用：通过Windows防火墙规则和Hyper-V专用规则过滤WSL流量。
• 启用（开）：
• 严格管控WSL与宿主机/外网的通信（需手动放行端口）。
• 适合企业环境或需高安全性的场景。
• 关闭（关）：
• 仅依赖Windows基础防火墙规则，灵活性更高。

3. 忽略的端口（wsl2.ignoredPorts）

• 条件：仅当 networkingMode=Mirrored 时生效。
• 作用：指定Linux应用可绑定但 不自动转发到Windows 的端口（如 3000,9000）。
• 用途：避免端口冲突或限制敏感服务暴露（如内部API端口）。
注：这项功能的意义是会从自动转发逻辑中排除指定端口，使其仅在 WSL 内部可用，Windows 无法通过 localhost:端口 直接访问，因为镜像模式下，WSL 与 Windows 共享网络栈，默认自动将 Linux 监听的端口映射到 Windows 的 localhost:端口，例如当 Windows 和 WSL 需要同时运行监听同一端口的服务时（如 Windows 的 IIS 占用了 80 端口，WSL 的 Nginx 也需监听 80），通过忽略该端口可防止冲突。忽略端口转发优先于端口转发优先于自动端口转发（手动配置优先于自动配置）

三、端口转发与本地访问

4. localhost转发（wsl2.localhostForwarding）

• 启用（开）：
• 允许通过 localhost:端口 直接访问WSL服务（如 http://localhost:3000）。
• 无需手动配置IP映射，适合快速调试。
• 关闭（关）：
• 需通过WSL虚拟机的独立IP访问（如 172.28.x.x:3000）。
注：Kex需要开启这个功能，因为Kex本质上是通过访问127.0.0.1的地址的端口转发进行工作的。

5. 主机地址环回（wsl2.hostAddressLoopback）

• 条件：仅当 networkingMode=Mirrored 时生效。
• 启用（开）：
• 允许WSL使用宿主机的 所有本地IP地址（如 192.168.1.x）通信，而不仅限于 127.0.0.1。
• 用途：多容器跨主机通信（如Docker集群）。
• 关闭（关）：
• 仅允许通过 127.0.0.1 访问宿主机，增强隔离性。
注：启用（开）​ ：WSL 使用宿主机任意本地 IP（如 192.168.1.100:端口） 宿主机通过任意本地 IP 访问 WSL 服务（需端口开放）
​关闭（关）​ ：WSL 仅能通过 127.0.0.1:端口 访问宿主机 宿主机仅能通过 127.0.0.1:端口 访问 WSL
例如：WSL 中运行 Docker 容器（如 192.168.1.101:8080），需与局域网内另一台物理机（192.168.1.200）上的服务通信。WSL 容器可直接通过宿主机的局域网 IP（192.168.1.100）与 192.168.1.200 通信。
宿主机上的其他设备可通过 http://192.168.1.100:8080 访问 WSL 容器服务。

四、代理与DNS优化

6. 自动代理（wsl2.autoProxy）

• 启用（开）：
• 自动同步Windows系统的HTTP代理设置到WSL（无需在Linux内配置代理）。
• 用途：企业内网或需代理上网的环境。
• 初始超时（wsl2.autoProxyTimeout）：
• 设置WSL启动时等待代理响应的超时时间（默认 1000毫秒）。
• 建议：网络延迟高时调至 2000-3000毫秒。
注：NAT 模式下的 WSL 不支持 localhost 代理。

7. DNS代理（wsl2.dnsProxy）

• 条件：仅当 networkingMode=Nat 时生效。
• 启用（开）：
• 强制WSL使用宿主机的NAT DNS服务器（与企业DNS策略一致）。
• 关闭（关）：
• 镜像复制Windows的DNS配置到WSL（可能更灵活）。

8. DNS隧道（wsl2.dnsTunnel）

• 启用（开）：
• 通过加密隧道传输DNS请求，绕过防火墙限制（如某些企业网络）。
• 副作用：可能增加解析延迟。
• 尽力DNS分析（wsl2.dnsResolveAggressively）：
• 启用（开）：尝试修复异常DNS响应（如忽略未知记录），但可能导致解析失败。
• 用途：调试非标准DNS环境。

三、交换机

首先我们先介绍一下交换机的作用：

  • 地址学习：交换机通过检查接收到的数据包中的源MAC地址，学习到连接到每个端口的设备的MAC地址，并将其存储在MAC地址表中。这样，交换机就能够知道哪个设备连接到哪个端口，以便在转发数据包时进行准确的寻址。
  • 转发/过滤：当交换机接收到一个数据包时，它会检查数据包的目的MAC地址，并在MAC地址表中查找对应的端口。如果找到匹配的端口，交换机就会将数据包转发到该端口，只让目的设备接收到数据包，从而实现了在局域网内的精准数据传输，避免了数据在整个网络中广播，减少了网络拥塞和冲突的可能性。如果目的MAC地址不在MAC地址表中，交换机通常会将数据包泛洪到除源端口之外的所有其他端口，以尝试找到目的设备。
  • 消除冲突域：交换机的每个端口都代表一个独立的冲突域。在传统的共享式网络中，多个设备连接到同一根电缆上，容易发生冲突，而交换机通过将每个端口连接的设备隔离开来，使得每个端口上的数据传输相互独立，大大减少了冲突的发生，提高了网络的传输效率和可靠性。

除此之外，一些高端交换机还可能具备VLAN（虚拟局域网）划分、QoS（Quality of Service，服务质量）管理、端口安全控制、链路聚合等功能，以满足不同用户对于网络管理、安全和性能优化等方面的需求。总的来说交换机处理的是链路层和物理层的协议。

而WSL是依赖于Hyper-V 的，所以我们需要通过Hyper-V的管理器进行配置，虚拟交换机的类型分为三种：External（外部）、Internal（内部）、Private（专用）其中 外部虚拟交换机（External Virtual Switch） 工作机制可以简化为以下三步：

1. 物理网卡虚拟化为交换机

• 物理网卡变身：
Hyper-V 将物理网卡（如以太网或 Wi-Fi 适配器）转化为 虚拟交换机。
• 物理网卡 ➔ 虚拟交换机（功能：像真实交换机一样转发数据包）。
• 物理连接保留：虚拟交换机仍通过原物理网卡的网线与外部物理交换机连接（唯一真实的物理链路）。

2. 宿主机获得新虚拟网卡

• 宿主机的新“网卡”：
为了让宿主机也能连接虚拟交换机，Hyper-V 为宿主机创建一个 新的虚拟网卡。
• 原网卡配置转移：原物理网卡的 IP 地址、网关、DNS 等设置全部迁移到新虚拟网卡。
• 物理网卡“下岗”：物理网卡此时仅作为虚拟交换机的“通道”，不再直接处理宿主机网络协议（仅负责收发原始数据）。

3. 虚拟机直连虚拟交换机

• 虚拟机接入网络：
虚拟机（或 WSL 实例）直接连接到虚拟交换机，与宿主机的新虚拟网卡处于同一网络层级。
• 通信方式：
◦ 虚拟机 ↔ 虚拟交换机 ↔ 外部物理交换机（通过物理网卡）。
◦ 宿主机 ↔ 虚拟交换机 ↔ 外部物理交换机（通过新虚拟网卡）。
• 效果：
◦ 虚拟机与宿主机共享同一物理出口，像独立设备一样获取局域网 IP（如 192.168.1.x）。
◦ 虚拟机与宿主机之间、虚拟机与外部网络之间均可直接通信。

关键总结

  1. 物理网卡 → 虚拟交换机：仅保留物理连接，不再处理协议。
  2. 宿主机 → 新虚拟网卡：继承原物理网卡的所有网络配置。
  3. 虚拟机直通外部网络：无需 NAT 或端口转发，性能更高、延迟更低。
  4. 逻辑架构图：
    [外部网络]↑↓（物理网线）
[物理交换机]↑↓（物理网卡 → 虚拟交换机）
├── [宿主机的新虚拟网卡]（IP: 192.168.1.100）
└── [虚拟机1]（IP: 192.168.1.101）
└── [虚拟机2]（IP: 192.168.1.102）

在这里虚拟机（WSL 实例）内部通过 虚拟网络适配器 处理自身的网络协议（如 IP 分配、TCP/UDP 传输），因此虚拟机无需虚拟网卡。

在这里插入图片描述
在这张图里，虚拟交换机都用vEthernet标识出来了，按照从左向右，从上到下的顺序第一个是Hyper-V创建的默认虚拟交换机（Hyper-V Virtual Ethernet Adapter），第二个（Hyper-V Virtual Ethernet Container Adapter）是Hyper-V 在 Windows Server 或 Windows 10 中为 Windows 容器 自动创建的虚拟网络适配器（下一节进行介绍），用于实现容器与宿主机、外部网络或其他容器之间的通信，第三个（Hyper-V Virtual Ethernet Adapter #2）是WSL创建的虚拟交换机，第四个（Hyper-V Virtual Ethernet Adapter #3）也是WSL创建的虚拟交换机，我们可以选择将哪个虚拟交换机（负责连接宿主机和WSL实例）作为连接原物理网卡（负责连接外部网络）的虚拟交换机，同时我们查看WLAN的属性，你会发现下图的情景：
在这里插入图片描述
WLAN已经成为了网桥的一部分，那么什么是网桥呢，你可以理解为是只有两个端口的交换机（连接两个独立的局域网），或者称交换机为多端口网桥。网桥的这一个端口连接的就是Hyper-V Virtual Ethernet Adapter这类整体的虚拟交换机，而另一端口与外部网线或者无线网络进行连接，通过下面的属性图也能看到，此时将原来物理网卡上的网络协议配置转移到了该虚拟网卡，这个网桥是没有网络协议配置的（处理网络层及以上协议的配置）：
在这里插入图片描述
而Hyper-V Virtual Ethernet Adapter是具备处理网络层及以上协议的功能的：
在这里插入图片描述

四、Hyper-V

上一节我们提到了Hyper-V 在 Windows Server 或 Windows 10 中为 Windows 容器 自动创建的虚拟网络适配器，为了理解这个东西我们要讲解一下什么是Hyper-V。
Hyper-V 是 Type 1 虚拟机管理程序（直接运行在物理硬件上的底层虚拟化层），而非依赖宿主机操作系统。开启 Hyper-V 后，Hypervisor 会直接接管 CPU、内存、存储等硬件资源，实现对物理资源的虚拟化。
而宿主机（如 Windows 10/Server）作为 特权分区（父分区）运行在 Hypervisor 之上，负责管理 Hyper-V 服务和用户交互。虚拟机（如 Linux、Windows Server）作为 非特权分区（子分区）运行在 Hypervisor 隔离的环境中，与宿主机共享硬件资源但互不干扰。
总的来说开启Hyper-V后，物理层上面的就不再是操作系统了，而是这个Hyper-V，整个操作系统都跑在了Hyper-V的上面。基于此衍生出了Hyper-V 容器，这个功能 是 Microsoft 基于 Hyper-V 虚拟化技术推出的容器化解决方案，旨在为 Windows 环境提供高效、安全的轻量级应用部署与隔离能力。每个 Hyper-V 容器运行在独立的 轻量级虚拟机 中，通过 Hyper-V 虚拟化层实现硬件资源（CPU、内存、存储）的强隔离，比传统的容器隔离方式（共享宿主机内核）更安全。
Windows 容器提供两种不同的运行时隔离模式：process 和 Hyper-V 隔离（上面说的Hyper-V 容器）。 在两种隔离模式下运行的容器创建、管理和运行方式相同。 它们还会生成和使用相同的容器映像。 隔离模式之间的区别在于容器、主机操作系统和在该主机上运行的其他所有容器之间的隔离程度。
下面来自微软文档：
进程隔离（process），这是容器的“传统”隔离模式，进程隔离技术允许多个容器实例在给定的主机上并发运行，隔离通过命名空间、资源控制和其他进程隔离技术来实现。 在此模式下运行时，容器与主机及彼此共享同一个内核。 这与 Linux 容器的运行方式大致相同。
在这里插入图片描述
Hyper-V 隔离模式提供了主机和容器版本之间的增强安全性和更广泛的兼容性。 通过 Hyper-V 隔离，多个容器实例在主机上并发运行;但是，每个容器在高度优化的虚拟机内部运行，并有效地获取其自己的内核。 虚拟机的存在提供每个容器和容器主机之间的硬件级隔离。
在这里插入图片描述

五、应用

那么Hyper-V的虚拟交换机类型与WSL设置中的网络模式有什么关系呢，这里我们通过一个问题引出：如果将wsl的虚拟交换机改成External但是wsl本身是设置成NAT连接的会发生什么？
答案是：会发生IP地址冲突和路由混乱，也就是如下的情况，解析到了IP地址但却无法找到主机的路由：
在这里插入图片描述
下面是具体解释：

冲突表现

  1. IP地址分配混乱
    • NAT模式依赖：
    NAT模式下，WSL通过虚拟子网（如 172.28.0.0/20）获取IP，由宿主机进行地址转换。
    • External交换机特性：
    External交换机要求WSL直接绑定物理网络适配器，从物理网络（如 192.168.1.0/24）获取IP。
    • 结果：
    WSL可能同时从两个子网获取IP，导致路由表冲突，无法确定默认网关，最终 无法访问任何网络。

  2. 流量路由冲突
    • NAT流量：通过宿主机虚拟网卡（vEthernet (WSL)）转发。
    • External流量：直接通过物理网卡（如以太网或Wi-Fi）发送。
    • 结果：
    出站流量可能在虚拟网卡和物理网卡之间反复跳转，触发 “No route to host” 或 “Connection timed out” 错误。

  3. 防火墙规则失效
    • Hyper-V防火墙（图中已启用）默认针对 Internal 交换机设计，若切换为 External，原有规则可能无法适配物理网络环境。
    • 结果：
    宿主机或企业防火墙可能拦截未经NAT转换的直连流量，导致 80/443端口被阻断。

根本原因

• 模式不兼容：
NAT 是 网络地址转换协议，依赖虚拟子网；External 是 物理网络桥接模式，两者设计目标冲突，无法共存。
• WSL限制：
WSL 2 的默认网络模式为 NAT，若强制绑定到 External 交换机，需显式禁用NAT并配置为 桥接模式（bridged），否则配置无效。

从中我们得知，External交换机应该与桥接模式（镜像模式）进行绑定，而NAT应该与Internal模式进行绑定

六、总结

一切都因为更新WSL之后Kex不能用了才引起的这次记录，真是bug使人进步啊。

相关文章：

  • MediaPipe框架解析(二)：mediapipe helloworld
  • 进阶向:Django入门,从零开始构建一个Web应用
  • GAN的思考及应用
  • SCAU期末笔记 - 操作系统 英文定义题
  • ShanghaiCity上海，又解锁一塔2025.06
  • PYTHON从入门到实践9-类和实例
  • LeetCode 第80题 删除有序数组中的重复项Ⅱ
  • Modbus 报文结构与 CRC 校验实战指南（二）
  • 学生宿舍智能控电技术的新发展和控制要求
  • 矩阵及矩阵快速幂
  • Kafka4.0初体验
  • [Linux入门] Linux LVM与磁盘配额入门指南
  • 项目目标不一致时，如何校准方向
  • watch、watchEffect和computed函数的区别
  • 【模型部署】如何在Linux中通过脚本文件部署模型
  • Prompt Depth Anything：以提示方式驱动的Depth Anything用于实现4K分辨率下的精确米制深度估计
  • RabbitMQ中，basicAck、basicNack和basicReject是三种核心的消息确认机制
  • 网络安全碎碎恋
  • Elasticsearch 集群升级实战指引—7.x 升级到 8.x
  • SRS流媒体服务器之本地测试rtc推流bug