Nginx+PHP-FPM频繁出现502 Bad Gateway
高并发下频繁出现502，出现502的接口并不是等待很长时间，而是马上响应了502，我在想是不是PHP-FPM资源处理不过来了？有什么方法能让这些请求阻塞，而不是马上502
很奇怪，每秒平均也就有20-30的并发量，为啥有大量的502，理论上我开起了上百个php-fmp进程
Nginx错误日志
[error] 3395405#0: *353418 recv() failed (104: Connection reset by peer) while reading response header from upstreamPHP-FPM配置
pm.status_path = /phpfpm_80_status
pm.max_children = 2000
pm.start_servers = 500
pm.min_spare_servers = 500
pm.max_spare_servers = 800
pm.max_requests = 1000
request_terminate_timeout = 60
request_slowlog_timeout = 5
关于 LearnKu
粤公网安备 44030502004330号
Connection reset by peer
大概率是处理不过来
可以尝试这些操作
fpm是阻塞性设计，当前请求没处理完，是不会接收后续请求的，超出fpm并发，就会导致此结果，所以优化按重要性如下：
pm.max_requests=300太小了，应提高此值。这个错误信息通常表示你的应用服务器（上游服务器）在 Nginx 试图读取响应头时突然关闭了连接。这可能是由于你的应用服务器崩溃或者运行超时。
你可以尝试以下方法来解决这个问题：
检查你的应用服务器的日志，看看是否有任何错误信息。这可能会帮助你找到问题的原因。
增加你的应用服务器的超时时间。这可能会帮助你解决由于运行超时导致的问题。
如果你的应用服务器是 PHP-FPM，你可以尝试增加 pm.max_children 的值。这可能会帮助你解决由于 PHP-FPM 子进程不足导致的问题。
如果你的应用服务器是 PHP-FPM，你可以尝试设置 request_terminate_timeout 的值。这可能会帮助你解决由于单个 PHP 请求运行过长导致的问题。
如果你的应用服务器是 PHP-FPM，你可以尝试设置 catch_workers_output = yes。这可能会帮助你获取更多的错误信息。
需要注意的是，这些方法可能不会解决所有的问题，你需要根据你的实际情况来选择合适的方法。
兄弟，你的上一个帖子还没关。我建议咱们先确定问题再进行调整，先把 fpm 的日志都打开，看看请求过来了没有，以及处理的时间。
如果是并发导致的，症结往往在处理速度上。你想让客户端等着排队连接不释放解决不了问题。你不如先找找哪里处理慢，进行程序优化。
如果你想让用户等待，也可以采取队列异步处理的方式，这样就能马上先响应等待状态并释放连接，再异步通过 websocket 等手段推送用户执行结果。
本质上是你的接口太慢了，看看监控，找找高频的慢接口，优化下
记录下请求日志，分析下耗时的请求。查看有没有过多耗时的或者使用mysql频繁的cmd
查看日志，可能是程序里面出致命错误了，不一定是并发问题。
fpm 设置成静态的，不要搞动态的。