Docker 容器已经处于运行状态，docker ps 里也能看到端口映射，但浏览器访问云服务器 IP 加端口仍然超时。这类故障看起来像是 Docker 网络坏了，实际可能卡在容器应用、宿主机监听、防火墙或云平台入口中的任意一层。
排查时不要一开始就重建容器，也不要同时关闭所有防护。按请求经过的路径逐层测试，通常几分钟就能确定流量到底停在哪里。
先看端口是否真正发布
先执行：
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'如果 PORTS 一栏只显示 80/tcp，它只是镜像声明的容器端口，并不代表宿主机已经对外提供访问。真正发布成功时，常见结果类似：
0.0.0.0:8080->80/tcp这里表示宿主机的 8080 转发到容器内的 80。Docker 官方文档也说明，桥接网络中的容器端口默认不会直接对宿主机外部开放，需要使用 -p 或 Compose 的 ports 发布。
创建容器时可以使用：
docker run -d --name web -p 8080:80 nginx已经创建的容器不能通过简单命令补加端口映射，通常需要保留数据卷和环境变量后重新创建。操作前先保存当前启动参数，避免为了修端口丢失挂载目录或应用配置。
容器里的服务是否真的在监听
端口发布只是转发入口，容器内还必须有服务接收请求。先从宿主机进入容器检查：
docker exec -it web sh
ss -lntp精简镜像没有 ss 时，可以直接在容器内访问本地服务：
wget -S -O- http://127.0.0.1:80如果容器内访问也失败，问题不在外部防火墙，而在应用没有启动、监听端口写错或进程启动后退出。此时查看日志更有效：
docker logs --tail 100 web还要注意监听地址。应用只监听 127.0.0.1 时，容器网络接口收到的请求可能无法进入。用于容器对外服务的程序通常需要监听 0.0.0.0，但具体配置项应以该应用文档为准。
从宿主机测试映射端口
容器内服务正常后，在宿主机执行：
curl -v http://127.0.0.1:8080
ss -lntp | grep ':8080'如果本机访问成功，说明容器应用和 Docker 端口转发基本正常，故障范围已经缩小到宿主机外部。若本机也失败，应重新核对端口方向。8080:80 左边是宿主机端口，右边是容器端口，把两边写反是常见错误。
还可以查看 Docker 保存的映射：
docker port web
docker inspect web不要只凭 Compose 文件判断。配置文件已经修改但容器没有重新创建时，实际运行参数仍可能是旧值，最终应以 docker ps 和 docker inspect 的结果为准。
检查宿主机防火墙
不同系统可能使用 UFW、firewalld、iptables 或 nftables。先确认当前启用的是哪一套，不要在不清楚规则来源时混用多种命令。
Ubuntu 常见检查方式：
sudo ufw status numberedRocky Linux、AlmaLinux 常见检查方式：
sudo firewall-cmd --list-allDocker 会为端口发布创建 NAT 和过滤规则，Docker 官方文档特别提醒，容器流量与 UFW 的处理顺序并不等同于普通宿主机服务。不要把关闭 UFW 后能够访问，直接当成永久关闭防火墙的理由。
需要限制容器外部访问时，应结合当前 Docker 使用的 iptables 或 nftables 后端设计规则，并优先在 DOCKER-USER 等合适链路处理。生产服务器修改前要保留现有规则，避免远程 SSH 一并被阻断。
云平台入口规则也要核对
宿主机本地访问成功、服务器防火墙也允许端口，但公网仍超时，就要检查云平台控制台的安全组或防火墙。入站规则至少要匹配协议、目标端口和允许来源。
例如应用使用 TCP 8080，却只开放了 UDP 8080，结果仍然无法访问。来源地址如果只允许办公网 IP，手机网络或家庭宽带测试也会超时。
我在不同平台部署容器时，会把云平台入口和系统内防火墙当成两道独立检查。像 萤光云 适合需要固定配置长期运行的站点，LightNode 支持按小时计费，调整架构或换地区验证访问链路时更灵活。无论使用哪家，控制台允许端口不等于系统内部一定允许，反过来也一样。
为了快速测试而把来源设置成全部地址时，要确认应用本身有身份验证，测试结束后再缩小允许范围。数据库、Redis、管理面板等端口不建议直接暴露给公网。
绑定地址可能限制访问范围
端口发布还可以指定宿主机地址：
docker run -d -p 127.0.0.1:8080:80 nginx这样服务只允许从宿主机本地访问，公网访问当然会失败。这种写法常用于让 Nginx 反向代理后端容器，本身并不是错误。
如果应用本来就只应该通过域名和 HTTPS 提供服务，保持 127.0.0.1 绑定往往比直接开放高位端口更安全。此时应检查反向代理配置，而不是把绑定地址改成全网可访问。
需要公网直连时，映射通常会显示为 0.0.0.0:端口 或指定的公网接口地址。修改前先确认业务入口设计，避免为了通过测试破坏原有隔离。
用外部网络做最终验收
本机 curl 成功只是中间结果。最终应从另一条网络访问云服务器公网 IP 和目标端口，同时观察服务器是否收到连接：
sudo tcpdump -ni any tcp port 8080如果外部访问时抓不到任何数据包，优先检查云平台入口规则、上游防护和目标 IP。能抓到 SYN 但没有正常响应，再回到宿主机规则、Docker 转发和应用日志继续定位。
验收时还要确认重启后的表现。Compose 项目可以执行一次受控重启，核对容器是否自动启动、端口映射是否仍然存在、反向代理健康检查是否恢复。真正修好应满足容器内、本机映射端口和外部入口三层都能按预期访问。
常见问题
EXPOSE和端口映射是一回事吗？
不是。EXPOSE 主要描述镜像计划使用的端口，不会自动把端口发布到宿主机公网。
docker ps显示0.0.0.0:8080->80/tcp，为什么仍然超时？
继续检查容器内服务是否监听、宿主机防火墙、云平台安全组以及访问的公网 IP 是否正确。
可以直接关闭防火墙测试吗？
不建议在远程生产服务器上整体关闭。更安全的做法是查看规则命中情况，临时增加范围明确的测试规则，并保留回滚方法。
数据库容器也可以用-p发布吗？
技术上可以，但公网直接暴露数据库风险很高。优先使用内网、Docker 网络、访问白名单或安全隧道。
