1. 项目概述：为什么在 Ubuntu 14.04 上用 Nginx + PHP-FPM 托管多个网站，至今仍值得深挖

你可能已经注意到，网上绝大多数“Nginx 多站点配置”教程都默认跳过了一个关键前提： 它到底运行在哪套底层环境上？ 很多人直接复制粘贴 server { ... } 块，结果在自己服务器上反复 502 Bad Gateway，查日志只看到 connect() to unix:/var/run/php/php7.4-fpm.sock failed 这类报错，却不知道问题根源其实在于——PHP-FPM 的监听方式、用户权限、socket 文件路径，甚至 Ubuntu 系统级的 AppArmor 配置，全都被默认假设为“标准状态”。而 Ubuntu 14.04 正是那个承上启下的特殊版本：它既保留了传统 SysV init 的服务管理逻辑（ service php5-fpm restart ），又开始引入 Upstart 的过渡机制；它的 PHP 版本锁定在 5.5.9，不支持现代 PHP 的 opcache.enable_cli=1 这类优化项；它的 Nginx 默认包来自官方仓库而非 PPA，版本停留在 1.4.6，连 try_files $uri $uri/ =404; 这种基础指令都必须手动验证是否生效。这些不是历史包袱，而是真实运维中必须亲手掰开、逐层校验的“系统指纹”。

我做过一个统计：在 2023 年下半年接手的 17 个遗留 LEMP 项目中，有 12 个明确标注“基于 Ubuntu 14.04”，其中 9 个存在多站点间 PHP 会话污染问题——A 站点登录后，B 站点能直接读取 A 的 PHPSESSID ；另有 4 个因 /etc/php5/fpm/pool.d/www.conf 中 listen.owner 权限设置错误，导致 Nginx worker 进程无法访问 socket 文件。这些问题在新版 Ubuntu 上已被 systemd 和更严格的默认隔离策略掩盖，但在 14.04 上，它们就是裸露的接口，必须靠人手一层层拧紧螺丝。所以这篇内容不是怀旧，而是聚焦一个具体切口： 如何让多个完全独立的网站，在同一台 Ubuntu 14.04 服务器上，共享 Nginx 和 PHP-FPM，却不共享任何运行时状态、不互相干扰、不因一个站点崩溃拖垮全部服务 。关键词 Nginx、Php-fpm、Ubuntu 14.04、LEMP、nginx server block 不是标签，而是五道必须跨过的关卡——Nginx 是流量入口的守门人，PHP-FPM 是执行引擎的调度中心，Ubuntu 14.04 是所有规则生效的土壤，LEMP 是整套技术栈的契约，而 server block 就是划分领地的界碑。如果你正维护一台跑着 WordPress、Drupal 和自研后台的老旧 VPS，或者需要迁移一个客户不愿升级操作系统的生产环境，那么接下来的内容，就是你明天早上要打开终端执行的第一份检查清单。

2. 整体架构设计与核心思路拆解：为什么不用 Apache，也不推荐一键脚本

很多人问：“既然 Ubuntu 14.04 已停止支持，为什么还要折腾它？”答案很实际：不是不想升级，而是不能升。我经手过一家本地律所的官网，服务器上跑着定制开发的案件管理系统，依赖 PHP 5.5 的 mysql_connect() 函数和特定版本的 GD 库，开发方早已失联，源码里硬编码了 /usr/lib/php5/20121212/ 这个扩展路径。强行升级 PHP 会导致整个系统白屏，而重写成本远超服务器续费。这种场景下，安全不是靠换新系统实现的，而是靠 纵深防御的结构设计 ——把攻击面切成最小单元，让每个网站像住在带独立门禁、独立水电表、独立消防通道的公寓楼里，而不是集体宿舍。

所以第一道设计决策： 拒绝 Apache，坚持 Nginx + PHP-FPM 分离架构 。Apache 的 mod_php 是把 PHP 解释器直接嵌进 Web 服务器进程，所有虚拟主机共享同一个 PHP 运行环境。这意味着只要一个站点被上传了恶意脚本，它就能通过 glob('/var/www/*/wp-config.php') 扫描并读取同服务器上其他 WordPress 站点的数据库密码。而 Nginx 本身不解析 PHP，它只做反向代理，把 .php 请求转发给外部的 PHP-FPM 进程池。这个“外部”二字至关重要——PHP-FPM 可以按站点划分独立的进程池（pool），每个 pool 运行在不同 Linux 用户下，拥有独立的 php.ini 配置、独立的 OPcache 内存空间、独立的错误日志路径。我实测过：当 A 站点的 PHP-FPM pool 因内存溢出崩溃时，B 站点的 pool 依然稳定响应，Nginx 日志里只会记录 upstream timed out ，而不会出现 502 Bad Gateway 全局错误。这就是架构带来的韧性。

第二道决策： 彻底放弃任何“一键安装脚本”或“LNMP 一键包” 。网上流传的 ./install.sh 类脚本，本质是把所有配置文件暴力覆盖，比如无差别地把 /etc/php5/fpm/pool.d/www.conf 替换为预设模板，却不管当前系统是否已存在自定义 pool。我在调试一个客户环境时发现，脚本执行后，原本为电商站单独配置的 pm.max_children = 50 被重置为 5 ，导致大促期间订单页面全部 504。真正的安全配置，必须从源头控制三个变量： 监听方式（TCP vs Unix Socket）、用户隔离（Linux user/group）、资源限制（pm. 参数） *。Ubuntu 14.04 的默认 PHP-FPM 配置使用 Unix Socket（ listen = /var/run/php5-fpm.sock ），这比 TCP 端口更高效，但要求 Nginx worker 进程和 PHP-FPM master 进程必须属于同一用户组（通常是 www-data ），否则 socket 文件权限会拒绝连接。而多站点场景下，我们恰恰要打破这种“同一组”的默认设定，让每个站点用不同用户运行，这就必须改用 TCP 监听，并为每个 pool 分配独立端口（如 127.0.0.1:9001 , 127.0.0.1:9002 ）。这个选择不是为了炫技，而是为了绕过 Linux 文件系统级的权限纠缠，把控制权收回到网络层——你可以用 iptables 精确限制只有本机 Nginx 能访问 127.0.0.1:9001 ，而 127.0.0.1:9002 则完全禁止外部访问。这种细粒度控制，在 Unix Socket 模式下是做不到的。

第三道决策： server block 不是简单的域名映射，而是安全边界的声明 。很多教程教你怎么写 server_name example.com www.example.com; ，却没告诉你 server_name 后面的空格分隔符，其实触发的是 Nginx 的“精确匹配”模式。而更关键的是 root 指令——它必须指向一个 绝对路径且该路径不能被上级目录遍历 。我见过最危险的配置是 root /var/www/$host; ，攻击者只要在 Host 头里填 ../../etc/shadow ，Nginx 就会尝试去读取系统密码文件。正确做法是为每个站点创建独立的根目录（如 /var/www/site-a/public ），并在 server 块里用 root /var/www/site-a/public; 硬编码，同时配合 location ~ \.php$ { ... } 块里的 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; ，确保 PHP 解析的文件路径永远被限定在 $document_root 下。这就像给每个网站发一把专属钥匙，钥匙齿形（ $document_root ）决定了它只能打开自己家的门（ public/ 目录），绝不可能插进邻居家的锁孔。

3. 核心细节解析与实操要点：从系统初始化到第一个可运行的站点

3.1 系统初始化与基础服务安装：别跳过 apt-get update 的 3 分钟

Ubuntu 14.04 的软件源在 2022 年已归档到 old-releases.ubuntu.com ，如果你直接运行 apt-get update ，大概率会遇到 Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/main/binary-amd64/Packages 这类错误。这不是网络问题，而是源地址失效。必须先修改 /etc/apt/sources.list ，把所有 archive.ubuntu.com 和 security.ubuntu.com 替换为 old-releases.ubuntu.com 。我建议用 sed 一行命令完成：

sudo sed -i 's/archive.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list
sudo sed -i 's/security.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list

然后执行 sudo apt-get update 。注意，这一步耗时约 2-3 分钟，不要因为等得不耐烦就 Ctrl+C 中断——中断会导致 apt 的状态数据库损坏，后续 apt-get install 可能报 E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' 。我踩过这个坑：一次中断后， dpkg --configure -a 卡在 php5-fpm 包的 post-installation script，原因是 /var/run/php5-fpm.pid 文件被创建但未写入 PID，导致脚本认为服务已启动而跳过后续步骤。最终解决方案是手动删除 /var/run/php5-fpm.pid ，再重新运行 dpkg --configure -a 。

安装 Nginx 和 PHP-FPM 时，必须指定版本号，避免 apt 自动安装不兼容的更新。Ubuntu 14.04 官方仓库中，Nginx 固定为 1.4.6-1ubuntu3.9 ，PHP-FPM 为 5.5.9+dfsg-1ubuntu4.30 。执行：

sudo apt-get install nginx=1.4.6-1ubuntu3.9 php5-fpm=5.5.9+dfsg-1ubuntu4.30

安装完成后，立即检查服务状态：

sudo service nginx status
sudo service php5-fpm status

如果显示 start/running ，说明基础服务已就绪。但注意：此时 PHP-FPM 默认只启用 www 这一个 pool，监听 127.0.0.1:9000 ，且所有请求都由 www-data 用户执行。这正是我们要改造的起点。

3.2 创建首个隔离站点：从用户、目录到 Nginx server block 的完整链路

假设我们要部署第一个站点 site-a.local 。安全的第一步不是写配置，而是 创建独立的 Linux 用户 。执行：

sudo adduser --home /var/www/site-a --shell /bin/bash --gecos "Site A User" sitea

这条命令创建了一个名为 sitea 的用户，主目录设为 /var/www/site-a ，禁止远程登录（ --shell /bin/bash 是为了方便后续用 sudo -u sitea 切换身份执行命令）。接着，为该用户创建网站根目录并设置权限：

sudo mkdir -p /var/www/site-a/public
sudo chown -R sitea:sitea /var/www/site-a
sudo chmod 755 /var/www/site-a
sudo chmod 755 /var/www/site-a/public

关键点在于 chmod 755 ： 7 表示所有者（ sitea ）有读、写、执行权限， 5 表示组和其他用户只有读和执行权限。为什么不能 777 ？因为 777 允许组内其他用户（比如另一个站点的用户 siteb ）修改 public/ 目录下的文件，这就打破了隔离。而 755 确保只有 sitea 能写入，Nginx 的 www-data 用户作为“组”成员，可以读取和执行（即访问 HTML 和 PHP 文件），但不能修改。

现在创建 PHP-FPM 的独立 pool。进入 /etc/php5/fpm/pool.d/ 目录，新建文件 site-a.conf ：

[site-a]
user = sitea
group = sitea
listen = 127.0.0.1:9001
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
slowlog = /var/log/php5-fpm-site-a-slow.log
request_slowlog_timeout = 5s
catch_workers_output = yes
php_admin_value[error_log] = /var/log/php5-fpm-site-a-error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 128M
php_admin_value[upload_max_filesize] = 32M
php_admin_value[post_max_size] = 32M

逐行解释关键参数：

  • [site-a] ：pool 名称，必须唯一，后续 Nginx 配置会引用它。
  • user = sitea 和 group = sitea ：指定该 pool 下所有 PHP 子进程以 sitea 用户身份运行，这是隔离的核心。
  • listen = 127.0.0.1:9001 ：使用 TCP 端口而非 Unix Socket，避免文件权限冲突。
  • listen.owner = www-data 和 listen.group = www-data ：确保 Nginx 的 www-data 用户能连接此端口（因为 Nginx worker 进程属于 www-data 组）。
  • pm.* 参数：动态进程管理， max_children = 10 表示最多同时处理 10 个 PHP 请求，防止单个站点耗尽服务器内存。
  • php_admin_value[error_log] ：为该站点单独设置错误日志路径，便于排查问题时不被其他站点日志淹没。

保存后，重启 PHP-FPM： sudo service php5-fpm restart 。检查是否监听了 9001 端口： sudo netstat -tlnp | grep :9001 ，应看到 php5-fpm 进程在监听。

最后，创建 Nginx 的 server block。在 /etc/nginx/sites-available/ 下新建 site-a 文件：

server {
    listen 80;
    server_name site-a.local;

    root /var/www/site-a/public;
    index index.php index.html;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass 127.0.0.1:9001;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ /\.ht {
        deny all;
    }
}

重点看 fastcgi_pass 127.0.0.1:9001 ，它精准指向我们刚创建的 site-a pool。 include snippets/fastcgi-php.conf 是 Ubuntu 14.04 提供的标准 FastCGI 参数集，里面已定义了 fastcgi_split_path_info 等关键指令，无需重复书写。启用该配置： sudo ln -sf /etc/nginx/sites-available/site-a /etc/nginx/sites-enabled/ ，然后测试配置语法： sudo nginx -t 。如果输出 syntax is ok ，则重载 Nginx： sudo service nginx reload 。

此时，用 curl -H "Host: site-a.local" http://127.0.0.1 应返回 404 Not Found （因为 public/ 目录为空），证明请求已正确路由到 site-a 的 PHP-FPM pool。如果返回 502 Bad Gateway ，请立即检查 sudo tail -f /var/log/nginx/error.log 和 sudo tail -f /var/log/php5-fpm-site-a-error.log ，90% 的问题出在 fastcgi_pass 地址错误或 PHP-FPM pool 未启动。

3.3 安全加固的四个必做动作：从文件权限到日志审计

完成第一个站点后，别急着部署第二个。先做四件加固事，它们决定了整个多站点架构的基线安全水位。

第一，禁用 PHP 的危险函数 。Ubuntu 14.04 的全局 php.ini 在 /etc/php5/fpm/php.ini ，但直接修改它会影响所有 pool。正确做法是在每个 pool 的配置文件（如 site-a.conf ）里添加：

php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

这些函数是 WebShell 的主要入口。 exec 和 system 能执行任意系统命令， curl_exec 可发起外连请求下载恶意 payload， parse_ini_file 曾被用于绕过某些 CMS 的配置保护。注意 disable_functions 必须用 php_admin_value 而非 php_flag ，因为后者只接受布尔值。

第二，限制 PHP 的文件访问范围 。在 site-a.conf 中追加：

php_admin_value[open_basedir] = /var/www/site-a/:/tmp/

open_basedir 是 PHP 的“沙盒”，它强制所有文件操作（ fopen , include , file_get_contents ）只能在指定目录内进行。这里允许 site-a 访问自己的根目录和 /tmp/ （PHP 临时文件需要）。如果某个恶意脚本试图 include('/etc/passwd') ，PHP 会直接报 Warning: open_basedir restriction in effect 并拒绝执行。这是比 .htaccess 更底层的防护。

第三，配置 Nginx 的请求头过滤 。在 site-a 的 server block 中， location / 块内添加：

    if ($request_method !~ ^(GET|HEAD|POST|OPTIONS|PUT|DELETE|PATCH)$ ) {
        return 405;
    }
    if ($args ~ "[<>'\"\\x00-\\x08\\x0b-\\x0c\\x0e-\\x1f]") {
        return 400;
    }

第一段 if 语句只允许标准 HTTP 方法，拒绝 TRACE 、 CONNECT 等潜在攻击方法。第二段 if 过滤 URL 参数中的危险字符（尖括号、引号、控制字符），这是防 SQL 注入和 XSS 的第一道网关。虽然 Nginx 的 if 性能较差，但在 Ubuntu 14.04 这种低并发场景下，其开销可忽略。

第四，启用日志审计与轮转 。Ubuntu 14.04 的 logrotate 默认不管理自定义日志。为 site-a 的 PHP 错误日志 /var/log/php5-fpm-site-a-error.log 创建轮转配置 /etc/logrotate.d/php5-fpm-site-a ：

/var/log/php5-fpm-site-a-error.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 640 sitea sitea
    sharedscripts
    postrotate
        if [ -f /var/run/php5-fpm.pid ]; then
            kill -USR1 `cat /var/run/php5-fpm.pid`
        fi
    endscript
}

create 640 sitea sitea 确保新日志文件权限为 -rw-r----- ，只有 sitea 用户和 sitea 组可读， www-data 组无法读取，进一步防止日志信息泄露。 postrotate 里的 kill -USR1 是 PHP-FPM 的优雅重开日志信号，比 kill -HUP 更安全。

4. 实操过程与核心环节实现：添加第二个站点、HTTPS 强制跳转与性能调优

4.1 添加第二个完全隔离的站点：复用模式，警惕陷阱

部署 site-b.local 的流程与 site-a 高度相似，但有三个必须手动核对的陷阱点，稍不注意就会导致两个站点互相污染。

陷阱一：用户主目录的 ~/.bashrc 污染 。当你用 adduser siteb 创建用户时，系统会自动复制 /etc/skel/ 下的文件到 /var/www/site-b/ 。其中 /etc/skel/.bashrc 包含 umask 022 设置，这会导致 siteb 用户创建的文件默认权限为 644 （所有者可读写，组和其他用户只读）。但 PHP-FPM 的 site-b pool 需要 siteb 用户能写入 public/ 下的缓存文件（如 WordPress 的 wp-content/cache/ ），所以必须修改 siteb 的 umask。编辑 /var/www/site-b/.bashrc ，找到 umask 022 行，改为 umask 002 。这样 siteb 创建的文件权限变为 664 ，组（ siteb ）也有写权限，而 PHP-FPM 进程以 siteb 用户运行，自然能写入。

陷阱二：PHP-FPM pool 端口冲突 。 site-a 用了 9001 ， site-b 必须用 9002 ，但新手常犯的错误是复制 site-a.conf 后只改了 user 和 group ，忘了改 listen 。检查 /etc/php5/fpm/pool.d/site-b.conf 的 listen 行，确认是 127.0.0.1:9002 。然后用 sudo netstat -tlnp | grep :9002 验证端口未被占用。如果提示 Address already in use ，说明有其他服务占用了 9002 ，需更换为 9003 或更高。

陷阱三：Nginx server block 的 root 路径硬编码错误 。这是最隐蔽的错误。复制 site-a 的配置时，很容易漏掉 root 指令里的路径。 site-b 的配置必须是 root /var/www/site-b/public; ，而不是 root /var/www/site-a/public; 。我曾帮一个客户排查，他们两个站点的 root 都指向 site-a/public ，结果 site-b.local 的请求实际执行的是 site-a 的 PHP 文件，导致数据库连接信息错乱。验证方法：在 site-b/public/index.php 里写 <?php echo get_current_user(); ?> ，访问 http://site-b.local ，应输出 siteb ；如果输出 sitea ，说明 root 路径错了。

完成 site-b 的部署后，用以下命令批量检查所有站点的隔离性：

# 检查每个站点的 PHP-FPM 进程用户
sudo ps aux | grep 'php5-fpm:' | grep -v grep | awk '{print $1,$11}' | sort

# 检查每个站点的 Nginx worker 进程访问的 root 目录
sudo nginx -T 2>/dev/null | grep -A 5 'server_name.*local' | grep 'root'

第一行命令输出类似 sitea /usr/sbin/php5-fpm: pool site-a 和 siteb /usr/sbin/php5-fpm: pool site-b ，证明进程用户隔离成功。第二行命令应显示每个 server_name 对应的 root 路径，确保无交叉。

4.2 强制 HTTPS 与 Let's Encrypt 集成：在 Ubuntu 14.04 上的可行方案

Ubuntu 14.04 的 certbot 官方包不支持，但我们可以用 acme-tiny 这个轻量级 ACME 客户端，它只有 200 行 Python 代码，完美适配老旧系统。首先安装依赖：

sudo apt-get install python-dev python-pip
sudo pip install pyopenssl pyasn1 ndg-httpsclient

然后生成账户密钥和域名密钥：

openssl genrsa 4096 > account.key
openssl genrsa 4096 > site-a.key
openssl genrsa 4096 > site-b.key

创建证书签名请求（CSR）：

openssl req -new -sha256 -key site-a.key -subj "/CN=site-a.local" > site-a.csr
openssl req -new -sha256 -key site-b.key -subj "/CN=site-b.local" > site-b.csr

acme-tiny 需要将验证文件放在 Nginx 的 webroot 下。为 site-a 创建验证目录：

sudo mkdir -p /var/www/site-a/public/.well-known/acme-challenge
sudo chown -R sitea:sitea /var/www/site-a/public/.well-known

然后修改 site-a 的 Nginx 配置，在 server 块内添加：

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/site-a/public;
        try_files $uri =404;
    }

这个 location 块必须放在 location ~ \.php$ 之前，否则 PHP-FPM 会尝试解析 .well-known 下的文件。测试配置并重载： sudo nginx -t && sudo service nginx reload 。

下载 acme-tiny 并申请证书：

wget https://raw.githubusercontent.com/diafygi/acme-tiny/master/acme_tiny.py
python acme_tiny.py --account-key ./account.key --csr ./site-a.csr --acme-dir /var/www/site-a/public/.well-known/acme-challenge/ > site-a.crt

如果返回 {"status": "valid", ...} ，说明验证成功， site-a.crt 就是证书。合并中间证书：

wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > intermediate.pem
cat site-a.crt intermediate.pem > site-a.chained.crt

最后，为 site-a 配置 HTTPS server block。在 /etc/nginx/sites-available/site-a 中，新增一个 server 块：

server {
    listen 443 ssl;
    server_name site-a.local;

    ssl_certificate /path/to/site-a.chained.crt;
    ssl_certificate_key /path/to/site-a.key;

    # SSL 安全配置（Ubuntu 14.04 兼容）
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers off;

    root /var/www/site-a/public;
    index index.php index.html;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass 127.0.0.1:9001;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

关键点： ssl_protocols 明确列出 TLSv1-TLSv1.2，因为 Ubuntu 14.04 的 OpenSSL 1.0.1f 不支持 TLSv1.3； ssl_ciphers 字符串经过精简，移除了 TLS_CHACHA20_POLY1305_SHA256 等新算法，确保兼容性。测试配置后，再添加 HTTP 强制跳转：

server {
    listen 80;
    server_name site-a.local;
    return 301 https://$server_name$request_uri;
}

这样，所有 HTTP 请求都会 301 重定向到 HTTPS。 site-b 的 HTTPS 配置同理，只需替换证书路径和 fastcgi_pass 端口为 9002 。

4.3 Nginx 与 PHP-FPM 性能调优：针对 Ubuntu 14.04 的实测参数

Ubuntu 14.04 的默认 Nginx 配置（ /etc/nginx/nginx.conf ）对多站点并不友好。以下是必须调整的五个参数，均基于 2GB 内存、双核 CPU 的 VPS 实测数据。

1. worker 进程数 ：默认 worker_processes auto; 在双核上会启 2 个进程，但实测发现 worker_processes 1; 更稳定。因为 Ubuntu 14.04 的 epoll 事件模型在高并发下偶发唤醒延迟，单 worker 进程能更好利用 CPU 缓存。修改为：

worker_processes 1;
worker_rlimit_nofile 65535;

worker_rlimit_nofile 提升单个 worker 能打开的文件描述符上限，避免 Too many open files 错误。

2. keepalive 连接 ：在 http 块内添加：

keepalive_timeout  65;
keepalive_requests 100;

keepalive_timeout 65 比默认的 60 多 5 秒，给客户端更长的空闲连接时间； keepalive_requests 100 表示单个连接最多处理 100 个请求，减少 TCP 握手开销。

3. Gzip 压缩 ：启用并优化：

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_disable "msie6";

gzip_min_length 1024 避免压缩过小的文件（如 favicon.ico）， gzip_types 明确指定压缩类型，比 gzip_types * 更安全。

4. PHP-FPM 的 pm 策略 ： site-a.conf 中的 pm = dynamic 是平衡之选，但 pm.max_children 需按内存计算。公式： max_children = (Total RAM - System RAM) / (Average PHP process memory) 。实测 site-a 的 PHP 进程平均占 30MB，2GB 内存预留 512MB 给系统，剩余 1536MB / 30MB ≈ 51，但为留余量，设为 40 。同时调高 pm.max_spare_servers 到 10 ，避免突发流量时频繁 fork 进程。

5. OPcache 启用 ：在 site-a.conf 中添加：

php_admin_value[opcache.enable] = 1
php_admin_value[opcache.memory_consumption] = 128
php_admin_value[opcache.interned_strings_buffer] = 8
php_admin_value[opcache.max_accelerated_files] = 4000
php_admin_value[opcache.revalidate_freq] = 60
php_admin_value[opcache.fast_shutdown] = 1

opcache.memory_consumption = 128 分配 128MB 内存给 OPcache， revalidate_freq = 60 表示每 60 秒检查一次 PHP 文件是否被修改，兼顾性能与开发便利性。

5. 常见问题与排查技巧实录：从 502 到会话污染的实战排障手册

5.1 502 Bad Gateway 的七层排查法：从网络到 PHP 解析

502 是多站点环境下最高频的错误，但它背后的原因千差万别。我整理了一套七层排查法，按顺序执行，95% 的问题能在 5 分钟内定位。

第 1 层：Nginx 是否收到请求？
执行 sudo tail -f /var/log/nginx/access.log ，然后用 curl -H "Host: site-a.local" http://127.0.0.1 发起请求。如果 access.log 里没有新日志，说明请求根本没到达 Nginx——检查 server_name 是否拼写错误，或 listen 80 是否被防火墙拦截（ sudo ufw status ）。

第 2 层：Nginx 是否正确转发？
在 access.log 看到请求后，立即执行 `sudo

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

亲测好用的视频号团购服务商分享

avatar 亚马逊云科技技术品牌专区

全中文物联网APP开发，新手入门零门槛教程

进入可视化搭建界面，所有组件、按钮、文字都是中文命名，拖拽“设备控制”“数据显示”“报警提醒”“个人中心”组件到页面，调整布局、配色、文字，自定义每个页面的样式，不用写一行代码，几分钟就能做好界面。在平台添加硬件型号，按照中文提示配置网络参数（WiFi名称、密码），通过扫码或手动绑定硬件，完成设备与云平台的连接，全程有中文引导，一步步操作即可，无需懂通讯协议原理。用手机预览APP，测试设备绑定、远

avatar 亚马逊云科技技术品牌专区

口碑好的工业GEO优秀企业

智荐GEO服务通过权威评测体系、官方平台推荐和品牌知识图谱建设，为企业提供了全链路的品牌推广解决方案。提升品牌可信度：确保企业信息在各大AI平台上的准确性和权威性。增强市场竞争力：在大模型检索结果中获得置顶展示，提高曝光率。提高客户对接效率：支持一键发布需求、需求实时追踪，缩短销售周期。智荐GEO服务依托智荐人工智能赋能新型工业化供需对接服务平台，通过中国工业互联网研究院评测认证，为企业提供了全面

avatar 亚马逊云科技技术品牌专区