Docker Desktop在Windows上绑定80端口失败，主因是Windows系统层占用：WinNAT预留端口（如80/443）、WSL2内部残留监听、或Hyper-V动态端口范围冲突；netstat常查不到，需逐层排查WinNAT排除范围、WSL2内ss命令、及Hyper-V端口配置。
直接告诉你：Docker Desktop 提示端口已被占用，**不是容器没关干净，大概率是 Windows 系统层在“偷偷占着”**——尤其是 80、443、6443 这类常见端口，netstat -ano 查不到，但 Docker 就是绑不上。得从 WSL2、WinNAT、系统服务三层往下挖。
查不到进程却报错？先确认是不是 WinNAT 预留端口范围搞的鬼
Windows 的 WinNAT 服务默认会预留 49152–65535 范围外的端口（比如 80、443），哪怕你没跑任何服务，Docker Desktop 启动时也会被拦截。这不是 bug，是 Windows 的安全策略。
- 运行
netsh interface ipv4 show excludedportrange protocol=tcp，看输出里是否包含目标端口（如 80） - 若确实在 excluded port range 内，临时绕过方法是：以管理员身份运行
netsh int ipv4 set excludedportrange protocol=tcp startport=80 numberofports=1 add=yes（不推荐长期用） - 更稳妥的做法是：改用非保留端口（如
-p 8080:80），或让前端走反向代理（Nginx / Caddy）统一入口
docker ps 看不到，但端口真被占了？重点检查 WSL2 内部状态
Docker Desktop 在 Windows 上实际跑在 WSL2 里，宿主机看到的端口占用 ≠ WSL2 里的端口占用。很多“幽灵冲突”其实发生在 WSL2 发行版内部。
- 先进 WSL2：
wsl -d docker-desktop（或wsl -d docker-desktop-data） - 在里面执行：
ss -tuln | grep ':80\|:443'，看是否有残留监听（比如旧容器没彻底退出） - 如果发现可疑进程，用
kill -9 PID干掉；再退出 WSL2，重启 Docker Desktop - 别依赖
docker ps -a，stopped 容器也可能通过 iptables 规则挂着端口映射
明明没开服务，却提示 6443 端口冲突？Kubernetes 和 Hyper-V 动态端口撞车了
Docker Desktop 自带 Kubernetes 时，默认控制平面监听 6443。而 Windows Hyper-V 的动态端口分配范围（默认 49152–65535）可能把 6443 划进去了，导致 API Server 启动失败。
- 查当前 Hyper-V 端口范围：
netsh int ipv4 show dynamicport tcp - 若起始端口 ≤ 6443，就必然冲突。修复命令（管理员权限）：
netsh int ipv4 set dynamicport tcp start=49153 num=16382 - 改完必须重启系统才生效，否则 Docker Desktop 的 Kubernetes 仍无法启动
- 临时方案：禁用 Docker Desktop 内置 Kubernetes，改用
kind或minikube
为什么 docker container prune 有时不管用？
docker container prune 只删 stopped 容器，但端口绑定可能还卡在内核的 iptables 或 WSL2 的 netfilter 规则里，尤其当容器异常退出时。
- 真正清干净要三步走：
docker stop $(docker ps -q)→docker system prune -a -f→wsl --shutdown - 最后这步
wsl --shutdown很关键，它强制终止所有 WSL2 实例，释放底层网络栈 - 之后再开 Docker Desktop，端口状态才是“干净重启”
最常被忽略的一点：Windows 上的端口冲突，80% 不在用户进程里，而在系统服务、WSL2 网络栈、WinNAT 预留机制这三层交界处。盯着 netstat 找进程，往往白忙活。先定位冲突发生在哪一层，再动手，省一半时间。
