美国vps服务器

2024年10月25号，周六。

本来该是大家歇口气的日子，Bear Blog的作者Herman却遇上了糟心事。

这款以极简、无广告、重隐私出名的博客平台，上线五年第一次崩了，也就是咱们常说的宕机。

这次宕机的原因有点绕。

不是负责内容展示的Web服务器扛不住，是管自定义域名的反向代理服务先撑不住了。

所有发往自定义域名的请求全超时，用户根本进不了博客。

更让人头疼的是，监控工具居然没报警。

Herman设的还是关键警报模式，按理说就算半夜也能吵醒人，可这次半点动静没有。

他过了好一阵才察觉不对，这无疑把故障时间又拉长了。

Herman后来在博客写了篇长文复盘。

里面提到，这次宕机看着是反向代理的问题，根子其实是爬虫闹的。

本来想只聊宕机的修复细节，但后来发现不把爬虫的事儿说清楚，根本没法理解这次故障的来龙去脉。

早阵子他就写过一篇叫《TheGreatScrape》的文章，说现在互联网上机器人流量快把正常流量挤没了，公开资源越来越危险。

这次BearBlog宕机，算是把这个问题摆到了台面上。

反向代理扛不住了！五年稳定的Blog为啥突然崩？

Bear Blog之前五年都没出过这种大问题，稳定性在中小平台里算不错的。

过去页面请求多了，系统能自动把Web服务器扩展到10倍容量，扛一扛也就过去了。

但这次不一样，周六早晨几百个博客突然被狂轰滥炸。

从日志上看，每分钟就有好几万条请求进来，根本分不清这些请求是故意的恶意攻击，还是太激进的爬虫行为。

前面的防护措施其实没掉链子。

Herman用了Cloudflare的WAF（Web应用防火墙），还有限速策略，这些常规手段本来能拦不少异常流量。

可架不住反向代理在最上游，所有请求都得先过它这关。

它一罢工，后面的防护措施再好也没用。

那监控为啥会哑火呢？Herman后来查了好几次，配置没问题，警报开关也开着，可就是找不着没报警的原因。

中小平台大多跟Herman一样，就靠一套监控盯着。

这玩意一旦出问题，就跟瞎了眼似的，等发现故障时，用户早炸锅了。

这次BearBlog宕机，算是给所有中小平台提了个醒：单靠一套监控太冒险。

要说这次宕机的幕后推手，爬虫绝对跑不了。

Herman把这些捣乱的爬虫分成三类，每类都有自己的坏招，咱们一个个说。

第一类是AI爬虫。

这类爬虫主要干两件事：要么帮大语言模型（LLM）抓数据训练，要么响应用户的搜索请求。

它们还算规矩，大多会标明身份，比如来自ChatGPT、Anthropic这些公司，也会说清楚是来干嘛的。

Herman对它们的态度很明确：用户搜索的请求就放进来，毕竟博客作者想让自己的内容被搜到；但用来训练模型的请求就拦了。

换谁也不想自己写的东西被拿去训模型，还没个说法。

这种区分挺合理的，既不影响博客的曝光，又护住了作者的内容版权。

现在大模型火，对数据的需求特别大，AI爬虫也越来越多，但只要能认出来，应对起来还不算难。

第二类是恶意爬虫。

这类就狠多了，专门盯着网站的漏洞钻。

比如找配置错的WordPress后台，或者泄露的.env、.aws文件，这些文件里往往藏着服务器的关键信息。

Herman说，就过去24小时里，他在几百个博客上就拦了快200万次这种恶意请求。

更离谱的是，这些爬虫还会换IP，上千个IP轮着用，查它们的ASN（自治系统号），大多是蜂窝网络的。

Herman猜，可能是有些手机应用搞的鬼：免费给用户用，却把用户设备的网络权限卖给爬虫团伙赚钱。

虽然这只是猜测，但想想也挺吓人，现在自己搭网站（自行托管）越来越危险，一点小错漏就可能被盯上。

第三类是未受控的自动化脚本。

美国服务器哪家强

Herman管这叫Vibe编程的产物，意思就是随便在AI工具里输句话，就能生成个能跑的爬虫脚本。

有人把这脚本放家里电脑上，24小时不停爬。

单看一个脚本不算啥，可架不住数量多。

几百上千个脚本一起爬，就成了轻度DDoS，服务器根本扛不住。

美国服务器的vps

现在家用电脑的性能早不是以前那样了，比很多小服务器（VPS）还强，一台电脑就能无意间搞出大麻烦。

Bear Blog过去几个月就老被这些小玩具误伤，这种爬虫最防不胜防，太分散了，拦都不好拦。

面对这么多爬虫，Herman也没闲着，试了不少招。

本来想搞点花活，比如用压缩炸弹反击爬虫，或者让爬虫先做工作量证明，就是让它们多花点算力才能爬，想劝退一部分。

甚至还想过返回无穷无尽的垃圾数据，让爬虫忙不过来。

但后来发现这些招都不实用：压缩炸弹容易误伤正常用户，工作量证明和垃圾数据又会让系统变复杂。

最后算下来，效果跟直接封禁请求差不多，还多了不少麻烦。

无奈之下，他只好放弃这些创意方案。

最后还是用了最实在的办法：靠Cloudflare的WAF和限速策略拦大部分异常流量，再加上自己写的识别逻辑，根据爬虫的行为模式，比如请求频率、访问路径，自动把恶意爬虫隔离开。

对中小开发者来说，实用比花哨重要。

毕竟没那么多时间和精力维护复杂的方案，能稳稳当当拦住爬虫，不影响用户，就已经很不错了。

Herman的改进方案！中小平台防爬能学啥？

宕机之后，Herman肯定要改，不然下次还得出问题。

他琢磨出了几套改进方案，都挺针对这次故障的，中小平台其实能学不少东西。

首先是加了监控冗余。

原来就一套监控，这次直接加了第二套。

以后再出宕机，两套监控会同时用电话、短信、邮件提醒他，就算一套哑火，另一套也能及时报信。

很显然，多一层保障总没错。

中小平台要是条件允许，真该学这招，监控这东西，不怕多，就怕关键时刻掉链子。

然后是把防护往前挪了。

以前是等请求到了Web服务器再拦，现在直接在反向代理层就过滤异常流量。

这么一改，服务器的负载直接少了快一半。

他还专门针对那些来自蜂窝网络的请求加了验证，毕竟之前发现恶意爬虫常用蜂窝网络的IP，多道验证就能多拦一部分。

还有就是给反向代理扩容。

原来的反向代理处理能力不够，这次直接提到了原来的五倍。

Herman还打趣说：有点过头，但算力便宜，我已经秃了，不想更秃。

这话听着幽默，其实是中小开发者的无奈：与其以后再出故障熬夜修复，不如现在多花点小钱，把问题提前堵上。

除此之外，他还加了个自动重启机制：要是带宽连续两分钟都归零，系统会自己重启反向代理。

这招能应对一些临时的小故障，不用等人工干预。

他还上线了一个专门的状态页（status.bearblog.dev），用户能实时看到博客的运行情况，就算出问题，也能及时知道进展，不用瞎猜。

这些改进看着都不复杂，但每一个都戳中了这次宕机的痛点。

对中小平台来说，不用学那些高大上的技术，先把这些基础的、针对性强的措施做好，就能少踩很多坑。

Herman的事儿不是个例。

现在互联网上机器人流量越来越多，不少平台都面临类似的问题。

比如豆瓣，之前就用行为指纹识别那些未受控的脚本，看用户的鼠标移动轨迹、页面停留时间，不是真人操作的就拦；知乎则用LLM分析爬虫的请求意图，精准区分是来搜索的还是来抓数据训练模型的，误拦率低了不少。

但中小平台没这么多资源。

没专业的安全团队，也没足够的钱搞复杂的防御系统，只能跟着大平台学些基础招。

如此看来，中小平台其实可以联合起来，比如共享爬虫的IP库，或者一起研究防御规则。

单干太难了，抱团才能扛住爬虫的进攻。

Herman在文末说：这场军备竞赛，还远没有结束。

我挺认同这句话。

现在爬虫技术越来越强，今天拦得住，明天可能就有新的爬虫绕过去；防御手段也得跟着升级，没有一劳永逸的办法。

BearBlog这次宕机，算是给所有做中小平台的人提了个醒：防爬虫不光要拦，还要盯着整个防护链条，比如反向代理这种上游环节；监控也得做冗余，别等出了问题才发现瞎了眼。

如果你也做平台，遇到过爬虫的麻烦，不妨在评论区分享下你的招。

大家互相学学，总比一个人琢磨强。

毕竟在反爬这件事上，多个人多份力，也能少走点弯路。

本服务器在美国服务