Facebook 爬虫机器人崩溃网站

Posted 2023-03-13

【中文标题】Facebook 爬虫机器人崩溃网站

【英文标题】：Facebook Crawler Bot Crashing Site

【发布时间】：2012-10-04 12:45:33

【问题描述】：

Facebook 是否只是实施了一些网络爬虫？在过去的几天里，我的网站已经崩溃了几次，被我追溯到 Facebook 的 IP 严重超载。

我尝试在 Google 上四处搜索，但找不到任何有关通过 robots.txt 控制 Facebook 爬虫机器人的明确资源。有一个关于添加以下内容的参考：

用户代理：facebookexternalhit/1.1 爬行延迟：5

用户代理：facebookexternalhit/1.0 爬行延迟：5

用户代理：facebookexternalhit/* 爬行延迟：5

但我找不到任何关于 Facebook 机器人是否尊重 robots.txt 的具体参考资料。根据较早的消息来源，Facebook“不会抓取您的网站”。但这绝对是错误的，因为我的服务器日志显示它们以每秒很多页的速度从 69.171.237.0/24 和 69.171.229.115/24 范围内的十几个 IP 爬取我的网站。

我找不到任何关于这方面的文献。我怀疑这是 FB 在过去几天刚刚实施的新东西，因为我的服务器以前从未崩溃过。

有人可以请教吗？

【问题讨论】：

是的，最近发生了一些变化，因为它开始让我们在 8 年来第一次崩溃。据说他们正在“更新他们的开放图”。但是，查看我们请求的页面（非常旧的晦涩页面），我想知道合法的机器人是否正在执行 javascript，并拉入类似的按钮，从而触发 FB OpenGraph 更新。这只是一种预感......

相关问题：***.com/questions/11521798/…和***.com/questions/7716531/…

感谢您的建议和参考，汉克。在一个转折的事件中，我的网站在 11 月 8 日或 9 日的几个小时内被每秒数十次访问所淹没。但这一次——不是Facebook，而是亚马逊。它突然开始在网站内大量搜索大量链接，但似乎没有任何明显的模式 - 访问的一些页面是晦涩的/旧页面，而有些是最新的页面。想知道他们是否正在刷新自己的搜索引擎数据库。

同样的修复将适用于亚马逊，以及 facebookexternalhit。请参阅 ***.com/questions/11521798/… 并添加一些条件 OR 来检查几个用户代理。

谢谢你，汉克。顺便说一句，也许您可​​以通过消除读取/写入日志文件的需要来进一步优化代码，并直接使用/更新文件的时间戳进行比较。

【参考方案1】：

正如in this similar question on facebook and Crawl-delay 中所讨论的，facebook 并不认为自己是机器人，甚至不会请求您的 robots.txt，更不用说关注它的内容了。

您可以实现自己的速率限制代码，如类似问题链接中所示。这个想法是在您的服务器容量过剩或被特定用户代理淹没时简单地返回 http 代码 503。

似乎那些为大型科技公司工作的人不明白“改进缓存”是小公司没有预算可以处理的事情。我们专注于为实际付款的客户提供服务，并且没有时间抵御来自“友好”公司的猖獗网络机器人。

【参考方案2】：

我们在大约同一时间（10 月中旬）看到了相同的行为 - 来自 Facebook 的大量请求导致请求排队和整个系统运行缓慢。一开始是每 90 分钟一次；几天后，这种频率增加并变得随机分布。

这些请求似乎不尊重 robots.txt，因此我们不得不考虑不同的解决方案。最后，我们设置 nginx 以将所有带有 facebook 用户代理的请求转发到一对专用的后端服务器。如果我们使用 nginx > v0.9.6，我们可以为此做一个很好的正则表达式，但我们没有，所以我们使用了类似于

的映射

    map $http_user_agent $fb_backend_http 
             "facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)"
                    127.0.0.1:80;
     

这对我们很有效；在我们受到重创的几周内，这种请求分区使繁重的流量远离系统的其余部分。

现在对我们来说似乎已经基本消失了——我们只是看到间歇性的峰值。

至于为什么会发生这种情况，我仍然不确定 - 4 月份似乎发生过类似的事件，归因于错误 http://developers.facebook.com/bugs/409818929057013/ 但我最近不知道有什么类似的事情。

【讨论】：

谢谢分享。我正在使用 Apache - 希望他们有类似的方法来重新映射用户代理的请求。但这会假设我有另一个好的服务器来卸载这些动态访问，因为它们不是静态页面，否则我将不得不完全丢弃请求并希望 FB 不会认为我的网站是无效的。与您观察到的相似，事件此后不久就停止了。这可能是一些混乱的 FB 流程 - 但最终不尊重 robots.txt 肯定是一种不好的做法。

【参考方案3】：

无论 facebook 发明了什么，你肯定需要修复你的服务器，因为它可能会因外部请求而崩溃。

另外，facebookexternalhit 在 Google 上的首次点击：http://www.facebook.com/externalhit_uatext.php

【讨论】：

谢谢。我确实查看了 FB uatext 页面，尽管它没有提供任何具体内容。使我的服务器崩溃的页面来自 Wordpress 博客部分，其中包含数千篇文章。不幸的是，即使安装了所有的调整和快速缓存，引擎也不够高效，我能想到的快速修复的唯一方法是实现 robots.txt 抓取延迟，但我不知道 FB 是否尊重它。我没有遇到谷歌抓取的问题，因为它全天传播。 FB 一下子扑向海量页面并杀死服务器。

我还有一个不喜欢 FB 的理由 :)