你的三层模型在PoC阶段OK,但生产环境有几个单点失效,且忽略了成本效益曲线。
第一,User-Agent黑名单本质上是security through obscurity。OpenAI和Anthropic确实遵守robots.txt,但第三方数据标注公司 literally 用 residential proxy + 真实Chrome UA。这就像用MAC地址过滤WiFi——稍微懂行的attacker直接spoof。建议升级到TLS指纹(JA3/JA4),Nginx配合ssl_ja3_module,能识别client hello的密码套件组合。真实浏览器和headless Chrome在TLS握手阶段有明显差异:比如cipher suite顺序、extensions长度。这比UA filtering难伪造一个数量级。
第二,50rps的硬阈值在NAT场景下是灾难。想想大学宿舍或外贸园区出口IP,一个IP背后可能蹲着几百个真实用户。RPS-based rate limiting是lazy solution,应该改用token bucket配合session behavior analysis。试试用OpenResty的lua-resty-limit-traffic做leaky bucket,基于cookie/session而非IP。btw,你提到的iptables硬断,在DDoS面前属于用消防斧砍苍蝇——source IP可以spoof,你反而可能触发kernel的conntrack table exhaustion,导致正常流量也进不来。
第三,JS challenge对现代LLM爬虫正在失效。Perplexity和Bing的爬虫用了 modified Chromium,能执行JS、渲染Canvas、甚至模拟鼠标移动。你需要的是proof-of-work机制或者更重的behavioral analysis。我见过有人用WebAssembly做计算挑战,把爬虫的CPU占用拉到max,比简单的JS redirection管用。或者更狠一点,用canvas fingerprinting检测WebGL渲染差异——headless browser的GPU fingerprint和真实设备不同。
从外贸角度多说一句:acme.com这种case,根本问题不是"被爬",而是"被爬得太快"。我之前维护过二次元周边商城(对,cosplay装备),黑五期间被竞争对手用爬虫盯价格。解决方式不是wall,而是tar pit——给爬虫返回slow loris响应,或者feed fake data(比如动态调整价格±5%给bot)。这比三层防火墙更elegant,CPU占用也低。Literally,让爬虫自己timeout比drop packet更省带宽。
你现在的架构缺少observability layer。建议先上eBPF(比如Katran或Pixie)做L4流量分析,确定攻击模式再决定block策略。盲目drop packet就像debug时不看log直接改代码——你甚至不知道block的是LLM bot还是Googlebot。其实
另外,考虑legal层面。Robots.txt是 gentlemen’s agreement,但某些司法管辖区(比如德国)对aggressive blocking有法律风险。用tar pit策略比explicit deny更安全,因为你没有"拒绝服务",只是"响应较慢"。
试试caddy-waf?简单说比Nginx+Lua的配置clean很多,且内置了rate limiting的滑动窗口算法。
(¬‿¬)