Бесплатный тест прокси до 2 часов: что успеть проверить за окно

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

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

Почему поведение целевого сайта заранее не предсказать

Каждая площадка отвечает по-своему. Один каталог поставщика спокойно отдаёт код 200 на сорока запросах в минуту с одного адреса, соседний начинает возвращать 403 уже после десятого. Проверки живут на разных уровнях: частота обращений с адреса, набор заголовков, длительность сессии, порядок обхода страниц, скорость перехода между разделами. Комбинация правил у каждого сайта своя, снаружи она не читается.

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

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

Порядок запуска и подготовка до старта окна

Запуск теста укладывается в шесть движений: выбрать тип прокси под свой софт, зарегистрироваться в кабинете, отправить запрос теста из меню, указать свой адрес в настройках, активировать доступ, написать оператору логин и тип прокси. Первый шаг делается до всех остальных. Оператору уходит именно тип, и переигрывать его внутри окна затратно по времени.

Тип определяется программой. Браузеры, сборщики выдачи и парсеры карточек ходят по HTTP и HTTPS. Почтовые клиенты, десктопные программы с произвольными портами и скрипты на сокетах берут SOCKS. В пакете доступны SOCKS4 и SOCKS5, мы рекомендуем SOCKS5: он умеет резолвить доменные имена на своей стороне. Когда программа принимает оба варианта, берём доступ по протоколу SOCKS5 под свой софт и проверяем на нём.

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

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

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

Сообщение оператору пишем одной строкой и сразу с двумя обязательными полями: логин в кабинете и выбранный тип прокси. Полезно добавить третьим пунктом название программы и характер задачи. Так ответ приходит одним сообщением, и минуты окна не уходят на уточняющую переписку. Оператор при этом видит, что именно проверяется, и подсказывает по формату строки подключения для конкретного софта.

План на два часа: разбивка окна по отрезкам

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

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

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

Первые десять минут: авторизация и адрес на выходе

Начинаем с одного запроса. Пока не подтверждено, что трафик уходит через пул, все остальные цифры бессмысленны.

# адрес на выходе через привязанный в кабинете адрес машины
curl -s -x http://185.24.87.14:8000 https://ifconfig.me

# то же самое с парой логина и пароля внутри строки
curl -s -x http://user5521:[email protected]:8000 https://ifconfig.me

# SOCKS5 с резолвингом доменных имён на стороне прокси
curl -s -x socks5h://user5521:[email protected]:8000 https://ifconfig.me

Ответ должен показать адрес, отличный от адреса рабочей машины. Совпадение означает, что программа обошла посредник стороной: у части утилит настройка прокси живёт в отдельном профиле и не подхватывается глобально.

Код 407 в ответе указывает на авторизацию. Разбираем две причины по очереди. Первая: привязка в настройках кабинета оформлена на прежний адрес машины. Вторая: программа ждёт логин и пароль отдельными полями и ломает строку, склеенную через двоеточие. Обе закрываются за минуту, если знать, куда смотреть, и обе разбираются вместе с оператором прямо внутри тестового окна.

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

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

for i in 1 2 3 4 5; do
  curl -s -x http://185.24.87.14:8000 https://ifconfig.me
  echo
done

Разные адреса в выводе означают, что ротация работает и запросы расходятся по пулу. Одинаковые тоже нормальны: пул держится в районе 12 000 активных адресов, и повтор на коротком отрезке встречается.

Время отклика: замер идёт по своим целевым доменам

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

curl -o /dev/null -s -x http://185.24.87.14:8000 \
  -w "connect=%{time_connect} first=%{time_starttransfer} total=%{time_total} code=%{http_code}\n" \
  https://target-catalog.ru/catalog/section/17

Гоняем этот запрос 50 раз подряд с паузой в секунду и складываем строки в файл. Три величины из вывода работают на разные вопросы: time_connect показывает качество канала до узла, time_starttransfer показывает, сколько думает сам сайт, time_total идёт в расчёт потоков.

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

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

Поведение целевого сайта при росте частоты

Это главный замер окна. Сайт спокойно отвечает на редкие обращения и меняет поведение при переходе через свой порог, а порог этот у каждого свой. Поднимаем частоту ступенями и фиксируем, что происходит на каждой.

Каждая ступень держится по пять минут. Записываем код, размер ответа и время. Размер важен наравне с кодом: часть площадок отдаёт 200 вместе с укороченной страницей вместо каталога, и по одному коду такую подмену не поймать. Заголовок Retry-After в ответе с кодом 429 подсказывает паузу, которую сайт считает приемлемой, и эта цифра прямо переносится в настройки задержки в программе.

Полезно записывать и заголовки ответа целиком. Часть площадок выдаёт подсказки прямо в них: X-RateLimit-Remaining показывает остаток квоты, Server и Via намекают на промежуточный узел перед приложением, Set-Cookie появляется там, где сайт начал вести сессию. Такая мелочь потом экономит часы разбора уже на боевом прогоне, потому что причина отказов оказывается видна с первого взгляда в лог.

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

Потоки и формат выдачи: последний час окна

Удержание потоков программой

Проверяем, что программа реально держит заданное число соединений. Ставим 20 потоков, засекаем скорость. Дальше 50, 100, 200 и расчётная цифра. На каждой ступени смотрим три показателя: фактическую скорость в запросах за минуту, долю таймаутов, глубину очереди ожидания.

Скорость растёт с числом потоков до определённой точки, потом упирается в целевой сайт или в саму программу. Эту точку и фиксируем. Она чаще оказывается ниже, чем ожидает покупатель, потому что упор возникает на стороне площадки. В A-Parser лимит потоков задаётся на уровне задания, и подробности настройки собраны на странице про настройку A-Parser под работу с пулом. В сборках автоматизации счётчик потоков живёт в свойствах проекта, разбор есть на странице про прокси для проектов ZennoPoster.

Стандартные пакеты дают до 1000 потоков, корпоративный до 3000. Пакеты по потокам не складываются, поэтому цифру из теста сравниваем с лимитом одного пакета.

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

Формат выдачи и импорт списка

Последние двадцать минут отдаём выдаче. Список приходит в двух форматах: IP:PORT для работы с привязанным адресом и IP:PORT:LOGIN:PASS для доступа по логину и паролю. Забрать его можно ссылкой или файлом, оба варианта лежат в кабинете. Список обновляется в режиме реального времени.

185.24.87.14:8000
185.24.87.15:8000
185.24.87.14:8000:user5521:pf39kd
185.24.87.15:8000:user5521:pf39kd

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

Три цифры из теста и как они превращаются в пакет

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

Формула короткая: требуемая скорость в запросах за час умножается на медиану в секундах и делится на 3600. Скорость 18 000 запросов в час при медиане 3,2 секунды даёт 16 одновременных соединений. Добавляем треть запаса на пиковые моменты, когда часть соединений ждёт ответа, и получаем 21 поток. Такая цифра спокойно ложится в стандартный пакет.

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

Третья цифра сравнивается с лимитом пакета напрямую. Если тест показал 21 поток, стандартного лимита хватает с большим запасом. Если прогон уверенно шёл на 700 потоках и упирался в программу, разговор идёт про корпоративный вариант с расширенным лимитом. Трафик безлимитный на всех пакетах, поэтому объём выкачанных страниц в расчёт не входит совсем: считаем только скорость, потоки и срок.

Записываем цифры в тот же файл, где лежал план. Через неделю подробности стираются, и у покупателя остаётся общее ощущение вроде «работало нормально». Строка вида «медиана 3,2 с, успешных 97 процентов, потолок 240 потоков» возвращает к выбору пакета в любой момент, и повторное окно для этого уже не понадобится.

Чего в тестовом окне делать не надо

Первое: тратить окно на установку программы. Софт ставится и проверяется по прямому подключению заранее, внутри окна меняется одна строка настроек.

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

Третье: менять несколько настроек за один заход. Поменяли протокол, потоки и паузу одновременно, картина изменилась, причина неизвестна. Меняем по одному.

Четвёртое: гнать максимум потоков с первой минуты. Целевая площадка отвечает на такой заход отказами, замер срывается, и половина окна уходит на ожидание, пока сайт снова начнёт отвечать нормально.

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

Частые вопросы

Подойдут ли прокси под мою задачу?

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

Как запустить бесплатный тест?

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

Чем проверять прокси во время теста?

Для массовой проверки списка мы рекомендуем чекер от Zennolab, у него есть демонстрационная версия. Он проходит список пачкой и показывает отвечающие строки, время отклика и тип прокси. Точечные замеры по своему домену удобнее снимать через curl с ключом -w.

В каком формате выдаётся список прокси?

Форматов два: IP:PORT и IP:PORT:LOGIN:PASS. Забрать список можно ссылкой или файлом, оба варианта доступны в кабинете, и список обновляется в режиме реального времени. Импорт в свою программу стоит проверить прямо внутри тестового окна.

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