Ошибка SE::Google Капчу так и не принимает, но в браузере выдаёт результаты с первого же токена

[apistudio.ru]

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

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

Также запускал шаблон в 50 потоков для проверки всего пакета проксей, что у меня был - серп всё так же отдаётся после первого же получения токена от ксевила. На этом же пакете проксей апарсер некоторое время собирает выдачу, и, судя по логам, по прежнему не принимая токен решенной ксевилом капчи, решая затем графическую капчу и в результате банит прокси. Собираются результаты за счёт тех проксей, которые какое-то время отдают данные сразу и без капчи. Понятно, что весь пакет прокси (500 штук без ротации) довольно быстро уходит в бан, и парсинг полностью останавливается.

В шаблоне подгружается профиль с куками авторизации гугла на его почту и настройкой выдачи 100 результатов на страницу. Это сделано больше для удобства записи видео (меньше диалогов с просьбами от гугла войти в профиль, подтвердить куки, выставить в настройках количество результатов и т.д.), потому как и без авторизации результаты те же – токены от ксевила принимаются с первого же раза и серп отдаётся. Шаблон работал несколько суток, ошибок было не много, ~95% успехов после решения капчи.

Версия апарсера, на которой проводились последние тесты - 1.2.1604, количество результатов – 1 страница со 100 результатами, локация – Нью-Йорк.

Предполагаю, что-то всё же изменилось на стороне гугла, и прошу специалистов апарсера глянуть ещё раз на парсер – возможно, получится наладить более корректную его работу. Прокси и шаблон с удовольствием предоставлю, если они понадобятся.

 

[ddeel]

было бы не плохо если была возможность в отдельную папку закинуть куки отдельными txt файлами 1 файл 1 кука, и при парсинге использовала бы их

 

[Support]

На видео выше показан парсинг гугла через браузер, насколько я понимаю, в один поток, и при этом используется авторизация. Я взял IP, который предварительно заспамил парсером до постоянных рекаптч, взял ссылку на результаты поиска в гугле (аналогичную той, которая используется в парсере) и проверил. Если открывать ссылку в браузере, где есть авторизация - никаких рекаптч, сколько бы я это не делал. Если в инкогнито - сразу рекаптча. Поэтому на видео получается вполне очевидно, что рекаптчи разгадываются сразу, т.к. используется авторизация.
В парсере авторизации нет. При этом, во время тестов на наших прокси (которые в целом довольно заспамлены) разгадывание рекаптч происходит иногда с первого раза, иногда нет, скорее всего зависит от конкретного IP. Т.е. какой-то очевидной проблемы не видно.
Кроме этого Гугл сейчас вполне нормально парсится и без разгадывания.

Мы еще продолжим тестировать и при нахождении каких-то проблем - обязательно устраним их в следующих версиях.

 

[apistudio.ru]

Благодарю саппорт за ответ и анализ моих тестов.


Но, со всем уважением, никак не могу согласиться с тем, что проблем с парсером гугла нет – ранее результат решения капчи апарсером принимался и гугл отдавал серп, теперь же парс гугла идёт исключительно перебором проксей и скорость парсинга, соответственно, упала в разы. Вот скрин с текущей скоростью на самом дорогом пакете прокси от апарсера в 500 потоков:


Версия апарсера, на которой проводились последние тесты - 1.2.1610, количество результатов – 1 страница со 100 результатами, локация – Нью-Йорк, запросы без операторов. С корректным разгадыванием капчи ксевилом мои результаты были в районе 3600-4000 запросов в минуту, то есть скорость была более, чем в 10 раз выше. Отсюда, собственно, и моя настойчивость в отслеживании ситуации с гуглом и в этой теме, конечно же, к этой скорости очень бы хотелось вернуться.

Касаемо авторизации – я уже писал в стартовом топике, что я не увидел её влияния на решение капчи, без неё серп гугла после решения капчи отдаётся точно так же, как и с ней. Куки авторизации я подсовываю гуглу только лишь для того, чтобы не кнопать на разного рода диалоги, и выводить 100 результатов на страницу, а не 10 по дефолту.

Благодаря ответу саппорта я действительно увидел ещё одну проблему - капчу начинает гонять по кругу (с выбрасыванием графической капчи) в том случае, если к гуглу идёт запрос НЕ с главной его страницы после ввода запроса в поле поиска, а после прямого запроса с параметрами, как делает апарсер (GET(…): https://www.google.com/search?q=what+is+inflammation+of+the+stomach&ie=utf-8&oe=utf-8&num=100&hl=en&lr=lang_en&gl=US&uule=w+CAIQICIfTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw==). В этом случае ксевил действительно не справляется со своей задачей, капча корректно не решается. Тут как раз и проявляется эта проблема, о которой писали в этой теме. Судя по всему, здесь гугл редиректит на какую-то «необычную» капчу, которую ксевил решить уже не может, вероятно, какой-то частный случай для запроса серпа прямым запросом GET, подозрение на автоматизацию. Всё это есть на этом видео, здесь сделал без авторизации.

Но эта самая «необычная» капча при этом прекрасно решается вручную и тоже с первого же раза (этот момент есть на видео, опробовано мной несколько раз). Я отпишусь на форуме ботмастера по этому вопросу, возможно, это удастся как-то решить. Но тут вот какой момент, скорость исправления своих багов ботмастером всем известна, тянуться это будет скорее всего долго, и это ещё в том случае, если удастся доказать наличие проблемы на стороне его софта, до этого он эту ситуацию уже отрицал.

Отсюда вытекает БОЛЬШАЯ прям просьба к специалистам апарсера посмотреть на эту ситуацию, возможно, получится найти решение до коррекции ксевила ботмастером, если она, конечно, будет. На мой непрофессиональный взгляд одно из решений видится таким: надо бы выявить те отличия, которые есть у прямого GET-запроса к гуглу с редиректом на капчу «необычную», которую ксевил не решает, и случаем, когда поисковый запрос сначала вводится в поисковую строку на главной странице https://www.google.com/ и редирект идёт на страницу с «обычной» капчой, которую ксевил решает корректно и с первого же раза. По моему скромному разумению, в этом случае можно было бы передавать в GET-запросе те куки/параметры, которые делают капчу «обычной», и которую ксевил решает без проблем – тогда удастся восстановить работу парсера с решением капчи.

Хотя более чем уверен, что специалисты апарсера увидят и какое-то более эффективное решение, им виднее))