did the fpm upgrade over the weekend and since then i get a handful of 502s an hour, totally random, no pattern i can find in the access log. fpm pool looks healthy, memory fine, nothing in dmesg. only thing that changed is the php version. before i start tearing the stack apart has anyone hit this and found it was something dumb like a pm.max_children default resetting?
check your opcache settings got carried over. the new build shipped a different default for opcache.memory_consumption on mine and it was silently thrashing under load. logged nothing until i turned fpm slowlog on.
slowlog is the move. i chased phantom 502s for a week and it was one cron overlapping with a backup job and spiking io. the php bump was a red herring for me, timing just lined up.
turned slowlog on, nothing caught yet but give it a few hours. opcache memory is at the old value, i set it explicitly years ago so that survived. good shout though.
when mine did this it was fpm not reaping children fast enough after the upgrade and the upstream timeout in nginx firing before fpm answered. bumped request_terminate_timeout and the 502s turned into slow 200s which was at least honest.
honest 200s lol. but yeah the nginx-to-fpm timeout mismatch bites people every single upgrade. worth a grep for the exact minute a 502 fired against your fpm access log, lines up fast.
update for anyone finding this later: it was request_terminate_timeout like cody said. default came back lower than my nginx proxy_read_timeout so long thumbnail gens got cut. raised it, quiet for two hours now.
nice, classic. file that one in the upgrade checklist, every point release seems to reset one of those two values.