用 Opsx + AI 治理网站恶意爬虫：7 月拦截近 4 TB 无效 CDN 流量
生成式 AI 普及以后，技术用户获取答案的方式正在发生变化。一部分原本需要访问社区、搜索历史问答或发布新问题的需求，被 AI 对话直接承接。对技术社区而言，真实用户访问和 UGC 活跃度承受压力并不意外。Stack Overflow 也曾在官方流量分析中披露，GPT-4 发布后的 2023 年 4 月出现过约 14% 的超常流量下降。 墨天轮的数据一度呈现出相反现象：在行业真实流量承压的背景下，网站访问指标没有下降，反而增长了数倍。按照过去以日活、月活为核心的运营口径，这原本应该是一个非常好的结果；但同期 UGC 产出，以及用户登录、签到等能够确认的互动数据并没有同步增长，部分指标反而在下降。 继续核对 CDN、NGINX 和应用日志后，指标之间的矛盾才得到解释。传统搜索引擎蜘蛛的流量变化很小，对这轮指标增长的影响可以忽略；真正抬高访问量的是大量伪装成普通浏览器的程序化抓取请求。它们的目的无法从访问日志直接证明：可能是搬运网站内容，可能是构建本地知识库，也可能用于大模型训练。能够确认的是，这些请求没有带来相应的登录、签到或内容互动，却被计入了原有的流量、日活和月活指标。 第一阶段，我先用 User-Agent 黑名单处理能够明确识别的低价值抓取请求。当前实际规则如下，Googlebot 和 Bingbot 没有进入名单，因此不会在这一层被拦截。下面为了阅读做了换行，CDN 中保存的实际配置仍是一条连续规则： *YisouSpider*|*Baiduspider*|*python-requests*|*Go-http-client*|*okhttp*|*Apache-HttpClient*|*Sogou*|*Firefox/3.0*|*Windows NT 5.1*|*360Spider*|*AhrefsBot*|*Windows NT 6.1*|pc|axios/1.7.7|*Bytespider* 这份名单不只包含一搜、百度、搜狗、360、Ahrefs 和 Bytespider 等已知蜘蛛，也覆盖 python-requests、Go-http-client、okhttp、Apache-HttpClient、axios 等常见程序化客户端，以及根据当前业务访问特征确认不再需要的旧客户端标识。规则生效后，CDN 侧流量下降约 30%，说明这一层简单、确定且几乎没有运行成本的过滤已经处理了相当比例的非用户请求。 但这一步很快遇到边界。剩余 Bot 不再使用固定的爬虫 User-Agent，而是伪装成 Chrome 等普通浏览器；有些还使用 IP 池轮换来源，把请求分散到同一网段的多个地址。单看某一个 IP，请求量可能并不突出；聚合到 /24 网段后，持续抓取的特征才会显现。只依赖 User-Agent 或单 IP 黑名单，已经无法继续识别这部分流量。 问题因此不再只是“访问量太大”。爬虫流量一方面污染运营指标，使表面增长与登录、签到、UGC 等互动指标发生背离；另一方面持续消耗 CDN、源站服务器和 OSS 资源。对于以原创技术内容为核心的网站，它还带来内容被批量获取的风险： CDN、源站服务器和 OSS 都在为它们消耗流量、连接和计算资源； 原创内容被外部平台批量抓取和搬运，墨天轮承担内容生产与分发成本，内容价值却被外部平台直接复用。 云 WAF 和 Cloudflare 都是可以考虑的方案，但并不适合直接套用到当前场景。WAF 的 Bot 识别与定制能力难以完整覆盖内容型网站的业务规则，整体费用也比较高；Cloudflare 在中国大陆的接入还有额外条件，其官方 China Network 文档要求先使用 Enterprise Plan，再单独订阅中国网络，并由合作方审核域名。 ...