смена прокси при бане и т.п.

Как сделать так, чтобы программа автоматически меняла прокси при вылете капчи/бане? Или было бы лучше, чтобы можно было задавать условие, к примеру если определенная граница окажется пустой (или нет) автоматически бы брался другой прокси из списка (а тот опционально удалялся из списка, или txt если открыто из файла).

 

Ребят, ну почему молчим?! Нашел похожий топик, человек предлагал похожий вопрос, и тогда ответ был таков

топик за 2015 год, а вопрос актуален и по сей день. Подскажите, есть ли на данный момент способы решения?

 

Почему не подходит вариант со списком прокси? Забаненные прокси из него автоматически удаляются.

 

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

Приведу пример:
допустим граница парсинга 1 настроена на текст, который появляется на странице, когда вылетает капча.
В настройках прокси, выставлено что-то вроде: "в случае если граница 1(2,3 - опционально) окажется не пустой - менять прокси. (и удалять его из списка опционально).
далее будет перезагружаться этот же документ но уже с новым прокси (его также менять и удалять если с ним граница 1 будет не пустой, и так дальше по циклу пока граница 1 окажется пустой, в таком случает документ успешно загрузится и этот прокси остается в списке, но для следующего документа, как обычно будет выбран следующий по списку прокси и т.д.

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

 

Попробовал, вроде срабатывает, но прокси не удаляет, как сделать так, чтобы прокси с которыми не грузится документ (после выставленных в окне ctrl+h числа попыток), удалялись из списка?

 

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



При автозагрузке списка прокси они будут проходить проверку на работоспособность.

 

Это, кстати, описано в хелпе Ссылки недоступны для гостей

 

Мануал изучал и насколько я понял, то он выполняет перепроверку ВСЕГО списка проксей после определенного (выставленного) числа спаршеных документов. У меня идея немного другая, в режиме реального времени по ходу парсинга, "выкидывать" прокси поштучно, которые не удовлетворили условию (с этим прокси граница n оказалась пустой/не пустой, число повторных попыток превысило определенный порог (например 5 (выставленный в ctrl+h) и т.д.). При этом можно переходить к следующему документу, а тот который "грузился" невалидным прокси добавлять в конец списка парсинга (например если выставлена галочка "пытаться повторно загружать документы" в окне ctrl+u и т.д.). Таким образом не придется делать много запросов к целевому серверу..

 

Ваша проблема надуманная. Пожалуйста, перестаньте ее мусолить.

 

Вот это и есть то что нужно, признаю не заметил этой опции. А чтобы показали пришлось помусолить ). Справедливости ради, отмечу что в мануле скрины еще без этой функции, а для непосвященных довольно таки сложно разобраться в тонкостях. Спасибо вам.

 

Информация добавлена

Ссылки недоступны для гостей

 

Добрый день. На сколько я понимаю, проверка прокси происходит через библиотеки CIS или WIN. Сайт не пускает на нужный раздел через библиотеки совсем, только WEBappECF. Соответственно проверка делается через другие разделы и заключается в данном случае только в простой проверке работоспособности того или иного прокси адреса. При парсинге часть адресов сразу может попасть в мягкий бан. Как задействовать проверку списка прокси через WEBapp или что можно еще предпринять в подобном случае?

 

Здравствуйте.

Скорее всего нужно просто наладить загрузку страниц данного сайта через Clever Internet Suite (CIS).

Приложите под HIDE с POSTCOUNT 10000 (чтобы увидел только я) ваш файл проекта со списком прокси.

 

Скрытое содержимое:

**Скрытое содержимое: доступно при наличии 10000 постов.**

Добрый день. В архиве кроме проекта дополнительно вложил результат парсинга. Там есть две ошибки. Все что записывает в первый столбец динамических границ перевернуто зеркально относительно остальных. Вернее сказать, все что в первой идет по порядку правил поиска замены, остальное наоборот. В этом файле есть только одно совпадение, но для остальных, если они будут попадаться на первый столбец, результат будет тот же. И еще строка, в которой ссылка на один товар, а данные подтянуты явно с другого. Увидел это только сейчас, поэтому не знаю, есть ли подобные ошибки еще. Прокси подтягиваются по ссылке, прописана в проекте. Спасибо.
P.S. В этом проекте почему-то вообще не происходит удаления не рабочих прокси серверов.

 

Проект не удаляет прокси сервера. Для подгрузки страниц используется WEBappECF. Включил в начало шаблона вывода строку [CHECKENTRY(<!--balance-entrance1-->)][DOCSOURCE][THENTEXT][PROXY_DELETE]. В проекте WEBapp дополнительно включил макрос записи содержимого страниц на диск SAVEHTMLTOFILE. Из него видно, что подобное вхождение в коде есть. В списке прокси, указал 1 попытку на неудачную подгрузку документа. Но как в мониторинге, так и в отчете видно, что прокси сервера не удаляются вовсе.

 

Нужно смотреть файл проекта. Так трудно угадать причину.

 

Файл проекта передал вчера, в нем немного отличается вхождение. Сегодня описал проблему подробнее. В отчете есть только ошибки отсутствия обязательной границы. На скрине видно, что из 5 прокси серверов 2 явно получают не то, но не отключаются.

 

Опция "обязательна" у выбранной вами границы парсинга прерывает выполнение макросов. Обойдитесь без ее использования в данном случае.