Не первый раз возвращаюсь к этой проблеме и не первый раз она меня ставит в тупик. Есть некий код, чекающий прокси: http://pastebin.com/KpeJcpRE Тестировал на 5-15 потоках на хостинге и на локалке. Причем результаты совершенно разные, на хостинге скрипт пропускает намного больше гудов, чем на локалке (учитывая, что на хостинге канал шире намного). Прочекал эти же прокси на C++ чекере: 100% good, не поленился через браузер прочекать, аналогично 100% гудов. Результаты в пропорции такие: Code: Total: 5 [PHP] Host: 1 valid [PHP] Localhost: 2 valid [C++] Localhost: 5 valid Причем php чекер ведет себя достаточно хаотично, то видет гуды, то нет. Это никуда не годится. Суть вопроса: реально ли вообще работать с прокси + многопоток на PHP?
Неоднократно работал с мкурлом, он не очень стабильный, нужно до настраивать сервер, у апача есть тест на потоки, я уже не припомню название утилиты. Gifts вам может помочь в этом вопросе если зайдет в тему) ЗЫ $th = 50; //threads это много, не превышайте 10 потоков для более менее корректной работы. И еще совет: PHP: $rawdata = curl_multi_getcontent($curl_arr[$i]); //get returned data from curl handle if($rawdata != '') echo $proxy.':'.$port.' valid <br/>'; для каждого псевдо-потока сделайте отдельную переменную, или ключ массива.
Для чего это делать? Не очень понятно. По-поводу потоков апача интересно было бы прочитать. PS: взял впс, запустил чекер там - 5 гудов. На локалке винда, там редхет.
AnGeI Я должен уточнить некоторые вопросы: 1) Прокси точно все HTTP? Возможно C++ чекер более "продвинут" нежели этот скрипт и чекает по разным протоколам 2) Вы пишете данные для дебага в файл VERBOSE.txt. Вы его читали? Для обеих систем? В какой момент происходит затык при обращении к серверу? 3) Какие расстояния между вами-прокси-яндексом, сервером-прокси-яндексом. Возможно просто коннект вокруг всего земного шара дважды - слишком быстро для прокси. Нередко видел прокси с временем коннекта >20 секунд. Я не знаком с реализацией таймаутов в курле, но гуглятся проблемы с этим. В обычных чекерах идет 3 подключения на проксю, чтобы избавиться от погрешностей передачи и временной не работоспособности коннекта. Прокси-то скорее всего паблик. 4) Сервер - ваш? Просто широкий канал на хостинге - не говорит ровно ни о чем Вообще, рекомендую поискать нормальную реализацию чекера на сокетах и селектах. Такая комбинация позволит видеть, где и почему что-то сломалось. Ну и если совсем точно хочется - делайте дампы wireshark/tcpdump и сравнивайте ваши комбинации
Прокси HTTP(S). Чекер на С++ работает не через курл, но именно для HTTP проксей. Была такая проблема ранее) VERBOSE.txt Для локалки: http://pastebin.com/8WBNmvsB 3/6 валид, из невалида только 1 отказ самой прокси (код 403), остальным сервер (site.de) просто отвечал 403 Forbidden. Итого получается 5/6 валид. Для виртуального сервера судя по конфигу все аналогично, хоть и он немного отличается формой записи http://pastebin.com/aDN3yA5H Хостинг обычный: вообще не выдал гудов, но по логу видно что они есть, но их меньше http://pastebin.com/aDN3yA5H Чекер проксей на С признал 1 проксю невалидом (именно та, которая 403 отдает). Чекнул эту же проксю в браузере - все работает, скорее всего она контент отдает, но статус нерабочий посылает (если такое возможно). Тоже над этим задумался, прокси/сервер/хостинг Германия. Сайт к которому коннектился (site.de) и искал слово Willkomen (оно там имеется в контенте). Ибо изначально задумывался как чекер не только самой прокси, а и на бан сайта к которому коннект. Прокси паблик, завтра на приватных и с большим колличеством проксей попробую еще. Понятное дело, что в таких полевых условиях нормально не получится это все проверить без погрешностей всякого рода помехов. Виртуальный сервер и хостинг обычный. Время выполнения везде разное, максимум 15 сек из 30 предусмотренных, быстрее всего на vps (до 10 сек). Когда-то пробовал тестировать на сокетах, там действительно все более прозрачно, с курлом неразбериха полная без VERBOSE.Теперь понял, что чек проксей и чек запрашиваемого контента таки разные вещи (чекер на С контент не проверял).
AnGeI Судя по логам скрипт который вы запускаете и скрипт, который вы выложили в первом посте - разные. Либо дефолтное поведение PHP + Curl изменилось с версиями. Уточняю - есть ли в ВАШЕМ скрипте строка вида Code: curl_setopt($curl_arr[$i], CURLOPT_HTTPPROXYTUNNEL, True); Если нету - тогда добавьте со значением False. Другая возможность - вы пытаетесь подключиться через прокси к сайту по протоколу HTTPS (и когда меняли адрес сервера заменили и порт). То тут могу сказать следующее - HTTP прокси не умеют подключаться к таким сайтам. Для этого у них также должна быть включена поддержка HTTPS, а именно метода CONNECT
Да, все верно, была эта строка, значение true. Заменил запустил на локалке и на сервере, время выполнения сократилось, все 6 проксей валид. Т.е. контент был получен. Чекер на С определил только 5 валидных проксей. VERBOSE с сервера: http://pastebin.com/6b4ug0tg Это я учел, к сайту по http подключался. На php.net написано: Code: CURLOPT_HTTPPROXYTUNNEL TRUE to tunnel through a given HTTP proxy. Теперь все вроде-как отлично. Что все-таки значит эта строка, я так понимаю она включала проверку ответа прокси сервера?
AnGeI Я не знаю как хорошо вы разбираетесь в HTTP протоколе. Краткое изложение - http прокси бывают обычные и https. К первым надо обращаться как к обычному веб-серверу (GET/POST запросы), вторые поддерживают метод CONNECT. Первых гораздо больше чем вторых. А вот ограничений у HTTPS прокси - гораздо меньше. В описании CURLOPT_HTTPPROXYTUNNEL важные слова не HTTP Proxy, а "tunnel through". То есть этот параметр заставляет обращаться к прокси с помощью метода CONNECT, который не все поддерживают Почитайте еще: http://www.freeproxy.ru/ru/free_proxy/faq/what_is_connect_proxy.htm Возникнут вопросы - обращайтесь.
barnaki необязательно, но HTTP прокси без метода коннект поддерживающая HTTPS это: a) совсем редкое сочетание б) к https серверу получается подключаетесь не вы, а прокси. Чем именно грозит? От вас до прокси данные идут незашифрованными, нет гарантии что удаленный сервер это тот, к которому вы подключаетесь (проверку сертификата, SSL handshake осуществляет прокси, вы на это не можете повлиять), браузер скорее всего через такую прокси не пойдет.
какой оптимальный вариант для работы крулом с https сайтом. при нужде часто менять ip адреса. лист https прокси ?
Я немного не понял, вот к примеру есть 2 вида прокси http https если я чекаю так PHP: $ch=curl_init("google.ru"); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_VERBOSE, 0); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_TIMEOUT, 15); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT,10); curl_setopt($ch, CURLOPT_PROXY, "$proxy"); $x=curl_exec($ch); curl_close($ch); то http прокси нормально откроет гугл а https нет и чтобы проверить работоспособность https прокси мне нужно чекать так PHP: $ch=curl_init("google.ru"); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_VERBOSE, 0); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_TIMEOUT, 15); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT,10); curl_setopt(ch, CURLOPT_HTTPPROXYTUNNEL, True); curl_setopt($ch, CURLOPT_PROXY, "$proxy"); $x=curl_exec($ch); curl_close($ch); правильно, или я не так понял
qaz уточню сразу, чтобы не получилось недопонимания. Бывают четыре вида проксей 1) Только HTTP. Проверять их надо первым кодом 2) Только HTTPS с методом CONNECT - проверять их надо вторым кодом 3) HTTP+HTTPS (с методом CONNECT) - проверять достаточно вторым кодом, будут открываться все сайты. Но и первый при обращении к обычным сайтам (не-HTTPS) не вызовет ошибки 4) HTTP+HTTPS без поддержки метода CONNECT. Первый код не вызовет ошибки при обращении к любым сайтам. Второй код - выдаст ошибку, что прокси нерабочая 4 вид - почти не встречается, но тем не менее бывает полезен. В браузере такая прокси вызовет ошибку доступа скорее всего Алгоритм действий. Проверяем все прокси вторым кодом, если работает - получили прокси. Если не работает - проверяем первым кодом. Если работает - прокси HTTP. Если нет - прокси нерабочая.