企业官网建设流程全解析

1. 开篇：为什么要折腾 WSL？一条让 Windows 和 Linux 共存的成熟路径

如果你手头有一台装了 Windows 11 的机器，又离不开 Linux 环境下的开发工具、脚本或服务，那 Windows 自带的 Linux 子系统（WSL，全称 Windows Subsystem for Linux）应该是最省心的方案。它不像虚拟机那样需要给整套系统分配大量内存和 CPU，也不用担心图形界面卡顿和磁盘占用翻倍；它也不是单纯在 Windows 里硬塞一个模拟器，而是通过微软官方提供的兼容层 / 轻量虚拟化技术，让你在一个原生 Windows 窗口里直接跑一个 Ubuntu 之类的发行版。

这篇博文围绕四个核心诉求展开：把 Linux 子系统装起来、让里面的服务在开机后自动跑起来、让局域网里的其他设备能访问到子系统里的服务、以及把 Windows 的磁盘目录挂载到 Linux 环境里使用。这四个点合在一起，基本覆盖了我在实际项目里用 WSL 的绝大多数场景——尤其是近期很多人提到的工控机开机自启动、ollama 局域网访问、wsl 安装后勾选功能失效等问题，都会在后面逐一拆解。

文章会按照“安装 → 自启动 → 局域网访问 → 磁盘挂载 → 常见问题排查”的顺序来写，每一步都给出可复现的操作命令和配置方法。无论你只是想在 Windows 上跑个 Linux 终端，还是想用 WSL 承载一个本地 AI 模型服务，这份内容都能直接抄作业。

2. 安装 Linux 子系统：从零到能用的完整步骤

2.1 先说清 WSL1 和 WSL2 的区别，选错版本会走弯路

很多人第一次接触 WSL 时会被两个版本搞糊涂。WSL1 走的是系统调用翻译层，把 Linux 的系统调用转换成 Windows 的调用，优点是启动快、文件 IO 和 Windows 盘符无缝互通；缺点是对 Linux 内核的兼容性不够完整，一些依赖 Docker、ebpf、特定内核模块的软件无法运行。

WSL2 则是在 Hyper-V 虚拟化平台上运行一个完整的 Linux 内核，兼容性大大提升。现在的 Docker Desktop 可以直接复用 WSL2 后端，ollama 这类本地模型服务也能正常运行。如果你的机器支持虚拟化（BIOS 里开了 VT-x 或 AMD-V），那直接上 WSL2 是标准选择；如果机器太老或虚拟化被锁，才需要退回 WSL1。

检查虚拟化是否开启，最简单的方式是打开任务管理器，切到“性能”标签，看 CPU 部分有没有“虚拟化：已启用”。如果显示“已禁用”，需要进 BIOS 开启，这一步不做，后面装 WSL2 会一直报错。

提示：WSL2 的磁盘文件默认存储在 ext4.vhdx 里，访问 Windows 盘的 /mnt/c、/mnt/d 反而比 WSL1 略慢。所以如果你只想要一个 Linux 终端环境，很少跑重负载服务，WSL1 反而更轻快。但考虑到 Docker、AI 推理这类热门场景，WSL2 是当前的主流选择。

2.2 新机简化安装：一行命令搞定 WSL2

Windows 11 的 WSL 安装如今已经比 Win10 时代简化很多。打开 PowerShell（管理员身份），执行：

wsl --install

这条命令的使命很明确：把 WSL 核心组件、虚拟机平台功能、默认的 Ubuntu 发行版一次装齐。安装完成后系统会要求重启，重启后进入 Ubuntu 首次配置界面，设置 Linux 用户名和密码即可。

如果你希望指定发行版，比如想用 Debian 或 Kali，可以执行：

wsl --list --online wsl --install -d Debian

我自己的经验是，第一次安装时网络很重要。wsl --install 需要从微软服务器下载组件和发行版镜像，如果网络不稳定，可能装到一半报错。遇到这种问题，可以稍后重试，或者先把 Windows 更新装上再执行安装命令。

安装完成后，在开始菜单里搜索 ubuntu 即可启动。常用检查命令：

wsl --status wsl --version

wsl --status会显示当前 WSL 版本，wsl --version会显示 WSL 内部组件的详细版本号。如果默认版本不是 2，可以用：

wsl --set-default-version 2

把默认版本固定为 WSL2。

2.3 历史遗留问题：勾选“适用于 Linux 的 Windows 子系统”后重启就失效

最近网上讨论很热烈的一个现象是：在“启用或关闭 Windows 功能”里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，结果重启后勾选状态又恢复原状，WSL 根本无法启用。

这种情况我在几台机器上都见过。本质原因是 Windows 功能开关写入失败，或者被系统策略、第三方优化工具拦截。排查思路分三步：

第一步，确认 Windows 版本。老版本的 Windows 10 对 WSL2 的支持不完整，出现功能开关回滚很正常。建议把系统更新到最新版 Windows 11。

第二步，使用 DISM 命令手动启用功能，而不是只靠图形界面勾选。在管理员 PowerShell 里执行：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

然后重启。这次重启后，功能状态应该能保住。如果仍然回滚，说明系统镜像或策略有问题，可以尝试运行系统文件检查：

sfc /scannow

或者用 Windows 11 安装介质做一个修复升级，这种方式能最大程度保留现有软件和数据。

第三步，第三方安全软件、系统优化工具可能把功能开关强制关闭。如果上述两步都无法解决，临时卸载或退出这类工具，再执行一次启用命令。

2.4 装完先做三件事：换源、更新、配置默认用户

Ubuntu 装好后的第一件事，我会把软件源换成国内镜像，否则 apt 下载速度太慢。编辑源列表：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list sudo apt update && sudo apt upgrade -y

我这里用的是阿里云镜像，实际环境里也可以换成清华、腾讯、中科大源，原理一致。

第二件事是改默认用户。如果你装好了 WSL，但每次在 Windows 终端里输入 wsl 后进入的是 root，或者反过来想用 root 结果进去是普通用户，都可以用这样一条命令切换默认用户：

wsl --manage Ubuntu --set-default-user 用户名

如果命令提示不支持，也可以直接进入 WSL 后执行：

echo "用户名" > /etc/wsl.conf

然后在 [user] 段落里加上 default=用户名。

第三件事是确认 systemd 是否可用。新版 WSL2（0.67.6 及以上）默认支持 systemd，这对服务自启动的配置至关重要。检查方式：

ps -p 1 -o comm=

如果输出的是 systemd，说明一切正常。如果输出的是 init，说明 systemd 未启用，需要在 /etc/wsl.conf 里添加：

[boot] systemd=true

然后在 Windows PowerShell 里执行 wsl --shutdown，重新进入 WSL 让配置生效。

3. 服务自启动：开机后让 Linux 里的服务自动跑起来

3.1 理解 WSL 的启动机制：为什么服务不会自动启动

WSL 和传统虚拟机不同，它的生命周期和 Windows 登录会话绑定。默认情况下，只有在你打开一个 WSL 终端窗口时，对应的 Linux 发行版才会启动；关闭所有 WSL 窗口后，系统会在几秒内自动回收这个发行版的进程。这意味着，你无法指望像 systemctl enable 那样，在 Windows 开机时就自动拉起 WSL 里的服务。

要实现服务自启动，正确的思路是：在 Windows 登录后主动执行 wsl 命令，让 WSL 实例启动，进入 Linux 后由 systemd 接管并启动所需服务。这也是工控机上电自启动的常规配置方式——Windows 开机后通过任务计划程序触发一条命令，WSL 里的服务自然就跟起来了。

这里有一个关键细节：wsl.exe 命令在首次启动发行版时会返回一个交互式 shell 的退出码，但服务进程会在 WSL 关闭后继续运行一段时间。如果所有 WSL 窗口都关闭，服务会随实例回收而终止。因此，为了让服务常驻，需要让 WSL 实例在后台保持运行，或者使用wsl -d Ubuntu --exec的方式，让系统认为有进程在占用。

3.2 首选方案：用 Windows 任务计划程序实现开机自启动

我在实际项目里最常用、最稳的方案就是任务计划程序。打开“任务计划程序”，右侧点击“创建任务”，在“常规”标签里填写任务名称，比如 WSL-AutoStart，勾选“使用最高权限运行”，并选择“不管用户是否登录都要运行”。

在“触发器”标签里新建触发器，选择“启动时”或“登录时”。如果你希望服务在用户输入密码进入桌面后启动，选“登录时”；如果希望更早启动，选“启动时”。工控机场景通常选“登录时”即可，因为需要桌面环境配合网络初始化。

在“操作”标签里新建操作，程序填写：

wsl.exe

参数填写：

-d Ubuntu -u root --exec /bin/bash -c "systemctl start your-service-name"

如果你是希望 WSL 实例常驻，不退出，可以改成启动一个 keep-alive 命令，比如：

-d Ubuntu -u root --exec /bin/bash -c "tail -f /dev/null"

任务计划里的wsl.exe默认会弹出控制台窗口，虽然不影响功能，但看着有点碍眼。解决方法是在程序路径里使用 conhost 的隐藏参数，或者把 wsl.exe 包一层，写成：

cmd /c start /min wsl.exe -d Ubuntu -u root --exec /bin/bash -c "systemctl start your-service-name"

这样窗口会在最小化状态运行，桌面不会显得杂乱。

3.3 备用方案：开机启动文件夹和组策略

如果你的使用场景不需要管理员权限，或者只是想在用户登录后快速启动某个脚本，可以把一条 wsl 命令的快捷方式放进“启动”文件夹。最简单的方法是写一个 .bat 文件，内容：

@echo off wsl.exe -d Ubuntu -u root --exec /bin/bash -c "/home/user/startup.sh"

然后把这个 .bat 文件放到运行框输入shell:startup打开的启动文件夹里。这种方式的好处是配置简单，不需要创建任务计划；缺点是必须等用户登录后才执行，且如果 WSL 启动失败，没有重试机制，不如任务计划程序可靠。

另一个思路是用组策略的脚本配置，在gpedit.msc里找到“计算机配置 → Windows 设置 → 脚本(启动/关机)”，添加一个启动脚本，内容同样是 wsl 命令。这种方案适合企业环境下统一分发配置，但对普通用户来说配置门槛偏高，不如任务计划直接。

3.4 在 WSL 内部配置 systemd 服务，让自启动更优雅

既然 WSL 支持 systemd，那我们应该把服务定义成标准的 systemd 单元，而不是在启动命令里手写一堆 shell 脚本。以 ollama 为例，创建一个服务文件：

sudo nano /etc/systemd/system/ollama.service

内容大致是：

[Unit] Description=Ollama Local AI Service After=network-online.target Wants=network-online.target [Service] User=root ExecStart=/usr/local/bin/ollama serve Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

保存后执行：

sudo systemctl daemon-reload sudo systemctl enable ollama sudo systemctl start ollama

这样，只要 WSL 实例被拉起，systemd 就会自动启动 ollama。配合前面创建的任务计划，在 Windows 登录时拉一次 WSL 实例，ollama 就一直在后台跑着。

提示：WSL2 的 systemd 并不是完整照搬一台物理 Linux 上的 systemd，有些依赖硬件设备、电源管理的单元不可用。如果某个服务无法启动，先看 journalctl -u 服务名 -n 50 的输出，多数问题是缺少硬件设备或网络等待时间不足。

4. 局域网访问：让其他设备连上你 WSL 里的服务

4.1 先看现象：为什么 localhost 能访问，局域网却不行

这是一个高频问题。WSL2 的网络模式和传统虚拟机不同，它并不是直接从路由器获取一个局域网 IP，而是通过 Windows 的虚拟交换机做 NAT。简单来说，WSL2 里的 IP 是 NAT 网络内的地址，Windows 主机的 localhost 转发只对本地回环有效。

举个例子：你在 WSL 里启动了 ollama，监听 0.0.0.0:11434。在 Windows 本机的浏览器里访问 http://localhost:11434 可以正常响应，但同一局域网内其他电脑用 http://Windows主机的IP:11434 访问，却大概率连不上。

原因有两层：一是 WSL2 的服务没有自动映射到 Windows 主机的端口上；二是 Windows 防火墙默认拦截外部入站连接。对局域网内其他设备来说，WSL 里的服务进程相当于藏在一个“内网的内网”里。

4.2 方案一：netsh 端口转发 + 防火墙放行

最经典的做法是用 Windows 自带的 netsh 命令做端口转发。在管理员 PowerShell 里执行：

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=11434 connectaddress=127.0.0.1 connectport=11434

这条命令的含义很清晰：让 Windows 主机监听所有网卡上的 11434 端口，收到连接后转发到 127.0.0.1 的 11434 端口。由于 WSL2 和 Windows 会通过 localhost 互通，所以 connectaddress 写 127.0.0.1 就能访问到 WSL 里的服务。

但只有端口转发还不够，Windows 防火墙默认会拦截外部对 11434 端口的访问。需要新建入站规则：

netsh advfirewall firewall add rule name="WSLPort11434" dir=in action=allow protocol=TCP localport=11434

如果想同时允许 UDP，可以再加一条。这一步做完，局域网其他设备就能通过http://Windows主机的IP:11434访问到服务了。

注意：管理员权限是必须的，否则 netsh interface portproxy 和 netsh advfirewall 会报“请求的操作需要提升”。

4.3 方案二：直接把 WSL 实例放进局域网（镜像网络模式）

netsh 方案用起来没问题，但有一个明显痛点：如果服务端口变化，或者你想让多个服务同时暴露到局域网，就要反复修改端口转发表，比较繁琐。而且服务监听在 0.0.0.0 或特定 IP 上，网络模式是 NAT，每次重启 WSL，NAT 网络的虚拟网关地址还可能变化。

比较新的 Windows 11 版本（WSL 2.0.0+）支持一种叫 mirrored 的网络模式，也就是镜像网络模式。在这种模式下，WSL 直接共享 Windows 主机的网络接口，不再有独立 IP 和 NAT 隔离。换句话说，WSL 里的服务如果监听 0.0.0.0，宿主机局域网上的设备可以直接通过 Windows 主机的 IP 访问，不再需要 netsh 转发。

开启方式是在用户目录下创建或编辑 .wslconfig 文件：

[wsl2] networkingMode=mirrored

然后执行：

wsl --shutdown

重新进入 WSL 后，查看 IP：

ip addr show eth0

如果看到地址和 Windows 主机网段一致，说明镜像模式生效了。此时无需任何 netsh 转发，Windows 防火墙只需要放行对应端口即可。

我在测试 ollama 局域网访问时发现，镜像模式对 Windows 11 22H2 以上系统支持较好，但如果你用的是老版本 WSL，可能没有这个选项。升级 WSL 的方法是：

wsl --update wsl --version

4.4 让局域网访问更稳定：静态映射和动态端口的处理

netsh 端口转发有一个隐蔽的坑：WSL2 的 NAT 网络地址在每次重启后可能变化，但这不影响 127.0.0.1 的转发，因为 Windows 和 WSL 之间的 localhost 互通是稳定的。所以 netsh 方案在“通用访问”层面其实还算稳妥。

但如果你安装了多个发行版，或者 WSL 里跑了 Docker，Docker 的容器端口映射可能会产生额外的 NAT 层，导致 netsh 转发时出现端口冲突。处理方式是把服务监听地址显式设置为 0.0.0.0，而不是回环地址，同时检查 Docker 的 -p 参数是否与 netsh 转发的端口重复。

另一个稳定性的问题是动态 IP。如果你的 Windows 主机在局域网内用的是 DHCP 动态获取 IP，那局域网内其他设备记下的 IP 可能在几天后失效。最简单的方案是在路由器管理界面为这台 Windows 主机绑定一个固定 DHCP 保留地址，或者直接在 Windows 网卡设置里写死一个静态 IP。这样，局域网访问地址就一直是同一个。

对于需要让局域网设备长期访问的场景，除了端口转发，我还会检查服务本身的监听地址。有些服务默认只监听 127.0.0.1，这在 WSL 里尤其常见。如果服务绑定在 127.0.0.1，即使 netsh 转发到 127.0.0.1:端口，外部设备也不可能访问到，因为服务没监听在外部可达的接口上。

所以排查步骤是：

1. 在 WSL 里执行 ss -tlnp | grep 端口，确认服务监听的是 0.0.0.0 还是 127.0.0.1。
2. 如果监听了 127.0.0.1，修改服务配置为 0.0.0.0，或者设置 HOST=0.0.0.0 环境变量。
3. 在 Windows 本机先访问 localhost 确认服务状态。
4. 再执行 netsh 转发和防火墙放行。

ollama 的情况比较特殊，它默认监听 127.0.0.1:11434。要让它可被局域网访问，常见做法是设置环境变量 OLLAMA_HOST=0.0.0.0，然后重启 ollama 服务。这个细节很多人在部署本地模型时踩过坑。

5. 磁盘挂载：让 Windows 目录和 Linux 环境无缝互通

5.1 WSL 默认的自动挂载机制

WSL 最让人舒服的一点是，Windows 的所有盘符会自动挂载到 /mnt 目录下。比如 C 盘对应 /mnt/c，D 盘对应 /mnt/d。你在 Linux 终端里直接 cd /mnt/d/workspace 就能操作 Windows 里的文件，反过来，在 Windows 资源管理器里输入 \wsl$\ 路径，也能直接访问 WSL 里的文件。

这个自动挂载机制由 WSL 内部的 init 进程实现，不需要额外配置。但要注意，/mnt/c 这类目录的读写性能相比 WSL 内部的 ext4 文件系统有明显差距。尤其是大量小文件的读写，在 drvfs（WSL 对 Windows 文件系统的驱动）上会慢很多。如果你的项目是编译、构建这类 IO 密集任务，我建议把源码放到 WSL 内部目录，比如 /home/用户名/project，而不是放在 /mnt/d 下。

5.2 手动挂载：U 盘、移动硬盘和其他磁盘分区

自动挂载虽然方便，但并不是所有设备都会自动出现在 /mnt 下。U 盘、移动硬盘以及一些未自动挂载的分区，需要手动挂载。

先插入设备，然后查看设备编号。在 WSL 里执行：

lsblk

这个命令会列出所有块设备。Windows 下的磁盘分区在 WSL 里的表现形式通常是 sda、sdb、nvme0n1 等。找到你想要挂载的分区后，创建一个挂载点并挂载：

sudo mkdir -p /mnt/e sudo mount -t drvfs E: /mnt/e

这里的 E: 是 Windows 盘符。挂载完成后，在 /mnt/e 下就能看到对应的文件内容。卸载时使用：

sudo umount /mnt/e

如果你希望开机自动挂载某个固定盘符，可以在 /etc/fstab 里添加一行，格式如下：

E: /mnt/e drvfs defaults,noatime 0 0

但要注意，WSL 的 fstab 不一定在每次启动时都会读取，如果发现没有自动挂载，检查 /etc/wsl.conf 里的 [automount] 配置。

5.3 通过 /etc/wsl.conf 定制挂载行为

WSL 的挂载行为可以通过 /etc/wsl.conf 自定义。这个文件是 WSL 里比较核心的配置文件之一，常用配置如下：

[automount] enabled = true root = /mnt/ options = "metadata,umask=22,fmask=11" mountFsTab = true

• enabled：是否启用自动挂载。
• root：自动挂载的根目录，默认是 /mnt/。
• options：挂载选项。metadata 表示让 Linux 在挂载的 Windows 文件上支持 chmod 和 chown；umask 和 fmask 用来控制权限。
• mountFsTab：是否读取 /etc/fstab。

如果你经常需要操作 Windows 目录下的脚本，并且希望它们有可执行权限，metadata 选项就很有用。如果不加这个选项，WSL 会把所有 Windows 文件都当作 0777 权限，这对部分需要检查执行权限的工具会造成困扰。

修改完 /etc/wsl.conf 后，需要执行：

wsl --shutdown

再重新进入 WSL 才能生效。注意，wsl.conf 只会影响后续启动的实例，对当前运行的 WSL 没有热加载能力。

5.4 反向访问：从 Windows 资源管理器操作 Linux 文件

磁盘挂载不只是让 Linux 访问 Windows 文件，反过来也同样重要。WSL 的文件系统在 Windows 下有独立的访问入口。在资源管理器地址栏输入：

\\wsl.localhost\Ubuntu\home\用户名

就能像访问 Windows 本地目录一样浏览 Linux 里的文件。复制、粘贴、编辑都很方便，适合不熟悉命令行的人操作。

对于需要频繁和 Windows 交互的目录，我建议在 WSL 里创建一个符号链接，比如：

ln -s /mnt/d/workspace ~/workspace

这样在 Linux 里访问 ~/workspace 就等价于访问 D 盘的 workspace 目录，路径短了很多，也更直观。

5.5 磁盘空间管理：别再让 vhdx 无限膨胀

WSL2 的镜像是一个动态扩展的 vhdx 文件，默认放在C:\Users\用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx。它不会自动收缩。你删除了大量文件后，这个 vhdx 文件可能依然占据着曾经的最大值空间。

如果你发现 C 盘空间越来越小，需要手动压缩 vhdx。步骤是：

1. 在 PowerShell 里执行 wsl --shutdown。
2. 打开管理员 PowerShell，定位到 vhdx 所在目录。
3. 执行 diskpart。

在 diskpart 里依次执行：

select vdisk file="C:\Users\用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx" attach vdisk readonly compact vdisk detach vdisk exit

压缩过程可能需要几分钟，执行完成后，重新启动 WSL 即可。这个方法我在用完 Docker 构建缓存之后试过，C 盘能腾出几个 GB 空间，效果还是很明显的。

6. 常见问题排查：安装、启动、访问环节的坑和对应解法

6.1 安装和启动阶段的疑难杂症

• 错误：WslRegisterDistribution failed with error：0x8007019e 这个错误在旧版 WSL 上很常见，通常是因为 Windows 版本太老，或者没装内核更新包。解决方法是运行 wsl --update，然后重试启动。

• 错误：The service cannot be started, either because it is disabled or it has no enabled devices associated with it. 这个错误和 Hyper-V 服务被禁用有关。在管理员 PowerShell 里执行：

Get-Service vmcompute

如果状态不是 Running，可以执行：

Set-Service vmcompute -StartupType Automatic Start-Service vmcompute

再去启动 WSL。

• 现象：WSL 启动后一直转圈，卡在 “Installing, this may take a few minutes...” 这通常是网络问题，发行版镜像没下载完整。可以先关闭当前窗口，执行 wsl --shutdown，然后使用 wsl --update，再重新启动发行版。

• 现象：WSL 版本明明是 2，但 Docker Desktop 提示需要 WSL2 backend。 检查 Windows 功能里是否启用了“虚拟机平台”。如果没启用，WSL2 无法运行。启用方式是前面提到的 DISM 命令。

6.2 服务访问常见问题速查表

6.3 我的故障排查顺序（实战心得）

遇到 WSL 服务访问不通的问题，我一般按这个顺序排查：

先确认服务在 WSL 内部是否正常。进入 WSL 执行curl http://127.0.0.1:端口，如果返回正常，排除服务本身的问题。如果服务报错，看 journalctl -u 服务名 -n 50，对症处理。

再确认 Windows 本机访问http://localhost:端口是否正常。不正常时，说明 WSL 与 Windows 的 localhost 互通出问题。可以用wsl --shutdown后重启 WSL 试试，绝大多数情况下能解决。

然后检查 netsh 端口转发表是否还在。netsh interface portproxy show all可以查看所有转发规则。如果转发规则缺失，重新添加。如果转发规则在但访问仍失败，多半是防火墙拦截，按netsh advfirewall firewall show rule name=端口号检查入站规则。

最后才去查路由器和其他设备层面。这个过程可以避免很多无谓的折腾，尤其是当你同时配置了多个服务时，按层排查是最高效的。

6.4 Docker 和 WSL 结合时的额外注意点

如果你在 WSL 里用了 Docker（比如 Docker Desktop 开启了 WSL2 后端），局域网访问容器的端口映射会多一层封装。Docker 的 -p 参数会把容器端口映射到 WSL 实例的某个 IP 上，然后你需要再把这个 IP 的端口映射到 Windows 主机。这种叠加转发比较容易搞晕。

我的经验是，始终在 Windows 主机层面做统一的端口转发入口。例如 Docker 容器暴露 8080 端口，WSL 里访问 127.0.0.1:8080 能通，那么 Windows 上就建一条 80 端口到 127.0.0.1:8080 的 netsh 转发。这样局域网设备统一通过 http://Windows主机IP:80 访问，不需要关心 Docker 内部网络细节。

另外，Docker Desktop 默认使用的 WSL 发行版是 docker-desktop 这个隐藏实例，它的 IP 地址和普通 Ubuntu 实例不同。如果你在 Ubuntu 里跑 ollama，又想通过 Docker 跑另一个服务并互相访问，需要让两个服务都监听在各自实例的 0.0.0.0 上，并确保网络互通。最简单的方式是使用镜像网络模式，把所有 WSL 实例和 Windows 放在同一网络平面，省去很多桥接的烦恼。

7. 一些值得长期保留的经验

再分享一个我实际配置过程中体会最深的点：WSL 本身就是一套“在 Windows 上跑 Linux 服务”的完整方案，但你一定要把它当一台真正独立的 Linux 服务器对待。备份重要数据、定期更新 apt 包、控制 vhdx 体积、限制日志文件大小，这些基本功一样都不能少。

如果你像我一样，主要是为了跑本地 AI 模型（ollama）或者内部知识库工具，那我强烈建议在 WSL 里配合 systemd 把这些服务都做成标准单元，再统一由一个 Windows 任务计划触发。这样即使在无人值守的工控机场合，Windows 开机后 30 秒内，服务就已经处于可用状态，省去了手动打开终端一个个 start 的麻烦。

最后再补充一个日常使用的小技巧：在 Windows 11 的终端里，WSL 可以和 PowerShell 并排使用，直接用命令wsl就能进入默认发行版。如果你希望在某些项目里固定使用某个发行版，可以用wsl -d Debian这样指定。日常操作 Linux 文件和启动服务，都可以在 Windows 终端完成，不必单独打开 Ubuntu 窗口。这个小习惯能让你减少上下文切换，使用体验会顺滑很多。