首次在韩国服务器上部署网站，真正需要先完成的不是安装一整套软件，而是建立一条可回退的上线链路：确认系统和登录权限，完成系统更新，限制公网入口，部署网站文件或应用进程，配置域名与 Web 服务，最后从本机、服务器和外部网络分别验证。若是静态网站，通常不需要数据库和应用运行时；只有网站本身明确依赖某种运行环境或数据库时，才增加对应组件。

首次部署最常见的中断原因包括：系统更新后服务没有正常启动、启用防火墙后 SSH 被锁在服务器外、域名解析到了错误地址、Nginx 配置指向了错误目录，以及动态应用进程未启动却直接配置了反向代理。下面的步骤以 Debian/Ubuntu 系列系统为例，命令执行前应先确认实际发行版；如果系统不是这一系列，不要直接套用 apt 和 UFW 命令。

1. 明确上线资产和前置条件

开始前，至少准备好以下信息：

如果控制台支持快照，建议在系统更新和首次配置前创建快照。快照是否可用、保留多久以及恢复方式取决于服务器管理平台，不能假定所有环境都具备这一功能。

先查看系统和已有监听端口：

cat /etc/os-release
uname -m
id
df -h
free -h
timedatectl
sudo ss -lntup

这一步重点看三类问题：

• 系统是否确实为 Debian 或 Ubuntu 系列；
• 磁盘是否有足够空间保存更新包、网站文件和日志；
• 是否已经有其他服务占用 80、443 或应用计划使用的端口。

不要仅凭服务器所在位置判断系统时区。日志时间应与业务排障习惯保持一致，修改时区前先和业务记录、数据库及监控系统的时间约定对齐。

2. 先做风险预演，避免首次上线被锁死

在操作前，可以按下面的失效场景检查一次。重点不是预判所有问题，而是确保每一种高影响故障都有可用的恢复入口。

最重要的原则是：不要在唯一 SSH 会话中直接启用防火墙、修改 SSH 端口或关闭 root 登录。至少保留当前会话，并从另一个终端完成一次真实登录测试。

3. 更新系统并建立可恢复的管理入口

3.1 更新前保存基础配置

以下示例适用于有 sudo 权限的 Debian/Ubuntu 系统。备份文件可能包含密钥、密码或其他敏感配置，应限制访问权限，不要直接上传到公开位置。

sudo tar -C / -czf "/root/etc-backup-$(date +%Y%m%d-%H%M%S).tgz" etc
sudo -v

如果管理平台支持快照，建议先创建快照，再执行系统更新。没有快照时，至少保留控制台登录能力和 /etc 备份。

3.2 执行系统更新

sudo apt update
sudo apt upgrade

apt upgrade 可能更新系统库、Web 服务或安全组件，也可能提示配置文件如何处理。确认变更范围后再继续，不要在不了解影响时强行覆盖现有配置。

更新完成后检查是否需要重启：

if [ -f /var/run/reboot-required ]; then
    cat /var/run/reboot-required
fi

如果系统要求重启，应在确认当前没有其他维护任务后执行：

sudo reboot

重启会中断当前 SSH 连接，属于有影响的操作。重新登录后再次检查：

uptime
systemctl --failed
sudo ss -lntup

如果出现失败服务，先查看具体状态，不要立即批量重启：

systemctl status 服务名 --no-pager
sudo journalctl -u 服务名 -b --no-pager

3.3 创建独立运维账号

如果目前只能使用 root 登录，建议先创建一个独立运维账号，但不要立刻关闭 root 或密码登录。先确认新账号能够正常登录，再进行 SSH 加固。

sudo adduser --disabled-password --gecos "" deploy
sudo usermod -aG sudo deploy
id deploy

如果系统提示 deploy 已经存在，先执行 id deploy，确认其归属组和家目录，不要重复创建。

从本地管理电脑向新账号写入 SSH 公钥：

ssh-copy-id deploy@SERVER_IP

如果本地没有 ssh-copy-id，也可以通过服务器控制台写入公钥。公钥文件应属于新账号，权限不能过宽：

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy /tmp/deploy_authorized_keys /home/deploy/.ssh/authorized_keys

将实际公钥文件放入 /tmp/deploy_authorized_keys 后再执行上述命令，并在操作完成后妥善处理临时文件。

打开第二个终端测试：

ssh -o PreferredAuthentications=publickey deploy@SERVER_IP 'id && hostname'

只有当新账号登录成功、具备必要的 sudo 权限，并且控制台入口仍然可用时，才考虑修改 SSH 加固策略。修改 /etc/ssh/sshd_config 前先备份，并使用以下命令检查语法：

sudo cp -a /etc/ssh/sshd_config /root/sshd_config.before-hardening
sudo sshd -t

sshd -t 没有输出通常表示语法检查通过。若检查失败，不要重载 SSH 服务；先恢复备份或修正配置。

4. 只开放网站真正需要的入口

网站首次上线通常只需要 SSH 管理端口、HTTP 和 HTTPS。动态应用的内部端口应优先只监听本机，不应为了方便直接开放到公网。

如果系统使用 UFW，先查看当前状态，不要直接执行重置规则：

sudo ufw status verbose

确认实际 SSH 端口后再放行。下面的 22 仅适用于 SSH 确实监听在 22 端口的情况：

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered

如果 SSH 使用其他端口，应将 22 替换为实际端口。执行启用操作前，保持当前 SSH 会话，并从另一个终端测试新连接：

ssh deploy@SERVER_IP

确认连接成功后再启用 UFW：

sudo ufw enable

启用防火墙会改变入站访问策略，可能影响已经运行的服务。若服务器控制台还有独立的公网防火墙或入站规则，也要同时检查 22、80、443 是否允许；两层规则中任意一层拒绝，外部访问都可能失败。

如果启用后 SSH 被拒绝，应通过控制台查看并修正规则，而不是反复尝试重启服务：

sudo ufw status numbered
sudo ss -lntp

删除规则前先记录编号和实际影响范围。不要使用 ufw reset 作为常规排障手段，因为它会清空已有规则，可能扩大暴露面或影响其他业务。

5. 部署网站文件或应用进程

5.1 静态网站：只安装必要的 Web 服务

静态网站只需要 Web 服务和网站文件，不需要为了“以后可能用到”提前安装数据库、应用运行时或其他服务。

安装并启动 Nginx：

sudo apt install nginx
sudo systemctl enable --now nginx
systemctl is-active nginx
curl -I http://127.0.0.1

如果返回 HTTP 响应，说明 Nginx 已经在本机监听。接下来使用独立发布目录，避免直接覆盖当前版本：

sudo install -d -o deploy -g www-data -m 0755 /var/www/example.com/releases/site-1

假设网站文件已经通过安全方式上传到 /tmp/site，只对静态文件执行复制和权限调整：

sudo cp -a /tmp/site/. /var/www/example.com/releases/site-1/
sudo chown -R root:www-data /var/www/example.com/releases/site-1
sudo find /var/www/example.com/releases/site-1 -type d -exec chmod 0755 {} \;
sudo find /var/www/example.com/releases/site-1 -type f -exec chmod 0644 {} \;
sudo ln -sfn /var/www/example.com/releases/site-1 /var/www/example.com/current

上述 chown 和 chmod 会递归修改指定发布目录，只适用于普通静态网站。不要把它们直接用于包含可执行文件、上传目录或特殊权限需求的动态应用目录。

创建站点配置：

sudo tee /etc/nginx/sites-available/example.com > /dev/null <<'NGINX'
server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

    root /var/www/example.com/current;
    index index.html;

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

    location ~ /\.(?!well-known) {
        deny all;
    }
}
NGINX

将 example.com 和 www.example.com 替换成实际域名。如果不使用 www，应同时从 server_name 和后续 DNS 检查中删除它。

启用站点前先检查配置：

sudo ln -sfn /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t

只有 nginx -t 显示语法检查成功时，才重载服务：

sudo systemctl reload nginx

reload 通常比 restart 更适合配置变更，因为它不会主动中断已有连接。若检查失败，不要重载，先查看报错中的文件路径、行号和权限。

5.2 动态网站：先验证应用，再接入 Nginx

动态网站的最小依赖取决于应用自身。应以项目锁定文件、部署文档和启动命令为准，不要因为服务器可以安装某个组件，就默认把数据库、缓存和其他服务全部装上。

建议按以下顺序处理：

1. 创建专用应用账号，不使用 root 启动应用。
2. 将应用文件放在独立目录，不直接放到 Nginx 静态根目录。
3. 安装应用明确要求的运行时和依赖。
4. 让应用先在本机端口启动并通过本机请求验证。
5. 再由 Nginx 反向代理到该本机端口。
6. 只有确有必要时，才配置数据库或其他后台服务。

应用应优先监听 127.0.0.1，例如本机 8000 端口，而不是直接监听所有公网地址。实际端口和启动命令必须以应用文档为准。验证时可以使用：

sudo ss -lntp | grep ':8000'
curl -i http://127.0.0.1:8000/

如果应用没有 / 路径或健康检查路径，应替换为项目实际存在的路径。只有本机请求成功，才继续配置 Nginx。

反向代理的配置示例为：

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

如果应用通过 systemd 管理，服务单元至少应明确运行用户、工作目录、启动命令和异常重启策略。以下是结构示例，User、WorkingDirectory 和 ExecStart 必须替换为该应用的真实值：

[Unit]
Description=Example application
After=network.target

[Service]
User=app
WorkingDirectory=/opt/example-app
ExecStart=/opt/example-app/bin/start
Environment=PORT=8000
Restart=on-failure

[Install]
WantedBy=multi-user.target

保存后先校验服务单元，再启动：

sudo systemd-analyze verify /etc/systemd/system/example-app.service
sudo systemctl daemon-reload
sudo systemctl enable --now example-app
sudo systemctl status example-app --no-pager

如果应用要求数据库，首次上线前必须确认数据库备份和恢复方法。数据库迁移不一定具备可逆性，不能把“回滚应用代码”当成“回滚数据库结构”。首次发布时，优先使用已验证过的迁移脚本，并在执行前保存数据库备份。

6. 配置域名并分层验证可用性

6.1 先验证 IP、站点配置和域名匹配

在修改 DNS 前，可以用 curl --resolve 将域名临时指向服务器 IP。这样能同时验证目标 IP、Nginx 配置和 server_name，避免把 DNS 问题与 Web 服务问题混在一起：

curl -i --resolve example.com:80:SERVER_IP http://example.com/

如果返回的是网站内容或预期的跳转，说明 Web 服务和站点匹配基本正常。如果返回 Nginx 默认页，通常是站点未启用、server_name 不匹配或请求使用了错误域名。如果返回 404，应检查 root 路径和文件是否存在。

然后配置域名的 A 记录指向服务器 IPv4 地址。如果确实启用了并验证过 IPv6，再配置 AAAA 记录。不要保留一个指向其他位置的旧 AAAA 记录，否则部分客户端可能优先通过 IPv6 访问错误目标。

DNS 查询可使用：

dig +short example.com A
dig +short example.com AAAA

如果系统没有 dig，可以使用：

getent ahosts example.com

解析结果应与实际服务器地址一致。解析尚未完成时，继续使用 --resolve 或直接访问本机测试，不要据此判断服务器已经对所有访问者可用。

6.2 按由内到外的顺序检查

先检查服务状态和本机访问：

systemctl is-active nginx
sudo ss -lntp | grep -E ':(80|443)\b'
curl -fsS -o /dev/null -w 'HTTP %{http_code}\n' http://127.0.0.1

再从服务器上使用真实域名测试：

curl -i -H 'Host: example.com' http://127.0.0.1/

最后从另一台网络环境执行：

curl -I http://example.com/
curl -sS -o /dev/null -w 'status=%{http_code} time=%{time_total}\n' http://example.com/

不同结果的含义通常如下：

• 200：请求已获得正常内容，仍需继续检查页面资源和业务功能。
• 301 或 302：可能是预期的 HTTP 到 HTTPS 跳转，也可能是应用配置了错误的跳转地址。
• 403：重点检查目录权限、文件权限和 Nginx 的访问规则。
• 404：重点检查域名匹配、root 路径、发布目录和应用路由。
• 502：重点检查动态应用是否运行、监听端口是否一致，以及 Nginx 是否能访问本机端口。
• 连接超时：优先检查 DNS、控制台防火墙、UFW 和监听地址。
• 连接被拒绝：目标地址可达，但对应端口没有服务监听，或服务已停止。

6.3 在 HTTP 正常后再配置 HTTPS

HTTPS 应放在 HTTP 站点能够稳定返回内容之后处理。证书签发通常要求域名能够被验证，因此应先确认域名解析正确，并确保验证所需的公网入口已经放行。

使用受信任证书服务和与当前系统兼容的客户端完成证书申请，具体安装方式应以系统版本和证书服务商的当前文档为准。不要在尚未完成域名验证时反复修改 Nginx 配置。

启用 HTTPS 后，至少检查：

curl -I https://example.com/

还可以检查证书对应的域名和有效期：

openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -subject -issuer -dates

如果 HTTP 正常、HTTPS 超时，优先检查 443 端口和 HTTPS 监听配置；如果提示证书域名不匹配，检查证书覆盖的域名与访问地址是否一致；如果 HTTPS 能访问但页面资源仍从 HTTP 加载，检查网站生成的绝对地址和应用的代理协议识别设置。

7. 失败时的回滚与恢复验证

7.1 Nginx 配置回滚

修改站点配置前先保存副本：

sudo cp -a /etc/nginx/sites-available/example.com /root/example.com.nginx.before-change

如果新配置检查失败，不要执行 reload。需要恢复时：

sudo cp -a /root/example.com.nginx.before-change /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

只有语法检查通过，才执行最后一条命令。如果原配置备份本身不存在，应通过控制台恢复快照或手动修正配置，不要随意删除整个 sites-enabled 目录。

7.2 网站文件回滚

使用发布目录的好处是可以切换当前版本，而不必覆盖旧文件。例如上一版本位于 site-1，新版本位于 site-2，确认新版本导致页面异常时，可以切回旧版本：

sudo ln -sfn /var/www/example.com/releases/site-1 /var/www/example.com/current
sudo nginx -t
sudo systemctl reload nginx

切换前确认两个路径都存在，并确认 current 确实是符号链接。回滚后重新执行域名访问、本机访问和外部访问测试，不要只以命令返回成功作为依据。

7.3 动态应用回滚

动态应用回滚需要同时考虑代码、环境变量和数据库结构：

1. 停止或切换到旧版本应用进程。
2. 将服务的工作目录或启动路径指向上一份发布目录。
3. 检查应用能否在本机端口启动。
4. 检查 Nginx 到本机端口的代理请求。
5. 如果涉及数据库迁移，按照已验证的恢复方案处理，不要直接执行未经验证的反向迁移。

应用服务出现异常时，先查看日志：

sudo systemctl status example-app --no-pager
sudo journalctl -u example-app --since "-15 min" --no-pager

Nginx 侧同时检查：

sudo journalctl -u nginx --since "-15 min" --no-pager
sudo tail -n 50 /var/log/nginx/error.log

日志中可能包含令牌、路径参数或用户信息，复制给他人排障前应先脱敏。

出现故障时的恢复优先级

网站首次上线后的恢复顺序，应优先恢复“能访问”，再恢复“完整功能”，最后处理性能和体验问题：

1. 确认服务器仍可通过控制台或 SSH 管理。
2. 确认公网防火墙没有误封实际 SSH、80 和 443 端口。
3. 确认 Nginx 或应用服务处于运行状态。
4. 使用 127.0.0.1 验证本机服务，再使用 --resolve 验证域名匹配。
5. 必要时切回上一份网站发布目录或恢复 Nginx 配置。
6. 最后检查 DNS、HTTPS、静态资源、登录流程和数据库读写。

完成首次部署后，应保留一份可执行的检查记录：系统更新是否完成、管理账号是否能登录、防火墙规则是否符合预期、站点配置是否通过 nginx -t、域名解析是否正确、HTTP/HTTPS 是否返回预期状态，以及旧版本和备份是否确实能够恢复。这样下一次更新出现问题时，恢复动作就不会依赖临时判断。