Пути обхода временного бана Google за частые обращения к базе

Самый нормальный вариант, это отлавливать в скрипте необходимость ввода капчи, предлагать её ввести через скрипт, т.е. картинку при этом качать в самом скрипте и отправлять гуглю результат ввода капчи и нормально работать дальше, до следующей капчи. Этот вариант, хотя и не удобнее варианта с проксями, но значительно проще реализовать совместно с 1 пунктом.

А в качестве 4 варианта, вполне можно использовать бесплатные хостинги с поддержкой PHP, единственно проблема, что curl’а там может не быть, так что хостинг придётся ещё поискать.

4-ый вариант - это криво реализованные свои прокси:) проще и лучше на этих хостингах прокси-серверы поднять
По сабжу проблема актуальная, тоже гугл парсю, сам обхожу просто - покупаю десятки айпи (20-30) на сервера, с которых парсится + незначительный таймаут. Для разумных объемов - около 10к разнообразных запросов в том числе: выдача по ключевикам, беки, пейджранк - работает на ура

пс скоро буду комментатор №1

to MegaS…
Тут ты не совсем прав…
Прокси фактически любой нормальный хостер вычисляет на “раз-два-три” и тебе придется общаться с их “секьюрити офицер” и объяснять что за скрипт такой ты поставил. Или кто-то умный из любителей фришных проксей отсканирует сетку и найдет твои прокси. В любом случае скорее всего с тобой никто общаться не будет - просто прикроют аккаунт и все. А вариант “кривых прокси” мною уже опробован на довольно известном хостере 3fn.net и прекрасно работает, и не нагружает самого хостера. А так как это все же не прокси - то и при сканировании портов его нет, а закрыть GET или POST запрос к этому скрипту паролем ничего не стоит.
К тому же, если говорить про “кривые” прокси и про “прямые” - в любом случае нужен некий многопоточный вариант или некий центральный менеджер, раздающий задачи. Вот его реализовать грамотно не сложно, но все же гораздо сложнее чем найти нескольких хостеров с работающими наружу CURL’ами.
В данный момент я знаю двоих таких хостеров, просто больше не искал. Ибо в том же 3fn.net спокойно можно взять 3-4-5 аккаунтов на серверах расположенных В РАЗНЫХ подсетях класса C, что будет выглядеть точно также, как разные аккаунты у разных хостеров. Даже больше того - есть много “хостеров” которые всего лишь реселлеры, и могут базироваться реально на одном сервере или одной подсетке - в этом случае “разные айпишники” будут для гугля все-равно “не разными” Это будет выглядеть как из одного компьютерного класса идет волна запросов - то есть айпишники вроде разные, но “рядом”, а это не есть гуд.

Теперь по поводу покупки десятков айпи на сервера… Верю на слово, но немного сомневаюсь. Дело в том, что обычная практика в настройке серверов заключается в том, что снаружи-то к ним можно обращаться по разным айпи, но реально эти адреса будут приходить на одну-две-три сетевые карточки (ну сколько их в сервер воткнуть можно? даже если они каждая многопортовая?).

Тут дело в том, что определенная сложность настроек (и лень администраторов) приводит к тому, что “прийти” к серверу можно с разных айпи, а вот обращения “от сервера” куда-то наружу обычно идут с одного и того же адреса. Реально настроить так, чтобы скрипты обращались от сервака к гуглю с разных айпишников можно, но сомневаюсь чтобы хостер об этом позаботился Ну 2-3 адреса он сделал, так сказать для резервирования или для распределения нагрузки на каналы. Но чтобы десятки!!! тут сомневаюсь…

Но повторяю, все может быть…

Однако если ты внимательно читал - речь еще и о деньгах шла. Насколько мне известно айпишники идут от 0.5$ до 1$. 20-30 айпишников это будет до 30 долларов. О какой бесплатности тогда идет речь? 30 долларов это реальные 6 аккаунтов на 3fn.net в реально разных подсетках со 100% гарантией от попадания в засвет перед гуглем. 30 долларов - это цена хорошего прокси-чекера. Причем разовая, а не помесячная. 30 долларов, это стоимость неплохого VPS-сервера, на котором это прокси-чекер можно поставить и тогда работать спокойно без боязни что айпишники на сервере как-то не так сработают из -за сисадминской лени. В конце концов 30 долларов - это больше ежемесячной стоимости вордтрекера, если его брать на год, то в месяц выйдет всего по 27$

При всех приведенных математических выкладках возникает вопрос - чем твой вариант лучше? И если не секрет, то как же твои 20-30 айпишников используются для парсинга? В один поток “по кругу” обходятся или как? Один скрипт на одном сервере при всем желании не сможет работать с разными айпи, даже если сервер ПРАВИЛЬНО настроен. Просто потому, что этот самый скрипт одновременно может выполняться только одним интерпретатором PHP, который, естественно, не имеет ни малейшего понятия, что твои запросы к гуглю надо по каким-то айпишникам раскидывать…

Так что реальный вариант только один - центральная часть, она же менеджер заданий, которая раскидывает задачи по нескольким отдельным потокам, при этом эти потоки должны быть отдельными скриптами на отдельных “серверах” (если используются прокси, то они как раз такими скриптами и будут, если не используются - надо делать свои “кривые”). Значит ты еще и 20-30 доменов под это дело покупаешь? Тогда цена вопроса еще больше выростает…

В общем - что-то тут не так. Буду признателен, если напишешь мне ответы не сюда, а по форме обратной связи на моем сайте (не пугайся, сайт несколько заброшен, так что не взыщи, просто тут мыло светить не охота, боты тоже бегают здесь

Давай просто не будем дальше путать и без того запутавшуюся молодежь, читающую этот блог? Свяжешься? Заранее благодарен!

Если бы в скрипте не нужно было логиниться в учетную запись, можно было бы просто с одного IP-шника работать подставляя различные User-Agent, т.к. Гугль банит не только по IP, он в том числе ещё проверяет User-Agent, по-крайней мере так работает поиск.

Забыл добавить, ни несколько прокси, ни несколько IP не будут работать, если будет использовать всего один логин, а если логинов будет несколько, то вполне может прокатить и свой User-Agent привязанный к каждому логину, даже при работе с одного IP, ИМХО.

Логинов по-любому нужна пачка, когда мы с ProfitHunter’ом все это обсуждали, то такая тема звучала… НО! они реально нужны только для ГуглТрендс, для получения данных о количестве поисков в CSV-формате нужно обязательно залогниться, а данный скрипт именно в этом формате получает результаты. Для получения данных о количестве конкурентных страниц используется “обычный” парсинг гугла, и тут логин-пароль никак не работает. Что он есть, что его нет. Просто надо предусмотреть не только “лог-он” для обращения к гугл-трендс, но и “лог-офф” перед обращением за компетиторами. Ведь скрипт не получает все данные одним махом - он делает два разных запроса на два разных гугловых урла. Вернее три - еще и логин ведь. Ну а может делать 4 - не велика беда…
Впрочем, я же сказал что у меня лично сейчас используется не один логин (в данный момент 5, но сами понимаете - нарегистрировать еще аккаунтов не проблема, а в скрипте это мною предусмотрено)

А вот мысль о том, что можно еще добавить рандомизацию по юзер-агенту - эта мысль пожалуй очень даже не лишняя Надо будет попробовать. Жаль сейчас сразу не могу, ибо обрабатывается большой бъем и риск схлопотать бан (если он все-же в результате таких проб возникнет) мне сейчас совсем не к месту… Хоть и временное это дело бан от гугла, но как раз сейчас время особо ценно…

Хотя я по-прежнему считаю, что аккаунт на “вордтрекере” или на “вордзе” (или еще где-то типа нишебота) по-любому нужен если подходить к делу серьезно. А значит самый простой вариант - это вариант про “два захода” - сначала скриптом с отключенным получением конкурентов прогоняется основная база на чекинг серчей. А уже после этого отфильтрованная скармливается вордтрекеру, где проверяются именно компетиторы. Там их кстати за один заход можно сразу по двум поисковикам проверить, например по гуглу и яхе, или по гуглу и МСНу. При большом количестве слов (а вордтрекер позволяет в одном проекте до 25000 кейвордов) конечно проверять устанешь, но для этого буржуи уже постарались - есть “автоматизатор проверки компетиторов в вордтрекере” - запускаешь софтинку, заходишь в свой аккаунт, жмешь “проверять” и гуляешь или занимаешься своими делами. Через 2 часа у тебя в почтовом ящике лежит 25000 проверенных кейвордов. Кстати ни при каком подходе (если не использовать супер-скрипты на выделенных серваках) такое количество отпарсить на обычном хостере не реально за это время. Так что эксперименты конечно дело интересное, но надо же и работать - вот я пока для себя с рабочим вариантом определился…

Ну а помелочам, так сказать для текущих потребностей в сотню-другую проверяемых кеев, пока буду тестировать МаркетСамурай, о котором нам так любезно рассказал ПрофитХантер. За что ему отдельное спасибо

Один момент учтите, если будет использовать юзер агент, предположим что нужно проверить 4 ключа (key1, key2, key3, key4) в 2 потока. Первый поток проверяет ключ key1, второй key2, когда первый поток перейдёт к ключу key3, то он ещё должен отправить refer с ключом key1, т.е. сделать вид что пользователь обработал один запрос и плавно перешёл к следующему, т.е. рефер не должен быть пустым. То же самое и для остальных потоков, имхо, в противном случае юзер агент может не сработать. Думаю не сильно ошибусь, если скажу, что гугль в первую очередь проверяет запросы с пустым рефером на бан.

По поводу вордтрекера, я слышал, что иногда он выдаёт данные отличающие от реальных на 1-2 порядка, кроме того, объёмы статистика гугля на несколько порядков больше, так что она будет понадёжнее, и бесплатно к тому же.

Если есть выделенный сервер, решение с нескольким IP от MegaS, мне нравится больше, т.к. оно в curl добавляется одной строчкой и его можно использоват как для гугля, так и для яху, так и для и алексы и т.п. Это если автоматизировать процесс до конца, те же 25000 ключей проверить за 2 часа вполне можно на ~12 IP-шниках. 1 запрос в 3,5 секунды (от 1 до 4 секунд задержка, 1 секунда на закачку) - это 1000 запросов за час, 2000 за 2, и при 12 IP должны спокойно обработаться. Если подождать подольше то 5 IP вполне достаточно.

А сделать ввод капчи, я предлагал для тех кто выделённого сервера не имеет, а сидит на денвере, например, или шаред хостинге.

Дополнение, описанный мной выше подход, подразумевает один юзер агент на всё время работы этого потока, иначе от рефера толку не будет.

Конечно. При такой нагрузке посетителей превышение одним умноженное на кол-во других может выбить сервери из колеи

Это вряд ли, то что я описал - всего 4 запроса в секунду. Например, пиковая нагрузка которую выдерживает MSN-поиск - это 1000 запросов в секунду на один кластер, а у них там не один десяток кластеров стоит.
Если имелся ввиду собственный сервер, то 4 запроса в секунду это тоже фигня, если правильно написаны скрипты.

Насчет рефера… Сейчас под рукой нет оригинального скрипта, только уже сильно переделанный и я не помню было ли это сразу (кажется все-же было) или я добавил… Каждый запрос к гуглю на логин и на парсинг передает ему рефер. Типа сначала зашел на гугль и только потом уже залогинился. Или сначала зашел на гугль и только потом уже послал поисковый запрос. Естественно, с получением, сохранением и возвращением “кукисов” - если их и нет на самом деле - это не беда, а вот если есть - это надо делать обязательно и curl это позволяет…

Насчет одного юзер-агента на поток - разумеется. И один логин-пароль на поток. Чтобы максимально приблизиться к среднестатистическому пользователю. Вы же, даже имея несколько разных гугловых аккаунтов, не перелогиниваетесь постоянно из одного в другой, в третий и так далее…

А вот насчет многих айпишников (вариант MegaS) - читайте мой комменатрий к нему. БЕЗ СПЕЦИАЛЬНОЙ ТЕСНОЙ БЕСЕДЫ С АДИМИНАМИ СЕРВЕРА ничего не выйдет, хоть ты обпокупайся этими айпишниками.
Только что проверил на одном их своих дедиков в “базовой” конфигурации которого есть 5 адресов. Когда с него обращаешься куда-либо наружу, все запросы идут от айпишника, привязанного к первой сетевухе (или к первому порту, если она многопортовая).

MegaS не ответил, так что я не могу знать как оно реально у него сделано. Но описание технической сложности было мною приведено для его варианта не просто так… Я, так уж вышло, системный администратор… Ну и еще про стоимость почитайте.

Так что “имея выделеный сервер” - я бы вам посоветовал купить прокси чекер (например Razor5 - я им доволен, сслок не даю чтобы за рекламу не заанил ПрофитХантер Это обойдется в тридцатку. После этого пишется многопоточный парсер, каждый поток которого уходит через проверенный чекером прокси - вот тогда скорость будет расти пропорционально накопленным в базе прокси-серверам. Только не стоит увлекаться новинками 5-го PHP типа мультикурла - реально он ждет ответа от самого медленного запроса и только потом продолжает работу. Надо именно много потоков, в кадом из которых по обычному curl используется. Тогда хоть в 20, хоть в 200 потоков можно работать, лишь бы канал был от выделенного сервера достаточно широким (а то есть и такие “дедики”, которые на 3 мегабитах подключены, но это не серьезно - я так дома через Стрим сижу)

В общем я вижу интерес к теме все-таки довольно большой. Наверное придется-таки скрипт дорабатывать и публиковать… Может быть…

Вот здесь посмотрите, как работать с несколькими IP на PHP:
http://masterhost.ru/support/doc/php/
ищете в тексте упоминание socket_bind, второй пример то что вам нужно. На PHP я это не применял, но на C мы с этим работали, для запросов к Yahoo XML всё прекрасно работало, даже вроде IP-шники были из одной подсети, но точно не помню, кстати говоря логин там был один на все IP, но это специфика Yahoo XML. Админ тут может и нужен, но только чтобы привязать к любой из имеющихся сетевых карт несколько IP, всё остальное делается из PHP.

Выделенного сервера у меня нет, а с проксями я работать не люблю, уж больно часто они в даун уходят, т.к. в текущий момент со скриптом автивно не работаю, то пока мне это не нужно, когда понадобится, я просто добавлю в него отслеживание ввода капчи и её непосредственный ввод, думаю временно это меня устроит.

Успеха в работе над скриптом.

еще вариант: купить у меня базу http://actualkeywords.com/ - там конкуренция для 180 000 000 кивордов уже собрана

да, это процесс не быстрый, но мы сделали это и периодически обновляем. малыми средствами тут не обойтись кстати, стопудов!

Коллеги!
Мы несколько увлеклись процессом и забыли откуда ноги растут…

Напоминаю, что речь шла о БЕСПЛАТНОМ скрипте, который хотелось бы научить работать без бана гугла. Выделенные серваки, покупки айпишников пачками, база за 300 с лишним уев, платный прокси-чекер - ЭТО ВСЕ НА САМОМ ДЕЛЕ ВЕЩИ НУЖНЫЕ, но они не имеют отношения к теме этой дискуссии!

Давайте не будем забывать, что большинство читающих этот блог все-таки начинающие. Во всяком случае, я так для себя определяю направленность ProfitHunter’a - а уж он меня поправит если что. И тут рассказывается все ДЛЯ НИХ. И при этом в такой форме, чтобы ОНИ могли этими советами воспользоваться. Бесплатно зарегистрироваться на 30-day Challenge, получить бесплатную софтинку GTrends Made Easy (царство ей небесное) или Market Samurai. Найти относительно недорогого хостера и так далее и так далее… Чтобы им было с чего начинать.

А вот уже поднабравшись опыта (читай - “и понабивав шишки”) и заработав первые денежки они уже смогут ими распоряжаться. И покупать базы, и нанимать проф-программеров, и брать сервера с пачками айпишников и многое другое. Но на том этапе, на котором они сейчас находятся, им был предложен бесплатный скрипт, который работает, но имеет ряд ограничений (ну все же на халяву!) И речь только о том и шла: можно ли, реально ли, целесообразно ли предпринять некие действия для улучшения работы этого скрипта. Да так, чтобы он все-же остался бесплатным. Ну или относительно недорогим.

Давайте на этом и остановимся? Если кому-то есть что сказать ПО ТЕМЕ, а не просто проспамиться - велкам…

то al13: ты пишешь “Вот здесь посмотрите, как работать с несколькими IP на PHP: http://masterhost.ru/support/doc/php/
ищете в тексте упоминание socket_bind”
Читаем внимательно:
—первый пример (сам код я естественно тут писать не буду) —-
Использовать функцию socket_bind: При использовании PHP-интерпретатора как модуля Apache (по умолчанию на виртуальном хостинге именно так) работа с сокетами запрещена, поэтому следует использовать свой PHP-интерпретатор, собрать который можно по инструкции при конфигурировании обязательно указав ключ –enable-sockets.
———второй пример—————-
C помощью curl_setopt: В этом случае также потребуется собрать свой интерпретатор PHP, указав при конфигурировании ключ –with-curl=/usr/local.
————————————–
То есть, оба варианта подразумевают ПЕРЕКОМПИЛЛЯЦИЮ интерпретатора PHP, что вам ни один обычный хостер просто не позволит. Значит для этого вам нужен или виртуальный выделенный сервер (VDS or VPS) или настоящий выделенный сервер (дедик, dedicated) Что автоматически подразумевает ежемесячный платеж от 30$ для первого и до 100$-300$(и выше) второго…

Еще раз повторю - вариант СО МНОГИМИ КУПЛЕННЫМИ ЙАПИШНИКАМИ больше не рассматриваем, он в контексте обсуждаемой ситуации никак “не танцует”!

Кстати, вышеупомянтуая “инструкция” по которой можно собрать “свой собственный” интерпретатор PHP относится к акаунтам с полноценным shell-доступом. Что опять же, далеко не является обычной услугой хостера (читай - за это надо заплатить больше)

to Savos:
Вы не правильно поняли второй пример, если на хостинге работает ваш скрипт (в текущем виде), то это уже автоматически означает, что PHP был собран с ключом –with-curl=/usr/local, т.е. этот ключ означает что подключается именно curl, а не поддержка нескольких IP. Так что в данном случае требование не наличие shell, а именно наличие curl’а, если он есть то и второй пример будет работать. Между прочим сокеты тоже обычно включены, а то что они там рекомендуют PHP пересобрать, это по-видимому фишка masterhost, это не мой хостинг, просто первый попавшийся пример.

Между прочим, то что вы используете функцию iconv, она является ещё менее стандартной чем наличие curl, у меня например её на хостинге нет, и мне пришлось написать затычку, чтобы запустить скрипт.

PS. Я всегда ищу хостинг (шаред) с наличием шелла, у меня на хостинге он есть, но этот никак ещё не означает что я могу пересобрать PHP, потому что наличие шелл ещё никак не означает наличие C и команды make. А шелл в основном нужен для работа с БД при больших объемах, gzip, tar и т.п., ну по-крайней мере мне для этогою

Забыл написать, вариант с несколькими IP прекрасно “танцует”, если хостер выделяет под каждый домен свой IP, такой вариант очень редко встречает на шаред хостингах, но в принципе, он возможен. И второй вариант, когда вы сами купили IP под какие-либо домены, потому что вам на них понадобились анонимные фтп, то вполне эти IP использовать под наши цели.

PS. Вы меня опять не правильно поняли, я вас не агитирую на использование нескольких IP, я просто пытался вам показать что технически это легко можно сделать. Лично я за вариант, с вводом капчи, но похоже он тоже вам не нравится, хотя для бесплатного скрипта, это как раз то что нужно.

Ок, согласен, принято к рассмотрению. Есть у меня сервер с пятью айпишниками - попробуем-с…
Насчет капчи - этот вариант подходит для так называемого “полуавтоматического” парсинга, когда вы постоянно присутствуете и следите за работой скрипта и вводите капчу когда надо. А если скрипт работает удаленно и просто пишет все в лог? А если вы запустили скрипт на ночь и пошли спать, в надежде что утром у вас будет большой объем данных для творческого осмысления, а скрипт остановился на капче через пол-часа и всю ночь простоял?
так что капча “в топку” - ее просто не надо допускать. D@nil выступает за прокси, вы с MegaS’ом за покупные айпи - эти варианты и будем рассматривать. По таким критериям как общедоступность, легкость в настройке и ипользовании, гарантия от бана (кстати тут прокси предпочтительней на мой взгляд), работоспособность (вот тут ваш вариант может дать фору проксям, ибо они обычно тормозят). Ну и вопрос цена/производительность остается актуальным. Тут звучала цифра в 25000 поисков в сутки. В зависимости от того, сколько понадобится этих самых прокси и айпишников для гарантированного многообразия и непопадания в бан. При заданной общей производительности. В любом случае уже думаю всем ясно, что совсем бесплатно этого не достичь - так что поднимаем планку и рассматриваем платные варианты. Тут прокси выгоднее, так как скрипт чекера покупается один раз, а за дополнительные адреса надо платить. но… будем проверять…

Да вариант с капчей полуавтоматический, но если рассматривать скрипт именно для начинающих, то он предпочтительней, т.к. он не требует никаких дополнительных затрат, даже собственного хостинга :), т.к. вполне достаточно денвера. Кстати капчу всё равно надо бы отслеживать, даже если её не вводить, для того чтобы если появилась капча, не долбить гугл ненужными запросами и выдать информацию об увеличении времени задержки.

И ещё один момент, если появилась капча при работе скрипта, то просто так вы её не снимете, если даже введёте её в браузере, скрипт всё равно дальше не заработает из-за юзер агента, т.е. разбанится только тот браузер, где была введена капча. Это по моему опыту работы, может это и не во всех случаях, не знаю.

В принципе, вариант который вы описывали выше, сначала проверить на конкуренцию (было бы неплохо здесь ещё проверку для yahoo добавить, чтобы не было случаев, как описывал profithunter, сначало ссылок несколько десятков тысяч, а через 2 недели несколько миллионов), а затем прогнать через гугль тренд, является оптимальным, если поставить довольно большую задержку, то с одного IP и в один поток (если не использовать юзер агент), можно прогнать тысяч 10-20 за сутки при средней задержке в 4-8 секунд. В этом случае и капча не нужна.

Я как раз сейчас проверяю именно величины этих “допустимых” пауз и их рандомизацию. Это требует времени, так как при каждом пропущенном бане ребуется время на восстановление работоспособности. Если приближаться к этому допустимому порогу “снизу”. Если же идти к нему “сверху”, то есть брать заведомо разрешенные большие паузы и постепенно их снижать, то сейчас у меня работает один вариант с рандомными паузами от 6 до 10 секунд и периодической вставкой между каждыми 20-30 запросами (рандомной же) еще одной дополнительной паузой от 6 до 13 секунд. То есть при самом “долгом” варианте это будет:
- пауза в 13 секунд после каждого 20-го запроса
- пауза в 20 секунд между самими запросами
Итого на 20 запросов (без учета времени одидания ответов сервера) будет тратиться 413 секунд. При работе с Денвера время ответа от Гугля у меня выходит еще по 2-3 секунды на запрос. В целом мы имеем 473 секунды в самом худшем случае. То есть порядка 3 запросов в минуту. Это уже быстрее чем в ручном режиме проверки (ведь вручную надо обратиться как минимум два раза к гуглу и два раза к гугл-трендсу на каждый один кейворд - то есть 13 запросов в минуту сделать не каждый сможет, а делать их безошибочно на протяжении сачов - и подавно). Но еще пока недостаточно быстро. Ведь в сутки пока выходит реально проверить только около 4500 кейвордов. Но это уже что-то. И абсолютно бесплатно. Но вот удастся ли снизить общие паузы в два с лишним раза, чтобы выйти на 10000 в один поток и без бана - это вопрос времени. Даже если снизить их в полтора раза, то 6-7 тысяч с одного Денвера тоже весьма неплохо. А дальше каждый такой поток “тиражируем” одним из обсуждаемых тут способом (да и скорость отклика Гугла на сервере будет гораздо меньше чем при работе Денвера на локальном компе). Так что общая заявленная выше планка в 25000 в сутки технически абсолютно не проблематична. Если для этого понадобятся “всего” 4-5 потоков, то она будет и довольно низкобюджетна.

ProfitHunter, тебе надо форум делать а то эта страница превратится в бесконечную ленту

Интересные данные, спасибо за инфу.

Savos, заспамят форум

Но читать вашу дискуссию реально интересно (несмотря на то, что большинство моментов мне непонятны ).

На базе этой ветки был опубликован мастер-класс на SEOnews.ru
Всем спасибо за живое обсуждение!
ProfitHunter’у отдельное спасибо
Почитать и сравнить, а также оставить отзывы можно тут
http://www.seonews.ru/masterclass/114/

Пользуйтесь seumka.ru и будет счастье. Пока вроде бесплатно

актуально, спасибо за инфу