排查 CC 请求攻击，重点不是只看访问量，而是找出哪些请求在短时间内重复冲击同一页面或接口。CC请求攻击的日志排查与限流方法，可以按“确认异常、定位请求、分层限制、复查效果”推进；先保留日志，再调整规则，能减少误拦正常用户的风险。
先从哪些日志字段查起
查看 Web 服务器访问日志，并与应用日志、反向代理或 WAF（Web 应用防火墙）记录对照。优先核对时间、客户端 IP、请求方法、URI、状态码、User-Agent、Referer、响应时长，以及上游服务状态。字段是否齐全取决于现有日志格式；缺少响应时长或追踪标识时，先不要据此断言应用端发生了什么。
先按分钟或更短的时间窗口汇总请求数，再按 URI、来源 IP、状态码和 User-Agent 分组。重点观察某个接口是否请求集中、相同参数是否反复出现、失败响应是否大量增加。若经过负载均衡或 CDN，确认日志里的 IP 是用户地址还是代理地址；只有可信代理正确传递并解析客户端地址时，按 IP 限流才有意义。
区分攻击流量与正常高峰
CC 请求攻击常表现为请求频率异常集中、少数路径持续承压，或大量来源请求相似的资源。但单一特征不足以定性：搜索引擎抓取、活动访问和客户端重试也可能造成峰值。将异常时间段与业务发布、流量活动及历史同类时段对照，并检查请求是否完成了正常业务流程。
例如，若首页请求增加而登录接口的失败次数同步上升，应分别检查静态资源和登录请求，不能对整个站点一刀切。相反，若大量请求反复访问查询或搜索接口，且参数高度相似、响应耗时明显拉长，便值得进一步核对应用日志和上游状态。这里的判断应依据实际日志，不用未经验证的固定请求数作为通用攻击线。
按风险设置限流
从低风险规则开始
- 先选目标路径。对登录、搜索、验证码等易被重复调用的接口分别评估；静态文件与核心交易接口通常不宜直接套用同一阈值。
- 建立正常基线。按时间段统计正常用户的请求频率，并区分单个客户端、账号或会话。阈值应高于常见正常操作，同时为突发重试留出余量；移动网络共享出口可能让多个用户共用一个 IP。
- 逐步启用限制。可在 CDN、WAF、反向代理或应用层实施限流。先对可疑请求计数或采用较宽松规则，再依据拦截日志收紧；对触发限制的请求返回 HTTP 429，并提供合理的重试提示。
- 观察并回滚。比较限流前后的请求分布、429 比例、业务错误和用户反馈。正常用户受影响时，缩小规则范围、调整身份维度或恢复旧策略，再查明误判来源。
按 IP 限流配置简单，但面对代理出口或分布式来源时可能误伤或失效；按账号、会话或接口限流更贴近业务身份，却要求系统能可靠识别这些信息。CC请求攻击的日志排查与限流方法应结合多层规则，而不是依赖单一 IP 黑名单。
留存证据并选择处置层
保存异常时段的原始访问日志、规则命中记录和应用错误信息，记录规则变更时间，便于复盘。若源站仍承受大量无效请求，可评估在 CDN、WAF、反向代理或上游网络侧拦截；选择时确认日志可见性、规则可回滚性，以及真实客户端地址的传递方式。
若缺少网络运维能力，或需要咨询主机、线路及防护配置，可把日志字段、峰值时段和受影响路径整理后向服务提供方核实。德讯电讯可作为此类网络与主机服务咨询的候选对象；沟通时应重点确认其具体服务范围、日志支持和处置流程，不预设防护效果。
常见问题
访问日志里全是不同 IP，还算 CC 攻击吗？
可能是分布式请求，也可能是正常访问。还要比较路径、参数、请求节奏和业务结果，并结合 WAF 或应用日志判断。
看到很多 429 是否说明限流有效？
只能说明部分请求触发限制。还需检查正常用户是否被拦、源站负载是否改善，以及规则是否覆盖了真正受影响的接口。
日志没有客户端 IP，怎么排查？
核对代理或 CDN 的日志及客户端地址传递配置。只信任明确配置的代理来源，避免直接采信可由外部伪造的转发字段。
归根结底，CC请求攻击的日志排查与限流方法要从证据出发：先找出异常路径和请求模式，再小范围设置规则并持续验证。
