攻击排查顺序：从 Ray ID 到处置的七步
被打的时候最容易犯的错是马上开开关。Under Attack Mode 一开、规则一加，症状可能变了，但你不知道是哪一步起的作用，也就没法收尾。有效的排查是一条固定顺序：先确认请求停在哪一层，再判断是哪类攻击，然后按"降损—精确—改架构"的次序处置，最后留记录。
这条顺序与具体工具无关，换任何 CDN 都适用。下面的路径按 Cloudflare 的界面与字段走，涉及的手段分布在前几篇里：WAF 规则见 77-waf-basics-free-rules.md，限流见 78-rate-limiting.md，机器人见 79-bot-management.md，DDoS 见 84-ddos-protection.md。
第一步：收集六个要素
动手之前先要数据，否则后面全是猜：
| 要素 | 从哪拿 | 用途 |
|---|---|---|
| 时间窗 | 用户反馈、监控告警时间 | 对齐图表与事件 |
| 具体 URL | 用户截图、访问日志 | 判断是单路径还是全站 |
| HTTP 状态码 | 用户端或 curl | 分流到不同排查路径 |
| Ray ID | 错误页底部、响应头 cf-ray | 在事件与日志里精确定位 |
| 客户端 IP 与国家 | 用户提供，或事件里的字段 | 判断是个别还是面 |
| 是否可复现 | 换网络、换设备试一次 | 区分本地网络问题与服务端问题 |
Ray ID 是最有用的一项。它把控制台的 Security Events、wrangler tail 的输出、源站日志三处的同一条请求串起来，比"大概下午三点"精确得多。免费档没有工单支持，但排查自己的问题时它同样省时间。
第二步：定位请求停在哪一层
用 curl 看响应头，一次请求就能分出三种情况：
curl -s -D - -o /dev/null https://example.com/some/path看三样东西：有没有 cf-ray 头、server 是不是 cloudflare、状态码是多少。
| 现象 | 请求停在哪 | 下一步 |
|---|---|---|
无 cf-ray，连接超时或 DNS 失败 | 边缘之前（DNS / 网络） | 查 DNS 解析与本地网络 |
有 cf-ray，403 且响应体是挑战页或拦截页 | 边缘（规则 / 挑战） | 查 Security Events |
有 cf-ray，502/522/524 | 边缘到源站之间 | 查源站与回源配置 |
有 cf-ray，200 但内容异常 | 已到源站，业务问题 | 查应用日志 |
这一步能排掉一半的误判。"站点打不开"里相当一部分是 DNS 没生效、本地网络问题、或者自己的规则把自己拦了。灰云记录（仅 DNS）的请求不经过边缘，也没有 cf-ray，看起来像"Cloudflare 没起作用"，实际是配置如此。
第三步：看整体曲线
Analytics → Traffic，选时间窗，看四个分布：请求量、状态码、来源国家、缓存命中率。
请求量垂直上升且来源集中在平时没有流量的国家，指向流量型攻击或代理池。请求量不变但源站负载暴涨，指向缓存失效或回源被打。状态码里 4xx 突增通常是扫描，5xx 突增是源站扛不住。
缓存命中率这一项常被忽略。命中率从 90% 掉到 40%，意味着同样 QPS 下源站压力翻了两倍多，可能不是攻击变强了，而是某次发布把缓存规则弄坏了。
第四步：看安全事件
Security → Events，按时间窗筛，重点看三列：Action（block / challenge / allow）、Service（哪个功能处理的，如 waf、rate limit、bot fight mode）、Path。
这里能回答两个问题：攻击有没有被挡住，以及是不是误伤。如果大量正常用户的请求出现在 block 列表里，先解决误伤再谈防护。判定方法：看被拦请求的 UA 与路径分布，如果集中在真实浏览器的 UA 与正常页面上，多半是规则写得太宽。
第五步：按类型选手段
| 类型 | 特征 | 处置 |
|---|---|---|
| 流量型 DDoS | 带宽跑满、请求数不一定高 | 通常自动清洗，检查源站 IP 是否暴露 |
| 请求洪泛 | QPS 垂直上升，路径集中 | 缓存 + 速率限制 + Under Attack Mode |
| 扫描与爆破 | 大量 404、集中在登录与已知漏洞路径 | WAF 规则拦路径，登录加 Turnstile |
| 爬虫采集 | 单 IP 慢速遍历列表页，UA 固定 | Bot 管理、速率限制、内容侧限流 |
| 应用层漏洞利用 | 特定参数、报错信息、异常响应长度 | 修应用 + 托管规则 + 虚拟补丁 |
| 账号滥用 | 登录成功率高但行为异常 | 应用侧风控，边缘只能限速 |
分类之后手段就确定了。用错手段的典型例子：拿 Under Attack Mode 对付慢速爬虫——爬虫本来就不跑 JS，挑战会把它挡住，但正常用户与 API 也一起挂；正确做法是按路径与 UA 做规则。
第六步：按次序处置
先降损，再精确，最后改架构。
降损阶段只做可逆动作：提高缓存覆盖、给最贵的接口加速率限制、必要时开 Under Attack Mode 并在攻击回落后立刻关。这一步的目标是让站点可用，不是把攻击者找出来。
精确阶段做规则：按路径、UA、国家、ASN 组合，逐条加、逐条看事件。一次只加一条，加完观察五分钟，确认拦截量上升且误伤没有同步上升。
改架构阶段解决根因：把管理入口放到 Access 后面、把 API 拆到独立子域、把源站藏到 Tunnel 后面、给表单加 Turnstile。这些动作的生效周期是小时到天，不适合应急，但能避免下次再被打穿。
第七步：留记录
攻击结束后记四样东西：时间线（开始、峰值、回落）、峰值指标（QPS、带宽、源站负载）、生效的规则清单、以及是否有误伤。这份记录在下次遇到同类攻击时能省掉一半时间，也是判断"要不要升级套餐"的依据。
常见问题
用户报 403，是攻击还是误伤？
先看 Security Events 里这条请求的 Action 与 Service。如果 Service 是 waf 且规则是你自己写的，检查表达式是否过宽；如果 Service 是 bot fight mode，大概率是自动化客户端被当成机器人。定位到规则后，用 Skip 或调整表达式解决。
边缘显示正常，源站还是挂，怎么办？
说明请求已经穿过边缘。查三处：源站是否被直连打（防火墙是否只放行 Cloudflare 网段）、缓存是否失效导致回源放大、Worker 是否在循环调用上游。522 与 524 的区别见 82-ssl-tls-modes.md 里的报错对照。
要不要直接封攻击 IP？
对少量固定 IP 有效，对代理池无效，而且容易误伤共用出口的正常用户。优先按路径、UA、行为特征拦，IP 封禁只作为短时应急。封完之后记得设过期时间，别留下来变成半年后的神秘故障。
小结
排查的攻击性来自顺序，不是来自工具数量。先收集 Ray ID 与状态码，用一条 curl 定位请求停在哪一层，再看曲线与事件判断类型，最后按降损、精确、改架构三步处置。每一步都有可验证的产出，不会出现"改了一堆配置但不知道哪个起了作用"的局面。
日常更值得投入的是把可避免的部分提前做掉：登录加人机验证、贵的接口加限流、源站 IP 藏住、缓存命中率盯住。这四件事做完，多数攻击只是曲线上的一个尖峰。
数据来源与检索时间
检索时间 2026-11-10。
| 来源 | URL | 对应数据 |
|---|---|---|
| WAF 概览 | https://developers.cloudflare.com/waf/ | Security Events 与规则的对应、免费档可用动作 |
| 速率限制规则 | https://developers.cloudflare.com/waf/rate-limiting-rules/ | 免费档 1 条规则、按路径匹配的限制 |
| Workers 限额 | https://developers.cloudflare.com/workers/platform/limits/ | 请求额度与超限行为（判断攻击是否打穿到 Worker） |
| Cloudflare 定价页 | https://www.cloudflare.com/plans/ | 免费档包含的防护项 |
核验说明
- 页面为本机抓取（HTTP 200），状态码含义与免费档能力取自文档。
- 未执行：无 Zone 权限，Security Events、Analytics 曲线、Under Attack Mode 均未在真实攻击中操作；
curl -D -判定命令只在自建 Worker 上验证过响应头里有cf-ray与server: cloudflare，没有对真实故障站点执行。 - 未验证：各类攻击的处置效果没有样本可复现；分类表与处置顺序是按文档与常见运维经验整理的，不是实测结论。