折腾 WSL2 的网络是个经久不衰的话题。我在 WSL2 里跑开发环境、部署测试服务平时用的是默认 NAT 网络大多数时候都挺顺但在多网卡笔记本、内网联调、虚拟机共存的环境里经常出现“Windows 上好好的进了 WSL2 就访问不通”的奇怪现象。折腾一圈之后我最终把 WSL2 的流量改成直接走 Windows 的 TUN 虚拟网卡整套网络一下子清爽很多。这套方案的思路并不复杂Windows 侧先建立一块 TUN 虚拟网卡再把路由优先级调好WSL2 的报文经过 Windows NAT 后自然落到 TUN 网卡上由对应的网络程序统一处理。整个过程对 WSL2 内部透明不用在发行版里装任何组件也不用逐个应用配网络参数。这篇文章会把原理、配置、验证、排错完整梳理一遍给同样被 WSL2 网络折腾的人一个可以直接抄作业的版本。1. WSL2 的网络架构先搞清流量是怎么走的1.1 WSL2 本质上就是一台轻量虚拟机WSL2 和 WSL1 最大的区别是 WSL2 把 Linux 内核跑在一个由 Hyper-V 平台托管的轻量级虚拟机里。既然是虚拟机网络就一定经过虚拟交换机Windows 上会因此出现一块叫 “vEthernet (WSL)” 的网卡。打开网络连接面板ncpa.cpl就能看到它这就是整套 WSL2 网络的入口。这块网卡的地址通常落在 172.20.0.0/16 到 172.31.255.255/16 范围内具体是哪一段由系统随机分配。WSL2 内部的 eth0 会拿到同一网段的地址默认网关就是 Windows 这块 vEthernet (WSL) 网卡的地址。举个例子我机器上 WSL2 的 eth0 是 172.23.137.77Windows 侧网关是 172.23.128.1子网掩码都是 255.255.240.0。WSL2 里任何发往外部的报文第一步永远是先被送到 172.23.128.1也就是 Windows 主机。这里有一个特别关键的点Windows 会把 WSL2 的出站流量做一次 NAT。换句话说你在 WSL2 里访问外网目标服务器看到的源地址是 Windows 物理网卡的 IP而不是 WSL2 里的 172.23.x.x。理解了这个流程后面不管是改路由还是排错思路都会清晰很多。顺带提一句容易混淆的东西默认情况下 Windows 上访问 localhost:8080 能通到 WSL2 里的 8080这是虚拟交换机提供的回环映射不是完整的网络路由。它只管 Windows 到 WSL2 这个方向反向连接和跨设备访问都还得另想办法。1.2 默认 NAT 模式在哪些场景会掉链子默认 NAT 模式对大多数人来说是够用的但遇到下面几种情况就会很难受。第一种是多网卡机器。笔记本同时插着有线网卡、无线网卡还开着虚拟机网卡和热点分享时Windows 路由表会自动选择默认出口WSL2 的 NAT 流量也跟着走那条路不一定是业务上期望的网卡。比如我试过在插着 USB 有线网卡时WSL2 里的流量全部从有线口出去而无线口才是连了正确网段的那个结果就是服务时通时断。第二种是内网联调场景。WSL2 里的服务想让局域网其他设备访问默认情况下要先做端口映射还要处理 Windows 防火墙的入站规则链路一多就非常繁琐。反过来WSL2 访问局域网里的一些共享设备打印机、NAS、路由器管理页有时也会因为 NAT 转发和回包路由问题出现延迟或失败。第三种是带有准入认证或者按网卡限速的办公网络。这类网络经常对网卡做身份校验WSL2 的流量经过 NAT 后源地址变了被识别成非预期流量是常有的事。还有多发行版并存、长时间待机恢复后路由错乱等情况都会让人陷入反复排查的泥潭。1.3 TUN 方案的核心思路Windows 侧统一接管遇到上面这些问题与其在 WSL2 内部一层层配置路由、DNS、防火墙不如反过来想WSL2 的流量反正都要先到 Windows那就在 Windows 侧把它接住。TUN 虚拟网卡就是用来接住流量的工具。启用 TUN 的软件会在 Windows 上创建一块新的虚拟网卡并往系统路由表里写入路由让指定范围的流量落到这块网卡上。因为 WSL2 的流量经过 Windows NAT 后就变成了 Windows 自己的出站流量只要 TUN 路由的优先级够高这些报文就会被 TUN 网卡接管后面的处理和分发全部由对应程序完成WSL2 内部完全无感知。这样做的好处显而易见网络复杂度集中到了 Windows 这一侧WSL2 里不用装任何额外组件TCP、UDP、ICMP、DNS 查询全部在网络层被接管覆盖面比只给个别应用配网络参数完整得多。后面所有配置都围绕这个思路展开。2. TUN 虚拟网卡原理为什么它能接管所有流量2.1 TUN 和 TAP 只差一层差别却很大TUN 是内核提供的一种虚拟网络设备工作在第三层也就是 IP 报文层。物理网卡是从网线上收发电磁信号TUN 设备则是从内核路由表中接收 IP 报文然后把报文交给打开这个设备的用户态程序处理。反过来程序写入 TUN 设备的数据会变成 IP 报文再通过内核协议栈发出去。TAP 是 TUN 的兄弟工作在第二层处理的是完整的以太网帧帧头带 MAC 地址。打个比方TAP 像是一个能看到货物原始包装盒的转运站TUN 则只关心快递单上的地址信息包装盒长什么样不关它的事。绝大多数需要接管网络流量的软件都选择 TUN因为三层报文已经足够完成识别、处理和路由二层的额外开销和复杂度完全没必要。这里要澄清一个容易误解的地方TUN 本身不负责处理逻辑它只是一条通道。真正干活的是那个打开 TUN 设备的用户态程序。程序从通道里读到报文按自己的策略决定怎么处理再把处理后的报文写回通道或者从物理网卡发出。TUN 只是把内核路由和用户态程序连接起来的那座桥。2.2 Windows 里的 TUN 网卡长什么样Windows 系统本身没有原生的 TUN 设备概念所以要靠虚拟网卡驱动来实现。启用 TUN 时驱动会注册一个虚拟网卡适配器你在“网络连接”或设备管理器里能看到一个新增的以太网网卡它和普通网卡一样有 IP、子网掩码、MAC 地址和接口索引。这块网卡创建好之后负责接管的程序会做两件事给网卡配上 IP 和子网然后往路由表写路由把需要接管的流量指到这个网卡上。常见的 TUN 网卡地址会落在 198.18.0.0/15 网段这个地址段是保留地址专门用于基准测试和文档示例选它是为了尽量避免和现有局域网段冲突。在命令行里可以用 ipconfig /all 看到这块网卡的完整配置用 Get-NetAdapter 可以拿到它的状态和接口索引。接口索引ifIndex是后面配路由要用到的关键数字建议先记下来。2.3 为什么 Windows 侧接管比 WSL2 内部配置更省心先对比几种常见做法差异非常直观配置方式生效范围重启后状态维护成本覆盖完整性WSL2 内部配路由单发行版容易丢失每个发行版都要配只覆盖手动配置的网段应用内逐个配网络参数单应用取决于应用配置环境变量和配置散落不读参数的程序无法覆盖Windows 侧 TUN 路由Windows 全局需要固化设置集中在 Windows 一侧网络层强制接管全部覆盖在 WSL2 内部配路由只对当前发行版生效而且 WSL2 每次重启虚拟机、IP 变化或者发行版重建配置就可能丢失还要被 WSL 的自动化逻辑反复覆盖。给应用逐个配网络参数覆盖面又太窄总有一些程序不读这些参数。Windows 侧配路由则是一劳永逸的思路路由表是全局的WSL2、其他虚拟机、普通桌面程序共享同一套规则。TUN 方案尤其适合需要在网络层强制接管流量的场景因为它对所有程序一视同仁不存在“某个程序不配合”的问题。我个人的体会是TUN 方案把复杂度集中到 Windows 一侧排查问题时的操作面大大缩小。你要检查的无非就是三样东西虚拟网卡是否在、路由是否指向它、程序是否正常处理报文。这三样查完90% 的问题都能定位。3. 实操配置把 WSL2 流量导到 Windows TUN 网卡3.1 安装与版本检查先满足这三个条件动手之前先确认三个前置条件。第一Windows 版本不能太老。建议 Windows 10 21H2 以上或 Windows 11确保 Hyper-V 相关组件可用。在 PowerShell 里运行 wsl --version 可以查看 WSL 内核和版本信息如果提示版本过低先执行 wsl --update 更新。老版本 WSL 在后续排查中会出现各种奇奇怪怪的问题比如网卡配置不生效、UDP 丢包等。第二以管理员身份打开 PowerShell。TUN 网卡的创建、驱动的加载、系统路由表的写入全都需要管理员权限。很多人说“拉起虚拟网卡失败”第一步就卡在权限上窗口标题没带“管理员”三个字就直接输命令当然不行。提示TUN 网卡的创建、驱动的加载、系统路由表的写入全都需要管理员权限。先确认窗口是管理员身份再排查其他原因。第三准备好 TUN 虚拟网卡的驱动来源。如果你使用的网络管理类软件自带 TUN 模式安装时一般会把这套驱动一起装好启用 TUN 后网卡自动出现不需要额外操作。如果只想单独创建一块 TUN 网卡就从你使用的工具的官方支持文档里找驱动安装方式不建议去第三方网站下载驱动。3.2 确认虚拟网卡已出现两条命令搞定启用 TUN 后先确认网卡真的出现了。最快的办法是打开网络连接面板按 WinR 输入 ncpa.cpl在列表里看有没有新增的启用状态网卡记下它的名字。命令行也有更精确的方式Get-NetAdapter | Format-Table Name, InterfaceDescription, ifIndex, Status重点关注 Status 是否为 UpifIndex 是多少。TUN 网卡的名字通常带有 “TUN”、虚拟网卡厂商名或驱动名之类的字样。接着用 ipconfig /all 查看这块网卡拿到的 IP 和子网掩码。如果网卡没有出现去设备管理器里查看网络适配器看是否存在处于禁用状态或带感叹号的虚拟网卡。很多时候驱动已经装上了但网卡默认被禁用右键启用就能解决。这种情况在系统更新后特别常见。3.3 路由调整让 WSL 网段的下一跳指向 TUN网卡就绪后关键动作是调整 Windows 路由表。先打开路由表看看现状route print重点看两处默认路由 0.0.0.0/0 的接口是哪块网卡以及有没有针对 172.x.x.x 网段的特殊路由。如果默认路由已经指向 TUN 网卡说明接管程序自动把路由写好了WSL2 的流量会自然被接管什么都不用做。如果默认路由还在物理网卡上可以手动加一条针对 WSL 子网的路由。考虑到 WSL 子网分布在 172.20.0.0/16 到 172.31.0.0/16直接用聚合的 172.16.0.0/12 覆盖避免以后子网变动还要重新加。在管理员 PowerShell 里执行route add 172.16.0.0 mask 255.240.0.0 0.0.0.0 if TUN接口索引 metric 20把 TUN接口索引 换成上面记录的实际 ifIndex。等价的 PowerShell 写法是New-NetRoute -DestinationPrefix 172.16.0.0/12 -InterfaceIndex TUN接口索引 -NextHop 0.0.0.0 -RouteMetric 20这里把网关写成 0.0.0.0表示这条路由是接口直连路由不经过额外的网关地址这也是大多数 TUN 网卡的常见用法。如果 TUN 网卡有明确的虚拟网关地址就把 0.0.0.0 换成那个地址。加完路由后再跑一次 route print确认 172.16.0.0/12 这条路由存在并且接口列显示的是 TUN 网卡的 ifIndex。注意很多 TUN 程序自带路由管理逻辑手动加的路由可能被它的定时检查覆盖或删除。遇到这种冲突优先在程序界面里调整路由策略而不是反复手动加。3.4 WSL2 内部验证网关、DNS、连通性一次查清楚Windows 侧配置完成后进入 WSL2 验证。先看网络基础信息ip addr show eth0 ip route show defaulteth0 应该有一个 172.x.x.x 的地址默认网关是 Windows vEthernet (WSL) 网卡的地址。只要默认网关存在流量就会先到 Windows后面交给路由表处理。接着测试连通性。先 ping 一个局域网内已知的 IP再通过域名访问一下外部服务比如 curl 一个外网地址看返回是否正常。需要确认 DNS 的话可以查看 /etc/resolv.conf 里的 nameserver通常是指向 NAT 网关的地址。如果在 WSL2 里访问一切正常说明 TUN 接管链路已经打通。这里要提醒一个验证重点不要只看 ping 通了就收工。ping 走的是 ICMP很多接管程序对 ICMP 的处理可能和 TCP 不同。建议再用 curl 或 wget 拉一次数据确认 TCP 路径也正常同时观察速度是否异常。如果 ping 通但 TCP 不通多半是程序层面的策略问题跟路由无关。3.5 更现代的方案mirrored 模式下直接共享 Windows 网卡如果你用的是 Windows 11 22H2 及以后的版本还有一个更省心的选择让 WSL2 直接共享 Windows 的网络接口。在用户目录下创建或编辑 .wslconfig 文件写入[wsl2] networkingModemirrored然后在 PowerShell 里执行 wsl --shutdown重新进入 WSL2 生效。开启 mirrored 模式后WSL2 内部可以直接看到 Windows 的物理网卡和虚拟网卡包括 TUN 网卡。这样不仅网络路径更短localhost 的双向访问也顺滑很多TUN 网卡的管理可以完全在 Windows 侧完成WSL2 里不再有独立的 NAT 网段。这个模式也有取舍。它会改变 WSL2 的网络语义如果你依赖默认 NAT 模式下的虚拟交换机隔离能力或者使用了特别老的工具链切换到 mirrored 之后可能遇到兼容性问题。我的建议是新环境、新项目可以直接上 mirrored存量环境则先在本机验证工具兼容性再切换。4. 常见问题与排查虚拟网卡失效和断网速查表先把高频问题整理成一张速查表后面的小节再逐个展开现象可能原因优先处理方向拉起虚拟网卡失败权限不足、驱动未装、安全软件拦截管理员运行、检查驱动、加信任TUN 开启后没网MTU 不匹配、DNS 未接管、路由竞争调 MTU、手动 DNS、对比路由表安全软件提示未知协议网卡报文特征被识别为异常加信任、改兼容模式、换 mirroredWSL2 域名解析失败resolv.conf 被改写、DNS 不可达手动指定 DNS、关闭自动生成重启后路由失效临时路由被清空、程序未自启持久化路由、启动脚本补齐4.1 拉起虚拟网卡失败怎么处理“拉起虚拟网卡失败”是 TUN 方案里最常见的报错排查顺序就三步。第一步检查权限确认程序或 PowerShell 是管理员身份运行驱动注册和网卡创建没有管理员权限基本必失败。第二步检查驱动打开设备管理器查看网络适配器下有没有灰色图标或黄色感叹号的虚拟网卡有的话右键更新驱动或卸载后重新安装。第三步看安全软件部分安全软件会拦截虚拟网卡驱动的加载把这个进程或驱动加入信任名单再试。如果还是失败在事件查看器里看系统日志网络适配器相关的错误会给出更具体的原因。我之前遇到一次是系统更新后虚拟机平台功能被关闭重新开启“虚拟机平台”可选功能后问题才解决。这个检查项经常被忽略。4.2 TUN 模式开启后反而没网了网卡在、路由也在但访问全部失败这种问题一般出在三个地方。第一个是 MTU。TUN 网卡的 MTU 如果跟物理链路不匹配大包会被分片或直接丢弃表现为网页打不开、下载卡住。把 TUN 网卡的 MTU 改成 1400 或更低再测能解决相当一部分问题。第二个是 DNSTUN 接管了 TCP 但没接管 UDP 的 DNS 查询时域名解析就会失败可以先改用手动指定的 DNS 服务器验证。第三个是路由竞争TUN 网卡和物理网卡各自有默认路由时Windows 按路由优先级选择优先级低的那个网卡流量可能一直处于重传状态。用 route print 对比两条默认路由的 metric把 TUN 的优先级调高。提示排查时先在 Windows 侧验证 TUN 链路是否正常不要一开始就在 WSL2 里折腾。Windows 侧不通WSL2 一定不通。排查这类问题时建议做一个最小化验证在 Windows 侧把 TUN 网卡设为默认出口测试 Windows 自身的浏览器是否正常如果 Windows 也不通说明是 TUN 链路自身的问题和 WSL2 无关先修好 Windows 侧再说。4.3 安全软件提示虚拟网卡存在未知协议有安全软件或防火墙会扫描新出现的网卡如果发现 TUN 网卡上的报文特征不是常见的协议形态可能弹出“检测到虚拟网卡上存在未知协议可能会导致虚拟网卡被截流”之类的提示。这个提示的直接后果是 TUN 网卡被安全策略限制了WSL2 走 TUN 后频繁掉线、速度异常甚至完全不通。处理的办法有几个在安全软件里把这块虚拟网卡加入信任或排除项看看安全软件有没有针对网卡协议的兼容模式确认系统防火墙的出站入站规则没有单独拒绝这块网卡。如果安全软件是公司统一部署的改不了策略那就尽量不要走 TUN 网卡方案改用前面的 mirrored 模式让 WSL2 共用 Windows 网卡绕开虚拟网卡这个环节。4.4 WSL2 里域名解析失败现象是 ping IP 通但 ping 域名不通或者解析特别慢。首先看 /etc/resolv.conf确认 nameserver 指向的地址还能不能访问。WSL 默认会自动生成这个文件但它可能被改写成一个不可达的地址或者指向了 NAT 网关但网关不在线。如果确认 resolv.conf 的内容有问题可以在 WSL2 的 /etc/wsl.conf 里加一行 generateResolvConf false然后手动编辑 /etc/resolv.conf 填入可用的 DNS 服务器。注意 WSL2 重启后需要重新确认文件没被覆盖。在 mirrored 模式下DNS 查询默认由 Windows 侧处理这类问题会少很多。4.5 重启之后路由失效如何固化电脑重启后Windows 的临时路由会被清空TUN 程序如果没有开机自启网卡也不会自动就位。解决思路是两条让 TUN 程序开机自启同时把路由做成持久化或者自动补齐。route add 命令加 -p 参数可以把静态路由持久化但有个坑如果开机时 TUN 网卡还没创建好持久化路由指向一个不存在的接口Windows 会跳过这条路由直到网卡恢复。更可靠的做法是写一个启动脚本检测到 TUN 网卡在线后自动补齐路由。下面这个 PowerShell 脚本可以保存为 .ps1放到启动目录$tun Get-NetAdapter | Where-Object { $_.Name -like *TUN* -and $_.Status -eq Up } if ($tun) { $route Get-NetRoute -DestinationPrefix 172.16.0.0/12 -ErrorAction SilentlyContinue if (-not $route) { New-NetRoute -DestinationPrefix 172.16.0.0/12 -InterfaceIndex $tun.ifIndex -NextHop 0.0.0.0 -RouteMetric 20 } }脚本的逻辑很简单先找处于启用状态的 TUN 网卡如果网卡在但缺少 WSL 网段的路由就补上。这样即使重启只要 TUN 程序先启动路由就能自动恢复不用每次都手动敲命令。5. 几条实测下来最值得记住的经验方案跑通之后有几条经验值得单独拿出来说。第一排查顺序永远是“网卡 → 路由 → 程序”不要上来就改 WSL2 内部配置。先确认 Windows 侧 TUN 网卡存在、路由指向正确、程序日志正常再去动 WSL2。两边问题叠加的时候在单侧排查能省一半时间。第二管理员权限这条说多少遍都不为过。我见过太多在普通权限窗口里执行 route add 然后报错的场景回执里明明写着“请求的操作需要提升”很多人还是先怀疑路由语法写错了。第三验证连通性别只用 ping一定要加一个 TCP 层面的请求测试。ICMP 的处理路径有时和 TCP 不同一次 curl 成功比十次 ping 成功都更有说服力。最后分享一个小技巧如果 Windows 版本支持 mirrored 模式新环境可以直接优先考虑它配合 TUN 网卡使用更流畅。但存量项目里默认 NAT 加 TUN 路由的方案依然是兼容性最好的选择——毕竟它不改变 WSL2 的网络语义只是在 Windows 侧多了一条路径而已。两种方案各跑一遍选择适合你当前环境的那个就行。
WSL2网络优化实战：用Windows TUN虚拟网卡统一接管流量路径
折腾 WSL2 的网络是个经久不衰的话题。我在 WSL2 里跑开发环境、部署测试服务平时用的是默认 NAT 网络大多数时候都挺顺但在多网卡笔记本、内网联调、虚拟机共存的环境里经常出现“Windows 上好好的进了 WSL2 就访问不通”的奇怪现象。折腾一圈之后我最终把 WSL2 的流量改成直接走 Windows 的 TUN 虚拟网卡整套网络一下子清爽很多。这套方案的思路并不复杂Windows 侧先建立一块 TUN 虚拟网卡再把路由优先级调好WSL2 的报文经过 Windows NAT 后自然落到 TUN 网卡上由对应的网络程序统一处理。整个过程对 WSL2 内部透明不用在发行版里装任何组件也不用逐个应用配网络参数。这篇文章会把原理、配置、验证、排错完整梳理一遍给同样被 WSL2 网络折腾的人一个可以直接抄作业的版本。1. WSL2 的网络架构先搞清流量是怎么走的1.1 WSL2 本质上就是一台轻量虚拟机WSL2 和 WSL1 最大的区别是 WSL2 把 Linux 内核跑在一个由 Hyper-V 平台托管的轻量级虚拟机里。既然是虚拟机网络就一定经过虚拟交换机Windows 上会因此出现一块叫 “vEthernet (WSL)” 的网卡。打开网络连接面板ncpa.cpl就能看到它这就是整套 WSL2 网络的入口。这块网卡的地址通常落在 172.20.0.0/16 到 172.31.255.255/16 范围内具体是哪一段由系统随机分配。WSL2 内部的 eth0 会拿到同一网段的地址默认网关就是 Windows 这块 vEthernet (WSL) 网卡的地址。举个例子我机器上 WSL2 的 eth0 是 172.23.137.77Windows 侧网关是 172.23.128.1子网掩码都是 255.255.240.0。WSL2 里任何发往外部的报文第一步永远是先被送到 172.23.128.1也就是 Windows 主机。这里有一个特别关键的点Windows 会把 WSL2 的出站流量做一次 NAT。换句话说你在 WSL2 里访问外网目标服务器看到的源地址是 Windows 物理网卡的 IP而不是 WSL2 里的 172.23.x.x。理解了这个流程后面不管是改路由还是排错思路都会清晰很多。顺带提一句容易混淆的东西默认情况下 Windows 上访问 localhost:8080 能通到 WSL2 里的 8080这是虚拟交换机提供的回环映射不是完整的网络路由。它只管 Windows 到 WSL2 这个方向反向连接和跨设备访问都还得另想办法。1.2 默认 NAT 模式在哪些场景会掉链子默认 NAT 模式对大多数人来说是够用的但遇到下面几种情况就会很难受。第一种是多网卡机器。笔记本同时插着有线网卡、无线网卡还开着虚拟机网卡和热点分享时Windows 路由表会自动选择默认出口WSL2 的 NAT 流量也跟着走那条路不一定是业务上期望的网卡。比如我试过在插着 USB 有线网卡时WSL2 里的流量全部从有线口出去而无线口才是连了正确网段的那个结果就是服务时通时断。第二种是内网联调场景。WSL2 里的服务想让局域网其他设备访问默认情况下要先做端口映射还要处理 Windows 防火墙的入站规则链路一多就非常繁琐。反过来WSL2 访问局域网里的一些共享设备打印机、NAS、路由器管理页有时也会因为 NAT 转发和回包路由问题出现延迟或失败。第三种是带有准入认证或者按网卡限速的办公网络。这类网络经常对网卡做身份校验WSL2 的流量经过 NAT 后源地址变了被识别成非预期流量是常有的事。还有多发行版并存、长时间待机恢复后路由错乱等情况都会让人陷入反复排查的泥潭。1.3 TUN 方案的核心思路Windows 侧统一接管遇到上面这些问题与其在 WSL2 内部一层层配置路由、DNS、防火墙不如反过来想WSL2 的流量反正都要先到 Windows那就在 Windows 侧把它接住。TUN 虚拟网卡就是用来接住流量的工具。启用 TUN 的软件会在 Windows 上创建一块新的虚拟网卡并往系统路由表里写入路由让指定范围的流量落到这块网卡上。因为 WSL2 的流量经过 Windows NAT 后就变成了 Windows 自己的出站流量只要 TUN 路由的优先级够高这些报文就会被 TUN 网卡接管后面的处理和分发全部由对应程序完成WSL2 内部完全无感知。这样做的好处显而易见网络复杂度集中到了 Windows 这一侧WSL2 里不用装任何额外组件TCP、UDP、ICMP、DNS 查询全部在网络层被接管覆盖面比只给个别应用配网络参数完整得多。后面所有配置都围绕这个思路展开。2. TUN 虚拟网卡原理为什么它能接管所有流量2.1 TUN 和 TAP 只差一层差别却很大TUN 是内核提供的一种虚拟网络设备工作在第三层也就是 IP 报文层。物理网卡是从网线上收发电磁信号TUN 设备则是从内核路由表中接收 IP 报文然后把报文交给打开这个设备的用户态程序处理。反过来程序写入 TUN 设备的数据会变成 IP 报文再通过内核协议栈发出去。TAP 是 TUN 的兄弟工作在第二层处理的是完整的以太网帧帧头带 MAC 地址。打个比方TAP 像是一个能看到货物原始包装盒的转运站TUN 则只关心快递单上的地址信息包装盒长什么样不关它的事。绝大多数需要接管网络流量的软件都选择 TUN因为三层报文已经足够完成识别、处理和路由二层的额外开销和复杂度完全没必要。这里要澄清一个容易误解的地方TUN 本身不负责处理逻辑它只是一条通道。真正干活的是那个打开 TUN 设备的用户态程序。程序从通道里读到报文按自己的策略决定怎么处理再把处理后的报文写回通道或者从物理网卡发出。TUN 只是把内核路由和用户态程序连接起来的那座桥。2.2 Windows 里的 TUN 网卡长什么样Windows 系统本身没有原生的 TUN 设备概念所以要靠虚拟网卡驱动来实现。启用 TUN 时驱动会注册一个虚拟网卡适配器你在“网络连接”或设备管理器里能看到一个新增的以太网网卡它和普通网卡一样有 IP、子网掩码、MAC 地址和接口索引。这块网卡创建好之后负责接管的程序会做两件事给网卡配上 IP 和子网然后往路由表写路由把需要接管的流量指到这个网卡上。常见的 TUN 网卡地址会落在 198.18.0.0/15 网段这个地址段是保留地址专门用于基准测试和文档示例选它是为了尽量避免和现有局域网段冲突。在命令行里可以用 ipconfig /all 看到这块网卡的完整配置用 Get-NetAdapter 可以拿到它的状态和接口索引。接口索引ifIndex是后面配路由要用到的关键数字建议先记下来。2.3 为什么 Windows 侧接管比 WSL2 内部配置更省心先对比几种常见做法差异非常直观配置方式生效范围重启后状态维护成本覆盖完整性WSL2 内部配路由单发行版容易丢失每个发行版都要配只覆盖手动配置的网段应用内逐个配网络参数单应用取决于应用配置环境变量和配置散落不读参数的程序无法覆盖Windows 侧 TUN 路由Windows 全局需要固化设置集中在 Windows 一侧网络层强制接管全部覆盖在 WSL2 内部配路由只对当前发行版生效而且 WSL2 每次重启虚拟机、IP 变化或者发行版重建配置就可能丢失还要被 WSL 的自动化逻辑反复覆盖。给应用逐个配网络参数覆盖面又太窄总有一些程序不读这些参数。Windows 侧配路由则是一劳永逸的思路路由表是全局的WSL2、其他虚拟机、普通桌面程序共享同一套规则。TUN 方案尤其适合需要在网络层强制接管流量的场景因为它对所有程序一视同仁不存在“某个程序不配合”的问题。我个人的体会是TUN 方案把复杂度集中到 Windows 一侧排查问题时的操作面大大缩小。你要检查的无非就是三样东西虚拟网卡是否在、路由是否指向它、程序是否正常处理报文。这三样查完90% 的问题都能定位。3. 实操配置把 WSL2 流量导到 Windows TUN 网卡3.1 安装与版本检查先满足这三个条件动手之前先确认三个前置条件。第一Windows 版本不能太老。建议 Windows 10 21H2 以上或 Windows 11确保 Hyper-V 相关组件可用。在 PowerShell 里运行 wsl --version 可以查看 WSL 内核和版本信息如果提示版本过低先执行 wsl --update 更新。老版本 WSL 在后续排查中会出现各种奇奇怪怪的问题比如网卡配置不生效、UDP 丢包等。第二以管理员身份打开 PowerShell。TUN 网卡的创建、驱动的加载、系统路由表的写入全都需要管理员权限。很多人说“拉起虚拟网卡失败”第一步就卡在权限上窗口标题没带“管理员”三个字就直接输命令当然不行。提示TUN 网卡的创建、驱动的加载、系统路由表的写入全都需要管理员权限。先确认窗口是管理员身份再排查其他原因。第三准备好 TUN 虚拟网卡的驱动来源。如果你使用的网络管理类软件自带 TUN 模式安装时一般会把这套驱动一起装好启用 TUN 后网卡自动出现不需要额外操作。如果只想单独创建一块 TUN 网卡就从你使用的工具的官方支持文档里找驱动安装方式不建议去第三方网站下载驱动。3.2 确认虚拟网卡已出现两条命令搞定启用 TUN 后先确认网卡真的出现了。最快的办法是打开网络连接面板按 WinR 输入 ncpa.cpl在列表里看有没有新增的启用状态网卡记下它的名字。命令行也有更精确的方式Get-NetAdapter | Format-Table Name, InterfaceDescription, ifIndex, Status重点关注 Status 是否为 UpifIndex 是多少。TUN 网卡的名字通常带有 “TUN”、虚拟网卡厂商名或驱动名之类的字样。接着用 ipconfig /all 查看这块网卡拿到的 IP 和子网掩码。如果网卡没有出现去设备管理器里查看网络适配器看是否存在处于禁用状态或带感叹号的虚拟网卡。很多时候驱动已经装上了但网卡默认被禁用右键启用就能解决。这种情况在系统更新后特别常见。3.3 路由调整让 WSL 网段的下一跳指向 TUN网卡就绪后关键动作是调整 Windows 路由表。先打开路由表看看现状route print重点看两处默认路由 0.0.0.0/0 的接口是哪块网卡以及有没有针对 172.x.x.x 网段的特殊路由。如果默认路由已经指向 TUN 网卡说明接管程序自动把路由写好了WSL2 的流量会自然被接管什么都不用做。如果默认路由还在物理网卡上可以手动加一条针对 WSL 子网的路由。考虑到 WSL 子网分布在 172.20.0.0/16 到 172.31.0.0/16直接用聚合的 172.16.0.0/12 覆盖避免以后子网变动还要重新加。在管理员 PowerShell 里执行route add 172.16.0.0 mask 255.240.0.0 0.0.0.0 if TUN接口索引 metric 20把 TUN接口索引 换成上面记录的实际 ifIndex。等价的 PowerShell 写法是New-NetRoute -DestinationPrefix 172.16.0.0/12 -InterfaceIndex TUN接口索引 -NextHop 0.0.0.0 -RouteMetric 20这里把网关写成 0.0.0.0表示这条路由是接口直连路由不经过额外的网关地址这也是大多数 TUN 网卡的常见用法。如果 TUN 网卡有明确的虚拟网关地址就把 0.0.0.0 换成那个地址。加完路由后再跑一次 route print确认 172.16.0.0/12 这条路由存在并且接口列显示的是 TUN 网卡的 ifIndex。注意很多 TUN 程序自带路由管理逻辑手动加的路由可能被它的定时检查覆盖或删除。遇到这种冲突优先在程序界面里调整路由策略而不是反复手动加。3.4 WSL2 内部验证网关、DNS、连通性一次查清楚Windows 侧配置完成后进入 WSL2 验证。先看网络基础信息ip addr show eth0 ip route show defaulteth0 应该有一个 172.x.x.x 的地址默认网关是 Windows vEthernet (WSL) 网卡的地址。只要默认网关存在流量就会先到 Windows后面交给路由表处理。接着测试连通性。先 ping 一个局域网内已知的 IP再通过域名访问一下外部服务比如 curl 一个外网地址看返回是否正常。需要确认 DNS 的话可以查看 /etc/resolv.conf 里的 nameserver通常是指向 NAT 网关的地址。如果在 WSL2 里访问一切正常说明 TUN 接管链路已经打通。这里要提醒一个验证重点不要只看 ping 通了就收工。ping 走的是 ICMP很多接管程序对 ICMP 的处理可能和 TCP 不同。建议再用 curl 或 wget 拉一次数据确认 TCP 路径也正常同时观察速度是否异常。如果 ping 通但 TCP 不通多半是程序层面的策略问题跟路由无关。3.5 更现代的方案mirrored 模式下直接共享 Windows 网卡如果你用的是 Windows 11 22H2 及以后的版本还有一个更省心的选择让 WSL2 直接共享 Windows 的网络接口。在用户目录下创建或编辑 .wslconfig 文件写入[wsl2] networkingModemirrored然后在 PowerShell 里执行 wsl --shutdown重新进入 WSL2 生效。开启 mirrored 模式后WSL2 内部可以直接看到 Windows 的物理网卡和虚拟网卡包括 TUN 网卡。这样不仅网络路径更短localhost 的双向访问也顺滑很多TUN 网卡的管理可以完全在 Windows 侧完成WSL2 里不再有独立的 NAT 网段。这个模式也有取舍。它会改变 WSL2 的网络语义如果你依赖默认 NAT 模式下的虚拟交换机隔离能力或者使用了特别老的工具链切换到 mirrored 之后可能遇到兼容性问题。我的建议是新环境、新项目可以直接上 mirrored存量环境则先在本机验证工具兼容性再切换。4. 常见问题与排查虚拟网卡失效和断网速查表先把高频问题整理成一张速查表后面的小节再逐个展开现象可能原因优先处理方向拉起虚拟网卡失败权限不足、驱动未装、安全软件拦截管理员运行、检查驱动、加信任TUN 开启后没网MTU 不匹配、DNS 未接管、路由竞争调 MTU、手动 DNS、对比路由表安全软件提示未知协议网卡报文特征被识别为异常加信任、改兼容模式、换 mirroredWSL2 域名解析失败resolv.conf 被改写、DNS 不可达手动指定 DNS、关闭自动生成重启后路由失效临时路由被清空、程序未自启持久化路由、启动脚本补齐4.1 拉起虚拟网卡失败怎么处理“拉起虚拟网卡失败”是 TUN 方案里最常见的报错排查顺序就三步。第一步检查权限确认程序或 PowerShell 是管理员身份运行驱动注册和网卡创建没有管理员权限基本必失败。第二步检查驱动打开设备管理器查看网络适配器下有没有灰色图标或黄色感叹号的虚拟网卡有的话右键更新驱动或卸载后重新安装。第三步看安全软件部分安全软件会拦截虚拟网卡驱动的加载把这个进程或驱动加入信任名单再试。如果还是失败在事件查看器里看系统日志网络适配器相关的错误会给出更具体的原因。我之前遇到一次是系统更新后虚拟机平台功能被关闭重新开启“虚拟机平台”可选功能后问题才解决。这个检查项经常被忽略。4.2 TUN 模式开启后反而没网了网卡在、路由也在但访问全部失败这种问题一般出在三个地方。第一个是 MTU。TUN 网卡的 MTU 如果跟物理链路不匹配大包会被分片或直接丢弃表现为网页打不开、下载卡住。把 TUN 网卡的 MTU 改成 1400 或更低再测能解决相当一部分问题。第二个是 DNSTUN 接管了 TCP 但没接管 UDP 的 DNS 查询时域名解析就会失败可以先改用手动指定的 DNS 服务器验证。第三个是路由竞争TUN 网卡和物理网卡各自有默认路由时Windows 按路由优先级选择优先级低的那个网卡流量可能一直处于重传状态。用 route print 对比两条默认路由的 metric把 TUN 的优先级调高。提示排查时先在 Windows 侧验证 TUN 链路是否正常不要一开始就在 WSL2 里折腾。Windows 侧不通WSL2 一定不通。排查这类问题时建议做一个最小化验证在 Windows 侧把 TUN 网卡设为默认出口测试 Windows 自身的浏览器是否正常如果 Windows 也不通说明是 TUN 链路自身的问题和 WSL2 无关先修好 Windows 侧再说。4.3 安全软件提示虚拟网卡存在未知协议有安全软件或防火墙会扫描新出现的网卡如果发现 TUN 网卡上的报文特征不是常见的协议形态可能弹出“检测到虚拟网卡上存在未知协议可能会导致虚拟网卡被截流”之类的提示。这个提示的直接后果是 TUN 网卡被安全策略限制了WSL2 走 TUN 后频繁掉线、速度异常甚至完全不通。处理的办法有几个在安全软件里把这块虚拟网卡加入信任或排除项看看安全软件有没有针对网卡协议的兼容模式确认系统防火墙的出站入站规则没有单独拒绝这块网卡。如果安全软件是公司统一部署的改不了策略那就尽量不要走 TUN 网卡方案改用前面的 mirrored 模式让 WSL2 共用 Windows 网卡绕开虚拟网卡这个环节。4.4 WSL2 里域名解析失败现象是 ping IP 通但 ping 域名不通或者解析特别慢。首先看 /etc/resolv.conf确认 nameserver 指向的地址还能不能访问。WSL 默认会自动生成这个文件但它可能被改写成一个不可达的地址或者指向了 NAT 网关但网关不在线。如果确认 resolv.conf 的内容有问题可以在 WSL2 的 /etc/wsl.conf 里加一行 generateResolvConf false然后手动编辑 /etc/resolv.conf 填入可用的 DNS 服务器。注意 WSL2 重启后需要重新确认文件没被覆盖。在 mirrored 模式下DNS 查询默认由 Windows 侧处理这类问题会少很多。4.5 重启之后路由失效如何固化电脑重启后Windows 的临时路由会被清空TUN 程序如果没有开机自启网卡也不会自动就位。解决思路是两条让 TUN 程序开机自启同时把路由做成持久化或者自动补齐。route add 命令加 -p 参数可以把静态路由持久化但有个坑如果开机时 TUN 网卡还没创建好持久化路由指向一个不存在的接口Windows 会跳过这条路由直到网卡恢复。更可靠的做法是写一个启动脚本检测到 TUN 网卡在线后自动补齐路由。下面这个 PowerShell 脚本可以保存为 .ps1放到启动目录$tun Get-NetAdapter | Where-Object { $_.Name -like *TUN* -and $_.Status -eq Up } if ($tun) { $route Get-NetRoute -DestinationPrefix 172.16.0.0/12 -ErrorAction SilentlyContinue if (-not $route) { New-NetRoute -DestinationPrefix 172.16.0.0/12 -InterfaceIndex $tun.ifIndex -NextHop 0.0.0.0 -RouteMetric 20 } }脚本的逻辑很简单先找处于启用状态的 TUN 网卡如果网卡在但缺少 WSL 网段的路由就补上。这样即使重启只要 TUN 程序先启动路由就能自动恢复不用每次都手动敲命令。5. 几条实测下来最值得记住的经验方案跑通之后有几条经验值得单独拿出来说。第一排查顺序永远是“网卡 → 路由 → 程序”不要上来就改 WSL2 内部配置。先确认 Windows 侧 TUN 网卡存在、路由指向正确、程序日志正常再去动 WSL2。两边问题叠加的时候在单侧排查能省一半时间。第二管理员权限这条说多少遍都不为过。我见过太多在普通权限窗口里执行 route add 然后报错的场景回执里明明写着“请求的操作需要提升”很多人还是先怀疑路由语法写错了。第三验证连通性别只用 ping一定要加一个 TCP 层面的请求测试。ICMP 的处理路径有时和 TCP 不同一次 curl 成功比十次 ping 成功都更有说服力。最后分享一个小技巧如果 Windows 版本支持 mirrored 模式新环境可以直接优先考虑它配合 TUN 网卡使用更流畅。但存量项目里默认 NAT 加 TUN 路由的方案依然是兼容性最好的选择——毕竟它不改变 WSL2 的网络语义只是在 Windows 侧多了一条路径而已。两种方案各跑一遍选择适合你当前环境的那个就行。
