必须进入容器用ss或netstat确认监听地址：若显示127.0.0.1:端口则仅限内部访问，需改为0.0.0.0:端口才能接收外部流量；docker ps的PORTS列仅反映映射配置，不验证应用是否真实bind成功。
直接看容器内进程是否真在监听，比只信 docker ps 的 PORTS 列更可靠——因为那列只反映端口映射配置，不验证应用是否真的 bind 成功。
用 docker exec 进容器查 netstat 或 ss
这是最直接的方式：进容器内部，看应用进程是否真在 listen 目标端口。很多新手误以为 docker ps 显示 0.0.0.0:8080->80/tcp 就代表 Nginx 肯定在跑、且监听了 80，其实它可能崩溃重启中、或配置写错根本没 bind。
-
docker exec -it sh（Alpine 镜像用sh，Ubuntu/Debian 通常用bash） - 进容器后执行：
netstat -tuln | grep :80或更轻量的ss -tuln | grep :80 - 若无输出，说明应用没启动，或监听地址写成了
127.0.0.1:80（只限本地 loopback，Docker 外部连不上） - 正确输出类似：
tcp6 0 0 :::80 :::* LISTEN（注意:::表示 IPv6 any，0.0.0.0:80是 IPv4 any）
docker inspect 查 NetworkSettings.Ports 和 State.Status
docker inspect 不只看端口映射，还能交叉验证容器状态和实际绑定信息。关键不是看有没有 -p 参数，而是看容器是否健康、网络设置是否生效。
-
docker inspect | jq '.[0].NetworkSettings.Ports'（需装jq）可清晰看到映射关系，例如"80/tcp": [{"HostIp": "0.0.0.0", "HostPort": "8080"}] - 同时检查
.[0].State.Status是否为running，以及.[0].State.Health.Status（如果定义了 healthcheck） - 若
NetworkSettings.Ports为空，但你用了-p，说明容器启动失败回退了——常见于端口被宿主机占用、或镜像 ENTRYPOINT 启动失败
Docker Desktop for Mac/Windows 的特殊限制
Mac 和 Windows 上 Docker Desktop 是通过 Linux VM 运行的，所以“宿主机端口”实际是 VM 的端口，再由 HyperKit / WSL2 转发到 macOS/Windows。这层转发会引入额外延迟和调试盲区。
- 在 macOS 上，
localhost:8080访问的是 VM 的 8080，不是你 Mac 的；但netstat -anv | grep 8080在 Mac 终端查不到，得进 VM：docker run --rm -it --privileged --pid=host alpine nsenter -t 1 -m -u -n -i sh -c 'netstat -tuln | grep :8080' - Windows WSL2 用户，
localhost可访问，但若用真实 IP（如192.168.x.x）访问失败，大概率是 WSL2 防火墙或 Windows 主机防火墙拦截，不是 Docker 问题 - Docker Desktop 设置里开启 “Expose daemon on tcp://localhost:2375” 后，
docker ps结果仍只显示映射，不等于容器内服务就通——这个开关只影响 Docker API，不影响容器网络
为什么 EXPOSE 不等于监听成功
EXPOSE 80 只是 Dockerfile 里的注释性声明，运行时完全不生效。哪怕你删掉它，docker run -p 8080:80 nginx 依然能映射；反过来，写了 EXPOSE 8080 但应用根本没 listen 8080，映射也白搭。
- 验证方式永远是：进容器 → 查
ss或lsof -i :80→ 确认进程 PID 和监听地址 - Node.js 应用常见错误：代码写
app.listen(3000, '127.0.0.1')，导致只响应容器内部 loopback，外部请求超时 - Nginx 配置常见错误：
listen 80;没加default_server或监听地址漏写0.0.0.0，在非 root 用户下可能静默失败
真正卡住人的往往不是命令怎么写，而是混淆了「Docker 做了什么」和「应用自己做了什么」——端口映射只是管道，管道通不通，得看两端的阀门有没有打开。
