Nginx 与 PHP-FPM 调优：参数耦合、失败信号与实验边界

如果手上没有目标环境的基线数据，能稳妥给出的不是一组“推荐参数”，而是一套判定顺序和参数之间的约束关系。Nginx 与 PHP-FPM 之间的调用链有多个超时点和多个容量上限，单独改其中任何一个，常见结果是问题换个形式出现：504 变成 502，或者排队消失但进程被 OOM killer 终止。下面按“先分信号、再看耦合、最后做实验”的顺序展开。本文不含实测数据；配置片段为未执行示例，数值须在目标环境测量后填写。

第一步：把症状对应到具体环节#

同一句“接口很慢”可能落在四个不同位置，处理方式完全不同：

• 请求进入 Nginx 但未到 PHP：看 error_log 中是否有 upstream 连接失败或超时记录，以及 fastcgi_connect_timeout 是否过短。
• PHP 在处理但超过 Nginx 等待上限：客户端收到 504，而 PHP-FPM 侧进程仍在执行，日志里能看到请求继续写下去。
• PHP-FPM 侧主动终止：request_terminate_timeout 触发后，Nginx 收到的是上游提前关闭连接，通常表现为 502。
• 进程池被占满：新请求排队，表现为延迟整体抬升而非个别超时；需要开启 pm.status_path 观察活跃进程与 listen queue。

这四类信号分别指向超时配置、进程容量和下游阻塞，先分清再动手，可以避免把容量问题当成超时问题调。

第二步：超时是一条链，不是三个独立开关#

链上至少有三个上限：Nginx 等待上游的 fastcgi_read_timeout、PHP-FPM 的 request_terminate_timeout、PHP 脚本自身的 max_execution_time。它们的大小关系决定了故障形态，这一点属于机制推断而非实测结论：若 Nginx 侧先到期，连接被切断，PHP 侧仍可能继续占用进程直到自身超时，等于容量被无效请求消耗；若 PHP-FPM 侧先终止，客户端看到的是上游中断。因此调整时应成组核对，而不是只改报错那一层。

# 未执行示例：仅示意参数对应关系，取值需按环境核实
location ~ \.php$ {
    fastcgi_connect_timeout 5s;
    fastcgi_read_timeout   30s;
    fastcgi_send_timeout   30s;
}
; php-fpm.d/www.conf
request_terminate_timeout = 30s
request_slowlog_timeout   = 5s
slowlog = /var/log/php-fpm/slow.log

slowlog 与 request_slowlog_timeout 的价值在于给出 PHP 栈，能把“慢”从猜测变成可定位的调用点。这是排查手段的建议，不是性能承诺。

第三步：进程数受内存约束，不受期望值约束#

pm.max_children 的实际上限由可用内存除以单进程常驻内存得出，而单进程常驻内存只能从运行中的进程测得，不同框架、不同扩展差异很大。写死一个“经验值”的风险是：并发上来后进程数达标，内存先耗尽。pm.max_requests 用于周期性回收进程，可缓解部分内存增长，但会带来进程重建开销，是否值得取决于内存曲线是否真的单调上升——这需要观测，不能预设。

第四步：把调优做成可回滚的实验#

1. 固定一份负载与请求组合，记录改动前的错误率、延迟分位与进程池排队情况。
2. 一次只改一组耦合参数（如超时链），观察窗口覆盖至少一个流量高峰。
3. 保留回滚点与原始配置文件，记录改动时间，便于与监控曲线对齐。
4. 若指标无变化，优先怀疑瓶颈不在这一层，而不是继续加大数值。

哪些问题调参解决不了#

慢 SQL、对外部 API 的同步阻塞调用、磁盘 I/O 争用、未启用 opcache 等情况，会同时表现为 PHP-FPM 排队与 Nginx 超时，但根因在应用或存储层。此时放宽超时只是把失败推迟，并放大进程占用。判断依据应是 slowlog 中的栈位置与数据库侧的执行记录，而非调参后的短期好转。

适用条件与待核实项#

本文所述指令名与语义为通用机制，具体默认值、不同大版本间的行为差异、以及托管环境对进程数与超时的额外限制，本次未联网核验，需对照所用版本与平台文档确认。上线前请以目标环境的测量结果替换示例中的占位数值。