第一次用 VPS 部署 Docker 封面

第一次用 VPS 部署 Docker：端口、数据卷和 HTTPS 最容易错在哪里？

从域名解析、Docker 官方安装、Compose 文件到 HTTPS 和数据卷，完成第一个可回滚的 VPS 部署。

文档维护：MatrixIDC 1 人阅读

第一次用 VPS 部署 Docker：端口、数据卷和 HTTPS 最容易错在哪里？

第一次在 VPS 上跑 Docker，最常见的体验是：容器显示 Up，浏览器却打不开；重建后数据没了；HTTPS 一直签不下来；为了排错把一堆端口暴露到公网。问题通常不在 Docker 本身，而是域名、网络、容器和数据之间的边界没有先画清楚。

**先说结论：**第一个 Docker 项目应选一个可随时删除、可用 Compose 重建的轻量 Web 服务。先让域名指向 VPS，明确只开放需要的端口，把数据放进命名卷或宿主机目录，再让反向代理处理 HTTPS。不要一上来就把数据库、面板和多个业务混在一台新机器上。

域名 HTTPS Docker 应用与数据卷请求路径图

开始前先确认四个前提

  1. VPS 已完成基础安全检查，有可用普通管理员账号和 SSH 密钥。
  2. 域名 A/AAAA 记录已指向 VPS；DNS 未生效时不要急着申请证书。
  3. 只公开 Web 所需的 80/443；数据库、缓存和管理端口不默认对公网开放。
  4. 你知道数据放在哪里，以及删掉容器后数据是否仍在。

没有域名时，先做产品验证或解析演练也可以，见 顶级域名怎么免费获取，特别适用于做产品验证。

按 Docker 官方文档安装 Engine 和 Compose

以下示例针对 Debian 12。Docker 官方当前建议通过它的 apt 仓库安装 docker-ce、containerd.io 与 Compose 插件；安装前也应确认没有冲突旧包。完整说明以 Docker 的 Debian 安装文档 为准。

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

hello-world 成功只说明 Engine 可运行，不代表 Web 服务已经安全上线。

用最小 Compose 项目理解组件关系

在独立目录创建 compose.yaml。下面以测试应用和 Caddy 反向代理为例：应用不直接发布端口，只有代理对公网开放。

services:
  app:
    image: traefik/whoami:v1.10
    restart: unless-stopped
    networks: [web]

  caddy:
    image: caddy:2.10
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks: [web]

volumes:
  caddy_data:
  caddy_config:

networks:
  web:

同目录创建 Caddyfile，把 example.com 换成已经解析到本机的域名：

example.com {
  reverse_proxy app:80
}

启动并检查：

docker compose up -d
docker compose ps
docker compose logs -f caddy

DNS、80/443 和域名都正确时，代理才能完成证书申请。证书失败先看解析、端口可达性和是否有其他服务占用 80/443，而不是盲目重启。

Docker 容器更新与持久化数据备份图

数据卷决定了更新后数据还在不在

容器应被视为可替换的运行单元；数据库、上传文件和证书数据不能只留在容器可写层。上例的 caddy_data 与 caddy_config 是命名卷，容器重建后仍可挂载。真实应用还要为数据库和上传目录单独规划数据卷，并纳入异地备份。

三个最容易误判的点

现象 常见原因 先查什么
容器 Up，但域名打不开 DNS、端口、防火墙或代理配置不通 解析、80/443、代理日志
重建后配置或数据没了 数据写进容器层 Compose 的 volumes 与备份
开了 UFW 仍被外部访问 Docker 发布端口的规则与预期不同 Docker 官方文档和实际暴露端口

FAQ

为什么不直接把应用映射到 80 端口？

单个练习可以，但反向代理能统一处理域名、HTTPS 和多个应用路由，也让应用留在内部网络。

docker compose down 会删除数据卷吗？

默认不会删除命名卷；加 -v 才会删除。无论哪种情况，上线前都要确认卷名、备份位置和恢复步骤。

1 核 1GB 能跑 Docker 吗？

能跑最小测试，但镜像拉取、反向代理、应用与数据库叠加后容易紧张。先观察内存、磁盘和日志，再决定是否升级。

部署 New API 等有密钥的服务时，还要把环境变量、日志和上游授权边界单独管理，见 如何用 VPS 搭建 New API 中转站。需要 Docker 学习、建站或轻量应用 VPS 时，可从 MatrixIDC 先按域名、端口和数据需求核对配置。