部署目标与前置条件

目标是在 Ubuntu 服务器上运行 Nginx、PHP-FPM 和 PHP 网站，通过有效的 TLS 证书提供 HTTPS 访问，并能检查网站响应、服务状态、资源使用和网络流量。海外大带宽服务器应对流量高峰，不能只看带宽规格：还要观察网卡实际收发、Nginx 请求与错误日志、PHP-FPM 进程及系统资源。本文的配置适用于使用 Ubuntu 软件源安装 Nginx、PHP-FPM 的常见环境；PHP 版本和服务名以服务器实际安装结果为准。

开始前准备好：

• 一台已安装 Ubuntu 的服务器，并拥有 sudo 权限。
• 已解析到服务器公网地址的域名，例如 example.com 和可选的 www.example.com。申请证书前应确认解析正确。
• 网站 PHP 文件及其所需配置；如果应用需要数据库，还应准备相应数据库和 PHP 驱动。
• 入站 TCP 80、443 端口可达。除了服务器本机防火墙，还需检查云平台或机房侧的访问控制。
• 通过 SSH 操作时，先备份现有 Nginx 配置、网站文件和应用配置。以下示例会创建新站点配置，不应直接覆盖正在运行的生产站点。

以下命令以 Ubuntu 为例。涉及配置变更时，先检查语法再重载服务；不要在未确认备份的情况下批量改写网站文件或权限。

安装运行环境并准备网站文件

更新软件索引并安装依赖

先确认系统版本及现有服务，避免在已有生产环境中重复安装或覆盖配置：

lsb_release -a
nginx -v
php -v
systemctl list-units --type=service 'php*-fpm.service'

若 Nginx 或 PHP-FPM 尚未安装，可通过 Ubuntu 软件源安装：

sudo apt update
sudo apt install nginx php-fpm php-cli php-curl php-mbstring php-xml php-zip php-gd php-mysql certbot python3-certbot-nginx

php-mysql 仅在应用使用 MySQL 或兼容数据库时需要；其他 PHP 扩展应按应用的依赖清单增减。安装后确认 PHP 版本和 FPM 服务名：

php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION.PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'
ls -l /run/php/

记录实际版本。例如，若版本命令输出 8.3，FPM 服务通常为 php8.3-fpm，套接字通常为 /run/php/php8.3-fpm.sock。不要照抄示例版本；后续 Nginx 配置中的套接字必须与 /run/php/ 下实际存在的文件一致。

创建网站目录并部署代码

以下示例使用 /var/www/example.com/public 作为网站根目录。将域名和路径替换为实际值。若目录中已有网站文件，先备份再复制，不要用新代码覆盖唯一副本。

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

将网站代码部署到 public 目录，并确认入口文件存在：

ls -la /var/www/example.com/public

通常入口文件为 index.php。静态资源和 PHP 源码不应由 Web 服务进程任意写入。应用确实需要上传或缓存时，只对对应目录授予写权限，不要对整个网站目录递归设置为可写。可先查看所有者和权限：

stat -c '%U:%G %a %n' /var/www/example.com /var/www/example.com/public

如需调整所有权或权限，先确认操作范围并保留现状记录；下面的命令只适用于网站代码确实由当前部署用户维护、Web 服务组为 www-data 的情况：

sudo chown -R "$USER":www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 0755 {} \;
sudo find /var/www/example.com -type f -exec chmod 0644 {} \;

这会改动该网站目录下全部文件权限。执行前应确认目录没有需要保留的特殊权限；若应用依赖特定权限，按应用要求单独处理。回滚时依据变更前记录恢复所有者和权限，或从备份恢复文件。

配置 Nginx 与 PHP-FPM

先确认 PHP-FPM 正常运行，并检查套接字路径：

sudo systemctl enable --now php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager
ls -l /run/php/

命令中的 php8.3-fpm 应替换为服务器实际服务名。若服务启动失败，先查看日志，不要继续配置 Nginx：

sudo journalctl -u php8.3-fpm -n 50 --no-pager

创建独立站点配置。将域名、网站根目录及 fastcgi_pass 套接字替换为实际值：

sudo nano /etc/nginx/sites-available/example.com

配置示例：

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;

    client_max_body_size 20m;

    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;
    }

    location = /nginx_status {
        stub_status;
        allow 127.0.0.1;
        allow ::1;
        deny all;
    }
}

client_max_body_size 应按网站允许的上传大小设置，并与 PHP 的 upload_max_filesize、post_max_size 配置协调；示例值不是性能或容量承诺。try_files 会让常见 PHP 应用把未命中的路径交给入口文件；如果应用要求不同路由规则，应按其官方部署说明调整。状态页仅允许本机访问，不要移除访问限制后向公网开放。

启用站点前检查配置语法。若默认站点与新配置发生冲突，应先确认现有访问入口，再决定是否停用默认站点；不要直接删除配置文件。

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

只有出现 syntax is ok 和 test is successful 后，才重载 Nginx：

sudo systemctl enable --now nginx
sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

如果 nginx -t 报错，先修正配置，不要重载。若启用符号链接时提示文件已存在，检查现有链接指向，不要强行覆盖。

开通 HTTPS

申请证书前，确认域名 A 或 AAAA 记录指向当前服务器；若配置了 AAAA 记录，IPv6 也应能访问服务器。外部网络需要能够访问 TCP 80 和 443。UFW 是否启用可用以下命令确认：

sudo ufw status

只有在确认使用 UFW 且当前规则允许调整时，才添加 HTTP、HTTPS 规则：

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

这会改变服务器本机防火墙规则；若远程管理端口规则不完整，可能影响后续管理连接。调整前应记录当前规则并确认已有远程管理放行项。云平台或机房侧的防火墙也需单独检查。

在 HTTP 站点已能访问的前提下，用 Certbot 的 Nginx 插件申请证书，并按提示选择是否将 HTTP 重定向到 HTTPS：

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

若只使用一个域名，就移除另一个 -d 参数。申请失败时，先检查域名解析、端口连通性、Nginx 配置和错误信息；不要反复申请以试图绕过错误。Certbot 可能会修改 Nginx 站点配置，执行前建议备份该文件：

sudo cp -a /etc/nginx/sites-available/example.com \
  /etc/nginx/sites-available/example.com.before-https

成功后检查 Nginx 配置并重载：

sudo nginx -t
sudo systemctl reload nginx

验证证书续期流程是否可用：

sudo certbot renew --dry-run
systemctl list-timers | grep -i certbot

--dry-run 用于测试续期流程，不会替代正式证书续期。若系统未显示定时器，应检查 Certbot 在当前 Ubuntu 安装方式下提供的定时任务，并按该安装方式启用续期调度。

结果验证与运行监控

验证网站、HTTPS 和 PHP

从服务器本机检查 HTTP 响应：

curl -I http://example.com
curl -I https://example.com

若已启用 HTTPS 强制跳转，HTTP 返回跳转响应是预期行为；最终应能通过 HTTPS 获得网站响应。还可查看证书信息：

sudo certbot certificates

确认 PHP-FPM 套接字与 Nginx 配置一致，并检查服务及错误日志：

sudo systemctl is-active nginx
sudo systemctl is-active php8.3-fpm
sudo tail -n 50 /var/log/nginx/example.com.error.log
sudo journalctl -u php8.3-fpm -n 50 --no-pager

将服务名替换为实际版本。应使用真实业务页面验证登录、表单、上传、数据库访问等功能，不要把仅能打开静态首页视为 PHP 应用已验收。

检查 Nginx 状态页时，使用实际域名访问本机回环地址：

curl --resolve example.com:80:127.0.0.1 \
  http://example.com/nginx_status

若 HTTP 已被重定向到 HTTPS，可通过 HTTPS 测试：

curl --resolve example.com:443:127.0.0.1 \
  https://example.com/nginx_status

状态页应只在本机可读；外部访问被拒绝是预期结果。若返回 404 或连接失败，依次检查站点是否加载、请求域名是否匹配、Nginx 是否重载以及访问控制配置。

监控资源、请求与流量

至少同时观察以下信息，才能判断问题发生在应用、主机还是网络层：

• Nginx：检查访问日志中的请求量、响应状态码和错误日志。错误日志持续出现上游连接失败，通常需要进一步核对 PHP-FPM 服务与套接字；大量客户端错误则应结合具体请求判断。
• PHP-FPM：检查服务状态、日志及进程情况。服务停止、频繁重启或进程资源紧张时，动态页面可能变慢或返回错误；应结合应用日志确认原因。
• 系统资源：使用 free -h、uptime、df -h 和 top 查看内存、负载、磁盘空间和进程。磁盘接近耗尽时，日志、缓存或应用写入可能失败。
• 网络接口：先用 ip -s link 查看网卡累计收发字节和丢包计数。若要观察一段时间内的变化，可安装并使用 sysstat 的 sar 工具：

sudo apt install sysstat
sar -n DEV 1 5

不同系统的网卡名称和统计方式可能不同；对比前后计数时应选定同一接口和时间窗口。网卡计数是累计值，不能单独证明流量峰值、用户体验或带宽利用情况。需要判断业务高峰时，应从外部监控点定时请求 HTTPS 页面，并记录检查地点、时间、网络环境、请求方法和样本次数，再与服务器日志、资源数据对照。单次请求或单一监控点不能代表所有访问者的体验。

监控告警阈值应根据正常时段的基线和业务特点制定，重点关注服务不可用、错误率变化、磁盘空间不足、内存压力、PHP-FPM 异常及网络接口收发变化。不要仅因某个瞬时数值就认定服务器已达到承载上限。

常见失败处理与回滚

• 域名无法访问或证书签发失败：先确认域名解析结果，再从外部检查 80、443 端口是否可达；随后运行 sudo nginx -t 并查看 Nginx 日志。解析不正确或端口未放通时，先修正对应环节，再重新申请证书。
• 出现 502 Bad Gateway：检查 PHP-FPM 是否运行、Nginx 中的 fastcgi_pass 是否与 /run/php/ 下的套接字一致，以及 Nginx 用户是否能访问该套接字。不同 PHP 版本可能对应不同服务名和套接字，不能仅凭配置示例判断。
• 出现 403 或 404：核对 root 是否指向包含入口文件的目录、目录权限是否允许 Nginx 读取、请求路径是否符合应用路由。不要通过把全站权限改为可写来处理访问错误。
• HTTP 正常但 HTTPS 异常：检查证书域名、证书状态和 Nginx 配置。执行 sudo certbot certificates、sudo nginx -t，并查看错误日志；不要在证书状态未明时删除 /etc/letsencrypt 下的文件。
• 配置修改后服务无法加载：停止继续改动，查看 nginx -t 输出。若确定新配置是原因，可恢复备份文件，再测试并重载。恢复前保留失败配置副本，以便定位问题。

恢复站点配置的示例适用于已按前文备份、且确认备份内容是变更前可用版本的情况：

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

该操作会覆盖当前站点配置，执行前应另行保存当前文件。若重载仍失败，不要继续删除或覆盖其他 Nginx 配置；恢复最近一次可用备份，并根据 nginx -t 输出处理。

如果新站点尚未投入使用，可先移除本次创建的启用链接来回滚；确认链接确实指向该站点后再执行：

readlink -f /etc/nginx/sites-enabled/example.com
sudo rm /etc/nginx/sites-enabled/example.com
sudo nginx -t
sudo systemctl reload nginx

删除链接不会删除网站文件，但会停止通过该 Nginx 站点配置提供服务。若站点已承载生产流量，应先确认替代配置和恢复路径，不要直接执行。证书文件可暂时保留，待确认不再需要后再按 Certbot 管理方式处理。

上线验收清单

• [ ] 域名解析指向当前服务器，所需的 80、443 端口可从外部访问。
• [ ] Nginx 和对应版本的 PHP-FPM 均处于运行状态，Nginx 配置检查通过。
• [ ] HTTPS 页面可访问，证书域名正确，续期测试通过。
• [ ] PHP 业务页面、数据库访问及应用所需功能已实际验证。
• [ ] 网站代码默认不可由 Web 服务进程任意写入，上传和缓存目录权限范围明确。
• [ ] 已检查 Nginx、PHP-FPM 日志，以及主机磁盘、内存和网络接口统计。
• [ ] 已保存上线前配置备份，并确认出现故障时能够恢复到可用配置。