dynamic是web服务最稳妥的平衡点，因其按负载自动伸缩空闲进程数，既避免内存浪费又防止突发请求排队；但需配套调优pm.start_servers、pm.min_spare_servers、pm.max_spare_servers等参数才能真正生效。
为什么pm = dynamic是PHP-FPM高并发下的默认安全选择
静态模式（pm = static）在流量突增时直接卡死，ondemand又因冷启动导致首请求延迟明显——dynamic才是Web服务最稳妥的平衡点。它按负载自动伸缩空闲进程数，既避免内存浪费，又防止突发请求排队。但很多人只改了pm却漏掉配套参数，结果还是502或响应变慢。
关键不是“选对模式”，而是让dynamic真正动起来：
-
pm.start_servers必须设，不能留空；建议取pm.max_children × 0.2–0.3，比如max_children = 50就设为10–15 -
pm.min_spare_servers和pm.max_spare_servers要拉开差距（如5和35），否则空闲进程池会僵住，无法响应爬升流量 - 别把
pm.max_children设成理论最大值：每个PHP进程实占20–40MB内存，2GB可用内存顶多撑50个，硬塞到100反而触发OOM Killer杀进程
fastcgi_pass用socket还是TCP？权限和路径最容易翻车
用unix:/run/php/php8.2-fpm.sock比127.0.0.1:9000快且稳定，但90%的502错误都出在这儿——不是Nginx没连上，是权限或路径错了。
检查三件事：
- Nginx worker进程用户（通常是
www-data或nginx）必须对.sock文件有读写权限；用ls -l /run/php/确认属组和权限位，必要时在php-fpm.conf里加listen.owner = www-data和listen.group = www-data -
fastcgi_pass路径必须和php-fpm.conf中listen配置完全一致，包括版本号（php8.2-fpm.sock≠php8.3-fpm.sock） - 如果用TCP，确保
php-fpm监听的是0.0.0.0:9000而非127.0.0.1:9000，否则Docker或非localhost部署会连不上
fastcgi_buffers配小了，大响应直接502
PHP脚本返回JSON或HTML内容超过默认缓冲区（通常128KB），Nginx就会丢弃连接并报502——日志里只写upstream prematurely closed connection，根本看不出是缓冲区惹的祸。
根据你应用的实际响应体大小调：
- 纯API服务（JSON为主）：
fastcgi_buffers 16 256k+fastcgi_buffer_size 256k - 含大量内联CSS/JS的页面：
fastcgi_buffers 32 512k，再加fastcgi_busy_buffers_size 512k - 千万别设
fastcgi_max_temp_file_size 0来“规避”问题——这会让大响应强制写磁盘，IO打满后照样502
backlog不够，连接在内核队列就丢了
Nginx和PHP-FPM各自维护一个等待处理的连接队列，叫backlog。默认值太小（Nginx 511，PHP-FPM 128），高并发下新连接还没进FPM就被内核丢弃，现象是请求随机超时或504，netstat -s | grep -i "listen overflows"能看到溢出计数飙升。
两处必须同步调大：
- Nginx配置中，在
listen 80后面加backlog=1024（如listen 80 backlog=1024;） - PHP-FPM池配置（如
www.conf）里设listen.backlog = 1024 - Linux内核也要跟上：
echo 'net.core.somaxconn = 65535' >> /etc/sysctl.conf && sysctl -p
这三个地方少一个，backlog优化就白做。很多团队调了Nginx和FPM却忘了改内核参数，压测时依然断连。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
