Ubuntu VPS 配置：发布第一个 HTTPS 网站
这份教程从一台全新的 Ubuntu 24.04 LTS VPS 开始，带你用 Nginx 发布静态网站并启用 HTTPS。除了网页本身，还会验证独立管理员账号、SSH 密钥登录、证书续期，以及服务器重启后的访问。
VPSuntu · 更新： · 约 7 分钟阅读
本页目录
先准备服务器、域名和恢复入口
准备一台带公网 IPv4 的全新 Ubuntu 24.04 VPS，SSH 使用 22 端口，初始账号具备 sudo 权限，并有一个你能管理的域名。下一节先生成 SSH 密钥，再创建服务器。若空白服务器已经创建，可通过现有登录方式安装新密钥。客户端命令在 Linux、macOS 或 WSL 的 Bash 中执行；服务器命令在 SSH 会话内执行。如果示例路径已用于现有部署，先不要继续。
把 203.0.113.10 全部替换为服务器 IP，把 app.example.com 替换为自己的主机名；它们都是文档示例。下文初始账号为 ubuntu，请改为服务商实际提供的账号。调整登录或防火墙前，先打开恢复控制台。使用后面的 UFW 分支前，核对该镜像的防火墙说明；Oracle Cloud Ubuntu 镜像需要采用另一条路径。
创建 SSH 密钥，并选择正确的安装路径
在自己的电脑上创建专用密钥，按提示设置密钥口令。若同名文件已存在，请另选文件名并在后续命令中一致替换。.pub 文件是公钥，私钥文件应保留在你的电脑上。
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub尚未创建 VPS：现在创建 Ubuntu 24.04 服务器，将公钥填入服务商的 SSH 密钥字段。确认初始用户名后，直接进行下方的主机指纹核验，跳过已有服务器的复制命令。
已经创建但尚未部署的空白 VPS：保留当前可用的 SSH 会话。在电脑的另一个终端中，使用现有认证方式复制新公钥。将 existing_vps_key 换成当前私钥文件名。如果现有连接使用密码或 SSH agent，省略 -i ~/.ssh/existing_vps_key；不需要更改服务器的认证策略。
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub回到已有的服务器会话，验证上传的公钥文件，再追加到初始账号的 authorized_keys。追加会保留原有条目，额外换行也能处理原文件末尾没有换行的情况。这些命令针对你自己的初始账号。若没有任何可用登录方式，先通过服务商的恢复流程解决访问问题。
if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
mkdir -p ~/.ssh
chmod 700 ~/.ssh
printf '\n' >> ~/.ssh/authorized_keys
cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
fi无论采用哪条路径，首次接受 SSH 连接前，都应将提示的主机指纹与可信恢复控制台中的对应主机公钥核对。对于 Ed25519 主机密钥，在该控制台运行：
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub在电脑上用新密钥建立一个新连接。确认成功前，保留原来的访问方式。
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10再从电脑的另一个终端复制公钥，供下一节的新管理员账号使用。若已有服务器路径已经上传了这个临时公钥文件，可以再次复制。
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub创建独立管理员，验证登录和 sudo
先在服务器运行 getent passwd deploy，预期不返回任何账号。如果 deploy 已存在，选一个未使用的用户名，先替换后文所有相关用户名、主目录路径和组名，避免覆盖别人的密钥文件。
确认镜像与资源，查看系统更新，然后创建管理员。为 sudo 提示设置强密码。install 命令会把密钥文件交给该账号，并限制文件权限。
cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keys在电脑另开终端，以新管理员身份登录：
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10在这个新服务器会话中运行 sudo，输入 deploy 的密码后应输出 root。登录和 sudo 都验证通过后，在新会话中继续，同时保留原来的访问入口。
sudo whoami安装 Nginx，按镜像要求配置防火墙
先在服务器安装 Nginx。虚拟机内部防火墙和服务商网络防火墙都会影响访问；调整期间保持恢复控制台与有效 SSH 会话可用。
sudo apt install nginx
sudo systemctl enable --now nginx在服务商防火墙中，允许管理位置访问 TCP 22，允许网站访客访问 TCP 80/443。如果 SSH 使用其他端口，保留实际端口规则。网络层放行不能解除虚拟机内部的阻断。
Oracle Cloud Ubuntu 镜像：跳过下面整段 UFW 命令。Oracle 提醒，UFW 可能破坏镜像必需的防火墙规则，甚至导致无法启动。保留系统提供的 iptables 规则，包括保护 iSCSI 启动盘和块存储卷的规则。通过 OCI 安全列表或网络安全组，以及文档要求的内部防火墙规则开放 HTTP/HTTPS。不要清空现有规则，也不要替换镜像的防火墙软件包。
其他全新 Ubuntu 镜像的 UFW 分支：只有服务商明确支持 UFW，且镜像不依赖其他受管理防火墙配置时，才使用以下命令。启用前先放行真正使用的 SSH 端口；示例假设为 22。
sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose完成任一分支后，都要重新建立 SSH 连接。旧会话仍然在线不能证明新连接正常。申请证书前，下一节的外部 HTTP 检查也必须通过。排查访问故障时继续保留既有登录方式。
为网站创建独立的 Nginx 配置
在服务器创建新的站点根目录和配置文件，把命令块中的主机名改成自己的。保留带引号的 EOF 标记，防止 shell 提前展开 $uri 等 Nginx 变量。
sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="en"><title>First deployment</title><h1>Ubuntu VPS is serving this page</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
listen 80;
listen [::]:80;
server_name app.example.com;
root /var/www/first-site;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -t在服务器上，仅当配置测试成功时才重新加载：
sudo systemctl reload nginx修改 DNS 前，先从电脑把这个主机名的请求发到服务器 IP。应显示你创建的标题，而不是 Nginx 默认欢迎页。
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/接入 DNS，签发 HTTPS 证书
为主机名创建指向 VPS IPv4 的 DNS A 记录。只有服务器上的 IPv6 已验证可用，才发布 AAAA 记录。过期或错误的 AAAA 可能把访客和证书验证请求导向其他位置。本例假设 DNS 直接指向 VPS，没有代理层。
在电脑上请求 http://app.example.com/，这次不加 --resolve。返回你的网页后再继续。在服务器安装 Ubuntu 软件仓库中的 Certbot 及 Nginx 插件；这些包需要 Universe 仓库，若提示找不到软件包，先排查再往下操作。
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timer按提示填写邮箱并确认条款。Certbot 会修改该站点配置并启用 HTTP 到 HTTPS 的重定向。检查续期定时器是否已安排运行；若未启用，可执行 sudo systemctl enable --now certbot.timer。保持 80 端口可达，供 HTTP 证书验证和续期使用。
从外部验证，并测试重启后的访问
在电脑上检查重定向、证书和页面内容。HTTP 应跳转到 HTTPS，HTTPS 请求应成功且显示你的标题。不要给 curl 加 -k，它会掩盖证书验证失败。
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/当部署仍处于测试阶段时，在服务器执行 sudo reboot。恢复后用 deploy 重新登录，检查 systemctl is-active nginx，再从外部请求 HTTPS。重启会主动断开 SSH；若机器没有恢复，使用控制台排查。
处理失败项，并保存重建资料
小屏幕上可左右滚动表格，查看完整内容。
| 现象 | 首先检查 |
|---|---|
| SSH 连接超时 | IP、服务商防火墙、系统防火墙及恢复控制台 |
| Permission denied (publickey) | 用户名、私钥及 authorized_keys 权限 |
| 出现 Nginx 默认页 | DNS 指向、server_name 和已启用站点 |
| 证书验证失败 | 公网 A/AAAA 记录与 80 端口可达性 |
| 修改后 Nginx 失败 | sudo nginx -t 与 sudo journalctl -u nginx -n 50 --no-pager |
登录失败时，先用SSH 排查指南区分网络、服务和密钥问题，再修改访问设置。
把网站文件、Nginx 配置、DNS 记录和重建步骤保存到 VPS 之外，先在另一台机器恢复一次，再依赖这套流程。如果备份证书私钥，要使用受保护的存储。添加可用性和证书到期通知；今天检查成功不代表明天续期也会被持续监控。
可以先做文件备份与恢复练习，验证静态页面和 Nginx 配置的独立副本，不覆盖正在运行的网站。完整恢复还需要其余资源、证书和服务配置。
本部署只提供静态文件。数据库或应用运行时需要单独的服务配置和备份方法。增加这些组件时，参考资源测量指南。
常见问题
这些命令能直接用于已有网站吗？
先在独立测试 VPS 上练习。示例会创建文件、启用防火墙，并让 Certbot 修改 Nginx。已有服务器应先检查现有站点、访问规则和恢复流程。
教程会安装 WordPress、Node.js 或数据库吗？
不会，最终结果是静态 HTTPS 网站。先保留这个已验证的基础，再添加应用运行时，测试启动、健康检查和数据恢复。