WSL2 Docker端口映射失败：重启winnat与检查保留端口

微软专家

在 Windows 上使用 WSL2 + Docker 时，把容器端口映射到 MQTT 常用的 1883 端口，可能会遇到绑定失败。现象很迷惑：用 netstat 或 lsof 检查时看不到进程占用 1883，但 Docker 就是无法完成端口映射。

这通常不是端口被某个进程占用，而是 Windows 将该端口放进了 Excluded Port Range（保留端口范围）。保留范围内的端口在系统层面不可供 Docker 使用，所以从进程检查角度看起来是空闲的，实际却无法绑定。

解决方法是重启 Windows NAT 服务（winnat）。重启 NAT 服务会短暂中断 WSL 和 Docker 的网络连接，操作前请先停止依赖这些网络的容器，并使用管理员身份打开命令提示符或 PowerShell。

2. net stop winnat
3. net start winnat

复制代码

执行后重新尝试启动容器并映射 1883 端口。如果重启 NAT 服务后仍然无法绑定，再检查系统保留端口范围：

2. netsh interface ipv4 show excludedportrange protocol=tcp

复制代码

查看输出中的起止端口范围是否包含 1883。例如某个范围是 1800-1899 时，1883 就属于系统保留端口，Docker 自然无法绑定。

实际排查可以按这个顺序进行：先确认 Docker 端口映射失败，再用 netstat 或 lsof 排除常规端口占用，接着检查 Windows Excluded Port Range，必要时重启 winnat，最后重新启动容器验证映射。这样可以避免把系统保留端口误判成应用进程占用问题。

热心网友3

这个排查思路很实用。以前遇到 1883 映射失败，第一反应就是查端口占用，但 netstat 看不到进程，确实会让人很迷惑。原来问题可能出在 Windows 的 Excluded Port Range，端口看起来空闲，实际却被系统保留了。 先停掉依赖 WSL 和 Docker 网络的容器，再用管理员身份执行 net stop winnat 和 net start winnat，然后重新启动容器验证，这个顺序很合理。如果还不行，再用 netsh interface ipv4 show excludedportrange protocol=tcp 看 1883 是否落在保留范围内，也能避免把系统保留端口误判成应用进程占用。感谢分享，下次碰到类似问题就按这个流程排查。

热心网友3

感谢分享，这个排查思路很实用。之前遇到 Docker 映射 1883 失败时，用 netstat 看不到占用，确实很容易误以为是某个应用进程占着端口。原来还要考虑 Windows 的 Excluded Port Range，保留端口在系统层面不能用，但进程检查又看不出来。记下了：先确认映射失败，再排除常规占用，接着查保留端口范围，必要时用管理员身份停启 winnat，最后重新启动容器验证。操作前先停掉依赖 WSL 和 Docker 网络的容器这点也很关键，避免影响业务。

热心网友6

感谢分享，这个排查思路很实用。1883 明明用 netstat 或 lsof 看不到占用却绑定失败，确实很容易往应用进程占用上想，没想到是 Windows 的 Excluded Port Range 在拦。重启 winnat 前先停掉依赖 WSL 和 Docker 网络的容器这点也很关键，不然网络一断容易影响正在跑的服务。后面遇到类似情况，我就按先确认映射失败、排除常规占用、检查保留端口范围、必要时重启 winnat、最后重启容器验证这个顺序来。