Оплата прокси за запросы

За что вы платите

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

За одинаковым словом «запрос» могут стоять разные услуги. Обычный прокси передаёт обращения вашей программы к сайтам и возвращает ответы. Программа сама загружает страницы и извлекает из них данные. У сервиса сбора данных, который работает через API, в цену могут входить запуск браузера, преодоление ограничений доступа и подготовка готового результата. Поэтому сравнивать только цену запроса недостаточно — нужно учитывать, что за неё делает сервис.

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

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

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

Что сервис считает одним запросом

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

Соединение — канал, по которому программа общается с сервером. По одному соединению можно отправить несколько запросов. В HTTP/1.1 его можно использовать повторно, а HTTP/2 позволяет вести через него несколько обменов одновременно. Поэтому количество запросов, количество открытых соединений и число соединений, работающих одновременно, — разные показатели.

Есть ещё одна особенность HTTPS. При подключении через HTTP-прокси программа обычно отправляет команду CONNECT и создаёт туннель до сайта. Дальнейшие обращения проходят внутри него в зашифрованном виде. Прокси передаёт эти данные, но при обычной работе не видит содержимое отдельных HTTP-запросов. SOCKS-прокси тоже предоставляет соединение с нужным адресом; каждое действие программы не обязательно требует нового соединения.

Из-за этого некоторые сервисы используют слово «запрос» для соединения или другого события, которое может посчитать их прокси-сервер. Другие считают отдельные HTTP-запросы либо обращения к API. Число запросов в инструментах разработчика браузера поэтому не всегда совпадает с расходом в личном кабинете провайдера. По одной лишь поддержке HTTP, HTTPS или SOCKS5 определить правило подсчёта нельзя.

Перед покупкой большого пакета выполните небольшой пробный запуск. Запишите, сколько задач выполнила программа и сколько запросов списал сервис. Используйте ту же программу, протокол и настройки, с которыми собираетесь работать дальше. Проверка простым HTTP-клиентом не покажет расход браузера, который дополнительно загружает скрипты и другие части страницы.

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

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

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

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

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

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

Для каких задач удобна такая оплата

Мониторинг по расписанию

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

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

Сбор данных через API и каталоги

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

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

Аудиты сайтов и проверки в браузере

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

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

Как ошибки и повторы влияют на расход

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

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

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

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

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

Как рассчитать нужный пакет

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

Возьмём учебный пример. Программа проверяет 150 URL каждые 30 минут в течение 30 дней. Допустим, обычная проверка расходует один запрос по выбранному тарифу, а дополнительные попытки увеличивают расход на 5%. Все числа и цены в этом примере условные: это не результаты проверки провайдера и не тариф ProxyCompass.

В выбранном пакете остаётся запас в 23 200 запросов. Он пригодится, если нагрузка вырастет, пока пакет ещё действует. Ожидаемые повторы уже включены в 10 800 дополнительных попыток; этот запас не нужно снова называть расходом на те же повторы.

Допустим, пакет стоит $10. В нём 250 тысяч запросов, поэтому номинальная цена тысячи — $0,04. За весь пакет вы заплатите $10. Если умножить ожидаемый расход в 226 800 запросов на эту ставку, получится $9,072. Это стоимость использованной части пакета, а не сумма покупки: за фиксированный пакет всё равно уплачены $10.

Теперь предположим, что после дополнительных попыток программа выполнила все 216 000 плановых проверок. Тысяча выполненных проверок обошлась примерно в $0,0463: $10 ÷ 216 000 × 1 000. В этой сумме учтены и дополнительные обращения, и купленный запас. Если выполнено меньше проверок, делить расходы нужно на их фактическое количество.

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

Проверьте также, успевает ли программа выполнить работу. В нашем примере получается 7 200 проверок в день, или в среднем пять запусков в минуту. Но можно запускать все 150 проверок разом каждые полчаса, а можно распределить их по времени. Расход пакета будет одинаковым, если каждая проверка потребует принятого в расчёте числа попыток, а нагрузка в момент запуска — разной. Ограничение числа одновременных соединений или частоты запросов может помешать выполнить первый вариант расписания.

Как сократить лишние запросы

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

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

Уменьшение размера ответа не всегда экономит запросы. Если провайдер считает HTTP-обращения, короткий ответ может стоить столько же запросов, сколько длинный. Чтобы уменьшить их число, можно реже запрашивать неизменившиеся данные, использовать сохранённый результат или получать несколько записей за один вызов API. При этом сведения должны оставаться достаточно свежими для вашей задачи.

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

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

На что смотреть при выборе тарифа

Сначала убедитесь, что сервис подходит для ваших сайтов и программы. Важны тип прокси, доступные страны, работа сессий и возможность получить нужные страницы через предоставленные IP. Затем сравнивайте состав услуги: кто загружает страницу, запускает браузер, извлекает данные и повторяет неудачные попытки. Это помогает понять, почему цена запроса у двух сервисов различается.

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

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