首次部署香港服务器时，先把目标限定为四项：能通过管理入口登录、系统基础状态正常、只开放必要端口、能从服务器外部访问一个明确的健康检查地址。完成这四项后，再部署业务程序，比一开始同时配置域名、证书、数据库和监控更容易定位问题。

以下步骤以 Ubuntu Server 22.04/24.04 LTS、systemd、IPv4、公网地址、具备 root 或 sudo 权限 为例，并假定可以使用服务商控制台或带外终端。若实际系统不是 Ubuntu，不要直接照搬 apt、ufw 和服务名，应先根据系统信息替换命令。

一、部署前确认目标状态和前置条件

开始前准备以下信息：

最小验收状态可以定义为：

• 使用新建的管理账号通过 SSH 登录成功；
• SSH 服务处于运行状态，磁盘、内存和系统日志没有明显错误；
• 防火墙仅放行必要端口；
• 本机健康检查成功；
• 从外部网络使用公网 IP 访问健康检查成功；
• 出现异常时，可以通过控制台恢复 SSH 或撤销最近一次配置。

如果服务商侧存在安全组、访问控制列表或云防火墙，服务器内部的防火墙规则不能替代它。外部策略至少要允许管理端到 SSH 端口的访问；若要做 HTTP 验证，还要允许 TCP 80。规则名称和控制台位置因环境而异，不应根据其他服务器的配置直接猜测。

二、首次登录后先检查系统和网络

使用初始账号登录后，不要立即修改 SSH 端口或关闭 root 登录，先记录当前状态。下面的命令适用于 Ubuntu Server：

cat /etc/os-release
hostnamectl
ip -brief address
ip route
df -hT
free -h
sudo ss -lntup
sudo systemctl --failed
sudo journalctl -b -p err --no-pager

重点查看：

1. ip -brief address 是否显示预期网卡和公网地址；
2. ip route 是否存在默认路由；
3. df -hT 是否有根分区接近满载；
4. ss -lntup 当前到底有哪些监听端口；
5. systemctl --failed 是否存在启动失败的服务；
6. 当前启动周期的日志是否有文件系统、网络或认证错误。

如果公网地址未出现在服务器网卡上，不要急着修改路由。某些环境可能通过 NAT 或其他网络方式提供访问，此时应以服务商控制台给出的连接方式和端口映射为准。

主机名和时区也应明确，但不要把服务器所在地区自动等同于业务时区。日志由香港本地团队查看时，可以按实际运维习惯设置：

timedatectl status
sudo timedatectl set-timezone Asia/Hong_Kong
timedatectl status

只有在确认业务、日志和监控都需要该时区时才执行设置。时区修改不会改变网络位置，但会影响日志时间、定时任务和故障排查记录。

三、先建立可恢复的管理账号

1. 创建 sudo 管理账号

不要在还没有备用登录入口时修改现有 SSH 认证方式。先创建一个独立管理账号，例如 deploy：

sudo adduser deploy
sudo usermod -aG sudo deploy
id deploy

adduser 会提示设置密码。若环境要求仅使用 SSH 密钥，也建议先保留一个可通过控制台恢复的认证方式，待新账号验证成功后再收紧策略。

2. 配置 SSH 公钥

在管理电脑上查看公钥内容：

cat ~/.ssh/id_ed25519.pub

如果本机没有该文件，应先在本机生成密钥；私钥只保存在管理电脑上，不能粘贴到服务器或发送给他人。

在服务器上创建密钥目录：

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudoedit /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

把管理电脑中的公钥单行内容粘贴到 authorized_keys，不要换行，也不要粘贴私钥。

在当前 SSH 会话保持不关闭的情况下，从管理电脑新开一个终端测试：

ssh -o PreferredAuthentications=publickey deploy@PUBLIC_IP

将 PUBLIC_IP 替换为实际公网地址。如果新账号无法登录，先检查公钥、用户名和权限，不要急着关闭初始账号的登录能力。

3. 可选的 SSH 认证收紧

确认新账号已经能够独立登录，并且控制台可用后，才考虑关闭密码认证。该操作可能造成远程锁定，执行前应备份配置，并保留当前会话。

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d%H%M%S)
sudo install -d -m 755 /etc/ssh/sshd_config.d
sudoedit /etc/ssh/sshd_config.d/99-first-deploy.conf

配置文件内容可写为：

PermitRootLogin prohibit-password
PasswordAuthentication no

保存后先检查语法，再重新加载服务：

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'

如果 sshd -t 报错，不要执行 reload。若新配置加载后新会话无法建立，可通过原有会话或控制台移除该配置文件，再检查并重新加载：

sudo mv /etc/ssh/sshd_config.d/99-first-deploy.conf \
  /etc/ssh/sshd_config.d/99-first-deploy.conf.disabled
sudo sshd -t
sudo systemctl reload ssh

这条回滚只影响刚创建的 SSH drop-in 配置，不会删除用户和密钥。

四、更新系统并设置必要的防火墙规则

1. 更新软件包

新服务器通常需要先更新包索引和已安装软件。批量升级可能触发服务重启，因此应在业务尚未上线时执行；如果环境支持快照，建议在升级前创建快照或保留可重建记录。

sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get install -y ca-certificates curl ufw nginx

检查是否需要重启：

if [ -f /var/run/reboot-required ]; then
  echo "A reboot is required"
else
  echo "No reboot flag found"
fi

如果出现需要重启的提示，应先确认新账号可以登录、控制台可用，再安排重启。不要在 SSH 认证尚未验证时直接重启服务器。

2. 启用主机防火墙

启用防火墙前必须确认 SSH 端口已经放行。下面以默认 SSH 端口 22、HTTP 端口 80 为例；如果 SSH 使用其他端口，应替换为实际端口。

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw status numbered
sudo ufw enable
sudo ufw status verbose

如果管理来源地址固定，SSH 规则可以进一步限制为管理网段，例如：

sudo ufw allow from ADMIN_CIDR to any port 22 proto tcp

ADMIN_CIDR 必须替换为实际网段，不能原样执行。若管理终端地址经常变化，过早限制来源可能造成新的登录故障。

防火墙调整的影响范围是所有进入服务器的连接。执行前应记录原有规则，执行后立即从外部验证 SSH；若远程连接中断，只能通过控制台恢复：

sudo ufw disable
sudo ufw status verbose

ufw disable 只应作为应急恢复动作，并应在问题定位后重新建立明确的入站规则。不要为了排查长期关闭防火墙。

五、部署一个最小健康检查地址

为了区分“服务器可登录”和“HTTP 服务可用”，可以先使用 Nginx 提供一个不依赖业务代码的健康检查文件。

先启动并设置开机启动：

sudo systemctl enable --now nginx
sudo nginx -t
sudo systemctl is-active nginx
sudo systemctl is-enabled nginx

创建健康检查文件前，确认目标文件不存在，避免覆盖已有业务内容：

test ! -e /var/www/html/healthz || {
  echo "/var/www/html/healthz already exists; stop to avoid overwrite"
  exit 1
}

printf 'ok\n' | sudo tee /var/www/html/healthz >/dev/null
sudo chmod 644 /var/www/html/healthz

先在服务器本机验证：

curl -fsS --max-time 5 http://127.0.0.1/healthz

正常结果应为：

ok

再确认监听地址和端口：

sudo ss -lntp | grep -E ':(80|443)\b'
sudo systemctl status nginx --no-pager

这里的本机验证只能说明 Nginx 已经在本机处理请求，不能证明公网访问路径正常。公网验证必须从服务器外部的管理电脑或其他实际访问网络发起：

curl -i --connect-timeout 5 --max-time 10 http://PUBLIC_IP/healthz

返回 HTTP 成功状态并包含 ok，才说明从外部网络到服务器、主机防火墙、Nginx 和文件路径这一整条链路基本可用。此阶段没有配置 TLS 时，不应把 443 端口视为已验证，也不应把 HTTP 结果描述为 HTTPS 可用。

六、按由外到内的顺序完成可用性验证

建议使用下面的顺序，避免在应用层反复修改配置，却忽略公网地址或防火墙问题。

如果管理电脑安装了 nc，还可以只验证 TCP 端口：

nc -vz PUBLIC_IP 22
nc -vz PUBLIC_IP 80

TCP 连接成功只代表端口可达，不代表 SSH 认证或 HTTP 内容正确。相反，TCP 超时通常优先检查外部防火墙、主机防火墙和路由；TCP 被拒绝则更多指向目标端口没有服务监听，或服务主动拒绝。

如果使用域名访问，应在 IP 验证成功后再增加 DNS 变量：

getent hosts example.com
curl -i --connect-timeout 5 http://example.com/healthz

域名解析结果不正确时，先修正 DNS；不要把 DNS 问题误判为香港服务器本身不可用。

七、常见失败处理

SSH 完全超时

先检查控制台中的地址、默认路由、服务商侧入站规则和 UFW 状态：

ip -brief address
ip route
sudo ufw status verbose
sudo ss -lntp | grep ':22'

如果没有监听 22 端口，检查 SSH 服务：

sudo systemctl status ssh --no-pager
sudo journalctl -u ssh -n 50 --no-pager

如果本机监听正常但外部超时，优先检查服务器外部的安全组或网络访问策略。

SSH 能连接但认证失败

检查实际登录用户名、公钥内容和权限：

id deploy
sudo ls -ld /home/deploy /home/deploy/.ssh
sudo ls -l /home/deploy/.ssh/authorized_keys
sudo journalctl -u ssh -n 50 --no-pager

不要为了临时登录而无条件重新开启密码认证。先确认客户端使用了正确私钥，再检查 sshd -T 的有效配置。

本机 HTTP 成功，外部 HTTP 超时

这通常说明 Nginx 本身工作正常，问题位于公网访问链路。依次查看：

1. UFW 是否放行 TCP 80；
2. 服务商侧安全组是否放行 TCP 80；
3. Nginx 是否只绑定了回环地址；
4. 外部测试是否访问了正确公网 IP。

可用以下命令确认监听地址：

sudo ss -lntp | grep ':80'
sudo nginx -t

监听在 0.0.0.0:80 或相应 IPv6 地址，通常表示具备外部监听条件；若只监听 127.0.0.1:80，需要检查 Nginx 站点配置。

本机 HTTP 也失败

先检查服务状态和配置：

sudo nginx -t
sudo systemctl status nginx --no-pager
sudo journalctl -u nginx -n 50 --no-pager
sudo ls -l /var/www/html/healthz

nginx -t 报错时，优先恢复最近修改的配置，不要直接删除整个 /etc/nginx 目录。若健康文件返回 404，说明网络和服务可能已经正常，应检查文件路径和当前启用的站点配置。

八、失败时的回滚路径

回滚应只撤销本次部署产生的变更，避免使用重置整台服务器或删除全部配置的方式。

• SSH 配置回滚：通过仍然打开的会话或控制台，将新建的 99-first-deploy.conf 改名为 .disabled，执行 sshd -t 后再 reload。
• 防火墙回滚：只在确认被锁定且能够使用控制台时执行 ufw disable，恢复访问后重新检查并建立规则。
• 健康检查文件回滚：仅当确认该文件由本次部署创建时执行：

  sudo rm -- /var/www/html/healthz

如果部署前文件已经存在，应恢复此前备份，而不是直接删除。

• Nginx 配置回滚：保留原配置备份，先运行 nginx -t，确认无误后再 reload。不要用 apt autoremove 作为故障处理手段。
• 系统升级回滚：软件包升级失败时先保留错误日志，不要盲目降级依赖。若有可用快照，按服务商控制台的快照恢复流程处理；没有快照时，应记录现状并评估重建是否比手工拆包更安全。

上线前验收清单

• [ ] 已确认系统版本、服务器公网地址和默认路由。
• [ ] 已确认控制台或带外终端可用。
• [ ] 已创建独立管理账号，并用新账号成功建立 SSH 会话。
• [ ] 公钥权限正确，未把私钥放入服务器。
• [ ] SSH 配置修改前已备份，修改后通过 sshd -t 检查。
• [ ] 系统更新完成，未出现未处理的启动失败服务。
• [ ] 防火墙先放行 SSH，再启用默认入站拒绝策略。
• [ ] 仅按实际用途开放 HTTP 等端口，没有提前开放数据库或其他管理端口。
• [ ] Nginx 配置检查通过，并设置为开机启动。
• [ ] 127.0.0.1/healthz 本机访问成功。
• [ ] 从服务器外部访问 PUBLIC_IP/healthz 成功。
• [ ] 已记录最近一次配置的回滚方式和备份位置。

完成这些检查后，香港服务器才具备继续部署业务程序的基础。后续增加域名、HTTPS、应用进程或数据库时，应一次只引入一类变更，并沿用“本机验证、外部验证、保留回滚”的顺序。