Случайно в логе наткнулся на такие строчки... см. скрин 1. капча распозналась правильно 2. парсер проигнорил результат капчи вообще и дальше пытается парсить туже фразу версия 1.1.436 beta
в логе отображается конечный урл редиректа, т.е. каптча используется, по логу видно что меняется прокси, т.е. предыдущий ответ был прерван и каптча могла израсходоваться впустую
опять логи анализировал, что-то прям таких ситуаций очень много. В одном задании в одной сессии насчитал 5 сбоев. вот ответ капчи - misoc (см скрин) далее происходит 2 обращения: 1. GET(156): https://ipv4.google.com/sorry/CaptchaRedirect?q=CGMSBA5hjKYY7KrjtwUiGQDxp4NLn9Q7FRwH***** 596 HTTPS(C) proxy error: Read error (0 KB) 2. Use proxy http://176.9.9.90:21880 GET(157): https://ipv4.google.com/sorry/CaptchaRedirect?q=CGMSBA5hjKYY7KrjtwUiGQDxp4NLn9Q7FRwH***** - 403 Forbidden (0 KB) При первом обращении используется тоже прокси, что и при получении картинки-капчи? При втором обращении используется прокси 176.9.9.90:21880 у которой реальный ip уже забанен гуглом и поэтому капча сгорает. Проблема в том, что разгадывание капчи для гугла как мы знаем очень дорогая штука по времени и ресурсам. Может быть для запросов типа https://ipv4.google.com/sorry/CaptchaRedirect* когда мы отсылаем разгаданную капчу гуглу использовать пул надежных сессий-проксей? или увеличить таймаут/кол-во попыток для той прокси с которой картинка была получена?
что значит надежных? если по прокси получена каптча она вроде уже надежная на тот момент времени? это возможно поможет только если прокси не умерла, а она скорее всего умерла раз была ошибка Read error
Еще странный пример. Я думал, что только при ответе 403 - это бан прокси гуглом и только при таком ответе прекращаются попытки взять выдачу с капчей, но почему прекращаются попытки отправить разгаданную капчу при ответе 503? - ведь гугл так не отвечает, это ответ "плохой" прокси? GET(1): https://www.google.ru/search?ie=utf...le.com;+expires=Tue,+29-Mar-2016+05:47:39+GMT - 503 Service Unavailable (1.73 KB)