容器状态显示 Up，浏览器却打不开；重建了一次容器，数据库里的数据没了；端口明明映射了，外部连接还是被拒。这些都是 Docker 上线时的常见故障，共同点是：容器能运行，不代表应用已经正确部署。

Docker 部署要同时考虑应用监听地址、容器端口、宿主机端口、安全规则和持久化存储。本文按“应用能启动、外部能访问、数据能保存、迁移能恢复”的上线顺序，讲国外云服务器部署 Docker 时的端口与数据卷设置。

第一步，搞清楚容器端口和宿主机端口的区别

应用监听端口是什么？

应用进程在容器内监听的端口，就是容器端口。比如一个 Web 应用监听容器内的 3000 端口，但容器启动了，这个端口也不会自动开放到公网。

端口映射的作用是什么？

Docker 端口映射，是把宿主机上的一个端口转发到容器内对应服务的端口。例如把宿主机的 8080 映射到容器内的 3000：

docker run -d -p 8080:3000 my-app

冒号左边是宿主机端口，右边是容器端口。示例里的数字只是举例，具体端口要按实际应用确认。

为什么映射了端口，外网仍然无法访问？

Docker 容器无法访问时，可以按下面的顺序一项项排查：

1. 应用是否真正启动并监听了预期端口

2. 容器端口是否正确映射到宿主机

3. 宿主机防火墙是否允许该端口

4. 云平台安全组或网络访问规则是否放行

5. 应用在容器内是不是只监听了 127.0.0.1，而不是 0.0.0.0

6. DNS 是否正确指向服务器公网 IP

排查时别图方便就开放所有端口。另外要留意，Docker 在默认配置下发布的端口，可能绕过 ufw 这类宿主机防火墙的规则，所以“防火墙里没放行却还能访问”并不罕见。要限制来源，得用 Docker 提供的方式，或者把端口只绑定到 127.0.0.1。

国外云服务器上的端口规划，应该如何设计？

只开放业务实际需要的公网端口

常见的 Web 应用，可以由 Nginx 或其他反向代理统一处理公网的 HTTP/HTTPS 请求，应用服务本身留在内部网络里，映射时写成 127.0.0.1:8080:3000，只让本机的反向代理访问。

数据库、缓存和管理端口不要直接暴露给所有来源

MySQL、Redis、管理面板和其他后台组件，按最小暴露原则处理。确实要远程管理，就结合可信来源 IP、VPN 等方式，限定能连接的来源和端口范围。

多个容器之间如何通信？

同一个 Docker 网络里的服务，可以按设计互相访问。用明确的服务名称、内部网络和配置文件管理依赖，不必把每个组件的端口都开放到公网。

数据卷为什么重要？容器删除后数据会去哪儿？

容器可写层不适合承担唯一的数据保存责任

容器随时可能被重新创建、升级或删除。重要的数据库数据如果只留在容器的可写层里，删除或重建容器时就可能丢掉。

Docker Volume 与绑定挂载分别适合什么场景？

两种方式的区别，大致是：

Docker Volume 由 Docker 管理，适合持久化数据库等容器数据

绑定挂载把宿主机上的具体路径映射进容器，适合需要明确管理主机文件或配置文件的场景

两者在权限设置、目录管理和备份策略上不一样，重要数据不要随手挂到临时目录。

数据库容器的持久化必须单独验证

以 MySQL 为例，要确认容器里的数据目录（常见是 /var/lib/mysql）映射到了正确的存储位置，并验证重启容器、重新创建容器之后数据还在。Redis 要不要启用持久化、MySQL 的数据怎么备份，要依据业务对数据可靠性的要求来定，用了 Volume 并不等于完成了备份。

用 Docker Compose 管理多容器应用时，需要检查什么？

先确认服务之间的依赖关系

应用服务要连数据库和缓存的话，服务名称、端口、环境变量和启动顺序，都要符合应用自身的要求。要明白，容器启动顺序正确，不等于依赖已经可用：数据库容器起来了，可能还在初始化。所以应用最好具备连接重试和错误处理，Compose 里也可以配合健康检查来控制。

环境变量和密钥如何管理？

普通配置与密码、API 密钥这类敏感信息要分开处理，别把凭证直接写进公开仓库或镜像里。

端口和 Volume 配置修改后如何验证？

按顺序检查 Compose 配置、实际运行的容器、端口映射、挂载路径、日志和业务连接。docker compose config 可以看合并后的最终配置，docker compose ps 看容器和端口，docker logs 看应用输出。

Docker 应用上线前的四项测试

网络测试：从服务器内部逐层确认到公网访问

先确认应用在容器内部可以访问，再从宿主机检查，最后用外部客户端测试。哪一层断了，问题就在哪一层。

持久化测试：重建容器后数据是否还在

在测试环境里执行容器停止、重建和数据核对，确认 Volume 绑定和数据路径正确。注意 docker compose down -v 会连命名卷一起删掉，测试时别误用。

安全测试：未使用的端口是否仍然对外开放

检查宿主机防火墙、安全组、端口映射和数据库访问范围，关掉不需要的公网暴露。

恢复测试：服务器故障后，如何重新部署？

保留 Compose 配置、镜像版本、环境变量配置说明和数据备份的恢复方法，让应用能在新的实例上重新部署起来。

国外云服务器部署 Docker，哪些问题需要提前与服务商确认？

恒讯科技的全球服务器产品，可以作为容器部署的基础资源，但是否适合某个 Docker 项目，要看目标系统、网络和存储需求。可以先向服务商确认：

目标产品是否支持所需的操作系统和 Docker 运行环境

服务器是否拥有满足需求的 CPU、内存和磁盘资源

公网 IP、带宽和防火墙规则是否适合应用的访问方式

后期能否扩容数据盘或迁移容器数据

部署与故障排查的责任，能否按项目需求安排

可以先从 全球服务器列表 了解产品，购买入口以匹配的当前产品页为准。

常见问题

1. Docker 容器启动正常，为什么公网仍然访问不到？

常见原因是端口没映射、应用只监听 127.0.0.1、防火墙或安全组没放行，或者 DNS 指向不对，按本文第一步的顺序逐项排查。

2. Docker 映射端口后还需要配置云服务器防火墙吗？

需要检查。宿主机防火墙和云平台的安全组规则都可能影响访问，要分别确认。

3. 删除容器以后，数据卷里的数据还在吗？

一般还在，除非连同卷一起删除（如 docker compose down -v）。重要数据仍要另外备份。

4. Docker 中的 MySQL 和 Redis 应该开放公网端口吗？

一般不建议。应优先通过内部网络访问，确需远程管理时，限制来源 IP。

5. 将 Docker 应用迁移到另一台服务器时，需要带走哪些文件？

Compose 配置、镜像版本信息、环境变量配置说明，以及数据卷或绑定挂载里的数据备份。

Docker 上线检查可以浓缩成四个动作：检查端口，确认网络规则，配置数据持久化，验证恢复流程。哪一步没验证过，就还不算部署完成。

咨询时，可以提供应用类型、操作系统要求、端口需求、数据量和访问地区，让销售核实对应的产品与环境。