香港高防裸机云面对CC攻击，清洗、防护策略和源站日志应如何联动

防护目标先定清楚：先保业务，再收敛攻击面

香港高防裸机云遇到CC攻击时，第一目标不是把所有异常请求“一刀切”挡掉，而是在清洗、防护策略和源站日志之间建立闭环：清洗侧负责过滤明显异常流量，源站日志负责判断业务是否仍被压垮、是否误拦正常用户，防护策略则根据日志结果逐步收紧或回退。

这个判断成立有几个前置条件：源站需要能看到可信的真实客户端IP或清洗节点传递的访问标识；Nginx、应用网关、业务日志的时间要尽量一致；清洗侧策略调整后，要能在源站日志中观察到请求量、状态码、响应时间和业务转化的变化。如果源站日志只看到清洗节点IP，或者没有区分URL、状态码和请求耗时，那么很难准确区分CC攻击与正常高并发。

威胁场景：CC攻击不一定打满带宽，但会打穿应用

香港高防裸机云常见的CC现场并不总是“带宽跑满”。更多时候表现为：

• CDN或清洗侧显示请求量突然升高，但入口带宽没有明显打满；
• 源站CPU、Nginx worker、PHP-FPM、Tomcat、Node.js进程或数据库连接数升高；
• 某几个动态接口响应时间变长，例如登录、搜索、下单、验证码、商品详情；
• 访问日志中大量请求返回 200、302、403、429、499 或 504；
• 用户反馈“网页能打开，但提交、登录、支付回调慢”。

这类问题的关键在于：CC攻击消耗的是应用层资源。即便香港线路、BGP带宽或清洗入口没有明显拥塞，只要动态请求持续命中源站，业务仍可能被拖慢。

因此处置方向不能只看入口流量，还要看源站日志中的访问路径、真实IP分布、请求耗时、状态码、Cookie、Referer、User-Agent以及业务日志中的登录成功率、订单创建率、支付回调成功率等指标。

先区分CC攻击与正常高并发

正常高并发和CC攻击都会带来请求量上升，但它们在日志中的行为模式不同。判断时不要依赖单一指标，例如“访问量大就是攻击”或“IP分散就不是攻击”都容易误判。

经验判断上，如果“请求量上升”和“业务转化上升”同步出现，通常更接近正常高并发；如果请求量暴涨但有效会话、登录成功、下单、支付等没有同步变化，且集中命中高成本接口，就要按CC攻击处理。

边界也要说明：有些促销、开服、投放活动会造成类似CC的尖峰；有些CC也会伪造Cookie和常见User-Agent。因此最终判断要回到源站日志和业务指标联动，而不是只看防护面板上的请求数。

分层防护：清洗、边缘策略和源站限速要各司其职

清洗侧先拦明显异常流量

清洗的价值是把明显非业务请求挡在源站之前，降低香港高防裸机云回源压力。策略上建议先从低误伤规则开始：

• 限制非业务端口，只开放实际需要的Web、API或管理端口；
• 对异常请求方法进行限制，例如业务不需要的 TRACE、异常 OPTIONS 请求；
• 对明显异常Host、空Host、伪造Host进行拦截；
• 对短时间内重复命中同一动态URL的请求设置频率阈值；
• 对登录、搜索、下单、验证码等高成本接口单独设置策略，不建议全站统一限速。

清洗规则不要一次性拉满。香港业务经常涉及跨境访问、搜索引擎抓取、支付回调、第三方API回调，如果直接按全局IP频率封禁，误拦截风险会很高。

源站侧保留最后一道应用层保护

清洗不能替代源站自身防护。源站仍需要具备基础限速、连接数控制、缓存和降级能力。以Nginx为例，如果源站位于清洗节点之后，首先要确认真实IP获取方式。

以下配置仅为示例，实际需要替换为清洗节点提供的回源IP段。不要把 set_real_ip_from 配成 0.0.0.0/0，否则客户端可以伪造 X-Forwarded-For。

set_real_ip_from <清洗节点回源IP段>;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=api_limit:20m rate=20r/s;

server {
    listen 80;
    server_name example.com;

    location = /login {
        limit_req zone=login_limit burst=20 nodelay;
        proxy_pass http://backend;
    }

    location /api/ {
        limit_req zone=api_limit burst=50;
        proxy_pass http://backend;
    }
}

执行配置变更前，应先备份当前Nginx配置，并在维护窗口或低峰期验证。常见验证命令如下：

nginx -t
systemctl reload nginx

如果 nginx -t 不通过，不要 reload。对于已经处于高压状态的源站，reload虽然通常比restart风险低，但仍建议先确认连接数、worker状态和业务高峰情况。

采购和架构上不要只看“防御”两个字

高防裸机云选型时，安全运维需要关注的不只是防护能力，还包括回源方式、日志可见性、规则调整粒度、真实IP传递、业务端口策略以及源站硬件承载能力。防护能力和线路策略会随方案变化，应以当前服务方案和实际测试为准，不应假设某个固定数值一定适用所有业务。

如果业务同时承载数据库、高并发网站或企业应用，基础硬件也会影响抗压边界。例如，LHIDC香港至强大内存服务器配置为 Intel Xeon Gold 6138、128G内存、2×960G U.2 SSD、25M CN2 + 100M BGP，适合数据库、多业务部署、高并发网站、企业应用等场景；香港AMD高性能服务器配置为 AMD EPYC 4585PX、64G DDR5-5600、960G NVMe SSD、25M CN2 + 100M BGP，适合跨境电商、企业官网、SaaS平台、数据库、游戏后端等场景。

但如果业务已经明确面临持续CC攻击，不能只按CPU、内存、硬盘和普通带宽下单，还要单独核对高防接入、清洗策略、回源安全和日志联动能力。

源站日志要能回答三个问题

源站日志不是事后留档，而是防护策略调整的依据。面对CC攻击，日志至少要回答：

1. 哪些URL正在消耗源站资源？
2. 清洗后还有多少请求打到源站？
3. 被拦截或限速的请求里是否包含正常用户？

建议记录结构化访问日志

以Nginx为例，可以增加一份JSON格式访问日志，便于后续用 jq、日志平台或SIEM系统分析。不要记录完整Cookie、Token、Authorization等敏感信息，只记录是否存在Cookie即可。

map $http_cookie $has_cookie {
    default "1";
    "" "0";
}

log_format lhidc_json escape=json
'{'
'"time":"$time_iso8601",'
'"remote_addr":"$remote_addr",'
'"xff":"$http_x_forwarded_for",'
'"host":"$host",'
'"method":"$request_method",'
'"uri":"$uri",'
'"args":"$args",'
'"status":$status,'
'"body_bytes_sent":$body_bytes_sent,'
'"request_time":$request_time,'
'"upstream_response_time":"$upstream_response_time",'
'"referer":"$http_referer",'
'"ua":"$http_user_agent",'
'"has_cookie":"$has_cookie",'
'"request_id":"$request_id"'
'}';

access_log /var/log/nginx/access_lhidc_json.log lhidc_json;

配置完成后同样先检查再重载：

nginx -t
systemctl reload nginx

如果当前环境不是Nginx，而是OpenResty、Apache、IIS、应用网关或容器Ingress，字段名称和日志路径会不同。原则不变：保留时间、真实IP、Host、URI、状态码、请求耗时、上游耗时、Referer、User-Agent、Cookie存在性和请求ID。

用日志验证清洗是否有效

假设日志路径为 /var/log/nginx/access_lhidc_json.log，可以先看高峰窗口内命中最多的URI。以下命令只做读取分析，不会修改业务配置。

LOG=/var/log/nginx/access_lhidc_json.log
START="2026-06-29T10:00"
END="2026-06-29T10:10"

jq -r --arg s "$START" --arg e "$END" \
'select(.time >= $s and .time < $e) | .uri' "$LOG" \
| sort | uniq -c | sort -nr | head -20

查看状态码分布：

jq -r --arg s "$START" --arg e "$END" \
'select(.time >= $s and .time < $e) | .status' "$LOG" \
| sort | uniq -c | sort -nr

查看真实客户端IP或XFF集中度：

jq -r --arg s "$START" --arg e "$END" '
select(.time >= $s and .time < $e) |
if (.xff != "" and .xff != null) then (.xff | split(",")[0]) else .remote_addr end
' "$LOG" | sort | uniq -c | sort -nr | head -30

查看高耗时URL：

jq -r --arg s "$START" --arg e "$END" '
select(.time >= $s and .time < $e) |
[.uri, .request_time] | @tsv
' "$LOG" \
| awk '{count[$1]++; sum[$1]+=$2} END {for (u in count) print sum[u]/count[u], count[u], u}' \
| sort -nr | head -20

这些结果要与清洗侧数据对照看：

如果清洗侧显示攻击已被大量拦截，但源站日志仍出现异常请求，重点检查是否存在绕过高防的入口，例如旧解析记录、测试域名、直接IP访问、未限制回源来源、备用端口暴露等。

业务误拦截风险要单独控制

防护策略越严格，误拦截风险越高。安全运维在调整香港高防裸机云策略时，建议把“止血规则”和“长期规则”分开。

止血规则用于短时间降低源站压力，可以更激进，但要设置观察窗口和回滚条件；长期规则应经过日志验证，避免影响正常用户、搜索引擎、支付回调、企业客户出口IP和移动网络用户。

常见的误拦截控制方法包括：

• 不对全站使用同一个频率阈值，登录、搜索、详情页、静态资源应分开处理；
• 对支付、短信、邮件、ERP、CRM等第三方回调接口建立独立白名单或签名校验；
• 对企业客户固定出口IP慎用封禁，优先使用会话、路径和行为组合判断；
• 对搜索引擎爬虫不要只看User-Agent，应结合来源验证，避免伪造；
• 对移动网络用户注意NAT出口集中，单IP限速过低容易误伤；
• 应急规则设置过期时间，避免攻击结束后长期影响业务。

如果需要启用验证码、JavaScript挑战或人机验证，建议只放在高风险路径或异常行为用户上，不要默认覆盖所有页面。对API、App、小程序、支付回调等非浏览器场景，更要谨慎使用浏览器挑战，否则可能直接造成业务不可用。

应急处理顺序：先止血，再验证，再细化

1. 锁定风险范围

先确定攻击窗口、受影响域名、端口、URL和源站资源瓶颈。不要一开始就全站封禁。

建议记录以下信息：

• 异常开始时间和持续时间；
• 受影响域名、IP、端口；
• 请求量最高的URL；
• 源站CPU、内存、连接数、负载、磁盘IO；
• Nginx或应用层状态码分布；
• 数据库慢查询、连接池耗尽、队列堆积情况；
• 清洗侧拦截量、放行量、规则命中情况。

2. 优先保护高成本接口

如果日志显示 /login、/search、/api/order 这类接口耗时高，应优先针对这些路径做策略，而不是全站统一限速。

处理顺序可以是：

1. 清洗侧对异常路径设置频率控制或挑战；
2. 源站侧对同一路径增加限速和并发保护；
3. 应用侧对高成本查询增加缓存、队列或降级；
4. 数据库侧检查慢查询和连接池，避免被单一接口拖垮。

3. 阻断绕过高防的入口

如果确认业务已接入高防清洗，但源站仍可被直接访问，应限制源站只接受清洗节点回源流量。这个操作涉及防火墙和远程管理风险，执行前必须确认：

• 管理端口不会被自己封掉；
• 有控制台、带外管理或其他恢复方式；
• 已保存当前防火墙规则；
• 已拿到清洗节点回源IP段；
• 变更后能立即验证业务访问。

不要在未确认回源IP段和远程恢复方式的情况下直接封禁源站公网访问。

4. 用源站日志确认效果

每次策略调整后，至少观察一个短窗口，例如5到10分钟，检查：

• 源站总请求量是否下降；
• 高耗时URL是否下降；
• 5xx、499、504 是否减少；
• 403/429 是否异常升高；
• 登录、下单、支付、搜索等核心业务是否恢复；
• 客服或监控是否仍收到同类投诉。

如果源站压力下降但业务投诉上升，说明策略可能过严，需要回退或细化；如果源站压力没有下降，说明攻击仍在穿透、存在绕过入口，或瓶颈已经转移到数据库、缓存、队列等后端组件。

回滚条件与持续观察窗口

安全策略上线后不能只看“攻击量下降”。建议设置明确的回滚条件，避免误拦截长期存在。

可以按以下条件执行回滚或降级：

• 正常用户登录、下单、支付、API调用出现明显失败；
• 关键客户、合作方、支付回调被 403/429 拦截；
• 源站日志显示被拦截请求主要来自正常业务路径和可信来源；
• 攻击峰值已过去，但应急规则仍造成大量挑战或限速；
• 清洗侧拦截量下降后，源站资源已经恢复到可接受范围。

回滚不等于关闭全部防护。更安全的做法是把全局强规则回退为路径级规则，把封禁改为限速，把强挑战改为低风险校验，并继续保留真实IP日志、状态码监控和高耗时URL分析。

对于香港高防裸机云，后续还应持续观察跨境访问质量、清洗回源稳定性、源站资源水位和业务转化指标。只要清洗策略、防护规则和源站日志能够形成闭环，CC攻击处置就不会停留在“感觉被打了、感觉拦住了”，而是可以根据证据逐步收敛风险。