php-fpm 重启后漏洞还在，问题通常出在 web 服务器（如 nginx）的缓存、反向代理配置未刷新，或者漏洞利用的是持久化存储（如文件、数据库）而非内存状态。要彻底解决，需检查 nginx 的 proxy_cache 或 fastcgi_cache 是否生效，确认 php 代码中的逻辑错误是否被写入磁盘，并清除相关缓存目录。
Nginx 缓存导致旧响应持续返回
如果 Nginx 开启了 FastCGI 缓存，PHP-FPM 重启并不能清除 Nginx 本地的缓存文件，导致客户端仍获取到包含漏洞的旧页面。解决方法是手动删除缓存目录或使用命令清理缓存。
location / {
fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=my_cache:10m;
fastcgi_cache my_cache;
fastcgi_cache_valid 200 302 10m;
# ... other config
}
执行 rm -rf /tmp/nginx_cache/* 后，再次请求将触发 PHP-FPM 重新生成响应，此时若代码已修复，漏洞即消失。
立即学习“PHP免费学习笔记（深入）”；
漏洞逻辑依赖持久化数据
若漏洞源于 SQL 注入或文件包含，且攻击者已通过之前的请求在数据库或文件系统中留下了恶意数据，仅重启 PHP-FPM 无法清除这些持久化状态。必须通过管理界面或脚本清理脏数据。
// 示例：清理用户提交的恶意标签
$db->query("DELETE FROM comments WHERE content LIKE '%<script>%';");
运行上述清理脚本后，即使重启服务，恶意内容也不会再被渲染，从而消除漏洞影响。
如何验证 PHP-FPM 进程是否真正重载了最新代码
要确认 PHP-FPM 是否加载了最新代码，可创建一个包含 phpinfo() 的测试文件，访问该文件并检查输出中的 “Loaded Configuration File” 和 “PHP Version” 是否与预期一致。若不一致，说明配置未生效或存在多实例冲突。
