前言把 PHP 8.5 项目放到 Nginx 后面最容易遇到的报错就是浏览器上那句冷冰冰的502 Bad Gateway。它的麻烦之处在于有时刷新一下就好了有时只在并发高的时候出现有时明明日志里什么都没写。于是很多人开始「改大超时」「重启 php-fpm」问题暂时消失过几天又回来。502 的本质是Nginx 作为网关没能从上游upstream拿到一个合法的响应。上游可能是php-fpm也可能是另一台后端服务。它和「请求太慢」导致的 504 是两回事混在一起调就会一直调不对。而且 PHP 项目走 Nginx 时通常用的是 FastCGI 协议不是 HTTP 反代因此proxy_*那一堆指令根本不生效——这是一个非常高频的误配。本文按「先看日志定位 → 分清 502/504 → 检查 FastCGI 指令 → 检查 php-fpm 进程池 → 检查 socket 与权限」的顺序把这条链路完整走一遍。文中配置基于PHP 8.5的php-fpm与 Nginx 1.2x 系列指令名在更早的 PHP 8.x 上也完全一致。一、第一步永远是看 error.log而不是猜Nginx 的error.log会明确告诉你 502 属于哪一类这是分诊的关键error.log 片段含义排查方向connect() to unix:/run/php-fpm.sock failed (2: No such file)socket 文件不存在listen路径写错、fpm 没启动connect() ... failed (13: Permission denied)权限不足nginx worker 用户不在 socket 属组、SELinuxconnect() ... failed (11: Resource temporarily unavailable)连接队列满进程池打满、listen.backlog太小recv() failed (104: Connection reset by peer)上游断开fpm worker 崩溃、被 OOM 杀掉upstream prematurely closed connection while reading response header上游没回完就关fpm 超时终止、脚本 fatalupstream timed out ... while reading response header等不到响应这其实是504超时配置问题先把error_log的日志级别调到warn或error并确认路径http {error_log /var/log/nginx/error.log warn;# ...}同时打开 php-fpm 的慢日志它记录的是「哪个脚本慢、慢在哪个函数」这是 Nginx 日志给不了的信息; /etc/php/8.5/fpm/pool.d/www.confrequest_slowlog_timeout 5sslowlog /var/log/php8.5-fpm-slow.logcatch_workers_output yes二、FastCGI 场景下生效的是 fastcgi_而不是 proxy_PHP 项目和 Nginx 之间走的是 FastCGIFast Common Gateway Interface配置在location ~ \.php$里。如果你把proxy_read_timeout从 60s 改到 600s 却毫无效果原因就在这里。location ~ \.php$ {fastcgi_pass unix:/run/php/php8.5-fpm.sock;fastcgi_index index.php;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;# 关键超时默认 60s长任务必须显式放大fastcgi_connect_timeout 5s;fastcgi_send_timeout 60s;fastcgi_read_timeout 300s;# 让上游返回的 Set-Cookie 等头正常透传fastcgi_buffering on;fastcgi_buffers 16 16k;fastcgi_buffer_size 32k;fastcgi_busy_buffers_size 64k;include fastcgi.conf;}三个超时的分工要清楚fastcgi_connect_timeoutNginx 连上 fpm 的等待时间正常极短设 5s 足够。fastcgi_send_timeout把请求体发给 fpm 的等待时间上传大文件时才需要放大。fastcgi_read_timeout等 fpm 返回第一段响应的等待时间。这个才是造成大面积 504 的元凶。fastcgi_buffering on时 Nginx 会先把上游响应缓冲到磁盘/内存再转发如果响应头超大而fastcgi_buffer_size太小会出现upstream sent too big header一类告警症状也可能是 502。注意这些缓冲区大小必须满足fastcgi_busy_buffers_size 2 * fastcgi_buffer_size之类的常见约束改小之前先想清楚。三、php-fpm 进程池502 的第一大来源connect() ... failed (11: Resource temporarily unavailable)几乎可以断定是进程池被打满所有 worker 都在忙新连接进不了队列。这类问题有两个层次——池子太小以及连接队列太短。; /etc/php/8.5/fpm/pool.d/www.conf[www]user www-datagroup www-data; 监听方式二选一; 1) Unix socket本机通信首选省掉 TCP 握手listen /run/php/php8.5-fpm.sock; 2) TCP跨机器或容器编排时用; listen 127.0.0.1:9000; 连接队列长度突发并发时排队超过就直接 502listen.backlog 1024; socket 属主与权限必须让 nginx 的 worker 用户能读能写listen.owner www-datalisten.group www-datalisten.mode 0660; 进程管理dynamic 适合波峰波谷明显的业务pm dynamicpm.max_children 32pm.start_servers 8pm.min_spare_servers 4pm.max_spare_servers 12; 单个 worker 最多处理多少个请求后重启用来兜住扩展的内存泄漏pm.max_requests 500; 单个请求的硬上限超时会被 fpm 直接杀掉request_terminate_timeout 300s怎么定pm.max_children先测出单个 PHP 进程处理时的常驻内存上限用ps -o rss观察峰值单位 KB再用「可用内存 ÷ 单进程内存」得出上限并留出 20%~30% 余量。设得比物理内存允许的还大只会让 OOM killer 来替你收场症状就是recv() failed (104: Connection reset by peer)。pm.max_requests也值得说一句设为0表示永不重启 worker短生命周期脚本没问题但一旦某个扩展有内存泄漏worker 会越吃越多直到被杀设得太小比如 10则会让 worker 频繁销毁重建白白浪费 CPU。四、socket 与权限看不见的那层使用 Unix socket 时「fpm 起来了」和「Nginx 能连上」是两个独立的事实。三种常见断法路径不一致listen写的是/run/php/php8.5-fpm.sockNginx 里写的是/var/run/php-fpm.sock。/var/run通常是/run的软链看着像一回事实际路径不同。权限不足listen.mode是0660时nginx 的 worker 用户必须在listen.group指定的组里否则报Permission denied。安全模块拦截在启用了 SELinux 的系统上Nginx 主动连 socket 需要放行报错看起来像权限问题但改文件权限没用。这类系统上需要按发行版文档调整布尔值改完记得看审计日志确认。判断 fpm 是否真的在监听可以直接问系统# 看进程与池子ps aux | grep [p]hp-fpm# 看 socket 是否存在、属主是谁ls -l /run/php/php8.5-fpm.sock# 走 nginx 之外的路径验证 socket 可用需要在池里配置 pm.status_pathcurl -s --unix-socket /run/php/php8.5-fpm.sock http://localhost/status# 看内核层面的连接队列溢出计数nstat -az | grep -i listennstat输出里的TcpExtListenDrops或TcpExtListenOverflows如果持续增长说明连接队列确实在丢包这时候调大listen.backlog与somaxconn同时也要看是不是单请求太慢。五、完整可用的最小配置把下面两段分别落到 Nginx 和 php-fpm就是一个能扛住常规并发、而且出问题能定位的基线配置。server {listen 80;server_name example.com;root /var/www/app/public;index index.php;location / {try_files $uri $uri/ /index.php?$query_string;}location ~ \.php$ {try_files $uri 404;fastcgi_pass unix:/run/php/php8.5-fpm.sock;fastcgi_index index.php;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;fastcgi_connect_timeout 5s;fastcgi_send_timeout 60s;fastcgi_read_timeout 300s;include fastcgi.conf;}# fpm 状态页只在内部可达排查时很有用location /fpm-status {allow 127.0.0.1;deny all;fastcgi_pass unix:/run/php/php8.5-fpm.sock;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;include fastcgi.conf;}}; /etc/php/8.5/fpm/pool.d/www.conf 的排查相关片段[www]listen /run/php/php8.5-fpm.socklisten.backlog 1024listen.owner www-datalisten.group www-datalisten.mode 0660pm dynamicpm.max_children 32pm.start_servers 8pm.min_spare_servers 4pm.max_spare_servers 12pm.max_requests 500pm.status_path /statusrequest_terminate_timeout 300srequest_slowlog_timeout 5sslowlog /var/log/php8.5-fpm-slow.log改完配置后的验证顺序固定不变先nginx -t检查语法再平滑重载nginx -s reload然后重载php-fpm最后压一次并发并用状态页观察active processes有没有顶到max_children。常见坑点1. 把 FastCGI 当成 HTTP 反代来调❌ 在location ~ \.php$里写proxy_read_timeout 600s;然后疑惑为什么不生效。 ✅ PHP 场景用的是fastcgi_read_timeoutproxy_*只在proxy_pass到另一台 HTTP 服务时才有效。2. 只放大超时不管进程池❌ 直接把fastcgi_read_timeout改成 600s慢请求占用 worker 的时间随之变成 10 倍池子更快被打满502 反而更频繁。 ✅ 超时和pm.max_children一起调更根本的是找出慢查询或慢接口把它从请求链路里挪走。3. 误以为max_execution_time能兜住慢脚本❌ 设置max_execution_time 30就以为脚本 30 秒必死 —— 在 Unix 上这个计时只统计脚本自身的执行时间不包含阻塞在系统调用上的时间等数据库、等外部 HTTP 都在此列。 ✅ 用request_terminate_timeout作为真正的硬上限它由 fpm 侧的定时器强制终止请求。4.pm.max_requests设成 0 或过小❌pm.max_requests 0让 worker 永不回收内存只涨不降或者设成10worker 频繁重建。 ✅ 设成几百如 500既能兜住泄漏又不会带来明显抖动。5.try_files $uri 404;缺失导致脚本路径被拼接❌ 只写fastcgi_pass而不做try_files请求/upload/evil.jpg/x.php这类路径时可能被交给 PHP 执行。 ✅ 在location ~ \.php$里先try_files $uri 404;或使用带if防护的等价写法并确认cgi.fix_pathinfo的取值符合预期。6. 改了配置但忘了重载❌ 编辑www.conf后直接测试以为没生效是因为「设置不对」反复改参数。 ✅ 每次修改后重载并核对状态页确认新值确实被加载。7. 用pkill php-fpm做「重启」❌ 强杀导致正在处理的请求全部中断用户看到一批 502。 ✅ 用发行版提供的服务管理命令做平滑重载让在途请求处理完再退出。8. 只盯着 Nginx 日志不看 php-fpm 日志❌ 排查半天只看到 502没有任何线索。 ✅ 同步打开 fpm 的 error 日志与 slowlog脚本 fatal error 会写进 fpm 日志而不是 Nginx 日志。总结现象最可能的原因优先检查failed (2: No such file)socket 路径不一致listen与fastcgi_pass是否逐字相同failed (13: Permission denied)socket 权限或安全模块listen.owner/group/mode与 nginx 用户failed (11: Resource temporarily unavailable)进程池或队列打满pm.max_children、listen.backlogConnection reset by peerworker 崩溃或被 OOM 杀系统日志、单进程内存上限大响应才 502缓冲区太小fastcgi_buffer_size等缓冲参数长请求超时超时链条未对齐fastcgi_read_timeout、request_terminate_timeout502 的排查几乎没有玄学先读error.log分清是「连不上」还是「连上了被断」再顺着 FastCGI 指令、进程池、socket 权限这三层往下查九成问题在一次定位之内就能收敛。真正要避免的是不看日志直接改超时——那只是把下一次故障推迟几天而已。