目标状态与变更前提

在 Ubuntu 欧洲服务器上部署外贸网站，目标是由 Nginx 提供 HTTP/HTTPS 服务、由 PHP-FPM 处理 PHP 请求，并使用有效证书启用 HTTPS。上线前应确认域名解析指向这台服务器、网站文件和数据库已有可恢复备份，且服务器允许网站所需端口的入站访问。具体 PHP 版本以服务器软件源和应用兼容要求为准，不要在未确认程序兼容性的情况下直接升级生产环境的 PHP。

以下操作适用于使用 APT 的 Ubuntu 系统。需要具备可执行 sudo 的账号、域名 DNS 管理权限，以及能够通过 SSH 登录服务器的条件。若网站正在运行，先约定维护窗口；修改 Nginx 配置前备份现有配置，配置通过检查后再重新加载服务，避免不必要的中断。

现状核对与变更准备

先确认系统版本、磁盘空间、服务状态和当前监听端口。若机器上已经有网站或其他服务，记录现有 Nginx 配置，不要直接覆盖默认站点或其他虚拟主机。

cat /etc/os-release
df -h
sudo systemctl status nginx --no-pager
sudo systemctl status php*-fpm --no-pager
sudo ss -lntp

命令显示服务不存在并不一定代表故障，可能是尚未安装。若 Nginx 已运行，检查启用的站点和当前配置来源：

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

nginx -T 会输出合并后的配置内容，可能包含站点路径或内部信息，查看结果时注意不要公开粘贴。还要核对域名的 A 记录；如果配置了 AAAA 记录，也要确认 IPv6 已在服务器和防火墙侧正确提供服务。错误的 AAAA 记录可能导致部分访问者连接到不可用地址。

变更前至少备份 Nginx 配置和网站数据。若网站使用数据库，另行按数据库类型执行经过验证的备份流程，并确认备份文件可读取。下面只备份 Nginx 配置，不代替网站文件和数据库备份：

BACKUP_DIR="/root/site-deploy-backup-$(date +%Y%m%d-%H%M%S)"
sudo mkdir -p "$BACKUP_DIR"
sudo cp -a /etc/nginx "$BACKUP_DIR/"
echo "$BACKUP_DIR"

记下输出的备份目录，回滚时需要用到。还应确认网站程序支持计划安装的 PHP 主版本及扩展；不确定时先查看应用文档或在测试环境验证。

安装 Nginx 与 PHP-FPM

更新软件包索引并安装基础运行环境。示例安装 PHP-FPM、常用扩展和 Nginx；扩展应按实际程序需要增减，避免仅因示例而安装不相关组件。

sudo apt update
sudo apt install nginx php-fpm php-cli php-curl php-mbstring php-xml php-zip

如果应用依赖数据库驱动，还需安装对应扩展，例如 MySQL/MariaDB 应用通常需要 PHP MySQL 驱动；应先核对应用要求和实际数据库类型再选择。安装完成后确认版本、服务名称和 PHP-FPM 的 Unix 套接字路径：

php -v
systemctl list-units --type=service 'php*-fpm.service'
ls -l /run/php/

/run/php/ 下的套接字名称会随 PHP 版本变化。后续 Nginx 配置中的 fastcgi_pass 必须使用这里实际存在的套接字，不能照抄其他服务器上的版本号。确认服务已启动：

sudo systemctl enable --now nginx
sudo systemctl enable --now "$(systemctl list-units --type=service --all 'php*-fpm.service' \
  | awk 'NR==2 {print $1}')"

如果自动选取服务的命令没有返回服务名，不要继续执行；通过 systemctl list-units --type=service 'php*-fpm.service' 查看实际服务名，再明确启动对应服务，例如：

sudo systemctl enable --now php8.3-fpm

示例中的版本号仅用于说明格式，必须替换成服务器上实际安装的服务名。

部署网站文件并配置 Nginx

将网站代码部署到独立目录，例如 /var/www/example.com/public。替换 example.com 为实际域名，确保目录中存在网站入口文件。不要把数据库密码、私钥或备份文件放在可公开访问的站点根目录中。

sudo install -d -o www-data -g www-data -m 0755 /var/www/example.com/public

如果发布流程要求由专用部署账号维护文件，可按实际账号和组设置所有权；不要为了消除权限错误而递归赋予所有用户写权限。Nginx 通常只需读取静态文件，PHP-FPM 的运行用户也应只对确实需要写入的缓存、上传等目录拥有写权限。

新建独立站点配置。以下示例适用于常见 PHP 网站；fastcgi_pass 中的套接字路径必须替换为前一步检查到的真实路径。

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

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

将配置保存为 /etc/nginx/sites-available/example.com，并替换域名、站点目录和 PHP-FPM 套接字。若应用使用不同的前端入口或路由规则，应采用该应用官方推荐的 Nginx 配置，不要机械套用 try_files 规则。启用站点前先确认不会与现有站点冲突：

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

如果检查通过，再平滑加载配置：

sudo systemctl reload nginx

若 ln 提示目标已存在，先检查已有链接指向和配置内容，不要直接删除。若 nginx -t 报错，依据报错行修正配置；此时不要 reload，线上服务仍可保持使用旧配置。

用临时 PHP 文件验证 Nginx 到 PHP-FPM 的处理链路。该文件会输出 PHP 环境信息，验证后必须删除，避免将运行环境细节暴露给访客：

printf '%s\n' '/dev/null

curl -i -H 'Host: example.com' http://127.0.0.1/health-check.php
sudo rm /var/www/example.com/public/health-check.php

预期响应正文为 php-fpm-ok。若出现 502，优先检查 PHP-FPM 服务是否运行，以及 fastcgi_pass 是否与 /run/php/ 中的实际套接字一致；若返回 404，检查站点根目录、文件是否存在及 Nginx 实际加载的站点配置。

配置 HTTPS 并验证证书

申请证书前，域名必须解析到当前服务器，且外部访问该域名的 HTTP 服务能够到达 Nginx。若 DNS 刚调整，先从外部网络检查解析结果；存在错误或过期的 AAAA 记录时，应先修正解析，避免验证请求被导向错误地址。服务器防火墙和云平台入站规则也应允许所需网站端口。调整防火墙前先确认 SSH 管理端口已放行，并记录原规则；错误的防火墙变更可能中断远程管理。

安装证书工具及 Nginx 插件：

sudo apt install certbot python3-certbot-nginx

按实际域名申请并配置证书：

sudo certbot --nginx -d example.com -d www.example.com

如果网站不使用 www 子域名，不要将它加入命令。按照交互提示完成邮箱和证书相关选择。工具会尝试识别并修改 Nginx 配置；执行后检查配置差异，确认没有覆盖其他站点规则，再测试并重新加载：

sudo nginx -t
sudo systemctl reload nginx

验证 HTTPS 证书及页面响应：

curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com 

检查响应状态、证书有效期和证书所覆盖的域名。浏览器仍提示证书异常时，先确认访问的主机名是否包含在证书中，再检查 DNS 是否指向本机、服务器系统时间是否正确，以及外部入站规则是否允许 HTTPS。若首页可访问但部分资源仍通过 HTTP 加载，应检查应用的站点地址和页面资源地址，并按应用自身的配置方式切换到 HTTPS；不要仅靠浏览器忽略告警。

最后检查自动续期是否可用：

sudo certbot renew --dry-run

测试成功表示续期流程通过模拟检查，不代表可以忽略后续证书到期监控。若失败，按输出检查域名可达性、Nginx 配置和验证端口；修复后再次执行测试。

上线验证、观察与回滚

正式切换流量前，逐项确认：

• sudo nginx -t 通过，Nginx 和对应 PHP-FPM 服务处于运行状态。
• 域名解析与预期一致，HTTP 和 HTTPS 均能从外部网络访问。
• 网站首页、关键页面、表单和需要登录的流程正常；涉及数据库的操作确认数据读写正常。
• PHP 错误日志、Nginx 错误日志没有持续出现新增异常。常见位置包括 /var/log/nginx/，PHP-FPM 日志路径则应按实际服务配置确认。
• 证书域名和有效期正确，续期模拟检查通过；临时健康检查文件已删除。

上线后在约定的观察窗口内持续关注访问错误、PHP-FPM 状态、磁盘空间和业务关键流程。出现持续 502/504、核心页面无法使用、数据库写入异常、证书与域名不匹配，或错误请求明显增加且无法及时定位时，应停止继续变更并按预案回滚。

回滚前先判断问题来自新配置、应用代码还是 DNS/防火墙，避免把无关变更一并撤销。若确认是 Nginx 配置导致，恢复备份并验证后再 reload：

sudo cp -a /root/site-deploy-backup-实际时间戳/nginx/. /etc/nginx/
sudo nginx -t
sudo systemctl reload nginx

将路径替换为变更前记录的真实备份目录。恢复前确认备份对应本次变更，且不会覆盖期间有意保留的其他站点修改。若失败发生在应用发布阶段，应按应用发布流程恢复上一版本代码和数据库备份；不要在未核实数据影响前直接恢复旧数据库。证书文件通常不必随 Nginx 配置回滚而删除，优先恢复服务配置并确保站点重新可用。若回滚后 nginx -t 仍失败，不要 reload，保留错误信息并检查恢复的配置版本。