排查php2shell漏洞时，要把web访问日志、php错误日志、工作进程异常记录、主机侧事件按时间线串起来核对。常规的访问日志大多不会存储请求体，单靠某个关键词、状态码或者一次异常上传，没法直接证明漏洞利用已经成功。
先存好原始日志，再开始筛选
收到告警后，先把对应时间段的日志存好副本，标注清楚所属主机、时区、日志轮转文件、采集来源，之后只在副本上做检索分析。别图省事直接清掉线上日志，也别只导出几条命中关键词的记录，不然正常请求的上下文很容易就丢失。
如果站点前面接了CDN或者反向代理，要同步留存边缘节点日志和源站日志。先确认各服务器时钟是否对齐，真实客户端IP是由哪一层可信代理写入的，用户自己携带的转发头不能直接当成可信身份依据。
为什么访问日志经常存不下完整攻击内容
PHP2Shell涉及请求处理中的内存错误或跨请求状态。异常可能出现在业务代码之前，应用日志因此未必记录完整过程；同一工作进程后续处理的请求也可能与之前的状态有关。普通访问日志多数只保留路径、时间和结果，不包含请求体，无法仅凭日志重建全部利用过程。
正常返回不代表不存在危险路径，服务器错误也可能来自合法上传、依赖故障或程序缺陷。这里采用的是“发现异常线索，再关联验证”的方法，不提供声称能识别全部PHP2Shell攻击的通用正则。
补全日志字段，但不要记录敏感请求内容
Nginx的日志格式可增加请求编号、方法、内容类型、请求长度、耗时和上游状态。请求长度包含请求行、请求头和请求体，并不等于上传文件大小；没有可靠长度声明的请求也不能简单忽略。
# log_format在http上下文定义；启用前先做配置测试
log_format php_audit escape=json
'{"time":"$time_iso8601","request_id":"$request_id",'
'"method":"$request_method","uri":"$uri","status":$status,'
'"request_length":$request_length,"request_time":$request_time,'
'"upstream_status":"$upstream_status","content_type":"$http_content_type"}';
# 在需要审计的站点server上下文启用，路径按实际环境调整
access_log /var/log/nginx/php-audit.log php_audit;
新的日志格式只会对之后的请求生效，没法补回之前没记录的请求体内容。别顺手把Cookie、Authorization头或者全部表单内容都记进去，日志本身也要做好访问控制、明确留存周期，执行受控导出规则。
靠请求编号和进程时间串联四类记录
从异常上传、突发报错、请求耗时突变或者告警发生的时间点切入，保留前后一段的正常流量做对照，别把业务高峰误判成攻击行为。
关联代理与PHP错误日志，查找同一时间的内存耗尽、工作进程退出或异常重启。先核对日志级别和采集范围，不把缺少报错当成排除证据。
接着核对文件改动、计划任务、账号登录记录和可疑外联行为，跨请求的问题不能死盯着单条HTTP记录不放，必要时要顺着节点和工作进程的上下文往下查。
把所有线索分成待核实、已确认异常、可解释的正常事件三类，每类都附上对应证据。如果确认有入侵嫌疑，立刻转入应急响应流程，同步安排PHP运行时的补丁更新。
| 已有材料 | 能先做什么 | 不能直接推出什么 |
|---|---|---|
| 仅Web访问日志 | 定位异常时间与路径 | 请求体内容及利用是否成功 |
| 多层日志加主机审计 | 关联进程和后续行为 | 没有命中就一定未入侵 |
一个不会误报“已确认攻击”的筛选示例
下面的PHP代码内置了三条教学用日志，只会把触发服务器错误的POST请求放进复核队列。代码里没有真实攻击流量，也不会访问任何远程地址，适合用来先验证日志解析和结果字段的处理逻辑是否正常。
<?php // 教学JSON行日志；规则仅筛出待调查记录，不是PHP2Shell检测签名。
$input = <<<'LOG'
{"time":"2026-10-22T08:00:00+00:00","request_id":"demo-a","method":"GET","status":200,"request_length":220}
{"time":"2026-10-22T08:01:00+00:00","request_id":"demo-b","method":"POST","status":500,"request_length":3100}
{"time":"2026-10-22T08:02:00+00:00","request_id":"demo-c","method":"POST","status":200,"request_length":3000}
LOG;
$review=[]; $invalid=0;
foreach (explode("
",$input) as $line) {
try { $row=json_decode($line,true,512,JSON_THROW_ON_ERROR); }
catch (JsonException $e) { $invalid++; continue; }
if (($row['method'] ?? '')==='POST' && (int)($row['status'] ?? 0)>=500) {
$review[]=['request_id'=>$row['request_id'] ?? null,
'reason'=>'POST with server error; correlate other evidence'];
}
}
echo json_encode(['teaching_sample'=>true,'review'=>$review,
'invalid_lines'=>$invalid,'exploit_confirmed'=>false],JSON_PRETTY_PRINT),PHP_EOL;
保存为audit.php后运行下面的命令。示例在macOS的PHP 8.5.10 WebAssembly环境执行，结果仅包含demo-b的待复核记录；其他两条未被选中，不代表它们经过了安全验证。
php audit.php
检索结果不对的时候，先排查这四个点
- 查不到对应时间的日志：核对时区、服务器时钟、压缩归档的轮转日志、CDN日志的留存范围。
- 所有访问者IP显示为同一个：检查可信代理的配置，不要直接采信用户自行传入的地址头。
- JSON日志解析失败：检查转义格式、内容截断、多套日志格式混写的问题，保留原始日志行留待复核。
- 只看到报错找不到后续攻击证据：结合业务故障现象和主机侧行为综合分析，不要看到错误率高就直接判定存在漏洞。
排查报告要同时记录已找到的线索、缺失的数据和推论的适用边界。补全监控和打补丁是两项并行的工作：就算日志里没发现异常，也要对照实际安装的版本来源核对补丁状态，确认所有服务进程都已经跑在修复后的运行时版本上。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
