网站访问日志出现异常请求怎么办？从识别扫描到止损复盘的排查清单

网站访问日志出现大量异常请求，先不要只看来源 IP，也不要因为返回 200、207 等成功类状态就认定“没有攻击”。正确做法是先保全日志，再按时间、主机、请求方法、路径、状态码、响应大小和应用错误关联分析，判断这是普通爬虫、漏洞扫描、已被拦截的尝试，还是应用已经执行了异常请求。

异常请求不等于已经入侵成功，但如果同一时间出现数据库错误、管理账户变化、代码文件新增或敏感接口返回异常大响应，就应提高事件等级，先止损再排查。

先保留证据，不要急着清日志

访问日志可能很快轮转，应用错误和 WAF 记录也可能使用不同保留周期。发现异常后，先记录发现时间和服务器时区，复制相关时间段的访问日志、错误日志、应用日志、数据库日志与 WAF 事件，并限制副本的读取权限。

• 记录原始文件路径、大小、修改时间和复制时间。
• 对证据副本计算哈希，用于确认后续分析期间没有被改动。
• 保留异常前后足够的时间窗口，不只截取最显眼的一行。
• 不要把含 Cookie、令牌、查询参数或个人信息的原始日志直接发到公开群聊。
• 如需交给第三方分析，先脱敏并记录谁取得了副本。

OWASP 建议安全日志能够回答“何时、何地、谁、做了什么”，同时强调访问令牌、密码、数据库连接串和密钥不应直接写入日志。日志既是证据，也可能包含敏感数据，本身需要访问控制和防篡改保护。

访问日志里先看哪些字段

字段	能回答的问题	异常信号示例
时间与时区	请求何时发生，是否与告警或变更重合	短时间突增、固定间隔或多个来源同时开始
Host、方法和路径	攻击了哪个站点、接口和动作	对不应公开的管理接口连续 POST，路径枚举
状态码	Web 层最终返回了什么结果	成功类状态伴随应用错误，或大量 5xx
响应字节数	不同请求是否触发明显不同的响应	同一路径在相似参数下出现稳定的大小分组
耗时	请求是否触发慢查询或计算	特定参数对应固定延迟，数据库负载同步升高
来源与 User-Agent	请求从何处来、如何自报身份	来源快速轮换、UA 与行为不一致

Nginx 的预定义 combined 日志格式包含来源地址、时间、完整请求、状态码、响应体字节数、Referer 和 User-Agent。实际分析前先确认服务器自己的 log_format，不要机械套用字段编号。

用聚合判断规模，不要逐行盯日志

单行日志很难说明问题。先按固定时间窗聚合，再找最集中的来源、路径、方法、状态码和响应大小。以下命令只适用于常见空格分隔格式，运行前应确认字段位置，并始终把日志内容视为不可信输入：

tail -n 200 access.log

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head

grep 'POST /target-path' access.log | wc -l

• 按来源聚合：可发现单一扫描器，但不能把 IP 当成永久身份，云主机和代理地址会变化。
• 按路径与方法聚合：比只封 IP 更容易找到真正需要修补或限制的入口。
• 按状态码与响应大小聚合：帮助识别同一探测在不同条件下是否得到不同结果。
• 按分钟统计：判断是持续爬取、瞬时爆发还是多个来源协同。
• 与正常基线比较：搜索引擎、健康检查、已授权安全扫描和真实用户行为都可能产生高频请求。

状态码能说明什么，不能说明什么

状态	初步含义	还要继续核对
401/403	请求在某个访问控制环节被拒绝	是 Web 服务器、WAF 还是应用拒绝，是否仍触发了后端逻辑
404	目标路径未找到	是否在批量枚举已知后台、备份文件或旧漏洞路径
200/201/207	请求被应用处理并返回成功类响应	响应内容、业务副作用、应用与数据库错误，不能仅凭状态判安全
429	限速策略生效	是否只限制单一 IP，真实用户和搜索引擎是否受影响
5xx	服务器、网关或应用处理异常	错误堆栈、数据库查询、资源使用和对应请求参数

尤其要注意“返回成功类状态，同时错误日志出现数据库语法、权限或对象异常”的组合。它说明请求至少进入了更深的应用流程，应立即检查对应组件的安全公告和已修复版本。

把 Web、应用、数据库和系统记录串起来

1. 用访问日志中的精确时间、进程或请求标识定位 Web 错误日志。
2. 查看同一分钟的 PHP、Java、Node.js 等应用日志，确认调用链和异常位置。
3. 核对数据库错误、慢查询、异常登录和权限变更，判断请求是否到达数据层。
4. 查看 WAF、CDN 和负载均衡记录，确认请求经过了哪些边缘节点以及真实来源字段是否可信。
5. 检查系统认证、计划任务、进程、出站连接和资源使用是否同期异常。
6. 把每条结论分为“已确认、较强迹象、尚未发现”，不要把缺少证据写成已经安全。

站点可用性检查与安全事件分析目的不同。若还需要判断 DNS、HTTPS、跳转和页面是否受影响，可结合域名状态监测清单完成外部验证。

如何判断是否需要按入侵事件处理

出现下面任一情况，都不应停在“封掉这个 IP”：

• 厂商确认相关版本存在可被远程利用的漏洞，日志模式与公开利用方式相符。
• 非预期管理员、角色、API 密钥、应用密码或会话被创建或修改。
• 站点核心、插件、主题、上传目录、启动项或计划任务出现无法解释的文件和代码。
• 数据库中出现异常查询、批量读取、用户或配置变更。
• 接口响应体、导出记录或网络出站流量显示敏感数据可能被读取。
• 日志被清空、时间戳异常或审计功能被关闭。

检查文件时不要只搜 .php。还要核对伪装扩展名、配置文件、Web 服务器重写规则、插件目录、定时任务和数据库持久化。已有可靠基线和官方校验值时，应优先做差异比较。

止损与修复的正确顺序

1. 控制暴露面：在理解业务影响后，临时限制易受攻击入口、增加 WAF 规则或限速，并持续监控绕过尝试。
2. 修复根因：按官方安全公告升级到已修复版本，或应用厂商认可的缓解措施；修改前保留数据库和文件备份。
3. 验证缓解：从外部复测入口、检查版本和日志，确认规则确实命中且正常业务没有被误伤。
4. 查找持久化：核对文件、账户、角色、计划任务、数据库、插件和出站连接，不因站点仍能访问就跳过。
5. 轮换可能暴露的秘密：根据可读取范围处理数据库凭据、管理员密码、应用密钥、Webhook、支付和云平台密钥，并使旧会话失效。
6. 恢复与观察：建立更高频告警，记录恢复时间、影响范围、未确认风险和后续整改负责人。

只封一个来源 IP 通常只是短期降噪。真正有效的是修复漏洞、限制不必要接口、更新组件并验证。域名访问路径巡查可以帮助发现被访问的 URL，但不能替代主机、应用和数据库层面的入侵排查；相关产品原理可查看摸个鱼风控使用教程。

平时怎样让日志真正可用

• 统一服务器时钟和时区，记录 ISO 8601 时间或明确时区。
• 同时保留 Web、应用、身份、数据库和安全设备的必要日志，并建立关联标识。
• 把关键日志复制到权限隔离或集中存储位置，避免攻击者取得站点权限后一起删除。
• 对高风险事件建立告警，如管理员变更、异常导出、重复验证失败、数据库错误突增和代码文件变化。
• 明确保留期限和容量，监控日志分区，避免攻击流量填满磁盘。
• 屏蔽密码、令牌、Cookie、连接串和不必要的个人信息，查询参数也要按风险脱敏。
• 把已授权扫描器、搜索引擎和监测服务作为分类，而不是完全排除在记录之外。

常见问题

User-Agent 写着搜索引擎就是正常爬虫吗？

不是。User-Agent 可以伪造。需要结合来源验证、访问节奏、路径、方法和官方验证方式判断，也不要因为自报为浏览器就降低警惕。

把异常 IP 全部封禁可以吗？

可以作为临时处置的一部分，但不应作为唯一修复。攻击者可以更换地址，误封也可能影响共享出口、搜索引擎或真实用户。应优先修复漏洞并针对路径、方法、身份和请求频率设置更精确的控制。

没有发现新增文件就能排除入侵吗？

不能。有些攻击只读取数据、创建账户、修改数据库配置或利用内存驻留，不一定落地新文件。文件检查是一个证据面，还要结合账户、数据库、会话、任务、出站连接和敏感数据访问记录。

总结

网站访问日志出现异常请求时，先保全证据，再通过时间、路径、方法、状态、响应大小和耗时聚合，把访问日志与应用、数据库、WAF 和系统记录关联。发现漏洞利用迹象后，应控制暴露面、升级修复、检查持久化并轮换可能泄露的凭据，最后通过外部复测和持续监控确认整改有效。

官方与行业参考

• Nginx：ngx_http_log_module
• OWASP：Logging Cheat Sheet
• CISA：Use Logging on Business Systems