容器内服务必须监听0.0.0.0而非127.0.0.1，否则仅容器内部可达；需用docker port验证映射是否生效，并确认宿主机防火墙、iptables及云安全组已放行，且端口未被占用。
容器内服务是否监听 0.0.0.0 而非 127.0.0.1
能连上端口（比如 telnet localhost 8080 成功）但页面空白或报 502/503，大概率是服务根本没响应 HTTP 请求——它只绑定了 127.0.0.1，拒绝来自宿主机网络栈的流量。
进容器执行：netstat -tuln | grep :8080 或 ss -tuln | grep :8080
如果输出是 127.0.0.1:8080，就不是 0.0.0.0:8080，问题在此。
- Flask 启动必须加
-h 0.0.0.0，不能只写flask run - Node.js 的
app.listen(8080, '0.0.0.0')缺一不可，漏掉第二个参数就默认127.0.0.1 - Spring Boot 需显式配置
server.address=0.0.0.0，别依赖默认值 - Python HTTPServer 类需传
('', 8080)，不是('127.0.0.1', 8080)
Docker Desktop 的端口映射是否实际生效（而非仅显示“Up”）
docker ps 显示状态为 Up 不代表端口映射存在。真正要看的是 docker port 输出。
运行：docker port
期望看到类似：8080->8080/tcp 或 0.0.0.0:8080->8080/tcp
- 若无任何输出，说明启动时漏了
-p 8080:8080，或用了--network host却误以为自动暴露 - 若输出是
127.0.0.1:8080->8080/tcp，表示只允许本机访问，Mac/Windows 上 Docker Desktop 会遵守该限制，外部机器仍无法访问 - 检查是否误用
-p 8080（只指定宿主机端口），而没写容器端口，Docker 会随机分配，导致服务监听的端口和映射端口不一致
HTTP 协议层是否被拦截或响应异常
端口通、服务在 0.0.0.0 监听、映射也正确，但浏览器打不开——这时候要确认是不是协议或响应本身出问题。
在宿主机执行：curl -v http://localhost:8080
观察三件事：
– 是否收到 HTTP 状态码（如 200、404、500）
– Content-Length 或 Transfer-Encoding 是否异常
– 响应体是否为空或含明显错误（如 Node.js 的 ECONNREFUSED 错误页）
- 某些框架（如 Express）默认不设
Content-Type，浏览器可能拒渲染纯文本响应 - 前端静态资源路径错配（如 Nginx 配置里
root /app/dist但实际文件在/app/build）会导致 404，但页面看似“打不开” - Docker Desktop for Mac/Windows 的 DNS 解析有时会干扰
localhost解析，可试curl -v http://host.docker.internal:8080（仅限容器内调用）或直接换 IP
Mac/Windows 上 Docker Desktop 的特殊限制
Docker Desktop 不是原生 Linux，它的网络栈经由虚拟机（Hyper-V / WSL2 / HyperKit）中转，有些行为和裸机不同。
- WSL2 用户：宿主机
localhost可访问容器，但 WSL2 内部用localhost访问宿主机服务需走host.docker.internal；反过来，容器内用host.docker.internal才能访问宿主机服务 - Mac 用户：
docker run -p 127.0.0.1:8080:8080会严格绑定回环，连本机 Safari 都可能因安全策略失败，建议统一用-p 8080:8080 - 防火墙提示常被忽略：macOS 的“防火墙”偏好设置里，Docker Desktop 进程本身可能被阻止接受入站连接，需手动放行
- 端口占用检测不准：Docker Desktop 启动时若发现端口被占，有时静默跳过映射而不报错，务必用
lsof -i :8080确认宿主机端口空闲
最常被跳过的其实是服务监听地址和 docker port 验证这两步——很多人看到容器 “Up” 就以为万事大吉，结果卡在协议握手之前。
