云waf和cdn应与源站访问控制、https及php补丁一起使用。以cloudflare为例，先核对请求确实经过代理，再配置规则、检查安全事件并回归正常业务；不能只开启缓存就宣告漏洞已经修复。
先理清楚流量走向，别急着直接开安全防护开关
把站点所有域名、API接口、上传入口和源站地址全部梳理清楚，确认所有需要防护的HTTP请求，确实都经过云代理链路。如果只修改部分DNS记录，或者仅把静态资源域名接入代理，剩下的动态接口不会自动被WAF纳入检测范围。
还要检查源站能否被直接访问。按实际部署采用可信回源访问控制、回源认证或其他隔离方式，并保留受控管理通道。隐藏IP地址本身不是安全边界，不能假设攻击者永远不知道旧地址。
缓存、请求检测、运行时补丁，三层各管各的作用
CDN主要处理边缘分发与缓存，WAF根据请求特征和规则采取动作，最终执行PHP的仍是源站工作进程。PHP2Shell涉及解释器内存和状态生命周期，代理层即使拦截部分请求模式，也不能替换运行时补丁或清除既有入侵。
立即学习“PHP免费学习笔记（深入）”；
云WAF的检测能力受套餐等级、请求解析能力及上限、配置范围、规则更新的共同影响。别光看产品名称就默认它能覆盖全部攻击路径，也别为了拉高缓存命中率，把带登录状态的敏感页面缓存给所有访问用户。
第一步：打开托管规则页，核对覆盖范围和实际生效动作
按Cloudflare现行官方操作路径，进入站点的Security rules页面，筛选Managed rules分类，找到Execute类型的部署条目，再点进Browse rules查看具体规则。
部署或者调整规则之前，先确认好账号权限、当前套餐支持的功能和规则的生效范围。
图中是官方文档的规则浏览示例，所选标签用于展示筛选控件，不代表PHP2Shell专用规则已经存在或启用。修改状态或动作前先在受控范围测试，并记录原设置和回退条件，不能直接把全站业务当试验流量。
第二步：按时间和动作维度筛选安全事件
打开Analytics页面切到Events标签，点Add filter，按需设置筛选的字段、运算符和对应值，最后点Apply确认生效。先把时间范围和站点范围限定好，再重点查看Block这类拦截动作的记录，别把不同业务的安全事件混在一起分析。
事件里出现拦截，说明对应安全功能采取了动作，不等于源站漏洞已经修复。安全事件还可能采用抽样数据，查不到某次请求时应结合日志保留范围、筛选条件和源站记录继续排查。
第三步：点开事件详情，和源站日志交叉校验
在Sampled logs中展开需要调查的事件，核对时间、路径、动作和触发的安全功能，按需导出事件JSON。单个请求可能触发多个安全事件，不要把事件条数直接当成独立攻击请求数。
Cloudflare Ray ID有助于关联，但官方不保证每个请求的编号都唯一。还应结合时间、路径、主机和日志来源，不按单一编号强行合并记录；客户端自行伪造的头也不能当作可信身份。
用教学样本检查日志关联，结果不能直接等同于拦截验证
<?php
// 两条教学事件故意使用相同Ray ID；真实关联还需时间、路径等上下文。
$events=[
['ray'=>'teaching-ray','time'=>'2026-10-22T08:00:00Z','path'=>'/login','action'=>'block'],
['ray'=>'teaching-ray','time'=>'2026-10-22T08:00:02Z','path'=>'/upload','action'=>'skip']
];
$groups=[];
foreach ($events as $event) {
$key=json_encode([$event['ray'],$event['time'],$event['path']],JSON_THROW_ON_ERROR);
$groups[$key]=($groups[$key] ?? 0)+1;
}
echo json_encode(['teaching_events'=>count($events),'context_groups'=>count($groups),
'origin_logs_checked'=>false,'php2shell_block_verified'=>false,
'note'=>'Ray ID alone is not a guaranteed unique join key'],
JSON_PRETTY_PRINT),PHP_EOL;
保存为audit.php后运行下方命令。本地使用macOS的PHP 8.5.10 WebAssembly环境，输入是两条教学事件，不曾连接云账号或发送攻击请求，输出保留未验证源站及漏洞拦截的状态。
php audit.php
静态资源分发和动态接口防护，要用不同的验收方法
- 先备份当前的站点范围、规则配置和变更时间点，确保出问题有可用的回退方案。
- 对着登录、上传、各类动态接口逐一测试正常请求，记录边缘节点的动作和源站返回的实际结果。
- 核对完源站的访问边界、补丁状态和全量副本，再逐步放量上线，全程留意有没有误拦截情况。
| 场景 | 重点设置 | 验收依据 |
|---|---|---|
| 图片和公开静态内容 | 缓存策略与更新机制 | 内容一致性及缓存行为 |
| 登录、上传和动态接口 | 托管规则、业务范围与源站控制 | 事件动作及合法请求回归 |
受控测试至少要覆盖登录、上传、支付相关的浏览器操作流程和后台接口。出现误拦截时，要针对具体规则和对应路径做调整，别为了恢复单个接口直接跳过整个WAF的防护，也别把所有带认证的请求长期加到无条件放行名单里。
防护接入完成后，重点排查四个常见盲区
- 排查问题时发现WAF完全没有对应记录：确认请求确实走了代理，事件筛选的范围设置正确，同时核对WAF的日志抽样和留存规则有没有限制。
- 源站还能被直接访问：检查备用域名、旧的直连地址和回源访问控制规则，先保留必要的管理通道，再逐步收拢所有对外入口。
- 合法上传请求被拦截：顺着具体触发的规则和请求上下文定位原因，不要直接全站关闭防护。
- 缓存泄露了用户登录态相关内容：检查会话关联页面的响应缓存策略，先隔离影响范围再做修正。
这套流程的作用是提升防护可见性、减少暴露面，不是对PHP2Shell攻击的完整阻断保证。上线之后仍要定期核对PHP补丁、运行进程和全量站点副本；如果已经出现入侵迹象，要单独开展应急响应处理。
