pm.max_requests重启策略能切断109619的复用链吗
不能。fpm的pm.max_requests配置项仅用于在子进程处理指定数量的请求后触发软重启，它无法切断或影响客户端与服务器之间基于http keep-alive建立的长连接复用链。keep-alive机制由web服务器（如nginx）和php-fpm之间的fastcgi协议交互控制，而pm.max_requests只作用于fpm内部的工作进程生命周期管理。
Nginx与PHP-FPM的Keep-Alive连接如何工作
Nginx通过FastCGI协议与PHP-FPM通信时，默认会复用TCP连接以减少握手开销。这种复用发生在Nginx worker进程与FPM master进程管理的worker进程之间，只要连接未被显式关闭或超时，就会持续存在。pm.max_requests触发的重启只会让当前处理的请求完成并丢弃后续新请求，但不会主动断开已建立的TCP连接。
server {
listen 80;
server_name example.com;
location ~ \.php$ {
fastcgi_pass unix:/run/php-fpm/www.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
上述Nginx配置中，fastcgi_pass指向Unix socket，Nginx会自动复用该socket连接。当PHP-FPM worker因pm.max_requests达到上限而重启时，Nginx可能仍持有旧连接引用，导致新请求被分配到新worker，但TCP层面的复用状态并未被显式清理。
如何验证pm.max_requests对连接的影响
可以通过监控TCP连接状态来观察实际行为。使用ss或netstat命令查看Nginx与PHP-FPM之间的连接数变化，结合pm.max_requests的设置值，可以确认重启是否影响现有连接。实验表明，即使FPM worker重启，Nginx的Keep-Alive连接仍可能保持活跃，直到超时或被显式关闭。
// PHP脚本示例：检查当前FPM worker ID echo "Worker ID: " . getmypid() . "\n"; // 输出示例：Worker ID: 12345
运行上述PHP脚本多次，观察输出中的PID变化。当pm.max_requests达到阈值时，PID会改变，证明worker已重启。但此时若Nginx仍向同一socket发送请求，说明TCP连接复用未受影响。进一步使用tcpdump抓包分析，可发现TCP序列号连续，无RST包中断，证实复用链未被切断。
