phpwaf临时停用需修改php.ini注释extension=phpwaf.so，恢复时取消注释并重启php-fpm；因其是php扩展无独立进程，不能用systemctl控制，且须确认对应php版本配置与重载fpm生效。
phpwaf 临时停用是通过修改配置文件实现的，不是 systemctl 或 service 命令控制
PHPWAF 是以 PHP 扩展形式加载的（如 phpwaf.so），没有独立进程，因此不能用 systemctl stop phpwaf 这类命令。它的启停完全依赖于 PHP 配置是否启用该扩展。
- 停用 = 在
php.ini或对应 ini 文件中注释或删除extension=phpwaf.so行 - 恢复 = 取消注释、补全路径、确保
extension_dir正确，并重启 PHP-FPM 或 Apache - 常见位置：
/etc/php/*/fpm/php.ini、/etc/php/*/cli/php.ini、/etc/php/*/mods-available/phpwaf.ini
确认 phpwaf 是否已加载，别靠“文件存在”判断
即使 phpwaf.so 文件在磁盘上，也不代表它正在生效。必须检查运行时扩展列表：
- 执行
php -m | grep phpwaf（CLI 模式） - 执行
php-fpm -m | grep phpwaf（FPM 模式） - 更可靠的方式：新建一个
info.php，内容为<?php phpinfo(); ?>，浏览器访问后搜索 “phpwaf” - 如果没出现，说明未加载成功 —— 可能是路径错误、依赖缺失（如 libcurl）、或 SELinux/权限阻止了 so 文件读取
停用后仍触发拦截？检查是否多版本 PHP 共存
很多服务器同时装了多个 PHP 版本（如 7.4 / 8.1 / 8.2），而 phpwaf 可能只编译适配了其中某一个。停用操作可能只改了 CLI 的 php.ini，但 Web 请求走的是 FPM 的配置。
- 用
ps aux | grep php-fpm看实际运行的 FPM 主进程对应哪个 PHP 版本 - 用
php-fpm -i | grep "Loaded Configuration File"查它真正加载的 ini 路径 - 务必同步修改该路径下的配置，否则 Web 请求照常被拦，而
php -v却显示没加载 - 某些面板（如宝塔）会为每个站点单独指定 PHP 版本和配置，需进面板确认站点级设置
恢复防护时最常漏掉的一步：重载 PHP-FPM 而非 reload nginx
PHP 扩展变更后，nginx 或 Apache 只是反向代理，真正解析 PHP 的是 PHP-FPM 进程。不重启 FPM，新配置永远不会生效。
立即学习“PHP免费学习笔记（深入）”；
- 正确操作：
systemctl reload php*-fpm（如systemctl reload php8.1-fpm）或kill -USR2 $(cat /var/run/php/php8.1-fpm.pid) - 错误操作：只
systemctl reload nginx，或只改了 ini 但忘记重载 - 验证方式：改完后立刻执行
php-fpm -m | grep phpwaf，必须有输出才算成功 - 注意：有些旧版 php-fpm 不支持 USR2 重载，必须用
restart，但会导致短时 502
实际操作中，最难排查的是「以为停了，其实某个子进程还在用旧配置」，尤其是容器化或 systemd socket-activated 场景下。建议每次变更后，用 php-fpm -tt 测试配置语法，再用 php-fpm -i 确认加载路径与模块列表。