Nginx需通过FastCGI将请求转发给PHP-FPM，配置错误会导致502或超时；PHP-FPM推荐dynamic模式，pm.max_children按内存（20–40MB/进程）设为50，socket通信优于TCP，fastcgi_buffers等参数须匹配响应大小，否则直接502。
Nginx 本身不执行 PHP，必须通过 FastCGI 协议把请求转发给 PHP-FPM —— 配错这一步，再高的并发也卡在 502 或超时上。
PHP-FPM 的 pm 模式选哪个？static、dynamic 还是 ondemand？
选错 pm 模式会导致 CPU 空转或请求排队。高并发场景下：static 适合稳定流量（如内部 API），dynamic 是 Web 服务最稳妥的选择；ondemand 在低频场景省资源，但突发请求会因进程冷启动明显延迟。
-
pm = dynamic时，重点调pm.max_children：按内存算，每个 PHP 进程平均占 20–40MB，假设服务器有 2GB 可用内存，设为50较安全 -
pm.start_servers建议设为max_children × 0.3左右，避免启动过慢 - 别碰
pm.max_requests设太小（如100），频繁重启进程反而增加上下文切换开销；生产环境建议500–1000
Nginx 的 fastcgi_pass 用 socket 还是 TCP？
Unix socket（如 unix:/run/php/php8.1-fpm.sock）比 127.0.0.1:9000 少一层网络栈，延迟更低、无端口争用，且默认权限可控。但要注意：
- socket 文件路径需和 PHP-FPM 的
listen配置完全一致，大小写和斜杠都不能错 - 确保 Nginx worker 进程用户（通常是
www-data）对 socket 文件有读写权限，否则报Permission denied - 若跨容器或远程部署，只能用 TCP，此时务必加
fastcgi_read_timeout（至少300），否则大文件上传易中断
哪些 Nginx 配置项一设错就拖垮 PHP 性能？
不是参数越多越好，几个关键项设错会让并发从“撑得住”变成“502 炸屏”：
立即学习“PHP免费学习笔记（深入）”；
-
fastcgi_buffers和fastcgi_buffer_size必须匹配 PHP 输出大小，比如模板渲染返回 1MB HTML，至少配fastcgi_buffer_size 128k; fastcgi_buffers 8 128k;，否则直接 502 -
fastcgi_busy_buffers_size应 ≥fastcgi_buffer_size，否则缓冲区满后无法继续接收响应 - 漏掉
fastcgi_temp_path自定义路径（默认在/var/cache/nginx/fastcgi_temp），磁盘满或 inodes 耗尽时，所有 PHP 请求静默失败 -
proxy_buffering off对 PHP 不生效 —— 这是常见误解，PHP 场景必须用fastcgi_*系列指令，不是proxy_*
如何验证 FastCGI 链路真正在高效工作？
别只看 curl -I 返回 200，要查三处日志和一个指标：
- PHP-FPM 的
slowlog（开启request_slowlog_timeout = 5s），看有没有脚本卡在 MySQL 查询或 file_get_contents - Nginx error log 里搜
upstream timed out或connect() failed，指向连接池或超时问题 - 用
systemctl status php8.1-fpm查Active connections和accepted conn差值，持续 >10 表示请求积压 - 最关键的：用
ss -lnp | grep :9000（TCP）或ls -l /run/php/*.sock（socket）确认监听状态，很多“配置好了却不行”其实只是 PHP-FPM 根本没起来
高并发下 PHP 性能瓶颈往往不在代码，而在 Nginx 和 PHP-FPM 之间那几行 FastCGI 参数的微妙失衡 —— 缓冲区大小、子进程数、超时阈值，差一点，就从毫秒级延迟跳到秒级超时。
