Nginx 502 与木马共存排查：网页后门定位与清除全流程

核心要点（TL;DR）

502 与木马共存时，先看 Nginx 与 PHP-FPM 错误日志锁定异常请求与进程。
用 find 按时间与权限筛出可疑 PHP 文件，再 grep 高危函数定位 webshell。
清除后门后必须重置凭据、修补入口并做文件完整性基线，否则会二次感染。
排查顺序固定为日志→进程→文件→清除→加固，可显著缩短恢复时间。

站点突然大面积 502，重启 PHP-FPM 只顶几分钟又挂，登录服务器一看 CPU 跑满、进程数暴涨——这往往不是配置问题，而是网页后门在后端偷偷干活。本文按实战顺序给出可执行命令，帮你同时解决 Nginx 502 与木马共存的问题，恢复业务并根除后门。

一、先判断：502 是故障还是入侵信号

Nginx 返回 502 的本质是上游（PHP-FPM、Tomcat、Node）无响应或连接被拒。正常故障多与配置、内存、并发有关；被入侵时则表现为“重启即好、很快复发”，且伴随陌生进程与异常文件。

先做三件事确认方向：

tail -n 200 /var/log/nginx/error.log
tail -n 200 /var/log/php-fpm/error.log
ss -antp | grep -E ':9000|:80|:443' | head -50

如果 error.log 中反复出现 upstream timed out 且请求 URI 指向陌生 PHP 文件，或 PHP-FPM 报 pool www seems busy，基本可判定后端被恶意脚本占满。

二、定位：从日志到进程锁定可疑请求

1. 找出高频异常请求

awk '{print }' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print }' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -30

关注两类特征：单一 IP 高频访问同一路径；路径为随机字母数字组合的 .php 文件，或带 ?cmd=、?pass= 等参数。

2. 关联进程与文件

ps aux --sort=-%cpu | head -20
ls -l /proc/<PID>/cwd /proc/<PID>/exe
lsof -p <PID> | grep -E '\.php|\.sh'

拿到可疑 PID 后，通过 /proc/PID/cwd 找到工作目录，通常就是后门所在站点。

三、找文件：按时间、权限与函数特征筛查

不要全盘盲搜，先缩小范围再人工确认。

# 近 7 天被修改的 PHP 文件
find /var/www -name '*.php' -mtime -7 -type f
# 权限异常文件
find /var/www -type f -perm 777
# 高危函数特征
grep -rnE 'eval\(|assert\(|base64_decode\(|system\(|passthru\(' /var/www --include='*.php' | head -50

特征	正常文件	可疑后门
修改时间	与发布记录一致	凌晨或攻击时间点突变
文件权限	644 / 755	777 或属主为 www 却可写
代码形态	结构清晰可读	单行超长、混淆编码、动态拼接
文件名	语义化	随机串、伪装成图片或缓存

对命中文件逐个打开确认，重点看 $_POST、$_GET 直接拼进执行函数的位置。

四、清除：止血、取证、替换，而不是逐个删

隔离：将节点从负载均衡摘除或切维护页，避免继续被利用。
取证：打包站点目录与数据库，保留日志，记录后门路径与时间。
清除：优先用官方干净包整体替换被感染目录，比逐个删更彻底。
清残留：检查 crontab -l、/etc/cron.*、systemctl list-units、~/.ssh/authorized_keys，删除异常项。
重置凭据：改数据库、后台、SSH、云账号口令，作废可疑会话。

crontab -l; ls -l /etc/cron.d /etc/cron.daily
cat ~/.ssh/authorized_keys
grep -rn 'eval' /var/www --include='*.php' | wc -l

五、加固：让 502 与后门不再复发

升级 CMS、插件与 PHP 到受支持版本，关闭上传目录的 PHP 执行权限。
Nginx 中限制上传目录：location ~* /uploads/.*\.php$ { deny all; }。
建立文件哈希基线，定期比对；开启 PHP-FPM 慢日志与请求日志。
部署主机层防护，如 AegisX 的文件完整性监控与恶意文件检测能力，可在后门落地或改动时告警，缩短发现窗口。

行动建议

把排查顺序固化为“日志→进程→文件→清除→加固”，每次事件后更新检查清单与基线。发现 502 反复发作时，不要只重启服务，先按本文查一遍后门，再决定是否扩容——顺序错了，问题永远修不完。

常见问题（FAQ）

Nginx 502 一直报，重启 PHP-FPM 就好一会儿，是木马吗？

不能直接断定，但这是典型信号。先用 tail -f 查看 Nginx error.log 与 PHP-FPM 慢日志，若发现同一 IP 高频请求某个陌生 PHP 文件，且该文件占用大量子进程，基本可判定为网页后门在消耗后端。重启只能临时缓解，必须定位并删除后门文件，同时检查是否有计划任务或守护进程在重建它。

怎么快速找出网站目录里的 webshell？

先缩小范围再人工确认。用 find 按修改时间筛出近期新增或改动的 PHP 文件，再用 grep 搜索 eval、assert、base64_decode、system 等高危函数组合，配合文件权限异常（如 777）和超短文件名排序。最后用静态查杀工具与人工审计结合，重点看混淆编码和动态拼接的代码段，避免误删正常业务文件。

删掉后门文件就安全了吗？

不够。攻击者通常留有多条入口，删文件只是止血。还需检查 crontab、systemd 服务、SSH 授权密钥、数据库中的可疑账号与 UDF，重置所有网站与数据库口令，升级 CMS 及插件到最新版本，并封禁日志中确认的恶意 IP。完成后建立文件哈希基线，定期比对才能发现再次植入。

如何在不影响业务的情况下清除后门？

建议先隔离再处理。把站点切到维护页或从负载均衡摘除该节点，备份当前目录与数据库用于取证，再在副本上分析确认后门路径。清除时逐文件替换为官方干净版本，而不是逐个删改，避免遗漏。处理完先在预发环境验证功能，再放回流量，全程保留操作记录便于复盘。

有没有必要上 WAF 或主机防护？

有必要，但要理解定位。WAF 能在请求层拦截常见 webshell 上传与访问特征，主机防护能监控文件改动和异常进程，两者互补。像 AegisX 这类方案可提供文件完整性监控与恶意文件检测能力，减少人工排查成本。不过防护不能替代修补漏洞，入口不封，绕过只是时间问题。

资讯中心