很多站长以为 CC 攻击的表现只有”网站打不开”，其实更常见的情况是：服务器 CPU 不高、带宽也没满，页面却能慢几秒，下单接口偶尔超时，转化率连续几天阴跌。本文用 9 个问答讲清 CC 攻击是怎么污染业务数据的、怎么区分攻击与运营波动、安全指标和业务指标怎么放在一张表里看，以及发现异常后的处置顺序。
Q：CC攻击为什么会拉低转化率？
因为 CC 攻击的目标通常不是”打挂”，而是”占满”。它用大量看似合法的请求占住后端应用的处理能力，让正常用户的请求排在后面：
- 页面变慢：动态页面每个请求都要走 PHP 或 Java，响应时间从 200ms 抬到 2s，用户直接关掉。
- 关键链路排队：下单、支付、登录这些接口本来就重，被刷之后正常用户的请求被挤在队列里超时。
- 数据被污染：统计报表里 PV 虚高、跳出率飙升、来源渠道全是 direct，运营看着假数据做错误决策。
一句话：CC 攻击是通过降低体验间接损害业务的，不会在你的服务器告警里直接写”业务受损”四个字。
Q：CC攻击是怎么污染业务数据的？
表现集中在四类指标上：
- 流量指标虚高：PV、会话数上涨，但转化数没动，转化率被分母拖下来。
- 行为指标失真：平均停留时间下降、跳出率升高，因为脚本不会滚动、不会点击。
- 来源渠道异常：直接访问（direct）占比突然变大，大量请求没有 Referer。
- 漏斗首层流失：转化漏斗在第一步就大量流失，后续环节数据正常，说明流量本身有问题。
统计工具默认区分不了人与脚本，报表一旦失真，投放、选品、改版的判断都会偏。所以业务指标异常时，第一件事不是改运营策略，而是先确认流量是不是真的。
Q：怎么判断数据异常是攻击还是运营波动？
看三个正交信号，两个以上命中就是攻击特征：
- 请求集中度：少量 IP 贡献大量请求，或单个 URL 占比过高。
- 时间分布：夜间没有正常回落，峰谷比被拉平。
- 质量指标：响应时间 P95 抬升、错误率上升，但资源利用率不成比例。
# 每分钟请求数，找出突增时段
awk '{print substr($4,14,5)}' access.log | sort | uniq -c | sort -rn | head -20
# Top IP 与单 URL 集中度
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20经验判定线：Top 10 IP 请求占比超过 30%、单个 URL 请求占比超过 60%、凌晨时段流量与白天持平，这三条基本可以定性为脚本流量而非真实用户。
Q：安全指标和业务指标怎么放在一起看？
建一张以时间桶为纵轴的联表，两侧指标对齐到同一行，再按小时滚动看：
- 安全侧：QPS、回源率、限速触发次数、429/503 比例、独立 IP 数、单 IP 平均请求数。
- 业务侧：会话数、注册/登录成功率、下单成功率、支付回调成功率、转化率。
核心方法是看先后顺序，而不是看谁涨谁跌：
- 安全指标先动、业务指标滞后几十秒到几分钟动 → 因果关系明确，是攻击导致业务受损。
- 两者同时抖动 → 更可能是同一外因（促销、投放、爬虫大规模抓取）。
- 业务指标先动、安全指标无异常 → 优先查代码发布、支付通道、第三方依赖。
前提是口径必须统一：时间步长都按分钟、时区都按北京时间，否则两张表永远对不上。
Q：具体要监控哪些指标？
按四层划分，每层只留 3 到 5 个核心指标，多了没人看：
- 流量层：QPS、独立 IP 数、单 IP 平均请求数、出向带宽。
- 质量层：响应时间 P95/P99、5xx 比例、缓存命中率、回源率。
- 资源层：CPU、内存、数据库连接数、应用队列长度。
- 业务层：登录成功率、下单成功率、支付回调成功率、转化率。
每个指标都要有两条线：一条是正常基线（按近 14 天同时段计算），一条是告警线（基线的 1.5 到 2 倍）。没有基线的告警只会制造噪音。
Q：日志和埋点怎么配合才能定位到具体接口？
关键是把两侧数据用同一个标识串起来。先让访问日志带上响应时间：
log_format main '$remote_addr [$time_local] "$request" $status '
'$body_bytes_sent "$http_referer" "$http_user_agent" '
'rt=$request_time urt=$upstream_response_time';
access_log /var/log/nginx/access.log main;然后在业务接口返回里带上 trace id，把 WAF 拦截记录、Nginx 日志、应用日志用同一个 id 关联。这样当”下单成功率下降”告警响起时，可以直接回查这批失败请求的来源 IP、UA、请求路径与上游耗时，判断是攻击还是自身故障。
Q：告警怎么设才有用？
三个原则：
- 关联告警：单个指标抖动不告警，只有”错误率上升 且来源集中度上升”同时成立才告警，能过滤掉九成以上的误报。
- 按影响分级：P1 打电话叫值班（转化率跌破基线 30%）、P2 转工单（5xx 超过 1% 持续 5 分钟）、P3 进日报（QPS 偏离基线）。
- 抑制窗口：同一规则 10 分钟内只通知一次，并留静默窗口，避免告警风暴让人麻木。
最值得单独设一条的就是：转化率在非活动时段跌破基线 30% 且伴随 5xx 升高。这条能同时抓住 CC 攻击和应用故障。
Q：发现指标异常后应该怎么处置？
顺序是先止损、后归因，不要一上来就查日志：
- 保业务链路：给动态接口单独限速、开启静态化或缓存兜底降级，先让正常用户能用。
- 定位来源：按 IP、按 UA、按会话三个维度做画像，区分攻击流量与真实用户。
- 带超时封禁：明确恶意的来源用 ipset 封禁并设置自动解封，避免永久误封。
- 事后复盘：把安全与业务两套指标的时间线对齐，确认止损动作是否真的挽回了转化率。
# 动态接口单独限速，避免拖垮整条业务链路
limit_req_zone $binary_remote_addr zone=order:10m rate=5r/s;
location /api/order {
limit_req zone=order burst=10 nodelay;
limit_req_status 429;
}注意限速返回码要设成 429 而不是 503，前者是”请求过多”，后者在监控里会和真实故障混在一起，反而掩盖问题。
Q：还有什么补充建议？
- 看分渠道转化率，不只看总转化率：攻击往往集中污染某一个渠道或某一个落地页，总量指标会把它稀释掉。
- 统计上报要能识别脚本：自建埋点做前端环境校验与签名，别让爬虫和 CC 流量直接进报表。
- 把”转化率异常”放进安全值班面板：安全团队看的是机器指标，业务团队看的是人指标，两边必须坐在同一张表前。
- 攻击期间暂停基于报表的运营决策：数据不可信时，改价、调投放、换素材都是放大损失。
- 长期做联合看板：安全指标与业务指标同源、同口径、同粒度，是长期最有价值的一件基础设施工作。
一句话总结：CC 攻击的杀伤力往往体现在转化率上；把安全指标和业务指标联表看、看先后顺序而不是看单点波动，先止损再归因，才能既挡住攻击又留住生意。