如何核查更新目录是否曾被成功访问

核查 wp-content/upgrade/ 是否曾被成功访问，不能只看更新命令是否返回成功，也不能只确认目录当前是否为空。应把“入口响应、访问日志、文件状态、更新时间线”放在一起判断，因为临时文件可能已经被访问、随后又被清理。

先验证当前入口是否被遮断

从站点外部请求升级目录及其下级路径，例如：

curl -i https://example.com/wp-content/upgrade/
curl -i https://example.com/wp-content/upgrade/index.php

如果站点部署在 /blog/ 等子目录，测试路径也必须使用实际公开路径。预期结果应是 403 Forbidden，或由上游安全设备统一返回的拒绝状态。若返回 200、206、目录列表、301，甚至出现 PHP 响应，说明请求仍可能到达站点处理链路，不能认为防护已经生效。

测试时还要确认请求经过的确实是生产入口。DNS、CDN、负载均衡、反向代理和另一台公网 Web 服务，都可能使用不同配置。Nginx 规则也必须位于实际生效的虚拟主机中，并在配置检查通过、平滑加载后再次测试。

再从日志确认是否发生过成功访问

在更新前后设定明确的观察范围，检索 Nginx 访问日志：

rg '/wp-content/upgrade/' /var/log/nginx/access.log*

重点核对四类信息：请求时间是否落在更新窗口；来源是否为公网；状态码是否出现 200、206 等成功响应；请求对象是否包含 PHP 文件、配置文件、压缩包或异常临时文件。还应结合 User-Agent、Referer、请求频率和源地址，区分正常探测与可疑访问。

403 只能证明某次请求被入口拒绝，不能证明此前没有成功访问，也不能覆盖其他公开路径。若日志在遮断规则生效前出现成功响应，应保存原始日志、时间、源地址和请求路径，并进一步检查核心文件、插件、主题、管理员账号、计划任务及出站连接。

用文件和版本证据完成交叉核对

更新后检查升级目录中的文件、所有者和修改时间，关注不明可执行脚本、异常压缩包以及与本次更新无关的内容。随后核对 wp core version、校验和结果、更新任务起止时间及业务功能。目录为空只能说明当前没有残留文件，不能单独证明没有发生访问。

最终应形成一条可复核证据链：规则生效时间、外部测试结果、访问日志结论、更新前后版本、文件检查结果和业务验收记录。只有这些信息相互吻合，才能判断升级目录是否曾被成功访问，以及是否需要按安全事件流程继续调查。