PHP后门清理不能仅靠删文件，需检查混淆代码、数据库注入、配置篡改、opcode缓存及定时任务等五层残留；命令行比面板更利于全面验证与清除。
PHP后门不是靠“删文件”就完事的——它往往藏在正常文件里、混淆代码中、或通过数据库/缓存持久化。直接删一个 shell.php 只是表面清理，真正的风险在隐蔽植入点。
怎么看清后门真实位置：别只盯着 webroot 下的可疑文件
后门常伪装成 wp-config.php、functions.php、index.php 的末尾或 base64_decode 区域，也可能藏在 .user.ini 或 .htaccess 的 auto_prepend_file 指令里。数据库中还可能有 wp_options 表里的恶意 option_value（比如 _transient_ 或 theme_mods_ 里嵌了 eval）。
- 用
grep -r "eval\|base64_decode\|system\|passthru\|shell_exec" /var/www/html/ --include="*.php"扫描，但注意绕过型后门会拆分字符串（如"e"."val"） - 检查 PHP 配置：运行
php -i | grep "auto_prepend_file\|disable_functions"，看是否被篡改 - 对比原始程序哈希：WordPress 可用
wp core verify-checksums（需 WP-CLI），否则手动比对官方 zip 解压后的md5sum
命令行删除 vs 面板删除：本质差在权限控制和上下文感知
面板（如宝塔、cPanel）删文件只是调用 unlink()，和命令行 rm 效果一样；但面板默认以 www 用户运行，删不了 root 写的文件，也看不到进程级后门（比如通过 inotifywait 监听文件变化并自动恢复的守护脚本）。
- 命令行优势：可切换用户（
sudo -u www-data php -r "unlink('shell.php');"）、查进程（ps aux | grep php）、清内存（php-fpm -t && systemctl reload php-fpm） - 面板劣势：不显示隐藏文件（
.git/、.env里可能存 WebShell）、无法批量处理数据库注入、日志记录不完整（删了文件但没留审计痕迹） - 真正差异不在“删”，而在“删前确认”和“删后验证”——命令行能快速结合
lsof -i :80、netstat -tulpn看有没有异常监听
删完立刻反弹？这些残留点90%的人会漏掉
后门不是静态文件，而是攻击链的一环。删完主文件，若没清理关联项，几秒内就可能重新生成。
立即学习“PHP免费学习笔记（深入）”；
- PHP opcode 缓存（
opcache）里可能已编译恶意代码：执行opcache_reset()或重启php-fpm - WordPress 插件目录下空文件夹（如
/wp-content/plugins/.maintenance）可能被用于写入新 shell - 数据库事件（
CREATE EVENT）或定时任务（crontab -u www-data -l）可能每分钟重建后门 - 服务器层面的
~/.bash_history或/etc/cron.d/里可能有攻击者留的反弹指令
最麻烦的不是找到后门，而是确认它没用其他方式复活——比如通过 WordPress 主题的 style.css 注释区加载远程 payload，或者利用未修复的 CVE（如 WP REST API 未授权创建用户）二次进入。删的动作本身不到一分钟，但验证闭环要覆盖文件、进程、网络、数据库、配置五层。
