假设一台新交付的香港服务器已经能通过 SSH 登录，工程人员准备放上第一个页面。此时“部署完成”不应只看安装命令是否成功，而要沿着一条可验证的路径检查：管理员能持续登录、Web 服务在本机返回预期内容、外部网络能通过服务器公网 IPv4 访问，并且重启后服务仍能启动。

开始前，至少准备好服务器公网 IPv4、可登录且具有 sudo 权限的账号及其 SSH 私钥、管理平台的控制台入口，以及可以修改入站访问规则的权限。下面以全新安装的 Ubuntu 24.04、部署一个不含敏感信息的静态页面为例；命令中的 SERVER_IPV4 必须替换为实际公网 IPv4。如果服务器已有网站或正在运行其他 Web 服务，应先查清现有配置，不能直接套用新机步骤。

先分清：登录成功不等于网站可用

典型现场是 SSH 登录正常，浏览器访问公网 IP 却一直等待。可能的原因并不只有 Web 服务：入站规则未放行、服务没有监听、配置未生效，或者访问到了另一份默认页面，都可能表现为“网站打不开”。

因此，工程人员先把本次交付范围限定清楚：

• 管理入口：从预定的管理网络，使用已有账号和密钥登录 SSH，并能执行 sudo。
• 应用入口：仅开放测试所需的 HTTP 端口，由 Nginx 返回一段可辨认的静态内容。
• 恢复入口：在调整入站规则或网站配置前，确认管理平台控制台可用；如有快照能力，可先保存当前状态，但快照不能替代逐项回滚。

这个页面只用于确认基础部署链路。它不接收密码、令牌或业务数据；HTTP 明文访问成功，也不代表需要登录或传输敏感信息的业务已经具备上线条件。

查看新机状态，再决定能否继续

先通过 SSH 登录，在服务器上确认系统、地址、磁盘和正在监听的端口：

cat /etc/os-release
ip -br address
ip route
df -h /
sudo -v
sudo ss -lntp

/etc/os-release 应与准备操作的 Ubuntu 环境一致；ip route 应能看到可用的出站路由；根分区不能处于空间耗尽状态。ss 的结果要重点查看 SSH 使用的端口以及 TCP 80 端口：如果 80 已被其他服务占用，先识别其进程和用途，不要为了继续安装而停止未知服务。

再从管理员自己的电脑打开第二个终端，重新建立一次 SSH 连接，并验证 sudo。这样做是为了确认当前会话并非唯一入口。若打算收紧 SSH 入站来源，先确认自己的出口公网 IP 是否固定或可控；规则应先允许实际管理来源，再在第二个终端复测，不能先封闭入口再尝试登录。

入站规则也要在此时核对：SSH 所用端口应只对需要管理的来源开放；本次测试所用 TCP 80 应允许预定的外部访问来源。若服务器内部还启用了主机防火墙，管理平台放行并不足够，主机防火墙也必须允许相应流量。修改规则的影响范围可能是整台服务器的入站连接；每改一项，都应立即用新连接验证。失联时优先通过已确认可用的管理平台控制台恢复原规则，不要依赖即将被修改的 SSH 会话。

安装服务并放上可识别的页面

以下操作适用于前述全新 Ubuntu 环境。安装前，应确认不是在接管已有网站；安装软件包可能启动 Nginx，并使默认页面开始监听 80 端口。

sudo apt update
sudo apt install nginx curl
sudo systemctl status nginx --no-pager
sudo ss -lntp

如果安装失败，先处理命令显示的软件源、磁盘空间或软件包错误，不要继续写网站配置。如果 80 端口被非 Nginx 进程占用，也应先停在这里判断是否存在原有业务。

为避免把“打开了 Nginx 默认欢迎页”误认为部署成功，建立独立目录，放入明确的测试标记。执行前确认该目录尚未用于其他网站；下面的写入操作会创建或覆盖同名 index.html。

sudo mkdir -p /var/www/hk-first
sudo tee /var/www/hk-first/index.html >/dev/null <<'EOF'



  
  


  
HK-FIRST-READY


EOF

接着为这个页面建立独立的网站配置。执行前先检查 /etc/nginx/sites-available/hk-first.conf 不存在，避免覆盖已有配置。把示例中的 SERVER_IPV4 改成实际公网 IPv4；这里只监听 IPv4 的 TCP 80。

server {
    listen 80;
    server_name SERVER_IPV4;

    root /var/www/hk-first;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

将上面的内容保存为 /etc/nginx/sites-available/hk-first.conf。可使用 sudoedit /etc/nginx/sites-available/hk-first.conf 编辑：保存后先核对 IP 和文件内容，不急于重载服务。

在全新安装、尚未添加其他网站的前提下，查看启用目录：

ls -l /etc/nginx/sites-enabled/

如果其中只有指向系统默认站点的 default 链接，可以先启用新站点，再把默认站点链接移出启用目录。以下移动操作只适用于已确认 default 是默认站点链接、备份位置不存在、没有其他网站依赖它的情况；它会改变随后重载时的默认站点行为。

sudo ln -s /etc/nginx/sites-available/hk-first.conf /etc/nginx/sites-enabled/hk-first.conf
sudo mv /etc/nginx/sites-enabled/default /etc/nginx/default-site.saved
sudo nginx -t

若机器没有 default 链接，跳过 mv，只建立新站点链接并运行 sudo nginx -t。若已有其他站点、同名链接或不同的 80 端口配置，不要移动文件或继续套用命令，应先检查现有 Nginx 配置，确定站点匹配关系。

只有 nginx -t 明确显示配置检查成功，才重载服务：

sudo systemctl reload nginx
sudo systemctl enable nginx
sudo systemctl is-active nginx

enable 用于设置开机启动；is-active 用于检查当前运行状态。两者不能替代外部访问测试。

按“本机、外部、重启后”的顺序验证

先在服务器本机请求新站点。Host 请求头要与配置中的公网 IPv4 一致，尤其在仍有其他站点配置时，不能只用 curl http://127.0.0.1/ 判断命中了谁。

curl -4 -i -H 'Host: SERVER_IPV4' http://127.0.0.1/

预期结果是 HTTP 响应成功，正文包含 HK-FIRST-READY。如果返回 Nginx 默认欢迎页或别的网站页面，说明请求没有命中预期配置；如果连接被拒绝，则先检查服务状态和监听端口。不要在本机结果不正确时，先去反复修改外部入站规则。

本机通过后，从服务器之外的网络访问公网地址：

curl -4 -i --connect-timeout 5 http://SERVER_IPV4/

外部响应也应包含同一标记。不要用服务器自己访问自己的公网 IP 来替代这一步：这种访问路径未必等同于外部用户路径。

最后，在控制台入口、SSH 登录和外部页面访问都已确认可用的前提下，安排一次重启验证。重启会中断当前连接，应避开已有业务操作窗口；如果无法接受中断，可以先记录为待验证项，不能把它写成已经通过。

sudo reboot

等待服务器重新启动后，分别检查 SSH 登录、Nginx 状态，以及外部访问是否仍返回 HK-FIRST-READY。如果重启前可用、重启后不可用，应从控制台检查系统启动和 Nginx 状态，再查服务日志，而不是立即重装服务器。

失败时沿访问路径回退

排查顺序从低风险检查开始，尽量一次只改一项：

1. SSH 无法新建连接：先用管理平台控制台核对服务器运行状态、SSH 服务及近期调整的入站规则。若故障紧随规则变更出现，优先恢复原规则。不要关闭仍可用的旧 SSH 会话。
2. 本机请求失败：运行 sudo nginx -t、sudo systemctl status nginx --no-pager 和 sudo ss -lntp。配置测试失败看报错文件与行号；服务未运行看服务日志；没有监听 80 则检查启动情况及端口占用。
3. 本机正确、外部超时：先确认请求使用的公网 IPv4，再检查管理平台入站规则和已启用的主机防火墙。超时与返回错误页面不同，不能仅凭浏览器提示就认定是 Nginx 配置问题。
4. 外部有响应但内容不对：检查访问的 IP、Nginx 的 server_name、启用目录中的链接，以及是否仍存在其他站点配置。此时网络链路至少已到达某个 HTTP 服务，重点应转向站点匹配。

如果问题发生在启用新站点后，并且此前确实按上述步骤备份了默认站点链接，可在控制台或仍可用的 SSH 会话中回滚。以下命令会移除本次创建的站点链接并恢复默认站点链接；执行前要核对两个路径指向预期文件，避免影响后来新增的网站。

sudo unlink /etc/nginx/sites-enabled/hk-first.conf
sudo mv /etc/nginx/default-site.saved /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

若最初没有默认站点链接，则不要执行恢复 default 的 mv；只移除本次新建的链接，检查配置后重载。若 nginx -t 未通过，先修复或恢复文件，不要强行重载。回滚网站配置不会自动撤销入站规则变更，规则也应对照变更前记录单独恢复。

这次部署最容易漏掉的不是安装命令，而是三个不同的证据：新 SSH 会话仍能进入、本机命中的是自己放置的页面、外部访问拿到的也是同一页面。再加上重启后的复测，才能把“服务刚才启动了”与“基础部署持续可用”区分开来。