连接数超过直接拉黑

链路已经核实清楚了。你的理解完全正确,而且代码就是这么实现的。我把整条链路给你画出来:

你说的没错——从"只丢包"进化成了"丢包 + 拉黑 IP"

以前 L4(XDP)对超速的 IP 只做丢包:包来一个丢一个,但 IP 本身没进黑名单,攻击者换个包速/歇一会又能打,XDP 每个包都要重新判一次速率。效率低。

现在这条链路补上了"判黑即拉黑",两个方向汇进同一个 L4 黑名单:

L7 侧(CC 一次质询即封) — challenge.lua:45-55 和 challenge.lua:102-103

超速被拦的 IP,只要再提交一次无效验证(真人验证失败)→ 立刻 add_blacklist,不走"3次验证码+3次拉黑"的阶梯。
下沉到 L4 — blacklist.lua:342-352

节点(CDN_NODE_ROLE=edge)判黑后不直接写,而是 enqueue_edge_report 入本地 Redis 队列(cdn:edge:report_queue)
agent BRPOP 转发主控 /api/edge/report,过四层护栏决定是否升级为全网封
升级后写进 L4 黑名单 map,XDP 直接在驱动层对这个 IP 整体拒绝——不再是逐包丢,而是这个 IP 一个包都进不来。
效率提升就在这:L4 从"每个包判速率再丢"变成"命中黑名单 IP 直接硬封",一次判断顶以前无数次,且封的是 IP 不是包。

一个细节值得注意:节点判黑不是直接下沉 L4,中间有主控的"四层护栏 + L7→L4 下沉开关"(见 blacklist.lua:319 注释)。这是防误伤——比如 NAT 出口共享 IP,不能一个真人验证失败就全网硬封一大片用户。

要我把主控侧 /api/edge/report 那段护栏逻辑也读出来,确认"什么条件才真正下沉到 L4"吗?这是判断会不会误伤的关键。