我收到了来自 Media Temple(为 CSS-Tricks 提供托管服务的提供商)的电子邮件,告知我本月的“GPU”使用量将超过限制。什么?原来 GPU 是“网格性能单元”,是 Media Temple 用于计算服务器资源使用量的专用方法。我认为除了数据库之外的所有内容都包含在内。他们在他们的界面中提供了一个“GPU 工具”,用于显示哪些网站部分导致了最多的使用量。我想我最好检查一下,确保一切都正常。
此网站的前三个使用量是主页、RSS 订阅和 Atom 订阅。对我来说很有意义……但是列表中的第四个很突出。它是 URL“css-tricks.com/images/ajax-loader.gif”。看看
在这个网站上我并没有真正使用 AJAX,除了少量简单的 jQuery 代码。我最初的想法是投票,因为它过去出现了一些奇怪的问题,并且确实使用了一个小型的旋转器来显示结果。但事实并非如此……文件名不同。奇怪的是,该文件不存在,这就是为什么访问时会抛出 404 错误的原因。
现在,当您在网站上安装了 WordPress(或其他 CMS)时,您可能拥有一个内置于其中的 404 页面,以提供比空白浏览器默认错误页面更友好的体验。看看 我的 404 页面。好吧,它可以更友好一些,但那是另一个故事。关键是,它需要服务器付出比提供一个小型 GIF 图片更多资源才能输出整个页面。我找到一个名为该名称的旋转 GIF 图片,并将其放入我的 images 目录中。
- 404 页面的总大小:767 KB
- ajax-loader.gif 的总大小:4 KB
那么这些奇怪的请求来自哪里?我 99% 确信它们是随机的,可能是恶意的,而不是来自该网站的合法请求。我所知道的是,如果我提供图片而不是 404 页面,我可以为每个请求该文件节省 763 KB 的带宽/资源。当每月被点击超过 16,000 次时,这可就积少成多了!
但这并不是唯一被请求该奇怪文件的 URL!各种 URL 都被请求该文件,所有都是 css-tricks.com 的 URL。大多数是不同的随机文章,比如“css-tricks.com/random-post-title/images/ajax-loader.gif”。加起来,这些随机请求比 /images 中的主要请求更加压力大。
我需要一个通用的解决方案来重定向所有这些奇怪的请求,让它们到达正确的位置。幸运的是,Perishable Press 的 Jeff Starr 撰写了一篇关于他遇到的类似问题的及时文章:将对不存在的文件的所有请求重定向到实际文件。他最初遇到的问题是针对对不存在的 favicon.ico 文件的奇怪请求。我也看到了这种现象,还有一些 robots.txt 请求。
是时候停止这一切疯狂,解决这个问题了!
使用一些 .htaccess 魔法,我能够将对该“ajax-loader.gif”文件以及 favicon.ico 文件的任何请求重定向到它们在服务器上的实际位置,并停止抛出浪费带宽的 404 错误。
以下是最终代码
# REDIRECT FAVICON.ICO
<ifmodule mod_rewrite.c>
RewriteCond %{REQUEST_URI} !^/favicon\.ico [NC]
RewriteCond %{REQUEST_URI} favicon\.ico [NC]
RewriteRule (.*) https://css-tricks.org.cn/favicon.ico [R=301,L]
</ifmodule>
# REDIRECT AJAX-LOADER
<ifmodule mod_rewrite.c>
RewriteCond %{REQUEST_URI} !^/images/ajax\-loader\.gif [NC]
RewriteCond %{REQUEST_URI} ajax\-loader\.gif [NC]
RewriteRule (.*) https://css-tricks.org.cn/images/ajax-loader.gif [R=301,L]
</ifmodule>
非常感谢 Jeff Starr 在此过程中与我合作,并使其正常工作。您可以通过尝试以以下方式请求文件来查看其效果
https://css-tricks.org.cn/blahblahblah/ajax-loader.gif
您将立即被重定向到正确的位置。
注意:如果您使用的是 WordPress 并且具有特殊的永久链接(像我一样),那么您的根级 .htaccess 文件中已经包含一部分特定于 WordPress 的内容。这些内容需要放在前面才能正常工作。
您发现这些请求最初发生的原因了吗?
这在 Microsoft 的 IIS 服务器上有效吗?还是只在 Apache Web 服务器上有效?
Dave Samuels 进来帮助回答这个问题……
@Brian Lang:这仅适用于 Apache Web 服务器。我做了一些快速搜索(即谷歌搜索),不幸的是,IIS 中没有直接等同于 .htaccess 文件的东西。我不确定您对托管网站拥有哪些访问权限,因为有一些“插件”可以在 IIS 中模仿 .htaccess 设置。祝您的网站好运。
感谢这篇文章 Chris,我也在我的 Media-Temple 网站上遇到了一些奇怪的访问请求,这应该会有所帮助。
@Marcus,我们自己托管网站,因此访问服务器没有问题。我会尝试找到一些这些“插件”。
我开启了代理,并观察到对您视频文章中的 ajax-loader.gif 的请求,特别是第 33 号和第 31 号,但不是第 31 号。对于包含嵌入式视频的 RSS 订阅可能也是同样的情况。
也就是说,“不是第 32 号”。
Chris,
太平洋时间上午 11:40,我刚刚点击了文章中的最后一个链接,指向 ajax-loader.gif,然后得到了加载器图片。它没有重定向。我认为您应该知道。
@John S. – 这就是想法,您实际上得到了加载器图片,而不是 404 页面,因为提供 404 页面需要更多的资源。
哎呀!忽略我最后一条帖子!看来我还困着,没有真正想明白。当然我得到了加载器……这就是重点!滴滴滴!我现在要爬回床上去了!
另一种抑制这种行为并避免 .htaccess 命中率的方法是,简单地在必要的位置放置“空白”文件(例如 favicon.ico)。
@David:问题是,有数百篇文章,它们都在收到奇怪的请求。而且由于我的永久链接结构,这些文章实际上在我的服务器上没有文件夹,因此我无法将空白文件放置在请求想要的位置。
这正是使用这种技术的目的。与其追逐虚拟位置上不存在的文件,并为越来越多的毫无意义的“虚拟”文件烦恼,不如使用一个简单的重写规则来一劳永逸地解决问题。简洁、简单且有效。
有人(或一些人)可能在他们自己的网站上某个经常使用的地方(比如主页或每个页面)的标签或其他地方链接了您的图片。
可能值得编写一个 PHP 脚本来替换图片,并将引用 URL 记录到文本文件中?除非您的 Web 托管提供商当然提供了完整的 Apache 日志!
但话又说回来,与其解决问题,您应该直接调查为什么会出现这个错误,以便您可以用正常的方法解决。进行重写也会导致不必要的服务器使用量。
@V1:我敢肯定这不是您所指的错误。我认为这确实是恶意蜘蛛程序在寻找支持 AJAX 的网站。
如果在一个网站上发现了 ajax-loader.gif 图片,那么它很可能正在运行一些 AJAX 功能……然后蜘蛛程序的拥有者就可以去寻找 AJAX 功能中的安全漏洞……
虽然很有趣……但我还没见过或听说过其他地方发生过类似的事情。
@V1:我不是专家,但根据我的经验,Joost 的结论是正确的:这种行为是故意的、恶意的,而且持续存在。这一结论是在花费了数小时做您所说的事情之后得出的:调查有问题的错误。
有一些糟糕的机器人程序在网络上漫游目录,寻找潜在的漏洞。在这种情况下,AJAX 功能是目标。正如 Chris 在他的文章中提到的,响应这种请求,提供数十个、数百个甚至数千个定制的 404 页面需要比简单的 htaccess 重定向更多的服务器资源。
如果您碰巧知道处理这种攻击的“正常方法”,请与我们分享,这样我们就可以放弃“解决问题”。
@Jeff Starr: 这不是一个在你的网站上爬取恶意内容的蜘蛛。出现这种情况的原因是,ajax-loader 文件是通过相对链接而不是绝对路径调用的。尝试在 javascript 文件或 css 文件中找到它加载的位置,并将 'images/ajax-loader' 更改为 '/images/ajax-loader'。
我更希望看到 200 响应而不是 301 => 200。
@Mike: 我不这么认为。首先,Chris 描述的这种行为在许多不同位置的许多不同文件中(例如 robots.txt、favicon.ico、ajax-loader.gif 等)都能看到。大多数这些 404 请求的目标 URL 仅在虚拟上存在,是由 Apache 的 mod_rewrite 功能(即永久链接)创建的。例如,许多人在他们的错误日志中看到过这样的条目
http://domain.tld/some-great-post/robots.txt
http://domain.tld/another-great-post/robots.txt
http://domain.tld/yet-another-great-post/robots.txt
robots.txt 文件不仅不存在,而且目录本身也不存在;这些类型的 URL 是根据数据库内容动态生成的。因此,当您有一个像这样的网站,它使用一些 jQuery 来创建一个漂亮的滑动效果时,它是在一个确实存在的本地目录中完成的,如以下假设设置所示
[网站根目录]
[css]
[images]
[javascript]
index.php
head.php
.
.
.
鉴于这种典型的文件夹结构,调用 ajax-loader.gif 文件的 jQuery 脚本将位于“javascript”目录中。所有对该文件的调用都是从服务器上的此位置进行的,而不是从随机的虚拟“永久链接”目录中进行的。我能想到的唯一一次()在日志中出现请求不存在文件(如 ajax-loader.gif)的永久链接 404 错误的情况是,当某个永久链接 URL 上的网页通过浏览器保存为脱机副本时。
因此,您的解决方案可能会消除一些错误(那些由保存网页的脱机副本引起的错误),但其他许多错误将持续存在,因为它们不是本地起源的。验证这些错误的恶意性质的简单方法是检查与请求关联的远程地址。
不偏离主题,但有一条关于 robots.txt 不存在的旁注……我认为,它应该始终存在!
您可以使用此文件来限制(行为良好的)机器人仅搜索您希望它们搜索的网站部分。让它们完全访问每个文件和每个图像会浪费大量的服务器资源。
我还为那些行为不佳的机器人设置了“蜘蛛陷阱”:) 我设置了一个包含一个 index.php 文件的目录,该文件没有任何链接到它,并在我的禁止列表的顶部列出了它。任何看到名称并转到该目录的糟糕的机器人(或黑客查看 robots.txt 以获取目录列表)都会被重定向到一个文件,该文件将他们的 IP 添加到一个列表中,并通知他们已被禁止。然后我的页眉(在每个页面上使用)调用一个文件,该文件检查每个用户的 IP 是否在该列表中,如果找到,则将他们重定向到一个文件,表明他们已被禁止。
摆脱了糟糕的机器人。摆脱了黑客。节省了服务器资源。:)