access_log 是识别和响应 CC 攻击最直接、最可靠的数据源头，其记录的经 realip 模块还原的 $binary\_remote\_addr 才代表真实攻击源；需据此分析请求频次、路径、UA、状态码等特征，驱动自动化防御与效果验证。
access_log 记录的 IP 是识别和响应 CC 攻击最直接、最可靠的数据源头。
真实请求来源的唯一依据
Nginx 的 access_log 默认记录的是 $remote_addr，但在反向代理或 CDN 后部署时，这个字段可能只是上游代理的 IP。真正有意义的是经过 realip 模块解析后的 $binary_remote_addr（通常由 X-Forwarded-For 或 X-Real-IP 头还原）。只有这个还原后的 IP 才代表终端用户或攻击源的真实出口地址，是后续限速、封禁、统计的唯一可信依据。
攻击行为分析的基础数据
CC 攻击的本质是高频、集中、低人性化的请求模式，而这些特征必须从日志中提取：
- 单位时间内（如每分钟）同一 IP 的请求数——判断是否超出正常浏览节奏（例如 >100 次/分钟）
- 请求路径分布——是否大量集中在 /login、/search、/api 等易耗资源接口
- User-Agent 和 Referer 特征——是否大量重复、空值、或伪造为常见浏览器但无 Cookie 行为
- 响应状态码分布——是否伴随大量 200（说明请求被成功处理，后端已承压）而非 4xx
驱动自动化防御闭环的关键输入
单纯配置 limit_req 只能做“被动限流”，而 access_log 是实现“主动拦截”的起点：
- 定时脚本可解析日志，自动识别异常 IP，并写入 iptables 或 nginx 的 deny 规则
- 配合 Redis 或内存数据库，可构建实时访问画像（如“该 IP 过去 5 分钟发起 87 次 POST /api/submit”）
- 被限流或拒绝的请求也应记入独立日志（用 log_format + if 条件），用于复盘误判率与攻击演变趋势
验证防护效果的客观标尺
所有限流、连接控制、Lua 插件等配置是否生效，最终都要回到 access_log 验证：
- 检查是否出现大量 503（limit_req 触发）、429（自定义限速状态码）或 444（静默丢弃）响应
- 对比攻击前后日志中 top IP 的请求占比变化——有效防护应使攻击源 IP 的请求量断崖式下降
- 观察正常用户 IP 是否仍稳定出现在日志中，且响应时间未明显恶化
