新手教程:30 分钟跑起你的第一台云服务器(含 Docker 与 HTTPS)

30 分钟跑起第一台云服务器:选区域、建实例、配密钥,用 Docker Compose 部署应用、解析域名、Caddy 自动签发 HTTPS,命令可直接复制。

2026-09-26

30 分钟跑起第一台云服务器:选区域、建实例、配密钥,用 Docker Compose 部署应用、解析域名、Caddy 自动签发 HTTPS,命令可直接复制。

「云服务器怎么用」这个问题,大部分人卡住的不是难,而是不知道从哪一步开始:机器买了,SSH 连不上;连上了,不知道装什么;装完了,域名和 HTTPS 又不知道怎么弄。这篇按真实上线顺序走一遍——30 分钟跑起你的第一台云服务器,从选区域到浏览器里看到小锁,每条命令都能直接复制。

本文假设:一台全新的 Ubuntu 24.04 LTS 实例、一个已经解析到这台服务器的域名、你的电脑上能执行 ssh。还没买域名也能跟到最后,只是第八步的 HTTPS 先跳过,用 IP + 端口访问即可。

30 分钟路线图:每一步花多久

先看全局,再动手。整条链路只有 8 个动作,难度从「点点鼠标」到「贴一段配置」,没有需要翻文档的黑魔法。

时间动作完成的标志
第 0–3 分钟选区域 + 最小规格确定 2 核 2G / Ubuntu 24.04 / 40GB 系统盘
第 3–7 分钟创建实例,绑定 SSH 密钥与安全组拿到公网 IP 和密钥对
第 7–10 分钟第一次 SSH 登录命令行提示符出现在云主机上
第 10–14 分钟ufw + 系统更新 + 时区只剩 22 / 80 / 443 三个入口
第 14–19 分钟装 Docker 与 Compose 插件hello-world 打印成功
第 19–23 分钟Compose 部署一个 Nginx 站点curl 127.0.0.1 返回 200
第 23–26 分钟加 A 记录解析域名dig +short 拿到服务器 IP
第 26–30 分钟Caddy 自动签发 HTTPS 证书浏览器地址栏出现小锁
  1. 选区域、选最小规格、想清楚要不要开自动续费
  2. 创建实例:镜像用 Ubuntu 24.04 LTS,现场生成一对 ed25519 密钥
  3. 安全组放行三条规则:22(只对自己的 IP)、80、443
  4. SSH 登录,把默认用户和密钥权限确认一遍
  5. 最小加固:ufw + 自动安全更新 + 对时
  6. 用官方 APT 仓库装 Docker 与 Compose 插件
  7. 写一个 compose.yaml,把 Nginx 站点跑起来
  8. 解析域名,再让 Caddy 接管 80/443 签发证书

按这个顺序走,每一步都有明确的「做完了」标志,不用回头验证前面。反过来做(比如先配 HTTPS 再解析域名)会把大量时间浪费在等待和排错上。

第一步:选区域和规格,2 核 2G 够起步

第一台云服务器不用买大。 你现在的目标是跑通流程,不是承载流量——配置越复杂,出错点越多。如果只想开一台跑博客或测试,轻量应用服务器 这种「计算 + 存储 + 带宽打包计费」的形态更省心,不用自己算流量。

  • 系统:Ubuntu 24.04 LTS。文档多、软件源新(自带 Docker 官方仓库),apt 装任何东西都不会缺
  • 规格:2 vCPU / 2 GB 内存。跑 Nginx + Caddy + 一个轻量应用,长期 CPU 使用率通常在 20% 以内
  • 系统盘:40 GB SSD 够用。系统镜像本身占 3–6 GB,剩下的留给日志和构建产物
  • 带宽:1–5 Mbps 固定带宽,或直接选按流量计费。第一个站不会有大流量,先别为峰值买单
  • 区域:离用户近的那一个。面向中文用户的香港 / 新加坡 / 日本节点,回源延迟一般落在 15–40ms 区间

如果这台机器要跑训练任务、数据库或编译大型项目,规格另说。先按 2 核 2G 起步,因为大多数云服务商支持随时升降配:扩容几秒生效,缩容按比例退费,猜错的成本很低。

别跳过区域这一步。 区域决定了延迟、合规要求和备份位置,而且事后迁移要换 IP、重做解析、下游证书全部重签——是所有决策里最难撤回的一个。价格差异在 20% 量级时,延迟带来的转化损失往往更大。

第二步:创建实例,镜像、密钥与安全组一次配对

各家控制台的名字略有差别(创建实例 / 新建云主机 / Launch instance),但要填的东西是同一组。下面三处是新手最容易漏的,填错一项会让你在后面某一步卡住。

  1. 镜像:Ubuntu 24.04 LTS(x86_64)。不要选预装宝塔 / 1Panel 之类的第三方面板镜像,也不要选来源不明的 Marketplace 镜像——后面所有命令都按官方镜像写
  2. 规格:2 核 2G + 40GB 系统盘,存储类型选 SSD / 高性能云盘。计费方式先按量,测试完再转包月
  3. 登录凭据:在控制台现场生成一对 SSH 密钥(算法选 ed25519),或选「已有密钥」后粘贴自己的公钥。能在文档里看到 ubuntu 用户,就说明这是标准云镜像
  4. 网络:绑定一个弹性公网 IP;安全组只放行三条规则——22 端口来源填你自己的公网 IP(不要填 0.0.0.0/0),80 与 443 端口来源 0.0.0.0/0
  5. 收尾:实例命名成能认出来的名字(如 first-web-01),并确认自动续费是否开启——纯测试的机器到期就释放,别让它一直计费

私钥是私有的,别贴进任何在线工具、截图或聊天窗口。 控制台生成的私钥通常只完整展示一次,下载到本地后立刻收紧权限: chmod 600 ~/Downloads/你的密钥文件.pem 权限比 600 宽松(比如 644),OpenSSH 会直接拒绝使用这把密钥,报 UNPROTECTED PRIVATE KEY FILE。

在控制台里查到这台机器的公网 IP 并记下来。下面用 203.0.113.10 指代它,实际执行时换成你自己的 IP,或者直接用之后绑定的域名。

第三步:第一次 SSH 登录

在你自己的电脑上执行(不是服务器上):

ssh -i ~/Downloads/你的密钥文件.pem [email protected] 第一次连接会问 Are you sure you want to continue connecting (yes/no)?——这是首次连接在建立主机指纹,确认 IP 没输错后输入 yes。成功后你会看到类似 ubuntu@first-web-01:~$ 的提示符。 如果报 Permission denied (publickey),按顺序查三件事:① 用户名是 ubuntu 而不是 root(官方云镜像默认禁 root 直登);② -i 指向的是私钥,没有 .pub 后缀;③ 创建实例时绑定的公钥,和你手上这把确实是同一对。 另外注意安全组:如果 22 端口只放行了你家网络的公网 IP,而你的出口 IP 变了(换 WiFi、VPN、公司网络),就会连不上。查自己的公网 IP 用 curl ifconfig.me。

进去之后先花 30 秒确认环境,别急着装东西:

cat /etc/os-release | head -n 3 whoami ip -br addr curl -sI http://ifconfig.me whoami 应输出 ubuntu;ip -br addr 里能看到那块公网网卡;最后一条用来确认这台机器的出口 IP,方便你在安全组里放行 22 时填对来源。

再给 ~/.ssh/config 加一段,以后一个 ssh web 就能直连,不用记长命令:

Host web
  HostName 203.0.113.10
  User ubuntu
  IdentityFile ~/Downloads/你的密钥文件.pem
写完直接 ssh web 验证。这段配置就是后面加 deploy 用户、加新机器时唯一需要复制的东西。

把 ubuntu 当成你唯一的日常入口。 需要 root 的命令一律加 sudo,权限边界清晰、审计也干净。万一后面要建独立的 deploy 用户,直接把这份入口公钥复制过去就行。

第四步:最小加固:ufw 与系统更新

云安全组是第一道墙(流量到主机前就被丢弃),主机内的 ufw 是第二道墙。两道墙都留着,成本几乎为零。 顺序有讲究:先放行 22,再启用默认拒绝。这一步只做最小可用;正式对外服务前该补的另外 8 项,见 云服务器安全基线清单。

sudo ufw default deny incoming sudo ufw allow 22/tcp sudo ufw allow 80,443/tcp sudo ufw enable sudo ufw status verbose ufw allow 22/tcp 必须在 ufw enable 之前。 顺序反了会当场踢掉你当前的 SSH 会话。真被踢出去也不要慌:云厂商一般提供 VNC / 串口救援控制台,进去 sudo ufw disable 修好安全组再重开就行。 另一条同样重要:ufw 生效后不要顺手关掉云安全组的 22 端口——两道墙要同时是通的才连得上。

接着把系统补丁、时区和自动更新一次性处理掉。

sudo apt-get update && sudo apt-get -y upgrade sudo timedatectl set-timezone Asia/Shanghai timedatectl 最后一条会打出本地时间与 NTP 同步状态。时间不对会让日志时间线、证书有效期校验、cron 定时任务全部错乱,值得多花这 30 秒。 新装的机器通常欠几十个安全补丁,再打开自动更新: sudo apt-get install -y unattended-upgrades sudo dpkg-reconfigure --priority=low unattended-upgrades

把当前用户加进 docker 组能省掉成千上万次 sudo,但先知道代价。 sudo usermod -aG docker $USER 之后 docker 命令不再需要 sudo——而能操作 Docker 就等于能以 root 身份做任何事。个人项目图省事完全可以接受;多人共用的机器请老老实实写 sudo docker。

第五步:装 Docker,走官方仓库

生产机器建议走官方 APT 仓库:版本新,且能被系统包管理器正常升级。便利脚本 get.docker.com 适合一次性实验环境,装出来的版本不受 apt 管理,以后升级容易出岔子。

sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
第四行是导入 GPG 公钥,第五到七行是添加仓库源——$(. /etc/os-release && echo "$VERSION_CODENAME") 会自动取到当前系统代号(24.04 是 noble),所以这段命令换版本也照样能用。

装完启动并自检,这是整条链路上第一个真正的「做完了」标志:

sudo systemctl enable --now docker
systemctl is-active docker
docker compose version
sudo docker run --rm hello-world
systemctl is-active docker 期望输出 active;docker compose version 期望输出 Docker Compose version v2.x(v2 才是 docker compose 这种写法);最后一条会拉一个不到 30MB 的镜像并打印欢迎信息,看到 Hello from Docker! 就说明镜像仓库、容器运行时、网络全都正常。

报 permission denied while trying to connect to the Docker daemon socket? 说明当前用户还没进 docker 组。执行 sudo usermod -aG docker $USER 后必须退出 SSH 重新登录才生效(组信息在登录时加载),用 groups | tr " " "\n" | grep docker 确认。

第六步:用 Compose 部署第一个应用

现在把第一个应用放上去。用 Compose 的好处是以后换应用只改一个 YAML 文件,不用记 docker run 的一长串参数,也不用自己记容器名。

mkdir -p ~/site/nginx && cd ~/site cat > nginx/index.html <<'EOF' <!doctype html><meta charset=\"utf-8\"><title>it works</title> <h1>第一台云服务器,跑起来了</h1> EOF cat > nginx/default.conf <<'EOF' server { listen 80; server_name _; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ =404; } } EOF cat > compose.yaml <<'EOF' services: app: image: nginx:1.27-alpine restart: unless-stopped volumes: - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro - ./nginx:/usr/share/nginx/html:ro ports: - \"80:80\" EOF 最后那个 nginx:1.27-alpine 是官方精简镜像,几十 MB 起步快。restart: unless-stopped 让它随开机自启,容器意外退出也会被拉起。

启动与验收:怎么确认容器真的跑起来了

启动并验收:

cd ~/site && docker compose up -d
docker compose ps
curl -I http://127.0.0.1
docker compose ps 里 app 状态是 Up;curl -I 返回 HTTP/1.1 200 OK 和 Server: nginx/1.27.x。要跟日志用 docker compose logs -f app,改配置后用 docker compose restart app 生效(只改静态文件不用重启,挂载的是目录,刷新浏览器就够)。 如果 docker compose ps 显示 Exit (1),用 docker compose logs app 看真实原因,九成是 default.conf 语法错误——先 docker compose logs --tail 20 app 再动手改。

image: 和 build: 的区别先分清:拉现成镜像写 image: nginx:1.27-alpine;自己有 Dockerfile 写 build: ./app(第一次要加 --build 才会构建);两个都写则构建并按 image 命名产物。部署自己的应用时,把 image: 换成 build: ./app,其余流程一字不改。

看到 200 OK 的这一刻,服务器已经是一个能对外提供服务的网站了——只是还没人知道它的地址。下一步解决「别人怎么找到它」。

第七步:域名解析,两条记录搞定

把域名的 A 记录指向服务器公网 IP。多数控制台在「网站 / DNS / 域名解析」里操作,新增记录时填三项:主机记录、记录类型、记录值。

主机记录记录类型记录值用途
@A203.0.113.10裸域 example.com
wwwCNAME@www.example.com 跟随裸域

保存后等解析生效。全球 TTL 生效通常几分钟,本地缓存最久要等一个原 TTL 周期(常见 600 秒)。这段时间不要反复改配置,越改越慢。

dig +short example.com
dig +short example.com @1.1.1.1
curl -I http://example.com
dig +short 直接输出 203.0.113.10 就说明已生效;curl 返回 200 说明流量真的到了你的 Nginx。dig @1.1.1.1 是绕开本地 DNS 缓存直接问公共解析,排查「我这边不通但别人能通」时特别有用。 如果你用了 CDN,先把代理开关关掉(灰色小云朵 / DNS only)。下一步的 HTTP-01 证书验证需要请求直达源站,代理开着有时会卡住验证;证书签发成功后再打开代理。

第八步:上 HTTPS,让 Caddy 自动签证书

Caddy 的价值在于把证书变成零维护:自己申请、自己续期、到期前自动更换,回应用 Nginx + certbot 也能做到,但需要你记得手动 renew 并 reload。下面用 Caddy,主打省心。

做法是让 Caddy 接管 80/443 端口再反代到 Nginx,Nginx 则改为只在 Docker 内网可达。覆盖 ~/site/compose.yaml:

cat > ~/site/compose.yaml <<'EOF' services: app: image: nginx:1.27-alpine restart: unless-stopped volumes: - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro - ./nginx:/usr/share/nginx/html:ro caddy: image: caddy:2-alpine restart: unless-stopped ports: - "80:80" - "443:443" volumes: - ./Caddyfile:/etc/caddy/Caddyfile:ro - caddy_data:/data - caddy_config:/config volumes: caddy_data: caddy_config: EOF cat > ~/site/Caddyfile <<'EOF' example.com, www.example.com { reverse_proxy app:80 } EOF cd ~/site && docker compose up -d 注意 app 上的 ports: 已经整段删掉了——它不再直接对外,只通过 Docker 内网被 Caddy 访问。Caddyfile 里的 app:80 是 Compose 服务名,不要写成 127.0.0.1:80,那样 Caddy 容器会去找它自己,永远 502。Caddy 启动时会自动读取这个文件、发现域名并立刻去申请证书。

HTTPS 证书怎么签发与续期,以及 certbot 备选方案

证书这一步有三件事最值得先知道:证书被存在哪里、签发成功时日志长什么样、以及不想用 Caddy 时的等价做法。把这三点看懂,证书问题基本就能自己排掉。

caddy_data 这个卷是证书的存放位置,别省。 没有它,每次 docker compose down 都会让 Caddy 重新申请证书,很快撞上 Let's Encrypt 的速率限制(同一组域名每周 5 次),然后你会看到一堆 too many certificates already issued for this exact set of domains。真撞上了只能等一周,或用测试环境证书临时顶一下。

docker compose logs -f caddy | grep -iE 'certificate|error' 看到 certificate obtained successfully 就成功了,首次签发通常 5–20 秒。HTTP 会自动 301 跳到 HTTPS,这是 Caddy 的默认行为,不用额外配置。签发失败最常见的原因是域名还没解析到这台机器(dig 没返回 IP),或者安全组 / ufw 没放行 80。 证书续期由 Caddy 自己在到期前完成,不需要 cron。

想用 Nginx + certbot 的话,等价路径是: sudo apt-get install -y certbot python3-certbot-nginx sudo certbot --nginx -d example.com -d www.example.com 交互里选 Nginx 配置中的 1,certbot 会自动加上 443 监听和跳转。续期由 systemd timer 负责,第一次务必先干跑一次确认:sudo certbot renew --dry-run。这条路径要多背两个概念(证书链 + 定时续期),所以本文默认走 Caddy。

验收清单:怎么确认真的上线了

别凭感觉判断「应该成功了」,逐条跑一遍。任何一条不通,就回到对应章节修,不要往下走——很多「HTTPS 配好了但打不开」其实是第 8 条防火墙的问题。

#检查项命令期望结果
1本机服务活着curl -I http://127.0.0.1200 OK
2容器都在跑docker compose psapp 与 caddy 均为 Up
3端口在监听ss -tlnp | grep -E ':(80|443)'两个端口都有 docker-proxy
4域名已解析dig +short example.com输出服务器公网 IP
5HTTPS 可用curl -I https://example.com200 OK
6HTTP 跳 HTTPScurl -I http://example.com301,Location 是 https
7证书在有效期内echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -datesnotBefore 在过去、notAfter 在未来
8防火墙没挡住sudo ufw status verbose22 / 80 / 443 均为 ALLOW

最后在真实浏览器里打开 https://example.com 一次——浏览器比 curl 更严格,它会额外校验证书链、SNI 和混合内容。这一步通过,你的第一台云服务器就算正式上线了。

怎么做到「下次重来只要 5 分钟」:把 ~/site 里的 compose.yaml、Caddyfile、nginx/ 提交进一个 Git 仓库。重建机器时 git clone + docker compose up -d,配置一行都不用重写。可复现的部署本身就是最好的备份。

上线之后:备份、监控与新手最常踩的坑

  1. 备份:给系统盘开定时快照(每天一次、保留 7 天)。快照是云厂商侧操作、不额外占你的磁盘,但它不等于数据备份——数据库要自己导出并放到另一处
  2. 监控:装一个 Uptime Kuma 之类的探活工具,从外部每分钟拨一次你的域名,挂了立刻收到通知。没有外部探活,服务器半夜挂掉你只能等用户投诉才知道
  3. 日志轮转:docker compose logs 不会自动轮转,长期跑要在 daemon.json 里设 log-opts.max-size 与 max-file,否则单个日志文件能把 40GB 系统盘写满
  4. 凭证不进 Git:私钥和 .env 一旦进了仓库(哪怕后来删掉)就按已泄露处理,要轮换而不是只删文件

新手最常踩的四个坑:① 安全组只放了 22 忘了放 80/443,本机 curl 正常但外网打不开;② 域名解析指向了内网 IP 或换机前的旧 IP;③ ufw 先 enable 后放行 22,把自己锁在门外;④ caddy_data 卷没挂,证书反复重签触发速率限制。前三个两分钟内能定位,第四个最费时间。

如果你卡在任意一步,别反复重试——把报错原文、加上 docker compose ps 和 docker compose logs --tail 50 的输出、以及你执行到第几步,一并发给我们的工程师,我们陪你一起看。还没下单、想让工程师先帮你确认区域和规格再买的,也可以先来问一轮:第一台服务器选错的成本,比多花半小时高得多。

按自己的用量算一遍?

告诉我们区域和配置,工程师给出配置建议与报价;支持 USDT TRC-20 付款。

立即充值