Почему Google загружает двоичные файлы с моего веб-сайта и использует пропускную способность?


9

Примерно с середины августа 2014 года несколько серверов Google загружали все (очень) большие двоичные файлы с моего веб-сайта примерно раз в неделю. Все IP-адреса отображаются как принадлежащие Google и выглядят следующим образом: google-proxy-66-249-88-199.google.com. Это GET-запросы, и они сильно влияют на трафик моего сервера.

До этого я не видел трафика с этих IP прокси-серверов Google, так что это, кажется, что-то относительно новое. Я вижу все виды трафика с других IP-адресов Google, все они - только запросы googlebot и HEAD.

Я не буду беспокоиться об этом, за исключением того, что все эти файлы загружаются Google примерно каждую неделю или около того. Используемая пропускная способность начинает становиться чрезмерной.

Я предположил, что, поскольку многие из этих файлов являются исполняемыми файлами Windows, возможно, Google загружает их для сканирования вредоносных программ. Даже если это правда, действительно ли это должно происходить каждую неделю?

Пример трафика с IP-адресов Google Proxy за ноябрь:

google-proxy-64-233-172-95.google.com: 8.09 GB
google-proxy-66-102-6-104.google.com: 7.50 GB
google-proxy-66-249-83-245.google.com: 3.35 GB
google-proxy-66-249-84-131.google.com: 1.54 GB
google-proxy-66-249-83-131.google.com: 4.98 GB
google-proxy-66-249-83-239.google.com: 2.48 GB
google-proxy-66-249-88-203.google.com: 2.94 GB
google-proxy-66-249-88-201.google.com: 2.58 GB
google-proxy-66-249-88-199.google.com: 4.89 GB

Обновление № 1: я забыл упомянуть, что эти файлы уже находятся в файле robots.txt сайта. Чтобы убедиться, что конфигурация robots.txt работает правильно, я также использовал тестер robots.txt в Инструментах Google для веб-мастеров, который показывает, что файлы определенно блокируются для всех ботов Google, за одним исключением: Adsbot-Google. Я не уверен, о чем это. И я искал в Google некоторые файлы, и они НЕ появляются в результатах поиска.

Обновление № 2: Пример: между 5:12 и 5:18 по тихоокеанскому времени 17 ноября, около полудюжины IP-адресов (все google-прокси) сделали GET для всех рассматриваемых двоичных файлов, всего 27. 4 ноября между 14:09 и 14:15 по тихоокеанскому времени те же IP-адреса сделали в основном то же самое.

Обновление № 3: На данный момент кажется очевидным, что, хотя это действительные IP-адреса Google, они являются частью прокси-службы Google, а не частью системы сканирования Google в Интернете. Поскольку это прокси-адреса, невозможно определить, где на самом деле исходят GET-запросы или они поступают из одного места или из нескольких. Исходя из спорадической природы GET, не похоже, что происходит что-то гнусное; скорее всего, кто-то решит загрузить все двоичные файлы при использовании прокси-службы Google. К сожалению, этот сервис, похоже, полностью недокументирован, что не помогает. С точки зрения администратора сайта, прокси довольно раздражающие. Я не хочу блокировать их, потому что они имеют законное использование. Но они также могут быть использованы неправильно.


Хороший вопрос. Я проголосовал за это! Вы наверняка захотите заблокировать их, используя robots.txt. Почему Google скачивает исполняемые файлы, мне не понятно. Ваша теория кажется хорошей, но почему-то из-за частоты я не уверен. Это кажется довольно странным. Похоже, это действительные IP-адреса Googlebot, хотя в моем списке нет google-proxy-66-102-6-104.google.com.
closetnoc

Я забыл упомянуть, что эти файлы уже находятся в файле robots.txt сайта. Смотрите обновление №1 выше.
boot13

Вы меня запутали. У меня есть подрядчик, ожидаемый в любую минуту, поэтому мне придется подумать об этом. Google делает забавные вещи с их доменными именами и распределением IP-адресов, и было некоторое совпадение с различными службами Google, включая хостинг и другие, где боты людей могут появляться в пространстве IP-адресов Google, однако я не видел их с использованием IP-адреса Googlebot пространство. Хотелось бы, чтобы Google выделял свободное пространство для различных поисковых процессов практически без наложения, чтобы системы безопасности могли должным образом доверять этим IP-адресам.
closetnoc

Ответы:


3

Я провел некоторые исследования по этому вопросу и нашел некоторые интересные вещи, такие как:

1. Это фальшивый гусеничный ход? -> /programming/15840440/google-proxy-is-a-fake-crawler-for-example-google-proxy-66-249-81-131-google-c

Вывод от пользователя:

Эти «сканеры» не являются сканерами, а являются частью предварительного просмотра веб-сайта, используемого в поисковой системе Google.

Я попытался сделать это, чтобы показать один из моих веб-сайтов в предварительном просмотре, и да, там он получил заблокированное IP-сообщение.

Если вы хотите, чтобы пользователи могли просматривать предварительный просмотр вашего веб-сайта, вы должны принять эти «сканеры».

Как говорили другие: «корневым доменом этого URL является google.com, и это не может быть легко подделано».

Вывод: Вы можете доверять этим ботам или сканерам, и он используется для предварительного просмотра в поиске Google.

Мы знаем, что предварительный просмотр не загружает ваши файлы, поэтому давайте перейдем к вопросу 2.

2. Является ли это частью услуг Google? -> Является ли этот прокси-сервер Google поддельным сканером: google-proxy-66-249-81-131.google.com?

Вывод:

Я думаю, что некоторые люди используют службы Google (например, Google Translate, Google для мобильных устройств и т. Д.) Для доступа к (заблокированным) веб-сайтам (в школах и т. Д.), А также для атак DOS и аналогичной деятельности.

Я думаю, что это то же самое, что и выше. Кто-то пытается использовать службу Google для доступа к вашим файлам, например, переводчик.

Если, как вы говорите, файлы уже заблокированы файлом robots.txt, это может быть только запрос вручную.

РЕДАКТИРОВАТЬ: Чтобы обратиться к OP Комментарий широко:

Могут ли сканеры игнорировать файл robots.txt? Да. Вот список, который я не думаю, что Google делает это, что означает, что это могут быть другие боты, использующие прокси Google.

Это может быть плохой бот? Да, и для этого я рекомендую:

Запрет .htaccess:

 RewriteCond %{REMOTE_HOST} ^209.133.111..* [OR]
 RewriteCond %{HTTP_USER_AGENT} Spider [OR]
 RewriteCond %{HTTP_USER_AGENT} Slurp
 RewriteRule ^.*$ X.html [L]

Этот код может заблокировать IP или пользовательский агент.

Или используйте Ловушку Паука, показанную здесь

Я придерживаюсь своего мнения, что это ручной запрос.


Я тоже видел эти ответы, но, похоже, они не касались моей конкретной проблемы. Возможно, вы правы в том, что Google Proxy каким-то образом используется неправильно, и в этом случае я, скорее всего, заблокирую его полностью, что отчасти неубедительно. Насколько я понимаю, robots.txt заключается в том, что программа на гусеничном ходу может игнорировать его. Дружелюбные боты, как полагают, уважают это, и большинство делает, но прокси разные (я думаю) разные.
boot13

1
@ boot13 Будьте осторожны, хотя. Это действительные IP-адреса Googlebot. Так что, если вы заблокируете его, заблокируйте его только для этих файлов. Предполагая, что вы используете Apache, вы сможете сделать это с помощью .htaccess. Но это может вызвать другие проблемы, поэтому обязательно обратите внимание на Google Webmaster Tools для сообщений.
closetnoc

@ boot13 Я обновил свой ответ. Можете ли вы проверить, сделаны ли обращения в один и тот же день / час или являются случайными?
nunorbatista

@nunorbatista: они кажутся случайными. Я обновил свой вопрос несколько раз.
boot13

@nunorbatista: см. обновление № 3 выше. Это не робот Google или любой другой сканер, это прокси-сервис Google. Это не связано с предварительным просмотром сайта Google. Похоже, что один или несколько человек только что загрузили двоичные файлы через Google Proxy, возможно, чтобы обойти локальный блок или ограничение. Предложение Spider Trap вряд ли поможет, так как трафик явно не бот. Я хотел бы заблокировать доступ Google Proxy IP к папке, содержащей двоичные файлы; Я попробую использовать код htaccess, но, конечно, загрузчик всегда может переключиться на другой прокси-сервер, поэтому это может быть бессмысленно.
boot13
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.