事情是这样的。你在 WSL 里跑了个python3 -m http.server 8000想拿手机看一眼页面效果。手机连的是同一个 Wi-Fi浏览器里敲电脑的 IP 加端口。结果转圈、超时、连不上。说实话我最初遇到这个问题的反应是我的防火墙是不是有问题。排查了半天最后发现不用排查这就是默认行为。WSL2 默认跑在 NAT 网络模式下外面的人本来就不该进得来。真正让我愣住的是另一件事。我把.wslconfig里加了一行配置networkingModemirrored重启 WSL同一个服务、同一部手机、同一个 Wi-Fi。通了。那一刻我是有点怀疑人生的。服务没动端口没动电脑没动。就改了一行配置一个 8000 端口从「只有本机能访问」变成了「全屋设备都能访问」。这篇文章想聊的不是配置教程而是为什么。为什么同一个端口换个网络模式命运完全不同我自己的感受是想清楚这个问题得先回答另一个问题这个 8000 端口到底属于谁同一个端口两种命运先把现象摆出来。在 WSL 里跑同一个服务两种模式下几个方向的访问结果完全不同。访问方向NAT 模式mirrored 模式Windows 本机访问 WSLlocalhost通自动转发通天然共享WSL 访问 Windows 本机localhost不通要查主机 IP通局域网设备访问 WSL不通要手动打洞通本机用局域网 IP 访问 WSL视防火墙而定不通默认注意到没有最后一行是最反直觉的。mirrored 模式下手机能从外面连进来你自己的电脑用局域网 IP 反而连不进来。这个细节后面会专门解释先留个悬念。这张表背后的问题就是开头那个端口属于谁。要回答它得先搞清楚 WSL2 到底是个什么东西。NAT 模式端口是虚拟机的私有财产WSL2 从底层讲是一台轻量虚拟机跑在 Hyper-V 上有自己的虚拟网卡和私有 IP172.x 段。它在网络上是独立的Windows 是 WindowsWSL 是 WSL两个网络栈谁也不欠谁的。具体到端口就是两边各有各的端口空间同一个 8000 端口可以同时绑定互不打扰。这就带来一个直接后果。WSL 里绑定的 8000 端口属于虚拟机不属于 Windows。你在 Windows 上敲netstat看不到它外面的设备更看不到它。那为什么浏览器里敲localhost:8000能打开 WSL 里的服务因为微软加了一个桥。localhost 转发一个本机专用的桥2019 年 9 月Windows build 18945 引入了一个功能官方名叫localhostForwarding默认开启。它的实现很有意思我翻过 WSL 的源码大致是这样一套链路。WSL 虚拟机WindowsHyper-V socket 通道程序访问 127.0.0.1:8000wslhost 转发进程localhost relayWSL 里的服务Windows 侧的 wslhost 进程在127.0.0.1:8000上真实地监听收到连接后通过 Hyper-V socket 通道把它递给虚拟机里的 relay 进程relay 再连回虚拟机的127.0.0.1:8000。对服务来说完全透明它以为你从虚拟机内部访问它。这不是端口映射是端口搬家公司。每一路连接都被实时搬运而不是静态指过去。但这个桥有明确边界只认127.0.0.1这一个地址整个 127/8 网段都不在服务范围内社区有人拿 127.x 段做反向代理就翻过车。而且服务得监听在能被回环连接的位置实践中统一绑0.0.0.0最省事。另外如果 Windows 本机自己已经占用了这个端口桥就搭不起来了。反方向的流量要自己找门牌号WSL 里的程序想访问 Windows 上的服务这个桥不管。你只能先查 Windows 在虚拟机视角里的 IP也就是 NAT 网关。iproute show|grep-idefault|awk{ print $3}输出通常是172.x.x.1这种。每次都要查因为 IP 是动态的。这就是 NAT 模式的原生生态两个栈之间只有一条窄窄的转发通道方向还不对称。局域网访问打洞的全过程外面的设备要访问 WSL 里的服务官方给出的方案是 portproxy 打洞。netsh interface portproxy add v4tov4 listenaddress0.0.0.0 listenport8000 connectaddressWSL的IP connectport8000再配一条 Windows 防火墙入站规则放行 8000 端口。原理是让 Windows 在0.0.0.0:8000上监听收到流量后转发给虚拟机的 IP。注意此时端口的所有权仍然在虚拟机手里Windows 只是帮它打工。这个方案有三大痛点。WSL 的 IP 每次启动都会变portproxy 里写死的是旧 IP一重启就失效wsl hostname -i和wsl hostname -I输出完全不同一个给的是占位地址一个才是对外 IP写错连不上防火墙、代理、VPN 层层叠叠出问题没法定位顺着这个再往下看你会发现所有这些痛点都指向同一件事NAT 模式把端口关进了虚拟机所有「共享」的努力都是在给外墙打洞。好那镜像模式是怎么解决这个问题的。mirrored 模式把网卡搬进虚拟机2023 年WSL 2.0 预览版第一次带来了 mirrored 网络模式前提是 Windows 11 22H2 及以上。名字很直白把 Windows 的网卡镜像到 Linux 里。开启后你进 WSL 敲ip addr看到的接口和 IP 跟 Windows 完全一样Wi-Fi 的192.168.1.100WSL 这边也有。网络接口镜像了协议栈自然也就共享了。端口空间从「两份」变回「一份」。8000 端口不再是虚拟机里藏着掖着的私产它重新变成了这台电脑的端口Windows 和 WSL 抢的是同一份端口空间所以后面才有端口冲突这回事。为什么「变成这台电脑的端口」就等于「全屋设备都能访问」反着想一下就通了。局域网设备访问电脑上的任何服务走的路从来只有一条电脑的局域网 IP 加端口。你在 Windows 上起个python -m http.server 8000手机敲http://电脑IP:8000就能打开这是电脑上服务的默认待遇防火墙放行是前提但这本来就是所有局域网访问的统一门槛。NAT 模式下 WSL 的端口不在这条路上它在虚拟机私有网络的深处手机从门口看过去根本没有这个门牌号。mirrored 模式做的事就一句话把 WSL 的端口搬回了这条路上。直接访问电脑IP:8000局域网设备共享协议栈Windows 程序WSL 程序WSL 里的服务所以之前那张访问矩阵的差异到这里全部说得通。局域网设备直接连 Windows 的 IP流量进了共享协议栈WSL 里的服务就在里面自然能通双向 localhost两边都认127.0.0.1IPv6 也通了VPN 兼容性大幅改善但共享从来都是有代价的mirrored 模式用起来也不是没有脾气。共享带来的新问题端口冲突。端口重新变成一份之后两边的程序开始抢。Windows 里如果已经有个服务占了 9000 端口你在 WSL 里 bind 9000 会直接失败。这在 NAT 模式里根本不可能发生两个栈各玩各的现在成了一份产权两家争。微软给了一个实验性的ignoredPorts白名单允许 Linux 绑特定端口但默认场景下冲突就是冲突。防火墙变了。流量不再走虚拟交换机Hyper-V 防火墙参与进来默认挡入站。想让局域网连进来先给 WSL 的虚拟机加规则。New-NetFirewallHyperVRule-NameWslWeb-DisplayNameWSL Web-Direction Inbound-VMCreatorId{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}-Protocol TCP-LocalPorts 8000这串 GUID 是微软给 WSL 虚拟机固定的身份标识。整台放行也可以Set-NetFirewallHyperVVMSetting -DefaultInboundAction Allow但一刀切放行等于把虚拟机的所有入站流量交给信任。自己连自己不通。还记得开头矩阵里那个反直觉的行吗。mirrored 模式下本机用局域网 IP 访问 WSL 服务会失败。原因很妙Windows 发现目标 IP 是自己的直接在本地协议栈处理了而本地没有程序监听这个端口流量根本没进 WSL。127.0.0.1有专门的中继局域网 IP 没有。想开的话有实验开关hostAddressLoopbacktrue默认是关的。IPv6 的坑。双向 localhost 只支持 IPv4 的127.0.0.1IPv6 的::1不支持。有些程序解析localhost时优先走::1然后你就碰到莫名其妙的超时。坦率的讲这些问题的根源都是同一件事镜像模式把隔离拆掉了安全边界从「虚拟机和 Windows 之间」移动到了「Windows 防火墙和 Hyper-V 防火墙」上。便利是实打实的代价也是实打实的。顺带一提Docker Desktop 的端口映射在 mirrored 模式下早期版本也踩过坑用 Docker 的话要留意版本。这不是新问题虚拟化一直在打一场拔河写到这里你可能会觉得这是 WSL 特有的纠结。其实不是。把时间轴拉长看WSL 只是把虚拟化领域一场几十年的大戏重新演了一遍。2016 年WSL1 发布。它不是虚拟机是系统调用翻译层网络栈直接共享 Windows 的。那时端口天然属于整台电脑局域网直接能访问没有任何打洞。这很便利代价是隔离为零。2019 年WSL2 换成真虚拟机NAT 隔离安全性和稳定性上来了便利性崩了。局域网访问没了IP 每次变要打洞。微软自己也知道所以这些年一直在往回补localhost 转发、DNS 隧道、自动代理都是给隔离的围墙加门。2023 年mirrored 模式来了方向直接反转把网卡镜像回去重新共享。中间还试过 bridged 模式2.4.5 起标记废弃。2024 年底又冒出一个 VirtioProxyWSL 2.3.25 起NAT 创建失败会自动回退到它。它不依赖 Hyper-V 虚拟交换机用 virtio 把流量代理给 Windows 网络栈。有意思的是它修的不是便利性问题而是 NAT 模式本身的基础设施问题虚拟交换机在某些环境下根本建不起来。你看这条线共享、隔离、再共享。同一个问题同一个钟摆。隔离和共享的拉锯其实是安全性和生产力这两件事在拔河历史上所有虚拟化产品都被这根绳子勒过。这个钟摆也不只在 WSL 里。你想想看Docker 的--network host和默认 bridge 的区别host 模式容器直接绑宿主端口bridge 模式要-p映射一样的思路。VMware、VirtualBox 的 NAT 和桥接模式一样的思路。端口能不能被外面访问说到底是一个网络栈归属问题而网络栈共享还是隔离是所有虚拟化产品都必须做的选择题。我始终觉得这道题的答案从来不是「哪个更好」而是「你现在更怕什么」。怕隔离带来的麻烦就共享怕共享带来的风险就隔离。微软把两个答案都留着NAT 仍然是默认mirrored 推荐给特定人群这本身就是对这道选择题最诚实的回答。没有银弹只有取舍。三个实验把两种模式跑给你看理论讲完落到命令上。这些命令我尽量写成可直接复制的但网络环境千奇百怪在你机器上不一定一次就通先别急着怀疑我看看自己的防火墙。实验一NAT 模式下打洞# WSL 里启动服务python3-mhttp.server8000--bind0.0.0.0Windows 里访问http://localhost:8000通。局域网设备访问http://电脑IP:8000不通。现在打洞。# PowerShell 管理员权限netsh interface portproxy add v4tov4 listenaddress0.0.0.0 listenport8000 connectaddress$(wsl hostname-I).Trim()connectport8000 netsh advfirewall firewall add rule namewsl-8000dirin actionallow protocolTCP localport8000通了。然后wsl --shutdown再启动wsl hostname -I的 IP 变了portproxy 指向旧 IP又不通了。这就是 NAT 打洞方案的原罪。实验二mirrored 模式直连# C:\Users\你\.wslconfig [wsl2] networkingModemirroredwsl--shutdown wslinfo--networking-mode输出mirrored说明生效。WSL 里重新跑服务手机直接访问电脑的 IP 加端口通。再验证那个反直觉的结论本机用局域网 IP 访问不通localhost 通。这块需要注意一下如果手机连不上多半是 Hyper-V 防火墙挡着回看上一节的规则命令。实验三端口冲突Windows 上先占一个端口。python-m http.server 9000WSL 里再绑。python3-mhttp.server9000--bind0.0.0.0NAT 模式下两边各绑各的相安无事。mirrored 模式下直接报错端口已被占用。两个网络栈抢一份产权这是共享最直白的代价。怎么选场景推荐只想本机访问服务NAT 默认就够不用折腾手机平板调试、局域网演示mirrored公司 VPN 环境DNS 老出问题mirrored dnsTunnelingWindows 10或对安全边界敏感NAT老实打洞端口长期暴露给同事mirrored 只放行指定端口的 Hyper-V 防火墙规则总结回到开头的问题8000 端口到底属于谁。NAT 模式下端口属于虚拟机。本机能访问靠的是一个只认127.0.0.1的转发桥外面能访问靠的是 portproxy 打洞IP 一换全白干mirrored 模式下端口重新属于整台电脑。共享协议栈局域网直连代价是端口冲突、防火墙参与、以及本机用 IP 连自己反而连不上的怪现象共享与隔离是虚拟化永恒的钟摆。WSL 从共享摆到隔离又摆回共享Docker、传统虚拟机都是同一个钟摆没有银弹只有取舍现在你的手机还连不上 WSL 里的服务的话先看一眼自己的网络模式。答案往往不在配置里在端口属于谁这个问题上。