Docker端口映射绑定127.0.0.1导致局域网无法访问，正确做法是显式指定0.0.0.0:8080:80；需检查docker ps中PORTS是否显示0.0.0.0，同时确认容器内服务监听0.0.0.0而非127.0.0.1，并开放Windows防火墙及处理WSL2网络穿透问题。
docker run 时端口映射绑定了 127.0.0.1
这是最常见也最容易被忽略的问题。当你用 docker run -p 127.0.0.1:8080:80 nginx 启动容器，Docker 只把宿主机的 127.0.0.1:8080 暴露出来，局域网其他设备根本连不到这个地址。
正确做法是显式绑定到所有接口：docker run -p 0.0.0.0:8080:80 nginx。注意不是省略 IP（Docker 默认行为在某些版本或配置下可能 fallback 到 127.0.0.1），而是必须写明 0.0.0.0。
- 检查当前映射：运行
docker ps，看PORTS列是否显示0.0.0.0:8080->80/tcp；若显示127.0.0.1:8080->80/tcp，说明已中招 - Compose 用户注意：
ports字段里写"8080:80"是不够安全的，应明确写成"0.0.0.0:8080:80"（Docker Compose v2.20+ 支持） - 旧容器无法热修复：改了
docker-compose.yml必须docker compose down && docker compose up -d，只docker compose restart不会更新端口绑定
Windows 防火墙拦住了入站连接
Docker Desktop 在 Windows 上跑，但端口暴露后，流量仍要穿过 Windows 自带的防火墙。哪怕你本地能访问，局域网请求默认会被拒绝。
打开 wf.msc（Win+R 输入后回车），进「入站规则」，找名字含 Docker 或 dockerd 的规则，确认状态图标是绿色勾（启用），不是红色禁止。没有？那就手动建一条：
- 新建规则 → 端口 → TCP → 特定本地端口（比如
8080）→ 允许连接 → 勾选“域、专用、公用”三个配置文件 - 规则名称建议写清楚，例如
Docker-Redis-6379，方便后续排查 - 别只信“专用网络”已开——很多公司/家庭路由器把设备自动划为“公用网络”，必须三者全开
WSL2 虚拟机网络与 Windows 主机不互通
Docker Desktop on Windows 实际运行在 WSL2 虚拟机里，而 WSL2 默认使用一个虚拟网卡（如 172.x.x.x），它和 Windows 主机的 192.168.x.x 局域网不在同一层。所以即使端口映射对了、防火墙放行了，流量也可能卡在 WSL2 和 Windows 的边界上。
验证方式：在 Windows 命令行执行 ipconfig，找到 WSL2 对应的适配器（通常叫 “WSL” 或 “vEthernet (WSL)”），记下它的 IPv4 地址（比如 172.28.128.1）。然后从另一台局域网电脑尝试访问 http://172.28.128.1:8080 —— 如果能通，说明问题就出在 Windows 主机没把 WSL2 的端口转发出去。
- 临时解法：在 Windows 上用
netsh interface portproxy手动转发（较麻烦，不推荐长期用） - 更稳方案：改用
host.docker.internal作为服务监听地址（仅限容器内应用代码可改时） - 终极建议：避免依赖 WSL2 网络穿透，直接让容器监听
0.0.0.0并确保宿主机端口映射走0.0.0.0，再配合防火墙规则
容器内服务只监听 127.0.0.1
端口映射只是“通道”，如果容器里那个程序自己只绑定了 127.0.0.1:8080，那就算宿主机映射再正确，外部流量也进不去。
进容器查真实监听情况：docker exec -it 。如果输出是 127.0.0.1:8080 或 ::1:8080，就得改应用配置。
- Node.js：启动时用
app.listen(8080, '0.0.0.0')，别用'127.0.0.1' - Python Flask：加
host='0.0.0.0'参数，app.run(host='0.0.0.0', port=8080) - Java Spring Boot：在
application.yml里设server.address: 0.0.0.0 - Redis：确认
bind配置没写死127.0.0.1，或干脆注释掉这一行
真正卡住人的地方往往不是 Docker 本身，而是容器里那个服务到底听谁的 —— 它不主动对外敞开门，外面敲再多次门也没用。
