CC攻击下高防香港服务器拦截不生效怎么办？七层规则与回源链路排查

页面还能打开、带宽也没有完全跑满，但高防香港服务器上的七层规则没有出现拦截记录，源站访问量和应用连接数却持续升高，这通常不是“阈值还不够低”，而是请求没有经过预期的七层策略，或规则命中了错误的字段、监听器和回源链路。处理时应先判断流量是否进入高防接入层，再确认 HTTPS 是否具备七层解析条件，最后对照边缘日志与源站日志定位回源是否绕过。

建议按照“DNS与入口 → 监听器和TLS → 规则范围与优先级 → 客户端身份识别 → 回源与源站日志”的顺序排查。每一步都要保留结果：如果在入口就发现直连源站，先修复链路；如果入口正常但没有规则命中，再检查规则绑定和匹配条件；如果边缘显示已拦截而源站仍有同一批请求，则重点检查旁路域名、IPv6记录、放行名单和日志关联方式。

先还原高防香港服务器的实际请求链路

典型的访问路径可以抽象为：

客户端
  │
  ├─ DNS解析到高防接入地址
  │
高防接入层
  │  ├─ TCP/HTTPS监听
  │  ├─ TLS终止
  │  ├─ 七层规则匹配
  │  └─ 清洗、限速、挑战或拦截
  │
回源链路
  │
香港源站服务器
  │  ├─ Nginx/Apache
  │  ├─ 应用服务
  │  └─ 数据库或缓存

七层规则要想按域名、URI、请求方法、Cookie、请求头或访问频率匹配，HTTP请求必须先被高防接入层解析。若HTTPS采用纯透传，边缘只能看到TCP连接和部分TLS握手信息，无法直接判断 /api/login、Cookie或具体请求参数。此时即使控制台中存在“URI拦截规则”，也可能不会产生命中记录。

同时要区分两个概念：

• 高防接入成功：请求到达了高防的公网入口。
• 七层规则生效：请求进入了正确的HTTPS/HTTP监听器，并命中了启用状态的匹配条件。
• 回源链路正确：未被拦截的请求才转发到预期的香港源站，且源站没有被其他地址直接访问。

这三者不能用“浏览器能打开”一个现象代替判断。

排查前先固定时间和证据

CC攻击期间不要一开始就重启Nginx、修改所有限速值或批量封禁IP。先记录一个短时间窗口内的现象，至少包括：

• 攻击域名、协议和端口，例如HTTP/80或HTTPS/443；
• 主要请求路径、请求方法和是否集中在某个接口；
• 高防控制台显示的入站请求数、放行数、拦截数和回源请求数；
• 源站Nginx或应用日志中的请求时间、Host、URI、状态码和来源地址；
• 高防事件日志中的规则ID、动作、请求ID或边缘时间戳；
• DNS当前的A、AAAA、CNAME记录，以及旧记录是否仍处于TTL缓存期。

时间必须统一。高防日志可能使用UTC，服务器日志可能使用香港本地时间。两个系统相差八小时，会让“边缘已拦截、源站仍有请求”的判断失真。

如果已经有一条有效的放行名单或管理IP，也不要在没有备份的情况下直接删除。规则和DNS修改前，分别保存当前策略截图或导出文件，并记录原始值，便于回滚。

第一优先级：确认DNS没有把请求送到源站

1. 检查A、AAAA和CNAME记录

在Linux或macOS终端执行，替换为实际业务域名：

dig +short A www.example.com
dig +short AAAA www.example.com
dig +short CNAME www.example.com

检查结果时，重点对照高防接入控制台提供的接入地址：

服务器上还可以检查本机实际使用的解析结果：

getent hosts www.example.com

如果本机解析仍为旧地址，不要立即判断高防配置失败。先确认权威DNS记录、TTL和递归解析缓存是否已经更新。高防入口切换后，旧TTL时间内仍可能有部分客户端访问旧地址。

2. 用安全的定向请求确认入口

在有权限的管理网络中，使用一个只读、低频的健康检查或静态路径进行验证。下面的地址仅为示例文档IP，请替换成实际的高防入口：

curl -sS -D - -o /dev/null \
  --connect-timeout 5 \
  --max-time 10 \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/healthz

这个命令的作用是保留域名和SNI为 www.example.com，但强制本次请求连接到指定的高防地址。它适合验证某个入口是否能够正确处理HTTPS请求，不应在攻击期间反复批量执行。

观察以下内容：

• TLS是否能建立；
• 返回的HTTP状态码是否符合预期；
• 高防访问日志中是否出现这次请求；
• 源站日志中是否出现相同时间、Host和URI的请求。

高防返回的响应头可能因产品配置而不同，不能只依赖某个 Server、Via 或自定义响应头来判断请求是否经过高防。更可靠的证据是高防日志中的请求记录、请求ID以及源站是否收到对应请求。

如果通过高防入口请求能够正常到达源站，但直接访问业务域名时高防没有日志，通常是DNS仍有旁路、客户端使用了AAAA记录，或实际访问的域名与检查的域名不一致。

第二优先级：确认HTTP/HTTPS监听和TLS模式

1. 不要把HTTP规则当成HTTPS规则

七层策略通常绑定在具体的协议监听器上。常见的配置冲突包括：

• 规则只绑定在80端口，攻击实际发生在443端口；
• 规则绑定了 api.example.com，实际攻击域名是 www.example.com；
• 规则只匹配 /api/，实际请求是 /index.php 或带有不同前缀的路径；
• HTTPS监听器存在，但策略仍挂在旧的证书或旧服务实例下；
• HTTP跳转到HTTPS后，真正的请求在另一个监听器上，原规则没有继承过去。

因此要在高防控制台逐层查看：

1. 防护实例或服务是否处于启用状态；
2. 80和443监听器是否都存在；
3. 目标域名是否绑定到正确监听器；
4. TLS证书、SNI和Host是否对应同一个业务；
5. 七层策略组是否明确关联到该监听器；
6. 规则动作是“观察/记录”还是“拦截/挑战/限速”。

2. 用SNI检查HTTPS接入对象

从Linux管理终端执行：

printf '' | openssl s_client \
  -connect 203.0.113.10:443 \
  -servername www.example.com \
  2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

这个命令主要验证指定IP上的443监听是否能够根据SNI返回目标域名证书。它不能单独证明七层规则已经生效，但可以发现以下问题：

• 443端口没有监听；
• SNI域名没有绑定证书；
• 访问到了默认站点；
• DNS或入口地址指向了错误的服务；
• 证书已过期或与业务域名不匹配。

随后仍要用一个低频HTTPS请求配合边缘日志验证。TLS握手成功，只能说明连接和证书处理正常，不代表URI规则已经被解析。

3. 确认TLS是否在高防层终止

在策略配置中查找类似“TLS终止”“HTTPS解密”“HTTPS透传”“回源协议”的选项。判断逻辑如下：

如果业务必须使用TLS透传，就不能把基于URI或Cookie的规则当作已经生效。可用的处理方式是让高防在边缘终止TLS并重新加密回源，或者改用连接层策略；具体能否使用哪种方式，取决于当前防护服务的监听能力。切换TLS模式前应确认源站证书、回源协议和证书校验配置，并先在低峰期验证，避免产生大范围证书错误。

第三优先级：检查七层规则的范围、动作和优先级

这是“规则已经配置但拦截不生效”最常见的原因。不要只看规则名称，应逐项核对规则实际绑定的位置和匹配条件。

1. 用规则检查表逐项确认

“观察模式”尤其容易被误认为拦截失败。观察模式可以记录命中量，但不会拒绝请求。如果边缘事件里显示规则ID和命中次数，而响应仍为200，需要先确认动作，而不是继续降低阈值。

2. 重点排查放行名单和规则顺序

一个典型的失效结构如下：

优先级1：放行所有来自某代理地址段的请求
优先级2：对 /api/ 按请求频率拦截

如果所有请求在高防层都被识别为同一个代理出口地址，那么优先级1会让优先级2永远无法执行。另一个常见结构是：

优先级1：放行指定Host下的所有请求
优先级2：拦截指定Host下的恶意URI

此时第二条规则也可能完全不会命中。

修复时不要直接删除全部白名单。应先导出当前规则，确认放行项的来源和用途，再把范围收窄到确实需要的管理地址、健康检查地址或可信上游。修改后先用单个授权请求验证，确认无误后再扩大策略范围。

3. 通过临时探针验证规则是否真的能命中

如果平台支持“仅记录”或“测试规则”，可以建立一条短时、窄范围的临时规则：

条件：请求头 X-L7-Probe 等于一段随机字符串
动作：记录
范围：目标HTTPS监听器、目标域名

在授权终端执行一次：

curl -sS -D - -o /dev/null \
  --connect-timeout 5 \
  --max-time 10 \
  -H 'X-L7-Probe: 7f3c9a-test-only' \
  https://www.example.com/healthz

预期结果是：

1. 高防访问日志出现该请求；
2. 临时规则显示命中；
3. 日志中的域名、路径和监听器与配置一致；
4. 源站只收到一次对应的健康检查请求。

如果没有命中，说明问题仍在入口、监听器、TLS解析、域名范围或请求条件，而不是CC阈值。测试完成后应删除临时规则，或恢复原有规则顺序，避免随机字符串规则长期留在策略中。

第四优先级：检查客户端IP识别和限速统计维度

很多CC规则不是按“每个真实客户端”统计，而是按高防到源站之间看到的连接地址统计。这里需要先区分两种位置：

• 高防边缘规则：应使用高防能够确认的真实客户端标识；
• 源站Nginx或应用规则：通常看到的是高防回源地址，需要在可信代理范围内恢复客户端地址。

1. 查看源站实际看到的来源地址

以Nginx默认访问日志为例，可先查看最近请求：

sudo tail -n 100 /var/log/nginx/access.log

如果日志量较大，可按攻击路径筛选：

sudo grep 'GET /api/' /var/log/nginx/access.log | tail -n 50

判断方式如下：

• 来源地址主要是高防的固定回源地址段：说明请求至少经过了高防回源链路；
• 来源地址直接出现大量公网客户端地址：可能存在直连源站、旁路域名或高防没有作为入口；
• 所有用户都显示为同一个高防地址：不能在源站简单使用“单IP限速”，否则可能把正常用户一起限制；
• 源站完全没有对应请求，但高防入站量很高：可能是边缘已经吸收，也可能是日志筛选路径不对，要结合高防放行量和规则动作确认。

不要直接信任任意请求携带的 X-Forwarded-For、X-Real-IP 等请求头。只有在源站确认请求来自可信高防回源地址段时，才应将这些字段用于客户端识别。

2.需要恢复真实客户端IP时的配置边界

如果确认使用Nginx，并且已经从高防服务资料中取得准确的回源地址段，可以采用类似以下思路：

# 示例仅说明配置关系，不能直接替换为实际地址段
set_real_ip_from 198.51.100.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

set_real_ip_from 必须填写实际可信代理网段，不能把 0.0.0.0/0 作为信任范围，也不能把未知客户端网段加入信任。配置修改前先备份Nginx配置，检查语法后再平滑加载：

sudo nginx -t
sudo systemctl reload nginx

预期结果是新请求日志中的客户端地址按照可信代理头恢复，同时未经过可信代理的请求不会伪造源地址。若 nginx -t 失败，不要执行reload；若加载后出现异常，恢复备份配置，再执行同样的语法检查和reload。由于不同发行版的服务路径和日志格式可能不同，先用以下命令确认服务名和配置路径：

nginx -V 2>&1 | tr ' ' '\n' | grep -E 'conf-path|prefix'
systemctl status nginx --no-pager

第五优先级：核对回源链路是否存在直连旁路

即使主域名已经进入高防，源站仍可能通过以下方式被直接访问：

• DNS中残留旧A或AAAA记录；
• origin.example.com、测试域名或旧业务域名仍公开解析到源站；
• 某个接口域名没有纳入高防策略；
• 应用使用了IP地址或内部别名，但该地址对公网开放；
• 防火墙允许任意公网地址访问源站端口；
• 高防只保护主站，静态资源或API使用了另一个未保护域名。

1. 在授权环境中进行定向源站测试

如果必须确认源站本身是否可直连，应从管理网络发起一次只读请求，不要在攻击流量中对源站进行高频测试：

curl -sS -D - -o /dev/null \
  --connect-timeout 5 \
  --max-time 10 \
  --resolve www.example.com:443:198.51.100.20 \
  https://www.example.com/healthz

这里的 198.51.100.20 是文档示例地址。测试结果的意义是：

• 能返回源站响应：说明源站公网入口可达，需要检查是否应限制为高防回源地址；
• 连接被拒绝或超时：不能单独证明源站安全，还要检查其他域名、IPv6和实际业务端口；
• 返回默认站点：可能是Host、SNI或源站虚拟主机配置不一致；
• 返回高防特有响应：可能填写的并非源站地址，应重新核对地址归属。

如果确定源站只应接受高防回源，修改安全组或防火墙前要保存现有规则，确认管理登录通道和监控探针不会被一并阻断，再只放行已核实的高防回源地址段。修改后先测试业务访问、管理访问和健康检查；若出现误封，按保存的原规则回滚。不要在没有明确回源网段的情况下套用通用防火墙命令。

2. 对照边缘日志和源站日志

一次请求至少要关联以下字段：

• 时间戳；
• Host；
• URI和请求方法；
• 边缘请求ID或自定义追踪ID；
• 源站响应状态；
• 源站接收时间。

判断分支可以按下表处理：

源站日志中没有请求，不代表用户没有收到响应。高防可能直接返回挑战页、错误页或缓存内容。要结合边缘的“放行量、拦截量、回源量”判断，而不是只看源站日志。

按结果选择修复方式

情况一：DNS或IPv6绕过高防

表现通常是主域名偶尔命中规则，源站却仍有一部分公网请求，或者IPv4检查正常、IPv6检查异常。

处理顺序是：

1. 修正A、AAAA和CNAME，使所有业务入口指向受保护地址；
2. 清理旧源站记录和不再使用的业务别名；
3. 等待原TTL生效，并从不同递归解析结果核对；
4. 在源站侧限制非高防回源访问；
5. 用高防入口和业务域名分别发送低频健康请求；
6. 对照边缘回源量与源站QPS是否一致。

情况二：规则命中但实际没有拦截

常见表现是事件日志中有命中次数，但响应仍为200，源站也持续收到请求。

优先检查：

• 动作是不是“记录”或“观察”；
• 规则是否仍处于草稿状态；
• 上级放行规则是否先于当前规则；
• 当前阈值是否只触发限速而不是阻断；
• 规则是否只对某个路径、方法或域名生效。

修复时先用一个临时探针规则验证“命中—动作—回源”完整链路，再调整正式规则。不要直接把全站规则切换为严格阻断，否则容易把健康检查、登录和正常API一起影响。

情况三：HTTPS透传导致七层规则无法识别

表现是TCP连接和TLS握手正常，但边缘没有URI、Cookie或请求方法字段，按路径创建的规则始终没有命中。

处理方式是确认是否可以在高防层终止TLS，再按原协议或加密协议回源。切换后必须验证：

• 证书和SNI是否正常；
• 高防能否看到Host、URI和方法；
• 回源证书校验是否符合当前配置；
• 业务是否依赖客户端证书或端到端TLS特性。

如果业务必须保持透传，就应使用与透传能力匹配的连接层策略，不要继续以为七层URI规则已经在工作。

情况四：客户端身份识别错误

表现是所有请求都被统计为同一个IP，或者一个高防回源IP触发限速后，大量正常用户同时受影响。

处理方式是：

• 在高防侧选择可信的客户端识别字段；
• 在源站侧只信任已确认的高防回源网段；
• 不接受任意公网客户端自带的代理头；
• 对高并发接口结合URI、会话、Cookie或业务令牌进行分层限速；
• 先采用记录或挑战动作观察误报，再逐步进入阻断。

单纯按IP设置一个很低的阈值，往往无法覆盖多源低频CC，也可能误伤共享出口的正常用户。

修复后的验证方法

修复不能只看“攻击页面是否恢复”。至少完成一次可重复的低风险验证。

1. 验证正常请求

从授权终端访问只读健康路径：

curl -sS -D - -o /dev/null \
  --connect-timeout 5 \
  --max-time 10 \
  https://www.example.com/healthz

检查正常请求是否：

• 经过正确的HTTPS监听器；
• 返回预期状态码；
• 在边缘日志中有记录；
• 在源站日志中只出现一次；
• 没有触发管理IP或健康检查误封。

2. 验证临时七层规则

使用前面生成的随机请求头测试临时规则。先让规则处于“记录”状态，确认能命中；再在很短时间内将动作改为挑战或阻断，发起一次请求。

预期结果是：

• 规则ID和请求字段在高防日志中一致；
• 阻断响应可能是403、429或服务定义的挑战响应；
• 源站没有对应的放行请求；
• 高防回源量没有因为该测试请求增加；
• 删除临时规则后，普通健康请求恢复正常。

动作和响应码会因服务配置不同而变化，所以重点是“命中记录、动作记录、源站是否收到”三项一致，而不是固定某一个状态码。

3. 观察一段完整窗口

修复后至少观察一个业务高峰或连续15至30分钟，重点看：

• 高防入站请求量；
• 七层放行、挑战和拦截数量；
• 回源请求量与源站实际QPS；
• 源站CPU、内存和连接数；
• Nginx 4xx、5xx和响应延迟；
• 正常用户登录、下单或API调用是否出现异常。

理想变化是：边缘拦截或挑战量上升，源站QPS和连接数下降或回到正常基线，业务错误率没有同步升高。如果源站负载下降但5xx增加，说明规则可能过严；如果边缘拦截量很高而源站仍持续高负载，则应回到DNS旁路、其他域名和回源防火墙继续排查。

最后确认临时规则、测试请求头、调试日志和临时放行项已经清理，正式规则已发布到正确的HTTPS监听器。以后遇到同类故障，优先沿着“域名解析是否到高防、TLS是否可解析、规则是否命中、动作是否执行、源站是否收到”的链路取证，通常比反复修改CC阈值更快找到真正的失效位置。