洛杉矶高防服务器面对CC攻击，清洗策略、WAF和源站日志如何分工

流量突然冲高时，先判断它是不是CC攻击

凌晨告警响起：洛杉矶业务入口带宽没有打满，但应用响应时间开始拉长，Nginx 访问日志里同一批 URL 被反复请求，数据库连接数上升，部分接口返回 499、502 或 504。此时如果只盯着“洛杉矶高防服务器有没有扛住”，容易误判。高防清洗、WAF 和源站日志解决的是三类不同问题：高防先处理大流量和异常连接，WAF 判断 HTTP/HTTPS 请求是否像业务请求，源站日志负责证明请求最终如何影响应用。

这里讨论的前提是：业务部署在洛杉矶节点，前面有高防清洗或高防 IP，HTTP/HTTPS 流量可接入 WAF，源站能保留访问日志、应用日志和必要的回源头信息。不同服务商的防护能力、清洗策略、WAF功能和合同范围会有差异，具体阈值、封禁方式、日志保留时间需要以当前套餐和服务说明为准，不能默认“高防服务器一定包含完整应用层防护”。

CC攻击的典型目标不是直接打满链路，而是让 Web 层、缓存层、数据库或业务接口消耗资源。它常见于以下表现：

• 单个或少量接口请求量异常放大，例如登录、搜索、列表页、支付回调查询等；
• 源站 CPU 不一定满，但应用线程池、PHP-FPM、Node.js worker、Java 连接池或数据库连接数接近上限；
• 请求看起来是 HTTP/HTTPS 正常访问，来源 IP 分散，User-Agent 可能伪装成浏览器；
• 带宽不一定明显超限，但 QPS、并发连接、慢请求数量明显升高；
• 静态资源访问正常，动态接口延迟显著变高。

正常高峰则更容易呈现“业务路径合理、转化链路连续、用户分布符合预期”的特征。例如促销开始后首页、列表页、详情页、下单接口依次升高；搜索引擎抓取也会有明确 UA、稳定频率和 robots 访问记录。CC攻击往往只盯少数高成本路径，访问节奏更机械，且会绕过静态缓存直接打动态接口。

高防、WAF、源站日志的职责边界

把三者混在一起，会导致策略做错位置。清洗中心适合挡大水，WAF适合看请求语义，源站日志适合定位业务损耗点。洛杉矶高防服务器面对 CC攻击时，建议按职责拆开处理。

一个实用判断是：如果链路、连接数或包量已经异常，先看高防清洗；如果请求已经到达 HTTP 层且路径、Header、Cookie、会话行为异常，交给 WAF；如果要判断“到底是攻击、真实高峰还是应用自身瓶颈”，必须看源站日志和应用指标。

威胁场景：CC攻击与正常高峰如何区分

安全优化不能只靠感觉。第一步要把“业务增长导致的高峰”和“被攻击导致的高峰”区分开，否则可能把真实用户挡在外面。

从访问路径判断

正常高峰通常有完整业务链路，访问路径有前后关系。比如用户先访问首页，再打开商品页，随后请求登录、购物车、下单。CC攻击则经常集中打某个资源消耗大的接口。

需要重点关注：

• 动态接口请求量是否远高于静态资源；
• 某个 URL 是否在短时间内占据大部分请求；
• 是否大量请求带随机参数，导致缓存无法命中；
• 是否反复访问会触发数据库查询、全文搜索、复杂排序或第三方接口的页面；
• 是否出现大量无 Referer、异常 Referer 或不符合业务来源的请求。

例如 Nginx 日志可以先粗略统计高频 URL。执行前确认日志路径，以下命令只读取日志，不会修改文件：

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

如果排名前几的都是动态接口，并且请求数远超正常业务比例，就需要进一步结合 WAF 和应用日志判断。

从客户端特征判断

CC攻击经常伪装成正常浏览器，但仍可能暴露出节奏和一致性问题：

• 同一 IP 或同一段 IP 对单一路径访问频率过高；
• 大量请求使用相同 User-Agent、Accept-Language 或 Header 顺序；
• Cookie 缺失、会话不连续，或同一 Cookie 从多个地区大量访问；
• TLS 指纹、HTTP版本、Header组合与真实用户差异明显；
• 请求间隔过于规律，缺少真实用户的停顿和页面跳转。

如果业务主要面向北美用户，洛杉矶节点的正常流量应与用户分布、投放渠道、活动时间基本匹配。短时间内出现大量与业务区域不符的来源，并集中打动态接口，风险级别应提高。但地理位置只能作为辅助判断，不能作为唯一封禁依据。

从源站资源消耗判断

CC攻击真正造成影响的地方，通常在源站应用层。需要同时看：

• Web服务器连接数、活跃请求数；
• 应用进程队列、线程池、worker 使用情况；
• 数据库慢查询、连接池等待、锁等待；
• 缓存命中率是否下降；
• 5xx、499、408、429 状态码是否集中出现。

如果流量升高但缓存命中率稳定、数据库压力可控、错误率不升，可能只是正常峰值。如果请求量不算极端，但数据库慢查询突然增加，说明攻击可能集中在高成本接口，应该优先用 WAF 做路径级限制，而不是只扩大服务器配置。

分层防护：先让流量进正确的门

高防清洗负责把异常流量挡在业务入口之外

洛杉矶高防服务器的核心价值，是在靠近入口的位置处理异常流量，降低源站直接暴露在大流量攻击下的风险。它更适合处理网络层、传输层和明显异常连接问题，例如突发包量、异常协议流量、伪造连接、无效握手等。

运维侧需要重点核对这些内容：

• 业务是否真正解析到高防 IP 或高防入口，而不是仍有域名指向源站真实 IP；
• 源站防火墙是否只允许可信回源地址访问业务端口；
• 高防清洗是否覆盖当前业务协议和端口；
• 清洗策略是否支持按需调整，例如连接速率、黑白名单、区域策略；
• 防护峰值、清洗触发条件、日志可见性和应急响应方式是否写入服务范围。

高防清洗不应被当成万能 WAF。对于“每个请求都像正常 HTTPS 请求，但集中访问高成本接口”的 CC攻击，仅靠网络层清洗可能无法精确识别。此时需要 WAF 接管 HTTP 层规则。

WAF负责识别“看起来正常但行为异常”的请求

WAF 的工作重点是请求语义：它能看到 Host、URI、Method、Header、Cookie、参数、请求频率和部分会话行为。面对 CC攻击，WAF 应优先做“低误伤”的分级策略，而不是一上来全站强拦截。

建议按以下顺序加固：

1. 对高成本接口单独限速 登录、搜索、列表筛选、验证码发送、订单查询等接口，按 IP、会话、设备指纹或账户维度设置频率限制。不要只做全站 QPS 限制，否则容易影响正常用户。
2. 对异常路径做挑战或拦截 例如无 Cookie 高频访问动态接口、Referer 不符合业务链路、User-Agent 明显异常，可以先启用 JS Challenge、验证码或人机校验，再观察误伤。
3. 对静态资源和可缓存页面放宽策略 静态资源请求量大不一定危险，过度拦截反而影响页面加载。WAF策略要区分静态与动态路径。
4. 对管理后台、登录口设置更严格规则 后台入口、API管理端、支付回调等应有白名单、双因素、来源限制或独立访问策略。
5. 保留灰度空间 规则先监控、再挑战、最后拦截。对核心交易链路尤其要避免直接大范围封禁。

WAF策略需要和业务约定。例如某些移动App没有标准浏览器Header，某些API客户端不支持 JS Challenge，某些跨境业务用户来源分散。不了解客户端形态就启用强校验，容易把正常请求当成攻击。

源站不要绕过防护层

很多防护失效不是因为高防或 WAF 没用，而是源站真实 IP 暴露。攻击流量绕过高防入口直接打源站，前端规则再完善也无效。

源站侧至少应检查：

• DNS历史记录、证书透明日志、邮件头、错误页是否泄露源站 IP；
• 源站安全组或防火墙是否仅允许高防/WAF回源地址访问 80、443 或业务端口；
• 管理端口是否限制固定办公 IP 或 VPN；
• 回源 Host 是否固定，避免被任意 Host 访问；
• 是否保留备用回源线路，避免单点故障。

如果需要在 Linux 上临时查看当前监听端口，可使用：

ss -lntup

查看 Nginx 当前访问来源分布，可使用：

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

如果前面有代理或 WAF，日志第一列可能是代理 IP，而不是真实用户 IP。此时不能直接用第一列做封禁依据，需要先修正真实 IP 记录方式。

源站日志与回源策略要配合，否则无法验证防护效果

日志必须记录真实客户端 IP 和回源信息

源站日志的价值在于回答三个问题：攻击是否被挡住、是否误伤正常用户、还有哪些请求打到了应用。要做到这一点，日志字段不能太少。

Nginx 可参考增加包含真实 IP、转发链路、请求耗时、上游耗时的日志格式。修改配置前请备份原配置，并先用 nginx -t 检查语法：

log_format waf_main '$remote_addr '
                    '$http_x_forwarded_for '
                    '$realip_remote_addr '
                    '$host '
                    '"$request" '
                    '$status '
                    '$body_bytes_sent '
                    '$request_time '
                    '$upstream_response_time '
                    '"$http_referer" '
                    '"$http_user_agent"';

access_log /var/log/nginx/access.log waf_main;

如果使用 X-Forwarded-For 或类似 Header 传递真实 IP，必须只信任高防/WAF的回源地址，不能盲目信任所有来源。否则攻击者可以伪造 Header，污染日志和限速策略。

Nginx 的真实 IP 配置通常类似下面这样，但其中的 IP 段必须替换为服务商提供的可信回源地址，不要照抄：

set_real_ip_from 203.0.113.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

修改后检查配置并平滑加载：

nginx -t
systemctl reload nginx

如果系统不是 systemd 管理 Nginx，或 Nginx 安装方式不同，需要先确认服务管理方式，避免误操作。

回源策略决定源站看到什么流量

回源策略会直接影响源站日志的解释方式。常见情况包括：

• WAF 缓存命中后不回源，源站日志看不到这部分请求；
• WAF 对异常请求挑战，挑战失败不回源；
• 高防清洗丢弃异常连接，源站日志不会记录；
• 动态接口强制回源，源站会看到真实业务压力；
• 缓存键配置不合理，随机参数导致大量请求绕过缓存。

因此，不能只看源站访问量下降就判断攻击结束，也不能只看源站还有请求就认为防护无效。正确做法是把高防清洗记录、WAF事件日志和源站日志按时间对齐。

建议建立一个最小验证表：

源站日志要和应用日志一起看

仅有访问日志还不够。比如 /search 请求很多，但真正拖垮数据库的是某个复杂参数组合；访问日志只能看到路径，应用日志和慢查询才能说明成本。

排查顺序建议如下：

1. 先定位高频路径 看 URI、状态码、请求耗时、来源分布。
2. 再定位慢请求 找出 request_time 或 upstream_response_time 明显偏高的接口。
3. 对照应用日志 查看是否有线程池耗尽、连接池等待、第三方接口超时。
4. 对照数据库慢查询 判断是否需要临时降级搜索、关闭复杂筛选、增加缓存或限流。
5. 回到 WAF 调整规则 对真正消耗资源的路径做限速、挑战或拦截。

示例：查看耗时超过 3 秒的请求数量，字段位置需根据实际日志格式调整：

awk '$8 > 3 {print $0}' /var/log/nginx/access.log | tail -50

如果日志格式不同，不要直接套用字段编号。先用 head -5 /var/log/nginx/access.log 查看字段顺序。

应急处理：先保业务，再缩小规则范围

第一阶段：确认入口与影响范围

发现疑似 CC攻击后，不建议立刻重启服务。重启可能暂时释放连接，但如果攻击仍在，服务会很快再次被打满，还会丢失现场信息。

优先做这些检查：

• DNS 是否指向洛杉矶高防服务器或高防入口；
• 源站真实 IP 是否暴露并被直接访问；
• 高防清洗是否已触发，是否需要联系服务商调整策略；
• WAF是否处于观察、挑战或拦截模式；
• 受影响的是全站、单域名、单接口还是单地区用户；
• 源站 CPU、内存、连接数、数据库连接和慢查询是否异常。

如果发现源站被绕过，应先收敛入口，让业务流量只能从高防/WAF回源。涉及防火墙或安全组变更时，要提前确认管理通道不会被自己阻断，尤其不要在没有控制台或带外访问方式的情况下直接封禁大范围 IP。

第二阶段：按路径加规则，而不是全站一刀切

对 CC攻击的应急策略要尽量贴近业务路径。常见处理方式包括：

• 对单个动态接口设置更低频率限制；
• 对无 Cookie 或无正常 Referer 的请求启用挑战；
• 对异常 UA、异常 Header 组合进入观察或拦截；
• 对登录、注册、短信、搜索等接口增加验证码或业务层限流；
• 对可缓存页面提高缓存命中率，减少回源；
• 对高成本功能做临时降级，例如关闭复杂排序或缩短查询范围。

这里的关键是“先判断再执行”。如果攻击集中在 /api/search，全站封禁某个地区可能误伤大量正常用户；如果攻击绕过缓存打随机参数，则应调整缓存键和参数白名单，而不是单纯扩大源站配置。

第三阶段：验证规则是否有效

规则上线后至少观察三个维度：

• WAF命中量是否上升，源站同路径请求是否下降；
• 源站响应时间、5xx、数据库慢查询是否恢复；
• 正常用户登录、下单、支付、API调用是否受影响。

可以用状态码分布辅助判断：

awk '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr

上面命令中的字段位置取决于日志格式。如果使用的是默认 combined 格式，状态码通常不是第 6 字段，需要根据实际日志调整。更稳妥的方式是使用结构化日志，例如 JSON 格式，再接入日志平台分析。

采购和配置时要提前确认的防护边界

选择洛杉矶高防服务器时，不能只看“高防”两个字。安全优化需要产品能力和运维策略配合，采购前建议把以下问题问清楚：

• 高防能力覆盖哪些协议和端口，是否包含 HTTP/HTTPS 应用层规则；
• CC攻击防护是高防自带、WAF提供，还是需要单独购买；
• 清洗触发条件、策略调整方式、响应时间和人工协助范围；
• 是否提供高防日志、WAF日志、回源 IP 列表和封禁记录；
• 是否支持 HTTPS 证书托管、SNI、多域名和自定义规则；
• 是否支持保留真实客户端 IP，使用哪个 Header；
• 源站是否可以限制只允许高防/WAF回源；
• 防护峰值、误封处理、黑白名单数量、日志保留周期是否有合同说明；
• 遭遇攻击时是否允许临时调整策略，是否涉及额外费用。

洛杉矶节点适合面向北美用户、海外业务或需要美国西海岸访问入口的场景，但地区选择不能替代防护设计。若用户主要来自亚洲、欧洲或多区域，仍需结合访问延迟、线路质量、合规要求和业务架构评估。具体线路、带宽、防护参数和可用库存会随服务商策略变化，应以下单前确认和当前测试为准。

回滚条件与持续观察项

安全规则不是越严越好。CC攻击缓解后，应保留必要防护，但把临时高压策略逐步回滚到可长期运行的状态。

可以按以下条件判断是否回滚：

• WAF拦截量连续下降，源站同路径请求恢复到正常区间；
• 核心接口响应时间、5xx、数据库慢查询恢复稳定；
• 正常用户投诉、登录失败、支付失败没有异常增加；
• 高防侧异常连接或清洗告警明显减少；
• 业务活动高峰已结束，访问分布回到预期。

回滚顺序建议从“最容易误伤”的规则开始，例如全站挑战、地区封禁、严格 UA 拦截；路径级限速、后台白名单、源站只允许可信回源等基础防护应长期保留。回滚后继续观察至少一个业务周期，重点看 WAF命中、源站日志、应用错误率和数据库慢查询。

洛杉矶高防服务器能降低攻击流量直接冲击业务入口的风险，WAF能把看似正常的 HTTP 请求进一步分层处理，源站日志则负责证明策略是否有效、是否误伤、是否还存在绕过路径。三者分工清楚，才能在 CC攻击中做到先稳住入口，再保护应用，最后用日志验证和回滚。