布隆过滤器不适合网络层CC拦截，因其无网络IO能力、不解析TCP包、不处理IP限流或TLS指纹，仅能判断key是否存在集合中，无法应对CC攻击的连接层和应用层特征。
布隆过滤器不能直接拦截cc攻击——它连http请求都收不到，更不处理连接、限流或ip识别。把它放在网络层做cc防护，属于用错工具。
为什么布隆过滤器根本不适合网络层CC拦截
布隆过滤器只干一件事：快速判断「某个key是否可能存在于预设集合中」。它没有网络IO能力，不解析TCP包，不看IP、User-Agent、TLS指纹，也不统计连接频率。CC攻击的核心特征（如单IP每秒建连200次、慢速发Header、复用SessionID）全在连接层和应用层协议里，bloom.Test()连这些字段的影子都见不到。
- 误判率再低也没用：它只能告诉你“这个域名可能在黑名单里”，但CC攻击者根本不会用黑名单里的域名，他们刷的是登录页、短信接口、搜索框——全是合法路径
- 无状态：布隆过滤器不记录时间、不维护IP计数、不感知burst行为，无法区分“正常用户秒刷3次”和“bot每秒发50个POST”
- 写入不可逆：一旦
Add()进一个IP，就永远在集合里；而CC场景需要动态封禁/解封，还得支持滑动窗口统计
真正该在网络层和连接层做的三件事
CC防御必须从连接建立阶段开始卡死，而不是等请求进到handler才查缓存。Go里能落地的实操点就三个：
-
http.Server.ReadHeaderTimeout设为2 * time.Second：拦住slowloris类攻击，强制中断卡在header解析阶段的连接 -
http.Server.MaxConnsPerHost设为50（配合net/http/httputil.NewSingleHostReverseProxy时），防代理层连接耗尽 - 在
net.Listener包装层用sync.Map按RemoteAddr().IP.String()+TLS ConnectionState.ServerName做连接指纹计数，超阈值直接conn.Close()
布隆过滤器唯一能帮上忙的地方：URL黑名单前置过滤
如果CC攻击目标明确指向某几个高危接口（比如/api/v1/login被撞库），且你已有静态黑名单（如已知恶意跳转域名、钓鱼子域名），这时可以加一层布隆过滤器做快速初筛：
- 初始化时用
bloom.New(10_000_000, 0.001)预热全部黑名单域名，注意统一小写、去https://前缀、截断?后参数 - 在中间件里调
bloomFilter.Test(normalizedDomain)，返回false直接http.Error(w, "", http.StatusForbidden) - 返回
true后必须查真实存储（比如Redis里该域名的详细策略），因为布隆过滤器不存规则，只答「可能存在」
布隆过滤器真正的价值不在“挡流量”，而在“省资源”——它让你用177KB内存代替800MB哈希表查百万级域名。但想靠它扛CC，就像拿筛子拦洪水：孔再小，水也从旁边过去了。
