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

Как устроен адрес IPv4: 32 бита и четыре числа

Адрес IPv4 занимает 32 бита. Читать двоичную строку неудобно, поэтому её делят на четыре части по 8 бит и записывают десятичными числами через точку: 203.0.113.24. Каждая часть называется октетом и принимает значения от 0 до 255. Всего комбинаций получается около 4,3 миллиарда, и это полный запас четвёртой версии протокола.

Одной записи для маршрутизации мало. Рядом с адресом всегда идёт маска подсети, она делит 32 бита на две зоны: старшие биты отвечают за номер сети, младшие за номер узла внутри этой сети. Запись 203.0.113.24/24 читается так: первые 24 бита это сеть, оставшиеся 8 бит различают узлы, и в блоке помещается 256 значений. Первое значение блока занимает адрес сети, последнее уходит под широковещательную рассылку, остальные 254 можно назначить оборудованию.

Двоичная запись показывает логику деления нагляднее. Октет 203 в двоичном виде выглядит как 11001011, и таких групп ровно четыре, отсюда и берутся 32 бита. Маска /24 это 24 единицы подряд и 8 нулей в конце, в привычной записи она выглядит как 255.255.255.0. Маска /16 оставляет под узлы 16 бит и даёт блок на 65 536 значений, маска /8 отдаёт под узлы 24 бита. Чем меньше число после косой черты, тем крупнее блок и тем больше адресов внутри.

Часть запаса выведена из открытого обращения. Диапазоны 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 работают внутри локальных сетей, 127.0.0.0/8 замкнут на сам узел, блок от 224.0.0.0 отдан групповой рассылке. Домашний роутер раздаёт устройствам именно такие внутренние значения, а наружу выпускает трафик под тем адресом, который выдал оператор связи. Отсюда простой вывод: адрес, который видно в настройках ноутбука, и адрес, который видит сайт, обычно разные.

Подсеть, диапазон и автономная система

Адреса раздаются блоками, поштучно их не распределяют. Минимальный блок, который принято анонсировать в глобальной таблице маршрутов, это /24 на 256 значений. У блока есть владелец, он записан в базе регионального регистратора, и любой желающий поднимет эту запись через whois за секунду. Там же видно название организации, страну регистрации и контакты для жалоб.

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

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

whois 203.0.113.24 | grep -iE "netname|descr|country|origin"
dig +short AS64500.asn.cymru.com TXT

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

Что происходит с запросом: разбор по шагам

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

1. Программа читает настройки и видит адрес посредника, порт и способ авторизации. 2. Устанавливается TCP-соединение с посредником, например на порт 8080 для HTTP или 1080 для SOCKS. 3. Посредник проверяет право на доступ: сверяет адрес, с которого пришло подключение, либо принимает логин и пароль. 4. Программа сообщает, куда идти дальше. В HTTP это метод CONNECT с именем узла и портом, в SOCKS5 короткий обмен служебными пакетами с тем же смыслом. 5. Посредник открывает соединение с площадкой от своего адреса IPv4 и связывает два канала. 6. Ответ возвращается тем же путём, программа получает страницу, площадка записывает в логи адрес посредника.

# HTTP, авторизация логином
curl -x http://203.0.113.24:8080 -U login:pass https://example.com/catalog

# SOCKS5, имя узла разрешается на стороне посредника
curl --socks5-hostname 203.0.113.24:1080 -U login:pass https://example.com/catalog

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

Почему адресов IPv4 не хватает и откуда берутся новые

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

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

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

Серверный адрес и адрес домашнего провайдера: в чём разница

Вопрос звучит примерно так: «почему мой домашний адрес плохо тянет 20 потоков». Ответ упирается в происхождение адреса и в канал, к которому он привязан на уровне сети.

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

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

Зачем адреса IPv4 нужны в рабочих задачах

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

Вторая задача это несколько рабочих кабинетов. Формулировка от читателя обычно такая: «я веду 8 кабинетов одного бренда и хочу, чтобы каждый жил своей жизнью». Сервис сопоставляет вход по адресу, отпечатку браузера и сессии, поэтому кабинеты разводят по разным адресам и разным профилям браузера. Для команды это ещё и вопрос порядка: у каждого сотрудника своя точка выхода и понятный след в логах.

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

Пул адресов и одиночный адрес: что меняется в работе

Разница видна на цифрах. Формулировка из переписки с поддержкой: «я держу 20 потоков и упираюсь в лимит площадки уже на третьей минуте». С одним адресом 20 потоков дают 20 одновременных обращений с одной точки, счётчик площадки видит всплеск и включает защиту. Те же 20 потоков через пул расходятся по разным адресам из разных подсетей, и на каждую точку выхода приходится частота, которая не выделяется на общем фоне.

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

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

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

Как устроен доступ: привязка адреса или логин

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

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

# формат под привязку адреса
203.0.113.24:8080
203.0.113.61:8080

# формат с авторизацией
203.0.113.24:8080:login:pass
203.0.113.61:1080:login:pass

Протоколы доступны на выбор: IPv4 с HTTP и HTTPS, а также SOCKS4 и SOCKS5. Под парсинг, почтовые клиенты и произвольные протоколы удобнее работа по протоколу SOCKS5, поскольку он передаёт трафик любого приложения и умеет разрешать имена на своей стороне. Потоков в обычных пакетах 1000, в корпоративном до 3000, при этом пакеты по потокам не складываются: лимит считается по конкретному пакету.

Сколько адресов в пуле и как работает автоматическая ротация

Типичный вопрос перед покупкой: «сколько адресов я получу и как они меняются». В пуле около 12 000 активных адресов IPv4 и SOCKS5, онлайн в сутки держится примерно на этой же отметке, а список обновляется в режиме реального времени и открыт только клиентам сервиса. География это микс со всего мира, в списке представлены адреса из 200 с лишним стран, выборка по отдельной стране не делается.

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

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

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

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

Как понять, что прокси подойдут под мои задачи?

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

Что делать, если мой домашний адрес меняется каждый день?

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

Мне нужен доступ с двух машин, это возможно?

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

Чем проверить, что адреса работают?

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

Дальше по разделу «Основы» логично разобрать разницу между приватным доступом и общим пулом, затем посмотреть, как площадки смотрят на подсеть и диапазон, и закрыть тему протоколов через разбор HTTP, HTTPS и SOCKS. Когда теория уложилась, переходите к практике: страница про бесплатный тест до 2 часов показывает, что успеть проверить за отведённое время и на какие цифры смотреть в отчёте.

Источник: https://kupit-proxy-ipv4.ru/osnovy/chto-takoe-proxy-ipv4/

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

Приватный доступ: три точки, где стоит проверка

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

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

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

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

Общий пул: около 12 000 адресов и как они распределяются

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

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

# формат под привязанный адрес
198.51.100.42:8000
198.51.100.77:8000

# формат с логином и паролем
198.51.100.42:8000:u82140:k3vqz9
198.51.100.77:8000:u82140:k3vqz9

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

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

Ротация внутри пула и открытый доступ к адресу: почему это разные вещи

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

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

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

Кто ещё может ходить через тот же адрес

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

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

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

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

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

Привязка адреса и пара логина с паролем: как отсекаются чужие

Технически приватность включается одним из двух способов, оба доступны в пакете и переключаются в любой момент.

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

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

# доступ по привязанному адресу
curl -x http://198.51.100.42:8000 https://ifconfig.me

# доступ по логину и паролю
curl -x http://u82140:k3vqz9@198.51.100.42:8000 https://ifconfig.me

# то же самое по SOCKS5, имя узла разрешается на стороне посредника
curl --socks5-hostname u82140:k3vqz9@198.51.100.42:1080 https://ifconfig.me

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

Открытые перечни из поиска: чем они отличаются от закрытого набора

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

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

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

Репутация адреса: как она складывается в каждом режиме

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

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

В закрытом режиме картина складывается из нагрузки клиентов сервиса, у каждого из которых потоки ограничены пакетом. Мы держим набор в рабочем состоянии постоянным обновлением состава: строки, которые перестали отвечать или начали получать отказы, уходят из выдачи, на их место приходят рабочие. Обновление в реальном времени работает именно на это.

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

Как выбрать режим доступа под парсинг, кабинеты и почту

Три типовые задачи требуют разной настройки, при этом набор адресов остаётся общим. Различие сидит в способе авторизации, протоколе и числе потоков.

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

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

Почта. Клиенты SMTP, IMAP и POP3 работают по TCP на портах 465, 587, 993 и 995, и через HTTP-посредник такой трафик не проходит. Берём SOCKS5, вписываем пару логина и пароля в настройках почтового клиента, потоков держим единицы. Про сокетный вариант подробно написано там, где мы разбираем прокси SOCKS5 для программ и почтовых клиентов.

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

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

Что входит в прокси-пул и кому открыт доступ?

В пуле около 12 000 активных IPv4 и SOCKS5. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000, пакеты по потокам между собой не складываются. Доступ к выдаче открыт только клиентам сервиса: список живёт в кабинете и появляется там вместе с включённым пакетом.

Сколько адресов можно привязать к пакету?

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

Прокси каких стран в списке?

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

Как понять, что режим доступа подобран верно?

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

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

Источник: https://kupit-proxy-ipv4.ru/osnovy/privatnyy-i-obshchiy/

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

Что стоит за серверным адресом на уровне железа

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

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

Адрес при этом закреплён за оборудованием площадки постоянно. Он не меняется от перезагрузки, не зависит от абонентского оборудования и не уходит в общую трансляцию вместе с сотнями соседей. Мы держим свой парк именно в таком виде, поэтому серверные прокси IPv4 на собственном оборудовании работают ровно под нагрузкой в сотни одновременных соединений.

Путь блока IPv4: от регистратора до порта в стойке

Адреса раздаются иерархией из трёх уровней. Наверху стоит IANA, она распределяет крупные блоки между пятью региональными регистраторами. Регистраторы известны по названиям: RIPE NCC обслуживает Европу и Ближний Восток, ARIN Северную Америку, APNIC Азию и Тихоокеанский регион, LACNIC Латинскую Америку, AFRINIC Африку.

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

Третий уровень это назначение внутри блока. Площадка делит полученный диапазон на части и расписывает их по своим задачам и клиентам, отмечая назначение отдельными записями. В базе такая запись отличается статусом: у выданного регистратором блока стоит ALLOCATED PA, у назначенного внутри него участка ASSIGNED PA.

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

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

Автономная система и номер AS: как блок попадает в маршруты

Одной записи в базе для работы мало, блок нужно анонсировать. Здесь появляется автономная система: набор сетей под единым управлением с общей политикой маршрутизации. У каждой такой системы есть номер вида AS64512, выдаёт его тот же региональный регистратор.

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

Рядом с анонсом живут две проверочные записи. Объект route в базе регистратора связывает диапазон с номером автономной системы. Подпись ROA в системе RPKI закрепляет эту же связку криптографически, и крупные операторы отбрасывают анонсы, которые с подписью расходятся. Обе записи публичны, поэтому пара диапазон плюс номер AS проверяется кем угодно за пару секунд.

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

Как площадка определяет принадлежность адреса

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

# кто владеет диапазоном и где его границы
whois 192.0.2.55 | grep -iE "inetnum|netname|descr|country|org|status|mnt-by"

# номер автономной системы для адреса
whois -h whois.cymru.com " -v 192.0.2.55"

# то же самое через DNS, без установки клиента whois
dig +short 55.2.0.192.origin.asn.cymru.com TXT

# обратная запись имени
dig +short -x 192.0.2.55

Ответ whois разбирается по полям. inetnum показывает границы диапазона, netname короткое имя сети, descr описание владельца, country страну регистрации записи, org организацию, status тип выдачи, mnt-by того, кто ведёт запись. Крупные площадки берут отсюда владельца и сопоставляют его со своими списками.

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

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

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

Почему серверные адреса отвечают быстро и ровно

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

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

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

# замер по фазам соединения через посредник
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n" \
  -x http://192.0.2.55:8000 https://example.com/catalog

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

Где серверный адрес видно в логах

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

В журнале веб-сервера адрес стоит первым полем строки доступа. Формат combined у nginx и Apache пишет туда переменную remote_addr, дальше идут время, метод, путь, код ответа и заголовок User-Agent. Когда запрос прошёл через посредник, сюда попадает адрес посредника, и исходный адрес клиента до сервера не доходит.

192.0.2.55 - - [12/Feb:04:18:31 +0000] "GET /catalog/page/7 HTTP/1.1" 200 18422 "-" "Mozilla/5.0"

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

Received: from mail.example.net (unknown [192.0.2.55])
        by mx.example.org with ESMTPS id 4a91c2b0

Отдельная тема это заголовки, которые добавляет сам посредник. Простые HTTP-посредники умеют вписывать поля X-Forwarded-For и Via с исходным адресом клиента, и тогда принимающая сторона видит обе точки сразу. Мы лишних полей к запросу не добавляем, что легко проверить запросом к сервису эхо-заголовков.

curl -s -x http://192.0.2.55:8000 https://httpbin.org/headers

Как площадки относятся к серверным диапазонам

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

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

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

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

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

Под какие задачи серверный набор подходит лучше всего

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

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

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

Четвёртая задача это почта и произвольные протоколы. Клиенты SMTP, IMAP и POP3 ходят по TCP на портах 465, 587, 993 и 995, поэтому здесь берут сокетный вариант: прокси SOCKS5 для почты и произвольных портов проводят трафик любого приложения и умеют разрешать имена на своей стороне.

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

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

Сколько адресов держится в серверном пуле?

В пуле около 12 000 активных IPv4 и SOCKS5, суточный онлайн держится примерно на этой же отметке. Список обновляется в режиме реального времени, поэтому строки, которые перестали отвечать, уходят из выдачи сами. Доступ к перечню открыт только клиентам сервиса.

Прокси каких стран есть в списке?

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

Какой протокол выбрать для серверного адреса?

В пакете доступны IPv4 с HTTP и HTTPS, а также SOCKS4 и SOCKS5. Мы рекомендуем SOCKS5: он проводит трафик любого приложения, работает с произвольными портами и разрешает имена узлов на стороне посредника. Адреса при этом одни и те же, меняется только строка подключения.

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

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

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

Источник: https://kupit-proxy-ipv4.ru/osnovy/servernye-adresa/

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

Ниже мы разбираем арифметику масок, счёт адресов в /24, /22 и /19, логику антифрода вокруг подсетей, проверку принадлежности адреса блоку через whois и практику раскладки нагрузки по диапазонам на крупном прогоне. Тему берём с азов, поэтому предварительных знаний о маршрутизации не потребуется.

Запись 203.0.113.0/24: базовый адрес и длина префикса

IPv4-адрес это 32 бита, записанные четырьмя октетами по 8 бит: 203.0.113.45. Каждый октет принимает значения от 0 до 255, поэтому старший октет 203 занимает биты с первого по восьмой, следующий 0 с девятого по шестнадцатый и так далее. Косая черта с числом после адреса называется префиксной записью CIDR.

Число после косой черты говорит, сколько старших бит закреплено за сетью. В 203.0.113.0/24 закреплены первые 24 бита, то есть три октета 203.0.113. Свободными остаются последние 8 бит, и меняться может только последний октет. Получается ровно 256 комбинаций: от 203.0.113.0 до 203.0.113.255.

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

Базовый адрес всегда кратен размеру блока. Запись 203.0.113.7/24 встречается в конфигурациях интерфейсов и читается как «адрес 203.0.113.7 внутри блока 203.0.113.0/24». В таблицах маршрутов и в ответах whois вы увидите ровный вариант с нулём в конце.

# три способа записать одно и то же
203.0.113.0/24
203.0.113.0 255.255.255.0
203.0.113.0 - 203.0.113.255

Маска подсети: как из префикса получается число адресов

Маска это тот же префикс, записанный четырьмя октетами. Единицы слева отмечают биты сети, нули справа биты узла. Префикс /24 превращается в 255.255.255.0, префикс /22 в 255.255.252.0, префикс /19 в 255.255.224.0. Третий октет маски в этих примерах меняется потому, что граница сети проходит внутри него.

Счёт адресов держится на одной формуле: свободных бит остаётся 32 минус префикс, а число адресов равно двойке в этой степени. Для /24 свободны 8 бит и получается 256 адресов. Для /22 свободны 10 бит и получается 1024 адреса. Для /19 свободны 13 бит и получается 8192 адреса. Чем меньше число после косой черты, тем крупнее блок.

Обратите внимание на границы в правой колонке. Блок /22 начинается с 203.0.112.0 потому, что третий октет должен делиться на 4: подходят 112, 116, 120, 124. Блок /19 начинается с 203.0.96.0, третий октет кратен 32. Правило кратности объясняет, почему провайдер выдаёт диапазоны кусками фиксированного размера и не режет их произвольно.

Ещё одна практическая деталь: /22 это ровно четыре соседних /24, а /19 это тридцать два /24. Держим это соответствие в голове, и любой ответ whois читается за секунду. Крупный блок распадается на мелкие по степеням двойки, обратное тоже верно.

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

Что площадка называет подсетью

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

Первый уровень это /24. Он выступает единицей учёта у большинства антифрод-систем: счётчики запросов, репутационные отметки и временные ограничения чаще всего вешаются именно на третий октет. Второй уровень это блок из whois, то есть тот диапазон, который зарегистрирован за конкретным владельцем. Он бывает шире /24: /22, /21, /19 и крупнее. Третий уровень это автономная система, ASN: номер, под которым сеть объявляет свои маршруты соседям.

Мы держим все три уровня в поле зрения, когда собираем пул: адреса приходят от разных операторов, из разных блоков whois и под разными номерами автономных систем. Такая раскладка даёт запас там, где счётчики площадки работают на уровне /24, и там, где они поднимаются до уровня оператора.

Почему поведение соседей влияет на приём запросов

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

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

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

HTTP/1.1 429 Too Many Requests
Retry-After: 120
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

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

Третий механизм это привязка сессии. Если авторизованная сессия открылась с адреса 198.51.100.20, а следующий запрос той же сессии пришёл с 203.0.113.90, площадка видит смену подсети посреди работы и обычно требует повторного подтверждения. Внутри одного /24 такой переход проходит спокойнее, потому что блок остаётся прежним.

Как проверить принадлежность адреса блоку через whois

Проверка занимает несколько секунд и отвечает сразу на три вопроса: какому диапазону принадлежит адрес, кто владелец блока и под каким номером автономной системы этот блок объявлен. Утилита whois есть в любом дистрибутиве Linux, в macOS она встроена, в Windows её заменяет одноимённая программа из набора Sysinternals.

# базовый запрос
whois 203.0.113.45

# только нужные поля, RIPE и APNIC
whois 203.0.113.45 | grep -iE "inetnum|netname|route|origin|country|descr"

# то же через публичный сервис whois по HTTP
curl -s https://rdap.db.ripe.net/ip/203.0.113.45 | head -40

В ответе RIPE и APNIC диапазон лежит в поле inetnum, у ARIN то же самое называется NetRange и CIDR. Поле netname даёт короткое имя блока, descr описание владельца, origin номер автономной системы. Ответ приходит в виде набора строк, и читать его удобнее через фильтр, показанный выше.

Дальше сравниваем два адреса из своего списка. Совпали inetnum и origin, значит адреса живут в одном блоке и для площадки они соседи. Разошёлся третий октет при совпадающем inetnum, значит блоки /24 разные, а владелец общий: часть счётчиков разведена, часть остаётся общей. Разошёлся origin, значит перед нами полностью независимые сети.

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

# сколько разных /24 в первых 200 строках списка
cut -d: -f1 proxy.txt | head -200 | cut -d. -f1-3 | sort -u | wc -l

# сколько разных автономных систем
for ip in $(cut -d: -f1 proxy.txt | head -30); do
  whois "$ip" | grep -im1 -E "^origin" 
done | sort | uniq -c | sort -rn

Зачем в работе нужны адреса из разных подсетей

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

Устойчивость темпа. Счётчики частоты живут на уровне блока, поэтому суммарная скорость прогона делится между блоками. На тридцати разных /24 общий темп держится в тридцать раз выше того, что выдержит один блок, при том же безопасном темпе на каждый счётчик. Мы собираем пул именно с таким расчётом, и на странице, где можно купить прокси IPv4 из широкого набора подсетей, состав пула описан по пунктам.

Независимость задач. Когда две задачи идут параллельно, разведение по блокам избавляет от взаимного влияния. Сбор карточек товаров и съём выдачи из одного /24 складываются в общий счётчик целевого домена, и медленная задача начинает страдать от быстрой. Разные блоки ставят между ними стену.

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

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

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

Как распределять нагрузку по диапазонам при крупном прогоне

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

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

# раскладка списка по группам /24
awk -F: '{split($1,a,"."); print a[1]"."a[2]"."a[3]"\t"$0}' proxy.txt \
  | sort -k1,1 | cut -f2 > proxy-by-subnet.txt

Второй приём: потолок потоков на блок. Правило простое: держим не больше 3-5 одновременных соединений с одного /24 к одному домену. Общий лимит пакета при этом остаётся прежним, просто он раскладывается шире. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000, и при двух привязанных адресах общий лимит делится между ними пополам.

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

Четвёртый приём: пауза по блоку, не по адресу. Получили 429 с одного адреса, отправляйте следующий запрос из другой группы, а исходную группу выведите из работы на время из заголовка Retry-After. Многие программы умеют это из коробки: в ZennoPoster логика собирается кубиками в проекте, а в A-Parser поведение задаётся в настройках потоков и повторов. Готовые связки для сборщика мы описали на странице про настройку A-Parser под работу с пулом.

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

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

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

Пул на 12 000 активных адресов при широком наборе блоков даёт сотни разных /24 и десятки разных автономных систем. География охватывает 200+ стран, пул собран как микс со всего мира, и уже поэтому адреса физически расходятся по множеству независимых сетей. Ротация внутри пула автоматическая, состав обновляется в реальном времени, поэтому одна и та же выборка через час покажет частично другие блоки.

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

Проверить разброс своими руками проще всего в тестовом окне. Бесплатный тест длится до 2 часов, список выдаётся в форматах IP:PORT и IP:PORT:LOGIN:PASS ссылкой или файлом, и этого достаточно, чтобы снять статистику по блокам на реальной выборке. Полный состав пакета с потоками и привязками разобран там, где оформляется доступ к пулу IPv4 и SOCKS5.

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

Можно ли получить набор адресов из одного диапазона?

Пул устроен как микс со всего мира, ротация внутри пула автоматическая, состав обновляется в реальном времени. Группировку по блокам вы собираете на своей стороне: список приходит плоским, один проход сортировки по третьему октету раскладывает его по группам /24, и дальше софт работает с этими группами как ему удобно.

Что входит в прокси-пул?

В пуле около 12 000 активных адресов IPv4 и SOCKS5, онлайн держится в районе этой цифры в сутки. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000, пакеты по потокам между собой не складываются. Доступ к списку открыт клиентам сервиса.

Как часто обновляется список адресов?

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

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

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

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

Источник: https://kupit-proxy-ipv4.ru/osnovy/podset-i-diapazon/

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

Откуда берутся служебные заголовки

HTTP-запрос это стартовая строка и набор пар «имя: значение». Браузер отправляет Host, User-Agent, Accept, Accept-Language, Cookie и ещё десяток полей. Прокси получает этот набор, при необходимости дописывает свои поля и отправляет дальше.

Дописывать поля прокси начал по причинам эксплуатации. Корпоративные шлюзы и кэширующие серверы ставили X-Forwarded-For, чтобы веб-сервер за ними видел настоящего клиента в логах. Балансировщики нагрузки делают то же самое до сих пор, и в их случае это работает на пользу владельцу сайта. Поле прижилось, вошло в привычку администраторов и потом получило стандартизованного наследника Forwarded.

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

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

Ещё одна деталь касается регистра и порядка полей. Имена заголовков нечувствительны к регистру, поэтому X-Forwarded-For и x-forwarded-for для сервера одно и то же. Порядок полей при этом значение имеет: он входит в отпечаток клиента, и посредник, который переставляет заголовки местами, оставляет след даже без добавления новых.

Прозрачный уровень: адрес клиента уходит открытым текстом

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

GET /page HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Via: 1.1 squid-gw (squid/5.7)
X-Forwarded-For: 198.51.100.20
X-Real-IP: 198.51.100.20
Proxy-Connection: keep-alive

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

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

Анонимный уровень: посредник виден, клиент нет

Анонимный прокси убирает исходный адрес из заголовков и оставляет признак своего присутствия. В типичном виде остаётся Via, иногда X-Forwarded-For со значением unknown либо с адресом самого выходного узла. Клиента за такой цепочкой не видно.

GET /page HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Via: 1.1 proxy
X-Forwarded-For: unknown

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

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

Встречается и промежуточный вариант, который иногда называют искажающим. Такой узел подставляет в X-Forwarded-For произвольный адрес, не имеющий отношения к клиенту. С точки зрения сервера картина выглядит как обычная цепочка посредников, и подставленное значение уходит в логи. На практике пользы от подмены немного: сам факт присутствия поля уже говорит о посреднике, а его содержимое серьёзные фильтры перепроверяют по другим признакам.

Отличить анонимный узел от искажающего просто. Отправляем запрос со своей машины, смотрим значение в X-Forwarded-For и сравниваем его с собственным адресом. Совпало, узел прозрачный. Стоит unknown или адрес самого узла, уровень анонимный. Стоит произвольный посторонний адрес, перед вами искажающий вариант.

Элитный уровень: запрос выглядит обычным

Элитный прокси передаёт запрос без единого добавленного поля. Набор заголовков остаётся тем, который сформировал ваш клиент: Host, User-Agent, Accept, Accept-Encoding, Accept-Language, Connection. Целевой сервер видит соединение с адреса выходного узла и обычный набор полей браузера.

GET /page HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

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

Проверка уровня через curl

Самая быстрая проверка занимает одну команду. Берём публичный сервис, который возвращает полученные заголовки в виде JSON, и отправляем запрос через свой прокси. Всё, что окажется в ответе сверх обычного набора браузера, дописал посредник.

# запрос через прокси с привязкой своего адреса
curl -x http://185.24.87.14:8000 https://httpbin.org/headers

# запрос через прокси с логином и паролем
curl -x http://user5521:pf39kd@185.24.87.14:8000 https://httpbin.org/headers

# только адрес на выходе
curl -x http://185.24.87.14:8000 https://ifconfig.me

# полный протокол обмена вместе с заголовками запроса
curl -v -x http://185.24.87.14:8000 https://example.com -o /dev/null

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

curl -s https://httpbin.org/headers > direct.json
curl -s -x http://185.24.87.14:8000 https://httpbin.org/headers > proxied.json
diff direct.json proxied.json

Пустая разница по служебным полям означает элитный уровень. Появились Via и X-Forwarded-For со значением вашего адреса, перед вами прозрачный узел. Появился только Via либо X-Forwarded-For: unknown, уровень анонимный. Дополнительно смотрим на адрес в поле origin ответа: он должен совпадать с адресом выходного узла.

Страница-эхо: своя проверка без внешних сервисов

Публичные сервисы удобны, но они видят весь ваш трафик проверки и иногда меняют формат ответа. Своя страница-эхо снимает эти неудобства и разворачивается за пару минут на любом сервере с PHP либо с Node.

<?php
// echo.php: возвращает все полученные заголовки и адрес соединения
header('Content-Type: application/json; charset=utf-8');
$out = ['remote_addr' => $_SERVER['REMOTE_ADDR'], 'headers' => []];
foreach ($_SERVER as $k => $v) {
    if (strpos($k, 'HTTP_') === 0) {
        $out['headers'][str_replace('_', '-', substr($k, 5))] = $v;
    }
}
echo json_encode($out, JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE);

Тот же смысл на Node без внешних пакетов:

const http = require('http');
http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.end(JSON.stringify({
    remote: req.socket.remoteAddress,
    headers: req.headers
  }, null, 2));
}).listen(8080);

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

Полезно повесить такую страницу на домен с сертификатом и проверять оба варианта, по HTTP и по HTTPS. Разница между ними существенная: при HTTPS прокси открывает туннель методом CONNECT и внутрь шифрованного потока не заглядывает, поэтому дописать что-либо в заголовки он физически не может. Именно по этой причине проверку уровня всегда делают по HTTP, иначе любой узел покажется элитным.

Из этого следует практический порядок замера. Сначала берём HTTP и снимаем сырой набор полей, затем повторяем по HTTPS и сверяем адрес соединения. Если по HTTP пришли лишние служебные поля, а по HTTPS картина ровная, узел работает в прозрачном либо анонимном режиме и просто не может вмешаться в шифрованный поток. Мы проводим оба замера подряд, когда разбираем чужую настройку по обращению клиента. Устройство самого туннеля и порядок работы метода CONNECT подробно описаны там, где оформляется подключение по протоколу HTTP и HTTPS.

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

Почему у SOCKS5 понятия заголовков нет

SOCKS работает на другом слое. Протокол занимается установкой соединения: клиент сообщает узлу адрес и порт назначения, узел открывает канал и дальше просто перекладывает байты в обе стороны. Содержимое потока для SOCKS-узла безразлично, разбирать HTTP он не умеет и не пытается.

Отсюда прямое следствие: дописать Via или X-Forwarded-For через SOCKS5 некому. Всё, что отправит ваша программа, дойдёт до сервера ровно в том виде, в котором вышло. Поэтому вопрос об уровне анонимности к SOCKS5 неприменим: заголовков на уровне протокола там попросту нет.

# обмен при установке соединения SOCKS5
клиент -> узел : 05 01 00                  выбор метода авторизации
узел -> клиент : 05 00                     метод принят
клиент -> узел : 05 01 00 03 0b example.com 01 bb   подключить к example.com:443
узел -> клиент : 05 00 00 01 ...           канал открыт
дальше идёт сырой поток байт

Второе преимущество сокетного варианта касается имён. В режиме socks5h разбор доменного имени передаётся на сторону узла, и запрос к DNS уходит оттуда же, откуда потом пойдёт соединение. Разбор запросов к службе имён вынесен в отдельный материал про утечку запросов к DNS, там показаны настройки для браузеров и парсеров.

# отличие двух схем в curl
curl -x socks5://185.24.87.14:1080  https://example.com   # имя разбирает клиент
curl -x socks5h://185.24.87.14:1080 https://example.com   # имя разбирает узел

В пакете доступны SOCKS4 и SOCKS5 на выбор, рекомендуем SOCKS5: он умеет авторизацию по логину, принимает доменные имена и работает с UDP. Строки подключения и порядок настройки собраны там, где оформляется покупка прокси SOCKS5 для программ.

Что ещё выдаёт работу через посредника

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

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

Второе это WebRTC в браузере. Механизм собирает адреса сетевых интерфейсов для прямого соединения между участниками и отдаёт их странице через JavaScript. Отключается флагом в настройках браузера или профилем антидетект-браузера, где нужные переключатели вынесены в интерфейс.

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

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

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

Какой уровень нужен под какую задачу

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

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

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

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

Наш пул состоит примерно из 12 000 активных адресов, ротация внутри пула автоматическая, список обновляется в реальном времени. Трафик безлимитный, потоки до 1000 на стандартных пакетах и до 3000 на корпоративном, включение пакета занимает примерно 5 минут. Мы выдаём список в форматах IP:PORT и IP:PORT:LOGIN:PASS, ссылкой либо файлом, и режим передачи заголовков одинаков для всех адресов пула. Подробности собраны там, где можно взять анонимные прокси под свою задачу.

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

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

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

Какой тип прокси вы даёте?

В пакете доступны IPv4 и SOCKS5, внутри сокетного варианта можно выбрать SOCKS-4 или SOCKS-5, рекомендуем SOCKS-5. Протоколы HTTP и HTTPS работают на тех же адресах, менять пакет для перехода между ними не требуется: меняется только строка подключения в настройках программы.

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

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

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

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

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

Источник: https://kupit-proxy-ipv4.ru/osnovy/urovni-anonimnosti/

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

Адрес соединения: что читается по одной строке в логе

Первое, что попадает в журнал веб-сервера, это адрес источника TCP-соединения. Через посредника туда пишется адрес выходного узла. Мы держим пул около 12 000 активных адресов, ротация внутри него автоматическая, поэтому два соседних запроса штатно уходят с разных выходов и в логе площадки выглядят как обращения разных клиентов.

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

whois 203.0.113.24 | grep -iE "netname|descr|origin|country"
dig +short 24.113.0.203.origin.asn.cymru.com TXT

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

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

Строка User-Agent и заголовки Client Hints

User-Agent это текстовая строка, которую браузер добавляет к каждому запросу. Она сообщает семейство браузера, версию движка, платформу и разрядность системы. Посредник её не трогает и не переписывает: строка формируется программой на стороне пользователя.

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
            (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

Современные браузеры на движке Chromium дополняют картину заголовками Client Hints. Часть из них уходит с каждым запросом сама, часть подтягивается по запросу площадки через заголовок Accept-CH. Смысл тот же, форма аккуратнее: значения разложены по отдельным полям и читаются машиной без разбора длинной строки.

Sec-CH-UA: "Chromium";v="126", "Google Chrome";v="126", "Not.A/Brand";v="24"
Sec-CH-UA-Platform: "Windows"
Sec-CH-UA-Platform-Version: "15.0.0"
Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"
Sec-CH-UA-Full-Version-List: "Chromium";v="126.0.6478.127"

Здесь появляется первый источник расхождений. Пользователь подменил User-Agent расширением, площадка запросила Client Hints, и в ответ пришла платформа, которая с подменённой строкой не сходится. Мы видим этот сценарий регулярно в обращениях: адрес из пула отрабатывает штатно, площадка отдаёт проверку, а причина сидит в двух полях, которые рассказывают о системе разные вещи. Подмена работает только тогда, когда её делает сам браузер на уровне движка, и ровно для этого существуют антидетект-браузеры с подменой отпечатка.

Набор и порядок заголовков запроса

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

Браузер на Chromium отправляет поля примерно в таком порядке.

:method: GET
:authority: example.com
:scheme: https
:path: /catalog
sec-ch-ua: ...
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 ...
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif
sec-fetch-site: none
sec-fetch-mode: navigate
sec-fetch-user: ?1
sec-fetch-dest: document
accept-encoding: gzip, deflate, br, zstd
accept-language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7

Скрипт на requests отправляет четыре поля в другом порядке и без единого заголовка группы Sec-Fetch. Библиотека честно сообщает о себе строкой python-requests/2.31, и площадке этого достаточно для однозначной классификации. Подстановка браузерного User-Agent поверх такого запроса картину не выравнивает: порядок полей и отсутствие группы Sec-Fetch остаются на месте.

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

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

curl -s -x http://203.0.113.24:8000 https://httpbin.org/headers | jq .headers

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

Отпечаток TLS: рукопожатие до первого байта HTTP

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

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

# сравнение отпечатков двух клиентов через публичный сервис
curl --socks5-hostname 203.0.113.24:1080 https://tls.peet.ws/api/all | jq .tls.ja3_hash

Расхождение выглядит так. В заголовке заявлен Chrome под Windows, а рукопожатие приходит от OpenSSL со списком шифров, которого у Chrome никогда не было. Площадка сопоставляет два признака за один шаг. Мы разбирали такие обращения десятки раз: адреса пула отвечают ровно, отклик стабильный, отказ приходит из-за библиотеки, которая ходит своим рукопожатием.

Отпечаток TLS формируется клиентской программой целиком. Посредник переносит байты рукопожатия дальше без изменений, потому что содержимое туннеля ему недоступно. Выравнивается признак заменой транспорта: браузер вместо библиотеки либо библиотека с имитацией браузерного ClientHello, такие сборки существуют для Go, Python и Node.

Что отдаёт сам браузер: язык, пояс, экран и шрифты

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

Язык, часовой пояс и локаль

Язык уходит двумя путями сразу. Первый это заголовок Accept-Language, он приходит с каждым запросом. Второй это свойства объекта navigator, которые читает любой скрипт на странице. Часовой пояс скрипт получает через штатный интерфейс интернационализации.

navigator.language            // "ru-RU"
navigator.languages           // ["ru-RU", "ru", "en-US", "en"]
Intl.DateTimeFormat().resolvedOptions().timeZone   // "Europe/Moscow"
new Date().getTimezoneOffset()                     // -180

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

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

Экран, графика и набор шрифтов

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

screen.width + "x" + screen.height        // 1920x1080
screen.availHeight                        // 1032
window.devicePixelRatio                   // 1.25

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

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

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

Cookies, хранилище и кеш

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

Кроме cookies браузер держит localStorage, sessionStorage, базы IndexedDB, кеш сервис-воркеров и кеш HTTP. Последний тоже работает меткой: сервер отдаёт картинку с уникальным значением ETag, браузер при следующем визите присылает это значение обратно в заголовке If-None-Match, и площадка узнаёт посетителя без единой cookie.

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

Поведение: мышь, клавиатура и ритм запросов

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

Автоматический обход выглядит иначе. Курсор перемещается по прямой либо не перемещается вовсе, текст в поле появляется целиком за один тик, интервал между запросами держится ровным до миллисекунды. Ровный интервал вообще самый заметный из поведенческих признаков, потому что для его подсчёта скрипты не нужны: достаточно журнала обращений на стороне сервера.

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

Сводная таблица: признак, кто его отдаёт, чем закрывается

Ниже собрано всё разобранное выше в одном месте. Колонка «кто отдаёт» отвечает на вопрос, где физически рождается признак. Колонка «чем закрывается» показывает, какой инструмент за него отвечает.

Читается таблица сверху вниз как порядок работ. Первые четыре строки закрывает пакет прокси. Строка про WebRTC требует одной галочки в настройках браузера. Всё, что ниже, живёт в профиле браузера и в настройках рабочей программы.

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

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

Как собрать признаки в согласованный набор

Сначала фиксируется транспорт. Для браузерных задач берём HTTP и HTTPS, для программ с произвольными портами и скриптов удобнее прокси SOCKS5 для программ и скриптов: имя домена разрешается на стороне выходного узла, и запросы к службе имён не уходят мимо туннеля. Про эту утечку и её проверку есть отдельный разбор в материале про запросы к DNS. В пакете доступны IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5, адреса при этом одни и те же, меняется только строка подключения, поэтому переход с одного протокола на другой ничего не стоит по времени.

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

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

# что видит площадка: адрес, заголовки и отпечаток рукопожатия
curl -x http://203.0.113.24:8000 https://ifconfig.me
curl -x http://203.0.113.24:8000 https://httpbin.org/headers
curl -x http://203.0.113.24:8000 https://tls.peet.ws/api/all

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

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

Закрывает ли прокси отпечаток браузера?

Прокси закрывает сетевой слой: площадка принимает соединение от выходного узла и записывает в журнал его адрес. Строка User-Agent, заголовки Client Hints, отпечаток TLS, шрифты, экран и графические подписи рождаются на стороне клиентской программы, поэтому за них отвечают настройки браузера и профиль антидетекта. Оба слоя нужны вместе, и таблица выше показывает, какой инструмент закрывает какую строку. Сетевую часть целиком берут на себя прокси с высокой ступенью анонимности, которые отдают площадке только адрес выходного узла.

Как проверить, какой адрес видит площадка?

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

Почему адрес в двух запросах подряд разный?

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

Можно ли получить адреса определённой страны?

Нет, наш пул это микс со всего мира, выборка по отдельной стране не делается. Адреса приходят из множества стран, всего в списке представлено 200+ стран, и такая схема даёт разнообразие подсетей без ручной настройки. Для сбора открытых данных, проверки выдачи и работы с несколькими кабинетами разнообразие подсетей весит больше, чем конкретная точка на карте.

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

Источник: https://kupit-proxy-ipv4.ru/osnovy/chto-vidit-sayt/

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

Два способа доступа: где живёт проверка права

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

При привязке узел смотрит на адрес источника входящего соединения и сверяет его со списком, который клиент завёл в кабинете. Совпало, соединение принято. Не совпало, соединение закрывается ещё до обмена по протоколу HTTP. Такой список принято называть whitelist по IP, и вся проверка укладывается в одно сравнение.

При доступе по логину узел ждёт учётные данные внутри протокола. В HTTP они приезжают заголовком Proxy-Authorization, в SOCKS5 отдельным шагом рукопожатия. Пока пары нет, узел отвечает кодом 407 и держит соединение открытым, ожидая повтора запроса уже с данными.

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

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

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

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

# внешний адрес рабочей машины
curl -s https://ifconfig.me
curl -s https://api.ipify.org

# то же самое из PowerShell на Windows
(Invoke-RestMethod https://api.ipify.org)

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

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

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

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

Доступ по логину и паролю: как он устроен

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

В HTTP обмен выглядит так. Программа отправляет запрос, узел отвечает 407 Proxy Authentication Required и заголовком Proxy-Authenticate: Basic, программа повторяет запрос уже с заголовком Proxy-Authorization: Basic <base64 логина и пароля>. Дальше туннель поднимается методом CONNECT, и весь дальнейший обмен идёт внутри него.

> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
> Proxy-Authorization: Basic dXNlcjU1MjE6cGYzOWtk
< HTTP/1.1 200 Connection established

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

Главное практическое достоинство этого способа: машина может быть любой. Ноутбук в дороге, виртуальный сервер у стороннего хостинга, облачный сборщик, чужой компьютер на проекте у заказчика. Адрес источника при этом никого не интересует, потому что право на доступ приезжает вместе с запросом.

Форматы IP:PORT и IP:PORT:LOGIN:PASS в реальном списке

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

# формат под привязанный адрес
185.24.87.14:8000
185.24.87.15:8000
185.24.87.16:1080

# формат с учётными данными
185.24.87.14:8000:user5521:pf39kd
185.24.87.15:8000:user5521:pf39kd
185.24.87.16:1080:user5521:pf39kd

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

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

Где вводится каждый вариант: браузер, curl, программы

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

Браузер

Firefox держит настройки посредника внутри себя: раздел параметров сети, ручная настройка, поля адреса и порта отдельно для HTTP и для SOCKS. При доступе по логину окно с запросом учётных данных появляется при первом же обращении, и браузер предлагает их запомнить. Chrome и браузеры на Chromium берут системные настройки, поэтому пара вводится в системном окне.

# запуск Chromium с явным указанием посредника
chrome.exe --proxy-server="http://185.24.87.14:8000"
chrome.exe --proxy-server="socks5://185.24.87.16:1080"

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

curl и командная строка

В curl оба варианта пишутся одной строкой. Ключ -x задаёт посредника целиком, ключ -U выносит пару отдельно, что удобнее для скриптов с переменными.

# доступ по привязанному адресу
curl -x http://185.24.87.14:8000 https://ifconfig.me

# доступ по логину, учётные данные внутри ключа -x
curl -x http://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

# то же самое, пара вынесена отдельно
curl -x http://185.24.87.14:8000 -U user5521:pf39kd https://ifconfig.me

# SOCKS5 с разрешением имён на стороне выхода
curl --socks5-hostname 185.24.87.16:1080 -U user5521:pf39kd https://ifconfig.me

Переменные окружения работают в том же ключе и подхватываются большинством консольных утилит, включая wget, git и пакетные менеджеры.

export http_proxy="http://user5521:pf39kd@185.24.87.14:8000"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1"

Прикладные программы и код

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

import requests

proxies = {
    "http":  "http://user5521:pf39kd@185.24.87.14:8000",
    "https": "http://user5521:pf39kd@185.24.87.14:8000",
}
r = requests.get("https://ifconfig.me", proxies=proxies, timeout=15)
print(r.status_code, r.text)

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

Меняющийся адрес провайдера: порядок действий

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

Вариантов действий два, и оба рабочие.

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

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

Две привязки в пакете и деление лимита потоков

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

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

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

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

Ошибки неверного способа доступа: 407 и отказ соединения

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

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

# так выглядит 407 в подробном выводе curl
curl -v -x http://185.24.87.14:8000 https://example.com
< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: Basic realm="proxy"

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

curl -x http://185.24.87.14:8000 https://example.com
# curl: (56) Recv failure: Connection reset by peer
echo $?   # 56

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

Отдельная история это пароль со спецсимволами. Знак решётки, косая черта, вопросительный знак и амперсанд внутри адресной строки разбираются как служебные, и программа обрезает пару в неожиданном месте. Мы разбираем такие обращения постоянно, лечится это двумя путями: пара выносится в отдельные поля программы либо символы кодируются процентной записью. В curl проще всего использовать ключ -U, там строка читается целиком и никакого разбора адреса не происходит.

Ещё один случай выглядит совсем безобидно: запрос проходит, код 200 приходит, а на выходе виден прежний адрес машины. Значит, программа обошла настройки посредника стороной. Мы проверяем это первым делом при разборе жалоб на неработающий доступ: сравниваем адрес прямого запроса и адрес запроса через выход. Полный список портов и протоколов, которые принимают наши узлы, собран там, где оформляется доступ к пулу IPv4 и SOCKS5, а разбор форматов авторизации для браузерного трафика лежит на странице про прокси HTTP с авторизацией по паре логина и пароля.

Смена привязки в кабинете и переключение между способами

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

1. Узнать текущий внешний адрес машины запросом к сервису эха. 2. Открыть настройки пакета в кабинете. 3. Вписать адрес в свободное поле привязки либо заменить прежнее значение. 4. Сохранить и подождать применения, обычно это меньше минуты. 5. Проверить доступ запросом через любой адрес из списка.

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

# короткая проверка после любой правки доступа
curl -sS -o /dev/null -m 15 -w 'code=%{http_code} time=%{time_total}\n' \
  -x http://185.24.87.14:8000 https://api.ipify.org

Ответ code=200 с разумным временем отклика означает, что доступ настроен верно. Пакет включается примерно за 5 минут после оплаты, и первая проверка делается сразу после включения, до запуска рабочего прогона. Мы советуем прогонять эту команду каждый раз после правки настроек: она занимает секунду и снимает половину вопросов заранее.

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

Сколько адресов можно привязать к пакету?

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

Что делать при динамическом адресе провайдера?

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

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

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

Как подключиться к прокси после покупки?

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

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

Источник: https://kupit-proxy-ipv4.ru/osnovy/avtorizaciya/

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

Почему вопрос «сколько адресов» упирается в потоки

Формулировка «мне нужно тридцать прокси» пришла из схемы, где покупатель получает короткий фиксированный список строк и раздаёт их своим процессам руками. У нас пакет открывает доступ ко всему пулу сразу, список забирается ссылкой или файлом в форматах IP:PORT и IP:PORT:LOGIN:PASS, обновляется он в реальном времени. Ограничивает работу лимит одновременных потоков, записанный в пакете.

Поток это соединение, которое программа держит открытым в конкретный момент времени. A-Parser показывает эту величину в настройках задания, ZennoPoster в свойствах проекта, Key Collector в параметрах сбора, обычный curl в связке с xargs -P принимает её флагом. Когда мы считаем нагрузку, мы смотрим именно в это поле. Всё остальное производные: сколько страниц пройдено за час, сколько времени займёт полный прогон, упрётся ли софт в потолок пакета.

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

Считаем требуемую скорость: страницы делим на часы прогона

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

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

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

Из скорости и времени отклика получаем число потоков

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

# потоки = запросы в секунду * среднее время отклика
# запросы в секунду = обращения / (часы * 3600)

python3 - <<'PY'
pages, hours, latency = 40000, 8, 1.2
rps = pages / (hours * 3600)
print(round(rps, 2), "запросов в секунду")
print(round(rps * latency, 1), "потоков по формуле")
PY

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

for i in $(seq 1 20); do
  curl -o /dev/null -s -w "%{time_total}\n" \
    -x http://185.24.87.14:8000 https://example.com/catalog/page/1
done | awk '{s+=$1} END {print "среднее:", s/NR, "с"}'

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

Лимит потоков в пакете: 1000, 3000 и почему они не складываются

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

На лимит влияет привязка. В пакет входит одновременная привязка 2 адресов со свободной сменой в настройках кабинета, и при двух привязанных адресах общее число потоков делится между ними пополам. Пакет на 1000 потоков при двух привязках отдаёт по 500 на каждую машину. Это ровно та деталь, которую забывают при расчёте: администратор считал нагрузку по полной цифре, а рабочая машина упирается в половину и логи наполняются отказами.

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

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

Ротация внутри пула из 12 000 адресов снимает вопрос количества

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

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

География пула это микс со всего мира, адреса приходят из 200+ стран. Для сбора открытых данных, съёма выдачи и разведения рабочих профилей такая схема даёт разнообразие подсетей без ручной настройки: соседние запросы уходят из разных диапазонов, и целевой сайт видит их как обращения из разных сетей.

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

Сбор прайсов поставщиков: расчёт на цифрах

Магазин снимает прайсы у шести поставщиков, суммарно 40 000 карточек, окно ночное с полуночи до восьми утра. Половина поставщиков отдаёт цену прямо в разметке карточки, вторая половина требует дополнительного обращения к внутреннему методу, поэтому реальных запросов выходит около 60 000. Делим на 8 часов, получаем 7 500 запросов в час.

Отклик по измерению держится около 1.8 секунды, площадки крупные и отвечают ровно. Запросов в секунду выходит 2.08, потоков по формуле около четырёх, в софте ставим 15. Прогон укладывается в окно с запасом, и даже при просадке отклика вдвое скорость остаётся плановой. Лимит стандартного пакета здесь используется на полтора процента, и это нормальная картина для одиночного парсера.

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

Съём позиций: расчёт на цифрах

Съём выдачи считается иначе, потому что единица работы здесь проверка одного ключа в одной поисковой системе. Семантика на 4 000 запросов, глубина проверки три страницы выдачи, две поисковые системы. Обращений получается 4 000 умножить на 3 и на 2, итого 24 000 за один съём.

Съём делается раз в неделю и растягивается на 6 часов, чтобы частота обращений к выдаче держалась ровной. Требуемая скорость 4 000 запросов в час, это 1.11 в секунду. Отклик у страниц выдачи заметно выше каталожного, около 2.5 секунды с учётом редиректов. Потоков по формуле выходит 3, в софте ставим 12.

Здесь важнее ровность, чем максимум. Key Collector и близкие программы дают задать паузу между обращениями и разброс этой паузы, и связка «умеренные потоки плюс разброс» держит съём стабильнее, чем попытка выжать всю семантику за сорок минут на двухстах потоках. Настройки для этой программы разобраны на странице про работу Key Collector через пул.

Отдельно считаем случай агентства. Двадцать проектов, средняя семантика по 1 500 ключей, съём раз в неделю по всем сразу, окно двое суток. Обращений 20 умножить на 1 500, на 3 и на 2, итого 180 000. При 48 часах это 3 750 запросов в час, потоков по формуле около трёх, в софте 12 при последовательном обходе проектов. Если же агентство запускает проекты параллельно на разных серверах, каждый сервер получает свой пакет и свой лимит, и суммарная нагрузка распределяется без упора в потолок. Тонкости съёма разобраны отдельно в материале про позиции и работу с выдачей.

Несколько рабочих кабинетов: счёт по профилям

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

Один профиль антидетект-браузера в активной работе держит от 6 до 12 соединений: сама страница, статика, запросы к внутренним методам интерфейса, фоновые опросы. Берём верхнюю границу. Команда из пяти человек, у каждого по три открытых профиля, итого 15 профилей и около 180 потоков в пике. Стандартный лимит это покрывает с большим запасом.

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

Как проверить расчёт за два тестовых часа

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

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

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

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

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

Что входит в прокси-пул и сколько там адресов?

В пуле около 12 000 активных IPv4 и SOCKS5, онлайн держится в этом районе в сутки, список адресов обновляется в режиме реального времени. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000. Доступ к пулу открыт только клиентам сервиса.

Есть ли лимиты по потокам и как они считаются?

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

Сколько пакетов можно держать на одном аккаунте?

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

Как понять, что рассчитанного лимита хватит под мою задачу?

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

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

Источник: https://kupit-proxy-ipv4.ru/osnovy/skolko-adresov-nuzhno/

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

Четыре величины, из которых складывается выбор

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

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

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

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

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

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

Сбор данных и парсинг: HTTP с HTTPS, потоки по прогону

Парсеры каталогов, прайсов и остатков работают по HTTP и HTTPS. A-Parser, Netpeak Spider, самописные сборщики на requests и aiohttp принимают строку посредника в одном поле, и никаких дополнительных библиотек под этот протокол ставить не приходится. Сокетный вариант эти программы тоже принимают, выигрыш появляется на прогонах, где страница тянет ресурсы с десятка доменов.

Потоки в таком сценарии редко выходят за пределы сотни. Прогон на 60 000 обращений за восьмичасовое ночное окно требует около 2 запросов в секунду, а при среднем отклике 1.8 секунды формула даёт четыре потока, и в софте ставится 15 с тройным запасом. Крупные ежедневные выгрузки на несколько сотен тысяч страниц поднимают цифру до 200 или 400 потоков, что всё ещё вдвое ниже стандартного лимита.

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

# проверка целевой страницы через HTTP-посредник
curl -x http://185.24.87.14:8000 -o /dev/null -s \
  -w "код %{http_code}, время %{time_total} с\n" \
  https://example-shop.com/catalog/page/1

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

Съём позиций: те же протоколы, упор на ровность обращений

Проверка выдачи устроена мягче парсинга по нагрузке и жёстче по требованиям к ритму. Key Collector, A-Parser в режиме съёма и близкие программы обращаются к страницам выдачи по HTTPS, и главная величина здесь пауза между обращениями с разбросом, а вслед за ней уже потоки.

Семантика на 4 000 запросов при глубине в три страницы и двух поисковых системах даёт 24 000 обращений за съём. Растянутый на шесть часов, он требует 4 000 запросов в час, это чуть больше одного в секунду. При отклике 2.5 секунды формула выдаёт три потока, в софте ставится 12. Умеренная параллельность с разбросом пауз держит съём стабильнее, чем попытка пройти всю семантику за сорок минут на двух сотнях соединений.

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

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

Несколько рабочих кабинетов: SOCKS5 и счёт по профилям

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

Один активный профиль держит от 6 до 12 соединений сразу: страница, статика, внутренние методы интерфейса, фоновые опросы. Пять сотрудников по три профиля дают 15 профилей и около 180 потоков в пике, отдел на сорок профилей выходит к 480. Стандартный лимит покрывает оба случая, при этом в расчёт входит одна деталь: в пакет входит одновременная привязка 2 адресов со свободной сменой, и при двух привязках общее число потоков делится пополам.

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

# профиль антидетекта, строка подключения по SOCKS5
socks5://user5521:pf39kd@185.24.87.14:8000

# та же машина, доступ по привязке адреса без пары логина
socks5://185.24.87.14:8000

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

Отправка почты: SOCKS5 обязателен, потоки минимальные

Почтовый сценарий стоит особняком. SMTP работает поверх собственного протокола на портах 25, 465 и 587, обычный HTTP-посредник такие соединения не переносит, поэтому здесь берётся SOCKS5. Приём почты по IMAP и POP3 устроен так же и требует того же сокетного варианта.

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

# отправка через сокетный посредник, порт 587 с STARTTLS
swaks --to check@example.com --from robot@mydomain.ru \
  --server smtp.mydomain.ru:587 --tls \
  --socks5 185.24.87.14:8000

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

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

Проверка своего сайта со стороны: минимум потоков, короткий срок

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

Протокол здесь HTTP с HTTPS, потому что вся работа идёт в браузере и в curl. Настройка в браузере занимает минуту, в консоли и того меньше. Для разовых проверок берётся суточный доступ, для регулярного мониторинга доступности недельный или месячный.

# сравнение ответа напрямую и через посредник
curl -s -o /dev/null -w "прямо: %{http_code} %{time_total}\n" https://mydomain.ru/
curl -s -o /dev/null -w "через пул: %{http_code} %{time_total}\n" \
  -x http://185.24.87.14:8000 https://mydomain.ru/

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

Сводная таблица: задача, протокол, потоки, срок

Таблица собирает всё сказанное выше в одну картину. Цифры потоков даны как рабочие ориентиры с запасом относительно расчётной величины.

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

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

Чего покупать не стоит и почему открытые списки не работают

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

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

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

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

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

Что успеть за тестовые два часа перед покупкой

План теста пишется заранее и занимает пол-листа. Без плана первый час уходит на установку софта, и к концу окна на руках оказывается один ответ сервера, по которому картина не складывается.

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

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

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

Какой тип прокси вы даёте?

В пакете идут IPv4 и SOCKS5, из сокетной пары доступны SOCKS-4 и SOCKS-5 на выбор, рекомендуется пятая версия. HTTP и HTTPS работают на тех же адресах, переключение делается в строке подключения, докупать под другой протокол ничего не нужно.

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

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

Можно ли заказать адреса определённой страны?

Пул представляет микс со всего мира, адреса приходят из 200+ стран, выборка по отдельной стране не делается. Для сбора открытых данных, съёма выдачи и разведения рабочих профилей такая схема даёт разнообразие подсетей без ручной настройки.

Чем проверять купленные прокси?

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

Соседние материалы раздела закрывают остальные шаги покупки: бесплатный тест до 2 часов с планом проверки по минутам, порядок покупки от кабинета до первого запроса, как приходит список адресов и что с ним делать дальше. Различия протоколов между собой подробно разобраны в материале про HTTP, HTTPS, SOCKS4 и SOCKS5.

Источник: https://kupit-proxy-ipv4.ru/pokupka/kakie-proxy-pokupat/

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

Три типа продавцов и чем они различаются

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

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

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

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

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

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

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

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

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

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

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

Второй признак это пул. Спрашивать нужно три величины: сколько адресов активно, как часто обновляется список и кому открыт доступ. Наш пул держится в районе 12 000 активных IPv4 и SOCKS5, онлайн держится около той же цифры в сутки, список обновляется в режиме реального времени, доступ открыт только клиентам сервиса.

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

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

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

Протоколы: HTTP, HTTPS, SOCKS4 и SOCKS5

Третий признак определяется вашим софтом. Браузеры и большинство парсеров ходят по HTTP и HTTPS, программы с произвольными портами и приложения на сокетах предпочитают SOCKS. В пакете доступны IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5, из сокетных вариантов мы рекомендуем пятый.

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

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

# HTTP через привязанный адрес
curl -x http://185.24.87.14:8000 https://ifconfig.me

# SOCKS5 с резолвингом на стороне прокси
curl -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

Отдельный сигнал: доплата за смену протокола. Адреса в пакете одни и те же, меняется строка подключения, поэтому переключение между HTTP и сокетным вариантом никак не влияет на состав пакета. Подробности сокетного варианта собраны там, где оформляется доступ по SOCKS5 для программ и скриптов.

Способы доступа и формат выдачи списка

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

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

Пятый признак идёт следом: формат выдачи. Мы выдаём список в двух форматах, 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

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

Лимиты потоков: какая цифра считается рабочей

Потоки это одновременно открытые соединения, которые программа держит к целевым сайтам. A-Parser, ZennoPoster и Key Collector показывают эту величину в настройках прогона. Стандартные пакеты у нас дают до 1000 потоков, корпоративный до 3000.

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

Рабочая цифра выводится из теста. Берём требуемую скорость в запросах за час, умножаем на среднее время отклика в секундах, делим на 3600 и добавляем примерно треть на запас. Прогон на 5 000 запросов в час при отклике в полторы секунды даёт около двух потоков расчётных и три с запасом, а тяжёлые страницы с откликом в восемь секунд поднимают ту же цифру до полутора десятков.

Продавец, который называет лимит потоков «безграничным», говорит о чём угодно, кроме своей инфраструктуры. Понятная цифра в описании пакета удобнее: она сравнивается с расчётом и превращается в выбор варианта за минуту. Сколько адресов и потоков нужно под конкретный объём, посчитано в разборе про число адресов под задачу.

Кабинет, скорость включения и доступность оператора

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

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

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

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

Открытые списки и перепродажа чужих пакетов

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

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

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

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

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

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

Что спросить у поставщика и какой ответ считать рабочим

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

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

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

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

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

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

Что входит в прокси-пул и кому он доступен?

В пуле около 12 000 активных IPv4 и SOCKS5, онлайн держится в районе той же цифры в сутки. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000. Доступ к пулу открыт только клиентам сервиса, в открытом виде список нигде не публикуется.

Прокси каких стран в списке и можно ли отобрать нужные?

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

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

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

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

Источник: https://kupit-proxy-ipv4.ru/pokupka/gde-pokupat/

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

Что определить до покупки: задача, объём, потоки и протокол

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

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

Потоки это одновременно открытые соединения, которые программа держит к целевым сайтам. A-Parser, ZennoPoster и Key Collector показывают эту величину в настройках прогона и там же её ограничивают. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000. Пакеты по потокам не складываются: два стандартных пакета на одном аккаунте не превращаются в 2 тысячи потоков, каждый работает со своим лимитом.

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

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

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

Два часа это много, если план проверки готов заранее. Тот, кто впервые пробовал прогон через пул без плана, обычно тратит первый час на установку софта и получает к концу окна один ответ сервера. Картина по такому прогону не складывается. План занимает пол-листа: авторизация, отклик, поведение целевого сайта, потоки, формат выдачи.

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

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

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

Регистрация в кабинете: что появляется внутри

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

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

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

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

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

Выбор пакета по сроку и числу потоков, оформление и включение

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

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

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

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

Список адресов: как забрать и в каком формате

Список забирается в разделе выдачи. Два формата на выбор: 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

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

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

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

Настройка доступа: привязка адреса или логин с паролем

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

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

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

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

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

# проверка доступа по логину и паролю
curl -x http://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

Первая проверка после подключения

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

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

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

Продление и переход на другой пакет

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

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

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

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

Типичные ошибки покупателей

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

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

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

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

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

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

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

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

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

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

Сколько адресов можно привязать к пакету?

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

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

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

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

Источник: https://kupit-proxy-ipv4.ru/pokupka/kak-kupit/

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

Из чего состоит пакет: шесть строк описания

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

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

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

Доступ к пулу примерно из 12 000 адресов

Первое, что даёт пакет, это доступ к пулу. Мы держим около 12 000 активных IPv4 и SOCKS5, онлайн держится в районе той же цифры в сутки. Доступ открыт только клиентам сервиса, в открытом виде список нигде не публикуется.

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

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

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

Автоматическая ротация внутри пула

Ротация в пакете работает сама. Мы перебираем адреса внутри пула автоматически, поэтому распределять их по потокам руками не требуется. Программа получает список и работает, а смена адреса на выходе происходит без участия администратора.

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

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

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

# десять запросов подряд через список из кабинета
for i in $(seq 1 10); do
  curl -s -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me
  echo
done

Безлимитный трафик и что он убирает из расчётов

Трафик в пакете безлимитный. Счётчика гигабайтов нет, доплаты за объём нет, объём выкачанных страниц на выбор пакета не влияет. Это снимает целый класс расчётов, который обычно съедает время перед покупкой.

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

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

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

Лимит одновременных потоков: 1000, до 3000 и правило сложения

Потоки это одновременно открытые соединения, которые программа держит к целевым сайтам. Мы даём до 1000 потоков на стандартных пакетах и до 3000 на корпоративном. Величина видна в настройках прогона у A-Parser, ZennoPoster и Key Collector, там же она ограничивается сверху. Сокетный вариант подключения для тех же программ разобран на странице про прокси SOCKS5 для программ и скриптов.

Расчёт нужной цифры короткий. Берём требуемую скорость в запросах за час, умножаем на среднее время отклика в секундах, делим на 3600 и добавляем примерно треть на запас. Прогон на 20 000 страниц за ночь при восьми часах работы даёт 2 500 запросов в час, при отклике в две секунды это около полутора потоков расчётных и два с запасом. Тяжёлые страницы с откликом в десять секунд поднимают ту же цифру до семи потоков, и разница между этими режимами видна только на тесте с реальными доменами.

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

Почему пакеты по потокам не складываются

Правило простое: у каждого пакета свой лимит потоков, и лимиты разных пакетов между собой не суммируются. Два стандартных пакета на одном аккаунте не превращаются в 2 000 потоков. Каждый работает со своей верхней границей, независимо от соседнего.

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

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

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

Две привязки адреса и деление лимита пополам

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

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

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

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

Выдача списка: два формата, ссылка или файл

Список адресов выдаётся в двух форматах. 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

Забрать список можно двумя путями: получить ссылку или скачать файл. Ссылка удобна там, где софт умеет подтягивать список сам: A-Parser, ZennoPoster и планировщики принимают адрес выдачи и обновляют строки перед каждым запуском. Файл проще для ручного импорта в антидетект-сборку и для раздачи внутри команды.

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

Протоколы, включение пакета и сроки доступа

Протоколы идут в пакете все сразу. IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5 доступны без доплаты, адреса при этом одни и те же, меняется только строка подключения. Из сокетных вариантов мы рекомендуем SOCKS5: он умеет передавать доменное имя на сторону прокси и принимает авторизацию по логину.

# HTTP через привязанный адрес
curl -x http://185.24.87.14:8000 https://ifconfig.me

# SOCKS5 с авторизацией и резолвингом на стороне прокси
curl -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

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

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

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

Как состав пакета превращается в рабочие цифры

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

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

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

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

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

Что входит в прокси-пул?

В пуле около 12 000 активных IPv4 и SOCKS5, онлайн держится в районе той же цифры в сутки. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000. Доступ к пулу открыт только клиентам сервиса, список обновляется в режиме реального времени.

Есть ли лимиты по потокам и как они считаются?

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

Сколько адресов можно привязать к пакету и что делать при меняющемся адресе?

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

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

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

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

Источник: https://kupit-proxy-ipv4.ru/pokupka/chto-vhodit-v-paket/

Дальше идёт разбивка окна по отрезкам, набор замеров с командами и правило, по которому цифры теста превращаются в выбор пакета. Общий порядок покупки разобран отдельно в материале про покупку прокси 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:pf39kd@185.24.87.14:8000 https://ifconfig.me

# SOCKS5 с резолвингом доменных имён на стороне прокси
curl -s -x socks5h://user5521:pf39kd@185.24.87.14: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. Забрать список можно ссылкой или файлом, оба варианта доступны в кабинете, и список обновляется в режиме реального времени. Импорт в свою программу стоит проверить прямо внутри тестового окна.

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

Источник: https://kupit-proxy-ipv4.ru/pokupka/besplatnyy-test/

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

Какие сроки доступа есть и чем они отличаются

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

Сутки закрывают ситуацию, когда объём известен заранее и работа заканчивается в один заход. Выгрузили каталог поставщика, сверили остатки, проверили свой сайт из другой сети, доступ отработал и закрылся.

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

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

За что платит срок доступа

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

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

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

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

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

Характер задачи задаёт срок

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

Границы между типами размытые, и в спорном случае мы советуем брать ступень выше. Задача с формулировкой «попробуем неделю, дальше посмотрим» через две недели превращается в постоянную, и продлевать сутками семь раз подряд утомительнее, чем один раз оформить месяц.

Работает и обратная проверка. Если задача звучит как «собрать один раз и забыть», длинный срок пользы не добавит: пул тот же, потоки те же, доступ просто останется открытым дольше нужного.

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

Арифметика: как посчитать срок под объём

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

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

страницы:            180 000
скорость прогона:    9 000 страниц в час
время прогона:       180 000 / 9 000 = 20 часов
запас на разбор:     20 * 0,35 = 7 часов
итого:               27 часов

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

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

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

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

Разовый прогон упирается в число потоков

Самая частая ошибка при выборе срока звучит так: «объём большой, возьмём месяц». Месяц при разовой выгрузке ничего не ускоряет. Прогон, который считался по формуле выше на 27 часов, займёт эти же 27 часов и на суточном, и на месячном варианте: скорость задаётся числом одновременных соединений и откликом целевой площадки.

Ускорение приходит из другого места. Двадцать потоков при медиане ответа 3 секунды дают около 24 000 страниц за час теоретического потолка, при этом реальная цифра ниже из-за пауз и повторов. Поднимаем потоки до сотни, и расчётное время сжимается пропорционально, пока целевой сайт держит частоту.

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

Верхняя граница у потоков тоже есть. Стандартный пакет держит до 1000 одновременных соединений, корпоративный до 3000. Пакеты по потокам не складываются: два стандартных пакета на одном аккаунте работают каждый со своим лимитом и в сумму не собираются. Поэтому рост нагрузки закрывается переходом на старший вариант.

Серия проверок и постоянная работа

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

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

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

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

Продление и переход на другой пакет

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

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

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

Срок и две привязки адреса

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

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

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

Есть и обходной путь для машин, которых больше двух. Формат выдачи IP:PORT:LOGIN:PASS авторизует запросы парой логина и пароля, и привязка адреса машины для него не требуется. Такой вариант удобен облачным сборщикам и серверам с меняющимся адресом, а лимит потоков при этом остаётся общим по пакету. Оба способа доступа входят в пакет, и переключаться между ними разрешено в любой момент.

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

Когда берут корпоративный месяц

Корпоративный месяц отличается потолком потоков: до 3000 против 1000 на стандартных вариантах. Берут его в трёх ситуациях, и все три опознаются по цифрам из расчёта. Размер компании тут ни при чём: мы регулярно видим корпоративный вариант у одного администратора с тремя серверами.

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

Вторая: агентство ведёт параллельные проекты клиентов. Расписание съёма выдачи, сбор прайсов и проверка страниц идут в одни и те же часы, суммарная нагрузка складывается, и потолок в 1000 соединений становится узким местом всей связки.

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

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

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

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

Какие сроки доступа есть у пакетов?

Доступны сутки, неделя, месяц и корпоративный месяц. Трафик безлимитный на всех вариантах, различие идёт по длительности доступа к пулу и по потолку одновременных потоков: до 1000 на стандартных пакетах и до 3000 на корпоративном.

Складываются ли потоки, если взять два пакета сразу?

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

Сколько адресов можно привязать и как это влияет на срок?

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

Как понять, какой срок нужен, до покупки?

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

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

Источник: https://kupit-proxy-ipv4.ru/pokupka/srok-dostupa/

Дальше разобрано, чем эти два формата отличаются на практике, почему ссылка удобнее файла при регулярной работе, как распарсить строку списка в bash и python, как превратить сырые строки в конфиг для curl, requests, A-Parser, ZennoPoster и антидетект-браузера, и как настроить автоматическую подтяжку списка перед каждым прогоном.

Два формата строки: что стоит за двоеточиями

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

# формат из двух полей, доступ по привязанному адресу
185.24.87.14:8000
185.24.87.15:8000
92.118.44.203:8000

Формат IP:PORT:LOGIN:PASS добавляет к тем же двум полям учётные данные. Логин и пароль едут внутри самой строки, поэтому запрос авторизуется откуда угодно и привязка машины при этом не требуется. Формат берут те, у кого прогон идёт с нескольких серверов сразу, или те, кто гоняет задачи в облачном сборщике, где внешний адрес заранее неизвестен.

# формат из четырёх полей, доступ по учётным данным
185.24.87.14:8000:user5521:pf39kd
185.24.87.15:8000:user5521:pf39kd
92.118.44.203:8000:user5521:pf39kd

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

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

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

Ссылка на выдачу и файл: чем они отличаются в работе

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

Файл удобен один раз. Человек скачал его, открыл, скопировал десяток строк в поле программы и пошёл работать. Такой путь закрывает разовую задачу: проверить сайт со стороны, прогнать сотню страниц, посмотреть, как целевой домен отвечает через посредника.

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

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

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

Почему список обновляется и что происходит со старым файлом

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

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

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

# быстрый ответ на вопрос «список свежий или нет»
# берём первые 30 строк и смотрим, сколько из них отвечает
head -n 30 proxy.txt | while IFS=: read -r ip port user pass; do
  code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 8 \
    -x "http://${user:+$user:$pass@}$ip:$port" https://ifconfig.me)
  echo "$ip:$port -> ${code:-timeout}"
done

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

Разбор строки списка в bash

Строка списка разбирается по двоеточию. В bash для этого хватает встроенного read с заданным разделителем, внешние утилиты не нужны. Разделитель задаётся через IFS, поля читаются в переменные, пустые хвостовые поля остаются пустыми.

#!/bin/bash
# proxy.txt содержит строки IP:PORT либо IP:PORT:LOGIN:PASS
while IFS=: read -r ip port user pass; do
  [ -z "$ip" ] && continue
  if [ -n "$user" ]; then
    echo "http://$user:$pass@$ip:$port"
  else
    echo "http://$ip:$port"
  fi
done < proxy.txt > proxy-urls.txt

Скрипт на выходе даёт готовые URL посредника, которые принимает почти любая программа. Тот же цикл переписывается под SOCKS5 заменой схемы в двух местах. Если нужны обе схемы сразу, добавляется второй echo со схемой socks5h://, и один список превращается в два файла под разные задачи.

# счётчик полей: понять, какой формат пришёл, до всякого разбора
awk -F: '{print NF}' proxy.txt | sort -u
# 2  -> IP:PORT
# 4  -> IP:PORT:LOGIN:PASS

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

# увидеть невидимое
cat -A proxy.txt | head -n 3
# убрать возврат каретки, если он есть
tr -d '\r' < proxy.txt > proxy-fixed.txt

Разбор строки списка в python

В python разбор строится на split(':') с проверкой числа полей. Функция ниже принимает строку любого из двух форматов и возвращает словарь с готовыми URL под HTTP и SOCKS5, а также отдельные поля для программ, которые ждут логин и пароль в разных полях интерфейса.

import re

LINE = re.compile(r'^\s*(\d{1,3}(?:\.\d{1,3}){3}):(\d{1,5})(?::([^:\s]+):([^:\s]+))?\s*$')

def parse(line):
    m = LINE.match(line)
    if not m:
        return None
    ip, port, user, password = m.groups()
    auth = f'{user}:{password}@' if user else ''
    return {
        'host': ip,
        'port': int(port),
        'user': user,
        'password': password,
        'http': f'http://{auth}{ip}:{port}',
        'socks5': f'socks5h://{auth}{ip}:{port}',
    }

def load(path):
    out = []
    with open(path, encoding='utf-8') as f:
        for raw in f:
            item = parse(raw)
            if item:
                out.append(item)
    return out

pool = load('proxy.txt')
print(len(pool), 'строк принято')

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

Готовый список сразу подставляется в requests. Библиотека ждёт словарь со схемами, поэтому конвертация занимает одну строку.

import requests, random

p = random.choice(pool)
proxies = {'http': p['http'], 'https': p['http']}
r = requests.get('https://ifconfig.me', proxies=proxies, timeout=10)
print(r.status_code, r.text.strip())

Обратите внимание на ключ https в словаре: там стоит схема http. Так и должно быть. Ключ обозначает протокол целевого адреса, значение обозначает адрес посредника, и для HTTPS-запросов через HTTP-посредник поднимается туннель, тип которого от схемы в словаре не зависит. Пакет с HTTP и HTTPS оформляется на странице, где мы даём доступ к пулу по HTTP и HTTPS.

Как превратить список в формат конкретных программ

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

curl принимает строку целиком, включая учётные данные. Проверка одного адреса выглядит так:

# HTTP-посредник, доступ по привязке машины
curl -x http://185.24.87.14:8000 https://ifconfig.me
# HTTP-посредник, доступ по учётным данным
curl -x http://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me
# SOCKS5 с разрешением имён на стороне выхода
curl -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

A-Parser читает список из файла либо тянет его по адресу выдачи, причём второй путь настраивается прямо в настройках парсера и обновляется по расписанию. Формат строки там сетевой, со схемой впереди, поэтому файл proxy-urls.txt из bash-скрипта выше подходит без правок. Подробности настройки собраны на странице про работу A-Parser через пул адресов.

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

Антидетект-браузер разносит поля по карточке профиля: тип посредника, хост, порт, логин, пароль. Копирование строки целиком в поле хоста приводит к отказу соединения, поэтому строку разбивают заранее. Скрипт на python выше отдаёт готовые поля host, port, user, password, которые остаётся разложить по колонкам таблицы импорта. Особенности профилей описаны на странице про прокси для антидетект-браузеров.

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

export http_proxy="http://user5521:pf39kd@185.24.87.14:8000"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1,10.0.0.0/8"

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

Автоматическая подтяжка списка перед прогоном

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

#!/bin/bash
# refresh-proxy.sh, запускается из планировщика перед каждым прогоном
URL="$PROXY_LIST_URL"          # адрес выдачи берём из окружения
DST="/opt/run/proxy.txt"
TMP="$(mktemp)"

curl -fsS --max-time 20 "$URL" | tr -d '\r' | grep -E '^[0-9.]+:[0-9]+' > "$TMP"

lines=$(wc -l < "$TMP")
if [ "$lines" -lt 50 ]; then
  echo "выдача вернула $lines строк, оставляем прежний файл" >&2
  rm -f "$TMP"; exit 1
fi

mv "$TMP" "$DST"
chmod 600 "$DST"
echo "список обновлён: $lines строк"

Три вещи в этом скрипте держат прогон на ногах. Флаг -fsS заставляет curl вернуть ненулевой код при ответе сервера с ошибкой, вместо того чтобы записать текст ошибки в файл списка. Фильтр grep отсекает всё, что не похоже на строку адреса. Порог в 50 строк отбивает случай, когда выдача ответила коротким телом из-за сетевого сбоя.

В python то же самое укладывается в полтора десятка строк, если прогон запускается изнутри питоновского скрипта.

import os, requests

def refresh(dst='proxy.txt', minimum=50):
    r = requests.get(os.environ['PROXY_LIST_URL'], timeout=20)
    r.raise_for_status()
    lines = [l.strip() for l in r.text.splitlines() if parse(l)]
    if len(lines) < minimum:
        raise RuntimeError(f'выдача вернула {len(lines)} строк')
    tmp = dst + '.new'
    with open(tmp, 'w', encoding='utf-8') as f:
        f.write('\n'.join(lines) + '\n')
    os.replace(tmp, dst)
    os.chmod(dst, 0o600)
    return len(lines)

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

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

Где держать список и как его не оставить в открытом виде

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

Порядок хранения короткий и понятный. Права на файл выставляются в 600, владелец служебный, каталог лежит вне репозитория и вне общего сетевого диска.

# файл читает только владелец процесса
chmod 600 /opt/run/proxy.txt
chown runner:runner /opt/run/proxy.txt
# каталог закрыт целиком
chmod 700 /opt/run

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

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

Что делать, когда часть строк из списка не отвечает

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

Код 407 говорит о доступе. Он приходит, когда сервер ждёт учётные данные, а запрос пришёл без них, либо когда прогон идёт с машины, чей адрес в привязке не значится. Проверяется это одной командой с ключом -v, где видно и заголовок ответа, и адрес источника.

curl -v -x http://185.24.87.14:8000 https://ifconfig.me 2>&1 | grep -i 'HTTP/1.1 407'

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

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

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

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

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

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

Как часто обновляется список адресов?

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

Прокси каких стран приходят в списке?

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

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

Источник: https://kupit-proxy-ipv4.ru/pokupka/format-vydachi/

Отсюда вытекает всё остальное: какие программы примут какой вариант, как выглядит строка подключения, где резолвится доменное имя и что посредник вообще способен увидеть по дороге. Ниже разобраны четыре протокола по порядку, показаны схемы строк http://, https://, socks4://, socks5:// и socks5h://, приведены рабочие команды curl и сведена сравнительная таблица по всем признакам сразу.

Уровни: где именно стоит посредник

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

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

Разница уровня объясняет странность, которая сбивает новичков. Один и тот же адрес и порт из списка работает и как HTTP-посредник, и как SOCKS5: сервер понимает, чего от него хотят, по первым байтам соединения. Мы выдаём в пакете сразу IPv4 с HTTP и HTTPS плюс SOCKS4 и SOCKS5, поэтому переключение протокола в программе не требует ни новых адресов, ни доплаты.

HTTP-прокси: посредник читает запрос

При работе по HTTP программа отправляет посреднику запрос с абсолютным адресом в стартовой строке. Выглядит это так:

GET http://example.com/catalog/page-2 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Proxy-Authorization: Basic dXNlcjU1MjE6cGYzOWtk
Accept-Encoding: gzip, deflate

Посредник видит здесь всё: метод, полный путь, строку агента, кодировки, cookie, тело POST-запроса. Он способен добавить свои заголовки, снять свои служебные поля перед отправкой и вернуть ответ обратно программе. Именно поэтому у HTTP-варианта есть собственный код отказа: 407 Proxy Authentication Required приходит от посредника, целевой сервер о запросе при этом даже не узнаёт.

Такая осведомлённость даёт удобства. HTTP-прокси умеет кешировать ответы, писать журнал по адресам, работать с заголовком Proxy-Authorization отдельно от авторизации на целевом сайте. Браузеры и парсеры выросли вокруг этого протокола, поэтому поддержка у него самая широкая: поле «HTTP-прокси» есть буквально везде.

# обычный запрос через HTTP-посредник
curl -x http://185.24.87.14:8000 http://example.com/robots.txt

# то же самое с учётными данными пакета
curl -x http://user5521:pf39kd@185.24.87.14:8000 http://example.com/robots.txt

# посмотреть служебный обмен целиком
curl -v -x http://185.24.87.14:8000 http://example.com/ 2>&1 | head -n 25

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

HTTPS через прокси: туннель поверх того же порта

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

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjU1MjE6cGYzOWtk

HTTP/1.1 200 Connection established

После строки 200 Connection established посредник теряет доступ к содержимому. Он знает имя хоста и порт из преамбулы, знает объём переданных байтов и длительность сессии. Пути, заголовки, cookie и тело ответа остаются внутри шифрования. Механика самого туннеля разобрана отдельно в материале про туннель CONNECT и работу с шифрованием, здесь достаточно самого факта.

Практический вывод для настройки: отдельного «HTTPS-порта» у посредника обычно нет. Тот же адрес и тот же порт принимают и обычные запросы, и запросы на открытие туннеля, сервер различает их по методу. Именно поэтому в конфигах библиотек ключ https часто указывает на строку со схемой http, и это правильная запись.

# HTTPS-адрес через тот же HTTP-посредник, туннель поднимается сам
curl -x http://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

# увидеть строку установки туннеля
curl -v -x http://185.24.87.14:8000 https://example.com/ 2>&1 | grep -i 'CONNECT\|established'

Схема https:// в самом ключе -x означает другое: шифрование самого канала до посредника. Такой режим поддерживают немногие программы, и в списке адресов он отражается настройкой на стороне сервера, схема строки при этом остаётся прежней. Состав пакета с шифрованным вариантом описан на странице, где собран доступ по HTTPS с туннелем до целевого узла.

SOCKS: посредник на уровне соединения

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

Из этого следуют три свойства, ради которых SOCKS и берут.

Первое: протокол внутри не имеет значения. По SOCKS ходят HTTP, SMTP, IMAP, POP3, FTP, обмен внутри игровых клиентов, произвольные бинарные протоколы собственной разработки. Посреднику всё равно, он переносит байты.

Второе: порт назначения любой. HTTP-посредник обычно ограничен разумным набором портов, сокетный вариант открывает соединение на 25, 587, 993, 5222 или 27015 без особых настроек.

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

# SOCKS5 с учётными данными
curl -x socks5://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

# SOCKS4, учётных данных в протоколе нет
curl -x socks4://185.24.87.14:8000 http://example.com/

# проверка произвольного порта, который HTTP-вариант обычно не пропускает
curl -x socks5h://user5521:pf39kd@185.24.87.14:8000 -v smtp://smtp.example.com:587

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

SOCKS4 и SOCKS5: три реальных отличия

Версии различаются тремя вещами, и все три ощущаются в работе.

Доступ по логину и паролю

SOCKS4 умеет передавать только идентификатор пользователя, поле в преамбуле короткое и проверку пароля не подразумевает. SOCKS5 описывает отдельный этап согласования метода: клиент перечисляет, что умеет, сервер выбирает, и при выборе метода с учётными данными идёт обмен парой логина и пароля. Поэтому строка socks5://user:pass@host:port работает, а socks4://user:pass@host:port пару молча теряет.

Доменные имена

SOCKS4 принимает в преамбуле адрес в виде четырёх байтов, то есть готовый IPv4. Программа обязана разрешить имя сама. SOCKS5 добавил тип адреса «доменное имя», и клиент отправляет строку example.com целиком, а разрешением занимается сервер на выходе. Это меняет картину запросов к службе имён и закрывает целый класс расхождений между тем, что видит программа, и тем, куда она реально попадает.

UDP

SOCKS4 переносит только TCP. SOCKS5 описывает отдельную команду UDP ASSOCIATE, через которую можно переносить датаграммы. Что именно из этого работает на практике и какие программы умеют пользоваться этим механизмом, разобрано отдельно в материале про TCP и UDP через SOCKS5.

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

Проверить, какая версия реально согласовалась, проще всего подробным выводом curl. При SOCKS5 в логе видна строка о выборе метода доступа, при SOCKS4 сразу идёт запрос соединения. Мы смотрим на эту строку каждый раз, когда пара логина и пароля вроде бы указана верно, а сервер отвечает отказом: половина таких случаев объясняется схемой socks4://, оставшейся в конфиге с прошлого прогона. Обе версии открыты в пакете, где мы держим сокетный доступ к пулу IPv4.

Схемы строк подключения и разница между socks5 и socks5h

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

Буква h в конце socks5h расшифровывается как hostname и означает ровно одно: доменное имя уезжает на сервер строкой и разрешается там. При схеме socks5:// библиотека сначала спрашивает у своей службы имён, какой адрес стоит за example.com, и только потом просит посредника соединиться с полученным адресом.

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

# имя разрешает локальная машина
curl -x socks5://user5521:pf39kd@185.24.87.14:8000 https://example.com/

# имя разрешает сервер на выходе
curl -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://example.com/

# короткая проверка: совпадает ли адрес на выходе с ожидаемым
curl -s -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

В python отличие выражается той же буквой внутри словаря схем.

proxies_local = {'https': 'socks5://user5521:pf39kd@185.24.87.14:8000'}
proxies_remote = {'https': 'socks5h://user5521:pf39kd@185.24.87.14:8000'}

Мы советуем ставить socks5h везде, где программа это принимает. Стоит это ничего, поведение становится предсказуемее, и вопрос «почему адрес показывается верно, а сайт ведёт себя странно» снимается сам собой.

Полная сравнительная таблица по четырём протоколам

Ниже сведены все признаки, по которым протоколы расходятся в реальной настройке.

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

Строку про коды отказа тоже стоит прочитать внимательно. У прикладного варианта отказ приходит текстом со статусом 407 и заголовком Proxy-Authenticate, его видно в любом логе и в любой панели разработчика. У сокетного варианта ответ бинарный, один байт кода, и программы переводят его в собственные сообщения вида «connection refused by proxy» либо «general SOCKS server failure». Из-за этого одна и та же причина отказа выглядит по-разному в зависимости от схемы, и мы всегда просим уточнять протокол, когда разбираем обращение по конкретному прогону.

Ещё один практический момент касается заголовков. Прикладной посредник способен добавить служебные поля вроде Via или X-Forwarded-For, сокетный такой возможности лишён по устройству протокола. Что именно уходит на целевой сервер в каждом режиме, проверяется одним обращением к сервису, который печатает полученные заголовки обратно.

Что выбирать под браузер, парсер, почту и произвольную программу

Выбор сводится к тому, что принимает софт и какой порт ему нужен.

Браузер. Настройки браузера принимают оба варианта. HTTP покрывает обычный сёрфинг и любые обращения к сайтам, включая HTTPS через туннель. SOCKS5 берут, когда важно, чтобы имена разрешались на выходе: в Chromium это включается ключом запуска, в Firefox галочкой в окне настроек.

# Chromium через SOCKS5 с разрешением имён на выходе
chromium --proxy-server="socks5://185.24.87.14:8000" \
  --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 185.24.87.14"

Парсер. A-Parser, Key Collector и подобные программы работают по HTTP и HTTPS, потому что собирают именно веб-страницы. Список подставляется целиком, потоки считаются по пакету, схема остаётся http://. Сокетный вариант там тоже принимается, выигрыша в скорости он не даёт, зато закрывает вопрос с обращениями к службе имён.

Почтовый клиент. SMTP, IMAP и POP3 ходят по своим портам, поэтому здесь берут SOCKS5. Прикладной посредник почтовые протоколы не понимает: он разбирает HTTP, и байты SMTP для него бессмысленны. Порядок отправки писем через сокетный доступ подробно разобран в материале про отправку почты через прокси.

Произвольная программа. Всё, что открывает TCP-соединение на нестандартный порт, идёт через SOCKS5. Игровые клиенты, обменники сообщений, самописные сервисы, клиенты баз данных. Если у программы есть поле «SOCKS-прокси», туда кладётся хост, порт и пара логина и пароля из списка.

Все четыре протокола входят в один пакет и работают на одном пуле примерно из 12 000 адресов, поэтому смена протокола в софте не требует ни новой покупки, ни нового списка. Состав пакета целиком описан на странице, где оформляется доступ к пулу IPv4 с полным набором протоколов.

Как проверить, что выбранный протокол реально работает

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

# адрес на выходе по HTTP
curl -s -x http://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

# адрес на выходе по SOCKS5
curl -s -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

# код ответа целевого домена, без тела
curl -s -o /dev/null -w '%{http_code}\n' \
  -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://example.com/

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

Если по HTTP запрос проходит, а по SOCKS отваливается, смотрим на схему и на порт: часть программ подставляет собственный порт по умолчанию при смене схемы. Если по SOCKS5 приходит отказ на этапе согласования, проверяем пару логина и пароля: SOCKS4 её игнорирует и создаёт ложное впечатление рабочей настройки. Серверная природа адресов при этом одинакова для всех четырёх протоколов, подробности собраны на странице про серверные адреса собственного оборудования.

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

Какой тип прокси вы даёте?

В пакете IPv4 и SOCKS5 доступны SOCKS-4 и SOCKS-5 на выбор, рекомендуем SOCKS-5. Прикладные варианты HTTP и HTTPS работают на тех же адресах, поэтому переключение протокола делается настройкой в программе.

Нужно ли покупать отдельный пакет под SOCKS5?

Отдельная покупка не требуется. Протоколы IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5 входят в один пакет, список адресов при смене протокола остаётся прежним, меняется только схема в строке подключения.

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

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

Что входит в прокси-пул?

Около 12 000 активных IPv4 и SOCKS5. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000, доступ к пулу открыт клиентам сервиса. Список адресов обновляется в режиме реального времени и забирается ссылкой или файлом.

Разбор протоколов продолжается в соседних материалах раздела: как устроен протокол SMTP с разбором пути письма, порты 25, 465 и 587 и выбор между ними, приём почты по IMAP и POP3 через сокетный доступ. Когда протокол выбран, поля строки подключения разложены по частям в материале про разбор строки подключения.

Источник: https://kupit-proxy-ipv4.ru/protokoly/http-https-socks/

Ниже разобрано, откуда взялся такой порядок, как выглядит обмен на уровне байтов, где внутри туннеля живёт заголовок Proxy-Authorization, какие коды приходят на этапе установки и почему через тот же механизм проходит не только HTTPS. Команды даны такие, чтобы обмен можно было посмотреть своими глазами за минуту.

Откуда взялся метод CONNECT

Обычный HTTP через посредник устроен прямолинейно. Клиент отправляет прокси полную строку с абсолютным адресом, GET http://example.com/page HTTP/1.1, посредник читает её целиком, сам идёт на целевой сервер, забирает ответ и отдаёт его обратно. Пока содержимое открыто, схема работает без оговорок: прокси видит путь, заголовки, тело и коды ответа.

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

Выход описали отдельным методом. CONNECT переводит посредника из режима разбора запросов в режим транспорта: прокси открывает TCP-соединение до узла, подтверждает готовность и дальше работает как труба. Метод закреплён в RFC 7231 и уточнён в RFC 9110, поддержка есть у всех распространённых прокси-серверов и у любого браузера. Мы держим этот механизм включённым на всех адресах пула, поэтому прокси HTTPS с поддержкой туннеля CONNECT работают с браузерами и парсерами без дополнительной настройки на стороне сервера.

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

Как выглядит обмен на установку туннеля и что идёт дальше

Обмен занимает две строки плюс пустая строка на каждой стороне. Клиент открывает TCP-соединение с прокси и отправляет:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjU1MjE6cGYzOWtk
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/5.0

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

Прокси разрешает имя example.com в адрес, открывает к нему TCP-соединение на порт 443 и, если всё сложилось, отвечает:

HTTP/1.1 200 Connection established
Proxy-Agent: proxy/1.1

Слово в статусной строке может отличаться: встречаются 200 Connection established, 200 OK и 200 Tunnel established. Значение одно, клиент смотрит на код. После пустой строки соединение перестаёт быть HTTP-обменом, и первым байтом от клиента идёт уже ClientHello протокола TLS.

Момент отправки 200 меняет роль прокси-сервера полностью. До подтверждения он работал разборщиком HTTP: читал строку запроса, проверял заголовки, проверял право доступа. После подтверждения он держит два сокета и копирует байты между ними, пока одна из сторон не закроет соединение.

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

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

Одно соединение туннеля обслуживает всю сессию с узлом. Браузер открывает CONNECT к example.com:443 один раз, поднимает TLS и дальше гоняет внутри десятки HTTP-запросов по тому же каналу. Когда параллельно нужен второй узел, поднимается второй туннель со своей строкой CONNECT. При работе в много потоков это стоит держать в голове: число одновременных туннелей равно числу открытых соединений, и оно упирается в лимит потоков пакета.

Где живёт Proxy-Authorization и почему он уходит один раз

Заголовок Proxy-Authorization относится к отрезку между клиентом и посредником. Он несёт пару логина и пароля в виде Basic с кодированием base64 и обрабатывается прокси-сервером. До целевого сервера он не доходит никогда: посредник снимает его при обработке, а в туннельном режиме он физически не может попасть дальше, потому что после подтверждения посредник уже ничего не пишет в поток.

Отсюда правило, которое объясняет половину вопросов по настройке. Учётные данные уходят ровно один раз, в самом запросе CONNECT. Всё, что клиент отправит после 200 Connection established, зашифровано и адресовано целевому серверу. Прокси не разберёт эти байты и не найдёт там никаких заголовков, поэтому авторизоваться внутри поднятого туннеля невозможно по устройству механизма.

Практика из этого вытекает такая:

# curl подставляет Proxy-Authorization в CONNECT самостоятельно
curl -v -x http://user5521:pf39kd@185.24.87.14:8000 https://example.com

# та же пара отдельным ключом, результат идентичный
curl -v --proxy 185.24.87.14:8000 --proxy-user user5521:pf39kd https://example.com

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

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

Коды ответа на этапе установки туннеля

До подтверждения посредник отвечает обычными кодами HTTP, и каждый несёт свою причину. Разбор занимает секунды, если знать, что означает конкретная цифра.

Код 407 приходит с заголовком Proxy-Authenticate: Basic realm="proxy", который подсказывает клиенту нужную схему. Браузер на этот код показывает окно с полями логина и пароля, curl печатает ответ и завершает работу. Причина обычно сидит в одном из трёх мест: опечатка в паре, привязка оформлена на прежний адрес машины, программа отправила заголовок под неправильным именем. Мы разбираем такие обращения по логину и типу прокси, ответ приходит одним сообщением.

Код 403 на этапе CONNECT чаще всего означает запрет порта. Многие посредники пропускают через туннель только 443 и несколько известных портов, поэтому попытка открыть канал на нестандартный порт заканчивается отказом ещё до соединения. Наш пул пропускает произвольные порты, поэтому такой код тут указывает на другое: доступ к конкретному узлу закрыт или пакет неактивен.

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

# смотрим, отвечает ли цель напрямую с этой машины
curl -v --connect-timeout 5 https://example.com -o /dev/null

# проверяем порт отдельно, без TLS и без HTTP
nc -vz example.com 443

Что видит посредник до и после туннеля

Разделение по времени тут строгое: до отправки 200 посредник читает открытый текст, после подтверждения он копирует байты. Таблица показывает, что остаётся доступным на каждом отрезке.

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

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

Заголовки, которые видны посреднику до туннеля, тоже стоит держать под контролем. User-Agent в запросе CONNECT отправляют не все клиенты, Proxy-Connection встречается у браузеров, Via и X-Forwarded-For добавляет уже сам посредник, если настроен так. Мы служебных пометок в туннель не подмешиваем, и анонимные адреса без служебных заголовков отдают целевому серверу ровно то, что отправил клиент.

Почему через CONNECT проходит не только HTTPS

Метод не привязан к TLS ни одной строкой. В запросе указывается пара из имени узла и номера порта, посредник открывает TCP-соединение и передаёт байты. Что именно поедет внутри, механизму безразлично: там может идти TLS, открытый текст, бинарный протокол или обмен, придуманный самим приложением.

Отсюда список того, что реально ходит через туннель на практике:

Ограничение тут ставит сам посредник списком разрешённых портов. Классическая настройка Squid разрешает CONNECT только на 443 и 563, поэтому почтовый клиент через такой прокси не пройдёт. Наш пул работает с произвольными портами, и почтовые задачи закрываются тем же способом, что и веб: разбор отправки писем собран в материале про SMTP через прокси.

Один момент туннель не покрывает: транспорт остаётся строго TCP. Обмен по UDP через CONNECT провести нельзя, потому что механизм построен на установленном TCP-соединении. Программам, которым нужен UDP, подходит сокетный протокол с отдельной командой, и там работает прокси SOCKS5 для произвольных портов и протоколов.

Как посмотреть обмен своими глазами

Первый инструмент это curl с ключом -v. Он печатает обе стороны обмена с посредником, включая строку CONNECT и ответ на неё. Строки с > идут от клиента, строки с < приходят от прокси.

curl -v -x http://185.24.87.14:8000 https://example.com -o /dev/null

Полезная часть вывода выглядит так:

* Connected to 185.24.87.14 (185.24.87.14) port 8000
* allocate connect buffer
* Establish HTTP proxy tunnel to example.com:443
> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
> User-Agent: curl/8.5.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* CONNECT phase completed
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate: example.com

Строка Establish HTTP proxy tunnel отмечает начало установки, CONNECT phase completed отмечает конец. Всё, что идёт после неё, относится уже к обмену с целевым сервером через поднятый канал. Если туннель не поднялся, вместо 200 в этом месте будет код отказа, и дальше вывод оборвётся.

Второй инструмент показывает сторону TLS подробнее. openssl s_client умеет ходить через посредника ключом -proxy и печатает цепочку сертификатов, версию протокола и выбранный шифр:

openssl s_client -proxy 185.24.87.14:8000 -connect example.com:443 -servername example.com

В выводе смотрим на четыре вещи: строку CONNECTED, цепочку Certificate chain, поле Verify return code: 0 (ok) и согласованную версию TLSv1.3. Нулевой код проверки подтверждает, что сертификат целевого сервера дошёл до клиента без подмены, и туннель отработал честной трубой. Когда пакет требует авторизации по логину, к команде добавляется ключ -proxy_user:

openssl s_client -proxy 185.24.87.14:8000 -proxy_user user5521 -connect example.com:443

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

tcpdump -i any -A -n 'host 185.24.87.14 and port 8000' -c 40

Разбор случаев, когда туннель не поднимается

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

Второй случай интереснее. Туннель поднялся, 200 пришло, а дальше соединение обрывается на TLS-рукопожатии с сообщением вроде SSL routines::unexpected eof while reading. Тут посредник свою часть выполнил, и разбираться нужно с целевым узлом: он может отвечать на 443 чем-то отличным от TLS, требовать SNI или закрывать соединения от незнакомых сетей.

Третий случай встречается у программ со своим сетевым стеком. Клиент отправляет вместо CONNECT обычный GET https://example.com/, посредник получает запрос с абсолютным адресом на схеме https и отвечает отказом. Лечится настройкой: в программе указывается прокси именно как HTTP-посредник для схемы HTTPS, тогда библиотека сама переключится на туннельный режим. Мы проверяем эту настройку первой, когда программа отказывается работать по шифрованной схеме.

Четвёртый случай связан с числом одновременных туннелей. Каждый CONNECT удерживает соединение, пока клиент его не закроет, и при агрессивных настройках парсера открытых каналов набирается больше, чем даёт лимит пакета. Стандартные пакеты держат до 1000 потоков, корпоративный до 3000, при двух привязанных адресах общее число делится пополам. Когда прогон упирается в потолок, часть запросов повисает в ожидании, и в логах это выглядит как таймауты без кода ответа.

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

Туннель в браузере и в программах

Браузер выбирает режим сам по схеме адреса. Ввод http:// даёт обычное проксирование с абсолютным адресом в строке запроса, ввод https:// включает CONNECT. Никаких отдельных галочек для этого нет: один и тот же прокси в настройках обслуживает обе схемы, порт тоже один.

В программах картина зависит от библиотеки. Python с requests берёт адрес посредника из переменных окружения и переключается на туннель для схемы https автоматически:

export http_proxy=http://user5521:pf39kd@185.24.87.14:8000
export https_proxy=http://user5521:pf39kd@185.24.87.14:8000
python -c "import requests; print(requests.get('https://example.com').status_code)"

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

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

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

Подойдёт ли туннель CONNECT под мою программу?

Заранее предугадать поведение каждой библиотеки и каждого целевого сайта нельзя, поэтому перед покупкой доступен бесплатный тест длительностью до 2 часов под ваш запрос. Проверять стоит той же программой с теми же настройками, которая пойдёт в работу: вывод curl -v покажет строку CONNECT и код ответа за первые секунды.

Какой тип прокси выбрать, если нужен и HTTPS, и произвольный порт?

В пакете доступны IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5, переключение идёт строкой подключения без доплат. Для веба и кабинетов берут туннельный режим по HTTPS, для программ с нестандартными портами и собственным транспортом рекомендуется SOCKS5. Адреса при этом одни и те же, меняется только протокол общения с посредником.

Почему выходной адрес внутри туннеля каждый раз другой?

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

Сколько туннелей можно держать одновременно?

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

Соседние разборы по протоколам собраны отдельно: чем отличаются HTTP, HTTPS, SOCKS4 и SOCKS5 с таблицей по возможностям каждого, как проходят TCP и UDP через SOCKS5 с разбором команд сокетного протокола, какой почтовый порт выбрать под отправку писем через посредника. Когда туннель поднимается, а доступ отбивается кодом авторизации, порядок разбора описан в материале про ошибку 407 при подключении.

Источник: https://kupit-proxy-ipv4.ru/protokoly/tunnel-connect/

Ниже разобрано, чем два транспорта отличаются на уровне практики, как выглядит каждая команда протокола внутри, почему браузеры при включённом посреднике перестают пользоваться QUIC, что делать программе, которой UDP нужен по-настоящему, и какими командами проверить, каким транспортом реально идёт трафик прямо сейчас.

TCP и UDP: разница на уровне практики

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

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

Как SOCKS5 открывает соединение по TCP

Сокетный протокол начинается с короткого приветствия. Клиент подключается к посреднику по TCP на его порт и отправляет байт версии 0x05, число предлагаемых способов проверки доступа и их коды. Способа два: 0x00 без проверки, для пакетов с привязкой своего адреса, и 0x02 с парой логина и пароля. Посредник отвечает двумя байтами и называет выбранный способ.

клиент -> 05 02 00 02          версия 5, два способа: без проверки и пара
прокси -> 05 02                выбран способ с логином и паролем
клиент -> 01 08 user5521 06 pf39kd    подстрока проверки доступа
прокси -> 01 00                пара принята

После проверки идёт сам запрос. Он занимает от 10 байтов и состоит из версии, кода команды, резервного нуля, типа адреса, самого адреса и порта в двух байтах:

клиент -> 05 01 00 03 0B example.com 01 BB
          |  |  |  |  |              |
          |  |  |  |  |              порт 443 (0x01BB)
          |  |  |  |  длина имени и само имя
          |  |  |  тип адреса: 03 это доменное имя
          |  |  резерв
          |  команда CONNECT
          версия протокола
прокси -> 05 00 00 01 B9 18 57 0E 1F 40   успех, адрес и порт на стороне выхода

Ответный байт 0x00 означает успех. Дальше то же самое TCP-соединение превращается в двусторонний канал: клиент шлёт байты, посредник перекладывает их на своё соединение с целью и возвращает ответ обратно. Разбора содержимого тут нет вообще, потому что сокетный протокол работает уровнем ниже прикладных заголовков. Мы держим оба способа доступа на одних и тех же адресах, поэтому прокси SOCKS5 для программ и скриптов подключаются и по привязке, и парой логина с паролем без смены списка.

Тип адреса 0x03 заслуживает отдельной строки. С ним посреднику уходит доменное имя вместо готового адреса, и тогда имя разрешает выходная сторона. Локальный резолвер машины при этом про целевой домен ничего не узнаёт, и запрос к DNS уходит вместе с трафиком. Это ровно тот случай, когда UDP-запрос к серверу имён вообще не покидает машину клиента отдельным пакетом.

Команды протокола и что каждая делает

Команд в сокетном протоколе три, и они закрывают три разных сценария работы. Байт команды стоит вторым в запросе.

Ответный код посредника тоже стоит разобрать: по нему видно, где именно оборвалась установка.

Мы смотрим на этот байт первым, когда программа отказывается работать через сокетного посредника. Код 0x07 встречается чаще остальных при разборе обращений по UDP. Программа просит канал для датаграмм, получает отказ по команде и дальше ведёт себя по-разному: одна откатывается на TCP молча, другая пишет в лог ошибку сокета, третья продолжает слать датаграммы напрямую с адреса машины.

Как устроен UDP ASSOCIATE

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

Разбираем порядок по шагам. Клиент открывает управляющее TCP-соединение с посредником и отправляет команду 0x03. В полях адреса он указывает ту пару адреса и порта, с которой сам будет слать датаграммы, либо нули, если заранее её не знает. Посредник отвечает успехом и называет собственный адрес и порт для приёма датаграмм. Дальше клиент шлёт UDP-пакеты на этот порт, причём каждая датаграмма получает служебную приставку: два нулевых байта резерва, байт номера фрагмента, тип адреса, адрес цели, порт цели и уже потом сами данные.

+-----+------+------+----------+----------+----------+
| RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
+-----+------+------+----------+----------+----------+
|  2  |  1   |  1   | по типу  |    2     | переменн |
+-----+------+------+----------+----------+----------+

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

Обычный сетевой стек операционной системы всего этого не умеет. Приложение вызывает sendto и ждёт, что датаграмма уйдёт по указанному адресу. Чтобы включить сокетного посредника, разработчику приходится переписывать работу с сокетами вручную или подключать библиотеку-обёртку. Поэтому поддержка живёт точечно: она есть у части торрент-клиентов, у отдельных сетевых утилит и у прослоек, которые перехватывают трафик целиком. Браузеры, парсеры и почтовые клиенты обходятся TCP и команду 0x03 не зовут.

Что вообще пробует ходить по UDP

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

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

Почему браузеры откатываются с QUIC на TCP

QUIC несёт HTTP третьей версии поверх UDP на том же порту 443. Сервер объявляет о поддержке заголовком alt-svc: h3=":443"; ma=86400, браузер запоминает объявление и следующую сессию пробует поднять по датаграммам. Выигрыш там в скорости установки: рукопожатие транспорта и шифрования складываются в один обмен.

Включённый посредник эту схему выключает. Chromium при заданном прокси перестаёт пробовать QUIC для проксируемых адресов, потому что канал датаграмм через посредника ему недоступен. Firefox ведёт себя так же. Результат один: браузер игнорирует объявление alt-svc, открывает обычное TCP-соединение и работает по HTTP второй версии внутри туннеля. Для сбора страниц, работы с кабинетами и проверки выдачи разницы в результате нет, отличается только время установки первой сессии.

В логах откат виден по трём признакам. В chrome://net-export при включённом посреднике отсутствуют события QUIC_SESSION, зато присутствуют HTTP2_SESSION. На вкладке сети инструментов разработчика колонка протокола показывает h2 вместо h3. На стороне машины tcpdump не видит исходящих датаграмм на порт 443 в сторону целевых узлов.

# при работе без посредника исходящий QUIC видно сразу
tcpdump -n -i any 'udp and port 443' -c 20

# при включённом посреднике этот фильтр остаётся пустым,
# зато соединение до прокси видно обычным фильтром
tcpdump -n -i any 'tcp and port 1080' -c 20

Иногда браузер всё же пробует датаграммы в обход настроек, и тогда часть трафика уходит с адреса машины. Проверяется это тем же фильтром tcpdump. Если исходящие датаграммы на 443 есть, QUIC выключается флагом запуска или настройкой профиля, после чего весь веб идёт через посредника по TCP. Мы держим адреса на собственном оборудовании с постоянным откликом, и серверные адреса для длинных сессий выдерживают долгие TCP-соединения без разрывов, которые обычно и толкают браузер пробовать другой транспорт.

Что делать, если приложению нужен UDP

Первый путь самый прямой: проверить настройки самой программы. Часть клиентов имеет отдельную галочку вроде «использовать прокси для UDP» или «резолвить имена через прокси». Когда такая галочка есть, поддержка команды 0x03 в клиенте реализована, и работа пойдёт без обходных манёвров.

Второй путь это перевод задачи на TCP. Многие протоколы имеют TCP-вариант, и включается он одной настройкой. Запросы к DNS ходят по TCP на том же порту 53 и через DoH по HTTPS. Голосовые сессии в мессенджерах переключаются сами. Игровые клиенты иногда предлагают запасной режим соединения. Такой перевод закрывает большую часть задач, потому что рабочие сценарии со сбором данных, кабинетами и почтой построены на TCP целиком. Мы держим сокетный режим на всех адресах пула, и пакет с доступом по SOCKS5 обслуживает эти сценарии тем же списком, что и веб.

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

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

Как проверить, каким транспортом идёт трафик

Проверка занимает одну команду и отвечает точнее любых предположений. Мы берём её за первый шаг разбора, потому что она сразу отделяет вопросы транспорта от вопросов доступа. На Windows список соединений с разбивкой по транспорту выдаёт netstat:

:: соединения по TCP с номерами процессов
netstat -ano -p TCP | findstr :1080

:: слушающие и активные сокеты UDP
netstat -ano -p UDP

На Linux и macOS то же самое короче делает ss. Ключ -t показывает TCP, ключ -u показывает UDP, ключ -p добавляет имя процесса:

# что открыто по TCP в сторону посредника
ss -tnp | grep 1080

# какие сокеты UDP держит машина прямо сейчас
ss -unap

# сводка по числу соединений каждого транспорта
ss -s

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

# всё, что уходит с машины по UDP, кроме запросов к серверу имён
tcpdump -n -i any 'udp and not port 53' -c 40

# запросы к DNS отдельно: видно, резолвит машина сама или нет
tcpdump -n -i any 'udp port 53' -c 20

# трафик до посредника: тут должно быть видно основной поток
tcpdump -n -i any 'host 185.24.87.14 and port 1080' -c 40

Читается вывод так. Строки с IP ... > ...: UDP, length означают датаграммы, ушедшие напрямую. Строки с флагами Flags [S], [.], [P.] относятся к TCP. Если весь основной обмен виден на адресе посредника, а датаграмм наружу нет, трафик идёт через пул полностью. Мы проверяем это первым делом, когда программа ведёт себя странно при рабочем на вид подключении.

Отдельно проверяем сам факт работы через сокетный протокол. Ключ --socks5-hostname заставляет curl передать имя посреднику типом 0x03, и в подробном выводе видно строку SOCKS5 request granted:

curl -v --socks5-hostname user5521:pf39kd@185.24.87.14:1080 https://example.com -o /dev/null

Нагрузка и число соединений при работе по TCP

Раз основной трафик идёт по TCP, планирование нагрузки строится вокруг числа одновременных соединений. Каждый вызов команды CONNECT в сокетном протоколе занимает один поток, и парсер с настройкой в 200 потоков держит до 200 открытых каналов через пул. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000, пакеты по потокам не складываются. При двух привязанных адресах общее число делится между ними пополам, и этот момент забывают чаще остальных.

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

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

Для сокетного режима порт в строке подключения обычно отличается от порта HTTP-режима, и это единственное, что меняется при переключении. Логин и пароль остаются прежними, адреса те же, список перечитывать не нужно. Программа, которая умеет и то, и другое, переключается правкой одного поля в настройках, и работа продолжается без паузы.

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

Какой тип прокси выбрать, если программа умеет и HTTP, и SOCKS?

В пакете доступны IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5, выбор идёт строкой подключения. Мы рекомендуем SOCKS5: он работает уровнем ниже прикладных заголовков, умеет передавать доменное имя на выходную сторону и подходит для произвольных портов. Доплачивать за протокол не нужно, адреса используются одни и те же.

Пойдёт ли моя программа по UDP через ваши прокси?

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

Чем отличается SOCKS4 от SOCKS5 в части транспорта?

SOCKS4 работает только с соединениями по TCP и принимает адрес в числовом виде. SOCKS5 добавляет проверку доступа парой логина и пароля, приём доменных имён отдельным типом адреса и команду для пересылки датаграмм. Оба варианта включены в пакет, рекомендуется пятая версия.

Сколько соединений можно держать одновременно?

Число упирается в лимит потоков пакета: стандартные пакеты дают до 1000, корпоративный до 3000. Пакеты по потокам не складываются. При двух привязанных адресах общее число делится между ними пополам, поэтому вторую привязку разумно держать пустой, пока она реально не понадобится.

Остальные разборы по протоколам собраны рядом: чем отличаются HTTP, HTTPS, SOCKS4 и SOCKS5 с таблицей по каждому режиму, как идёт письмо по протоколу SMTP от команды до кода ответа, как принимать почту по IMAP и POP3 через посредника. Разбор полей строки подключения, включая порт сокетного режима, собран в материале про строку подключения по полям.

Источник: https://kupit-proxy-ipv4.ru/protokoly/tcp-i-udp/

Дальше разобран весь путь по порядку: кто участвует в доставке, из каких команд состоит сеанс, что означают трёхзначные коды ответов, чем конверт письма отличается от заголовков, что записывается в Received и зачем домену три подписи SPF, DKIM и DMARC. Настройка отправки через посредника вынесена в отдельный материал про SMTP через прокси и выбор исходящего адреса, а разбор портов лежит в материале про почтовые порты 25, 465 и 587.

SMTP простыми словами: что берёт на себя протокол

Аббревиатура раскрывается как Simple Mail Transfer Protocol, простой протокол передачи почты. Слово «простой» здесь честное. Весь обмен состоит из строк ASCII, которые читаются глазами без декодера: клиент пишет команду, сервер отвечает трёхзначным числом и пояснением на английском. Именно поэтому почтовый сеанс до сих пор разбирают вручную через telnet или openssl s_client, и половина отказов становится понятной за пару минут наблюдения.

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

Второе свойство важнее первого. SMTP работает по схеме push: соединение всегда открывает тот, у кого письмо на руках. Сервер получателя сидит и слушает порт, ничего сам не запрашивает и никуда не ходит. Отсюда следует практический вывод, который потом всплывает в каждом разборе доставки: адрес, с которого открыто соединение, виден принимающей стороне всегда и записывается в служебные заголовки письма. Когда отправка идёт через посредника, подходит сокетный туннель, потому что прокси SOCKS5 пропускают произвольный TCP-порт без разбора того, что внутри соединения.

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

Путь письма: участники доставки и четыре участка

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

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

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

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

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

MX-запись: как сервер отправителя находит сервер получателя

Домен получателя в адресе выглядит как example.org, при этом почту для него может принимать совсем другая машина. Связь задаётся записью MX в DNS. Сервер отправителя берёт часть адреса после знака @, запрашивает у DNS записи типа MX и получает список имён с числовыми приоритетами.

$ dig +short MX example.org
10 mx1.mailhost.example.
20 mx2.mailhost.example.
30 backup.mailhost.example.

Меньшее число означает более высокий приоритет. Сервер отправителя сначала пробует mx1, при отказе переходит к mx2 и дальше вниз по списку. Имена из ответа резолвятся в адреса записями A, и уже к ним открывается TCP-соединение. Если MX-записей у домена нет вовсе, работает запасное правило: почта идёт на адрес из записи A самого домена.

Одинаковые приоритеты у нескольких записей означают распределение нагрузки: отправитель выбирает из них произвольно. Такая конструкция часто встречается у крупных почтовых систем, где десяток машин принимает поток параллельно. Мы проверяем MX первым делом, когда письма к одному домену уходят в никуда: устаревшая запись объясняет отказ быстрее логов.

Сама сеть, из которой уходит соединение, на выбор MX никак не влияет: список принимающих серверов одинаков для всех. Влияет она на другое, на то, какой адрес увидит принимающая сторона. Тем, кто разводит отправку по разным сетям, подходит вариант, где можно купить прокси IPv4 с доступом к общему пулу и держать соединения через него.

Сеанс SMTP по командам: от EHLO до QUIT

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

Живой обмен по порту 587 выглядит так. Строки клиента помечены стрелкой, строки сервера идут без пометки.

220 mail.example.org ESMTP Postfix
> EHLO client.example.net
250-mail.example.org
250-PIPELINING
250-SIZE 26214400
250-STARTTLS
250-AUTH PLAIN LOGIN
250-8BITMIME
250 SMTPUTF8
> STARTTLS
220 2.0.0 Ready to start TLS
> EHLO client.example.net
250-mail.example.org
250-AUTH PLAIN LOGIN
250 SMTPUTF8
> AUTH LOGIN
334 VXNlcm5hbWU6
> c2VuZGVyQGV4YW1wbGUub3Jn
334 UGFzc3dvcmQ6
> cGFzc3dvcmQxMjM=
235 2.7.0 Authentication successful
> MAIL FROM:<sender@example.org>
250 2.1.0 Ok
> RCPT TO:<user@example.com>
250 2.1.5 Ok
> DATA
354 End data with <CR><LF>.<CR><LF>
> From: Sender <sender@example.org>
> To: User <user@example.com>
> Subject: Test message
> Date: Mon, 12 Aug 10:41:03 +0300
>
> Text of the message.
> .
250 2.0.0 Ok: queued as 4A1F2C0B7E
> QUIT
221 2.0.0 Bye

Ответ на EHLO заслуживает отдельного внимания: сервер перечисляет расширения ESMTP, и по этому списку сразу понятно, чего от него ждать. SIZE 26214400 задаёт потолок письма в байтах, около 25 мегабайт. PIPELINING разрешает слать команды пачкой без ожидания каждого ответа. 8BITMIME и SMTPUTF8 отвечают за восьмибитные тела и адреса с национальными символами. STARTTLS показывает готовность поднять шифрование поверх открытого порта. AUTH PLAIN LOGIN перечисляет доступные способы авторизации.

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

Коды ответов сервера: 2xx, 4xx, 5xx и что делать с временным отказом

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

Разница между 4xx и 5xx определяет всю логику очереди. Код 450 говорит «сейчас нельзя, приходите позже», и правильно настроенный сервер отправителя тут же ставит письмо в очередь. Повторы идут по нарастающему интервалу: сначала через несколько минут, потом через полчаса, дальше через час и реже. Общий срок жизни письма в очереди у Postfix задаётся параметром maximal_queue_lifetime и по умолчанию равен пяти суткам. Всё это время отправитель продолжает стучаться.

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

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

Конверт письма и заголовки: почему адреса расходятся

Письмо состоит из двух слоёв, и они живут независимо. Первый слой это конверт: значения из команд MAIL FROM и RCPT TO. Второй слой это сам текст письма, который начинается после DATA и содержит заголовки From:, To:, Subject:, Date:.

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

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

Вторая: адрес в MAIL FROM и адрес в From: тоже расходятся. Конвертный отправитель отвечает за возвраты, и принимающий сервер записывает его в заголовок Return-Path при доставке. Сервисы рассылок ставят туда служебный адрес вида bounce-4f2a@mail.sender.example, чтобы отчёты о недоставке падали в автоматический обработчик. Видимый From: при этом остаётся человеческим.

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

Заголовок Received: что по нему видно

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

Received: from mx1.mailhost.example (mx1.mailhost.example [203.0.113.24])
        by mail.example.com (Postfix) with ESMTPS id 4A1F2C0B7E
        for <user@example.com>; Mon, 12 Aug 10:41:07 +0300
Received: from client.example.net (unknown [198.51.100.77])
        by mail.example.org (Postfix) with ESMTPSA id 9D3B1A5C42
        for <user@example.com>; Mon, 12 Aug 10:41:03 +0300

Нижняя строка рассказывает о сдаче письма. from client.example.net это имя, которым клиент представился в EHLO, оно задаётся программой и легко ставится любым. В скобках стоит правда: unknown означает, что обратной записи PTR у адреса нет, а 198.51.100.77 это реальный адрес, с которого пришло соединение, его подставил сам сервер. Метка ESMTPSA расшифровывается как ESMTP с шифрованием и авторизацией, буква A в конце подтверждает, что клиент прошёл AUTH.

Верхняя строка описывает межсерверную передачу: письмо принесла машина mx1.mailhost.example с адреса 203.0.113.24, приняла его mail.example.com, протокол ESMTPS без буквы A, потому что авторизации на порту 25 нет. Идентификатор очереди в поле id пригодится, когда придётся искать письмо в логах конкретного сервера.

Практический вывод простой. Адрес в самой нижней строке Received показывает, откуда физически ушло письмо. Именно его мы смотрим первым делом, когда проверяем, что отправка идёт по задуманному маршруту. Имя из EHLO при таком разборе доверия не заслуживает, потому что клиент вписывает туда что угодно. Шифрование канала на этом участке разбирается тем же способом, что и обычный прокси HTTPS с туннелем CONNECT, где посредник передаёт байты, ничего не читая.

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

SPF, DKIM и DMARC: три проверки на стороне получателя

SPF отвечает на вопрос, имел ли адрес соединения право отправлять почту от имени домена. Владелец домена публикует запись TXT со списком разрешённых отправителей, например v=spf1 ip4:203.0.113.0/24 include:_spf.mailhost.example -all. Принимающий сервер берёт домен из конверта, из MAIL FROM, запрашивает эту запись и сверяет с ней адрес, с которого открыто соединение. Хвост -all означает жёсткий отказ всем остальным, ~all мягкую пометку. Проверка привязана к конверту, поэтому пересылка письма через промежуточный ящик её ломает: адрес соединения меняется, домен остаётся прежним.

DKIM отвечает на вопрос, менялось ли письмо в пути и подписал ли его домен. Отправляющий сервер считает подпись по телу письма и части заголовков, кладёт её в заголовок DKIM-Signature и указывает там селектор. Получатель забирает открытый ключ записью TXT по адресу селектор._domainkey.домен, пересчитывает подпись и сверяет. Ключевое отличие от SPF: проверка не зависит от адреса соединения, поэтому переживает пересылку, пока текст письма и подписанные заголовки остаются нетронутыми.

DMARC связывает первые две проверки с видимым адресом в From:. Запись публикуется в TXT по имени _dmarc.домен и выглядит как v=DMARC1; p=quarantine; rua=mailto:reports@example.org; pct=100. Политика p= говорит принимающей стороне, что делать с письмом, которое провалило и SPF, и DKIM: none только наблюдать, quarantine класть в спам, reject отбивать на уровне SMTP кодом 5xx. Дополнительно DMARC требует выравнивания: домен из From: должен совпадать с доменом, который прошёл проверку. Параметр rua задаёт адрес для сводных отчётов, и они показывают владельцу домена, кто отправляет почту от его имени.

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

Как посмотреть сеанс своими руками

Ручной сеанс остаётся самым быстрым способом понять, что происходит. Для порта 587 с переходом в TLS подходит openssl s_client с ключом -starttls smtp, для порта 465 тот же инструмент без ключа, потому что там шифрование поднимается сразу.

# порт 587, шифрование поднимается командой STARTTLS
openssl s_client -connect mail.example.org:587 -starttls smtp -crlf

# порт 465, соединение шифруется с первого байта
openssl s_client -connect mail.example.org:465 -crlf

# быстрый просмотр списка расширений без ручного ввода
printf 'EHLO test.example\r\nQUIT\r\n' | nc mail.example.org 25

Утилита swaks делает то же самое одной строкой и печатает весь диалог, включая коды ответов. Она удобна, когда нужно проверить связку логина, пароля и порта, ничего не настраивая в почтовом клиенте.

swaks --to user@example.com \
      --from sender@example.org \
      --server mail.example.org:587 \
      --auth LOGIN --auth-user sender@example.org \
      --tls

Что мы смотрим в выводе по порядку. Первое: пришло ли приветствие 220, потому что его отсутствие означает проблему с самим соединением. Второе: какие расширения перечислены в ответе на EHLO. Третье: прошла ли авторизация, код 235 подтверждает успех. Четвёртое: приняты ли MAIL FROM и RCPT TO. Пятое: какой код пришёл после точки, завершающей DATA.

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

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

Чем SMTP отличается от IMAP и POP3?

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

Почему письмо приняли с кодом 250, но оно не появилось у получателя?

Код 250 после завершения DATA означает, что сервер взял письмо в очередь и отвечает за него дальше. Что произойдёт потом, зависит от следующих участков: письмо может уйти в спам по итогам проверок DKIM и DMARC, попасть под фильтр содержимого или вернуться отчётом о недоставке. Разбор идёт по логам сервера, где письмо ищется по идентификатору очереди из ответа.

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

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

Какой тип прокси вы даёте для работы с почтовыми портами?

В пакете IPv4 и SOCKS5 доступны SOCKS4 и SOCKS5 на выбор, рекомендуем SOCKS5. Пул держится в районе 12 000 активных адресов, список обновляется в реальном времени и выдаётся в форматах IP:PORT и IP:PORT:LOGIN:PASS ссылкой или файлом. Трафик безлимитный, пакет включается примерно за 5 минут после оформления.

Соседние разборы по протоколам собраны рядом: приём почты по IMAP и POP3 с разбором папок и флагов, туннель CONNECT для шифрованных соединений и сравнение вариантов в материале HTTP, HTTPS, SOCKS4 и SOCKS5. Практическая настройка почтовых программ и серверных скриптов описана отдельно в разделе про подключение в программах и на сервере.

Источник: https://kupit-proxy-ipv4.ru/protokoly/chto-takoe-smtp/

Ниже собран рабочий порядок: почему сокетный туннель обязателен, что происходит на уровне рукопожатия SOCKS5, как прописать посредника в Thunderbird и The Bat, как отправить письмо из кода на python и PHP, как поднять локальный туннель для программы без поддержки посредника, что смотреть при отказе соединения и как убедиться по заголовку Received, что письмо ушло с ожидаемого адреса. Сам протокол разобран отдельно в материале про устройство SMTP и путь письма.

Почему для SMTP берут SOCKS5

SOCKS5 работает на уровне TCP-сокета. Клиент говорит посреднику одну вещь: «соедини меня с этим хостом на этом порту», и дальше байты идут в обе стороны без разбора. Что внутри туннеля, посреднику безразлично: почтовые команды, поток IMAP, произвольный двоичный обмен. Для протокола вроде SMTP такая прозрачность и нужна, потому что почтовый сеанс начинается с приветствия сервера, которое приходит до всякой команды клиента.

Второй довод касается портов. Почтовые порты 587, 465 и 25 к веб-трафику отношения не имеют, и посредник, который умеет работать только по знакомым ему схемам, туда не пойдёт. SOCKS5 принимает номер порта параметром запроса и открывает соединение на любой из них. Разбор самих портов и того, какой выбрать под задачу, лежит в отдельном материале про выбор почтового порта 25, 465 или 587.

Третий довод про имена. В SOCKS5 клиент вправе передать посреднику доменное имя вместо адреса, и резолвинг произойдёт на стороне прокси. В библиотеках это включается флагом rdns, в схемах curl буквой h в конце: socks5h://. Для почты это удобно, потому что запросы к DNS уходят по тому же маршруту, что и соединение.

Мы отдаём пакеты, где на одних и тех же адресах доступны SOCKS4 и SOCKS5, и для почтовых задач рекомендуем пятую версию: она умеет авторизацию логином и паролем и принимает доменные имена. Пакет оформляется там, где описаны прокси SOCKS5 для почтовых программ.

Как устроен HTTP-прокси и почему почтовый сеанс идёт мимо него

HTTP-прокси разбирает то, что через него проходит. Клиент присылает строку запроса вида GET http://example.org/page HTTP/1.1, посредник читает её, вынимает адрес, ставит свои заголовки и делает запрос сам. Работа идёт с сообщениями протокола HTTP, и без такой строки посредник не понимает, что от него хотят.

SMTP устроен наоборот. Первым говорит сервер: сразу после установки TCP-соединения он присылает приветствие 220 mail.example.org ESMTP. Клиент молчит, пока не увидит эту строку. HTTP-прокси в этот момент сидит и ждёт от клиента запрос, которого никогда не будет, и через несколько десятков секунд соединение закрывается по таймауту. Даже если клиент заговорит первым, команда EHLO client.example.net для разборщика HTTP выглядит мусором, и в ответ прилетает 400 Bad Request.

Остаётся вариант с методом CONNECT, тем самым, которым HTTP-прокси открывает туннель для HTTPS. Технически туннель получается сырым, и почтовый сеанс по нему пройти способен. Практически почти все реализации ограничивают список портов, куда CONNECT разрешён, обычно это 443 и иногда 563, поэтому запрос на 587 отбивается кодом 403 Forbidden. Устройство этого метода подробно разобрано в статье про туннель CONNECT и шифрованные соединения.

Вывод прямой: почтовый клиент, в настройках которого стоит HTTP-посредник, письмо не отправит. Поле SOCKS в тех же настройках закрывает задачу сразу. Мы держим на одних и тех же адресах все четыре схемы, поэтому переезд почтовой задачи на сокетный туннель не требует нового пакета. Отдельно отметим, что прокси HTTP для браузеров и парсеров остаются удобным вариантом для веб-запросов, и в пакете доступны обе схемы на одних адресах, поэтому переключение занимает одну строку в настройках.

Рукопожатие SOCKS5: что происходит до первой команды SMTP

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

Сначала клиент присылает список способов авторизации: версия 0x05, число способов, сами способы. Значение 0x00 означает работу без логина, 0x02 авторизацию логином и паролем. Посредник выбирает один и отвечает двумя байтами. Если выбран 0x02, следом идёт отдельный обмен по подпротоколу авторизации: версия 0x01, длина логина, логин, длина пароля, пароль. Ответ 0x01 0x00 подтверждает успех. Мы советуем смотреть именно на эти два байта, когда клиент молча закрывает соединение.

Дальше идёт сам запрос: версия, команда 0x01 для CONNECT, зарезервированный ноль, тип адреса, адрес и порт двумя байтами. Тип 0x01 это адрес IPv4, тип 0x03 доменное имя с длиной впереди. Посредник открывает соединение до цели и отвечает кодом результата. Только после этого в туннель приходит 220 от почтового сервера, и начинается обычный сеанс SMTP.

Быстрая проверка туннеля до почтового порта делается одной командой. Ответ с приветствием 220 подтверждает, что путь открыт целиком.

# проверяем, что через SOCKS5 доходим до порта 587
curl -v --socks5-hostname user5521:pf39kd@185.24.87.14:8000 \
     smtp://mail.example.org:587 --mail-rcpt user@example.com \
     --mail-from sender@example.org --upload-file /dev/null

# и заодно смотрим, какой адрес видит внешний сервис
curl -s -x socks5h://185.24.87.14:8000 https://ifconfig.me

Настройка в почтовом клиенте: Thunderbird и The Bat

В Thunderbird посредник задаётся один на всю программу и действует на отправку и приём сразу. Путь такой: «Настройки», раздел «Основные», в самом низу страницы блок «Прокси-сервер», кнопка «Настроить». В открывшемся окне выбирается «Ручная настройка», заполняется поле «Узел SOCKS» и порт, ставится переключатель «SOCKS v5». Ниже стоит включить пункт про запросы к DNS через SOCKS v5, тогда имена почтовых серверов резолвятся на стороне посредника.

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

The Bat держит настройки посредника отдельно для каждого ящика, и это удобнее при работе с несколькими адресами отправки. Путь: «Ящик», «Свойства почтового ящика», раздел «Транспорт». В блоке отправки рядом с адресом сервера SMTP стоит кнопка настроек соединения, внутри выбирается тип «SOCKS v5», вписываются адрес посредника, порт, логин и пароль. Приём настраивается тем же порядком в блоке получения, и там же выбирается схема для IMAP.

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

Python: PySocks и smtplib

Стандартный smtplib про посредников ничего не знает, поэтому туннель подставляется на уровне сокета. Библиотека PySocks ставится как pip install PySocks и даёт класс socksocket, совместимый с обычным сокетом.

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

import smtplib, socks, ssl
from email.message import EmailMessage

socks.set_default_proxy(socks.SOCKS5, "185.24.87.14", 8000,
                        rdns=True, username="user5521", password="pf39kd")
socks.wrap_module(smtplib)

msg = EmailMessage()
msg["From"] = "sender@example.org"
msg["To"] = "user@example.com"
msg["Subject"] = "Proxy test"
msg.set_content("Sent through a SOCKS5 tunnel.")

with smtplib.SMTP("mail.example.org", 587, timeout=30) as srv:
    srv.ehlo()
    srv.starttls(context=ssl.create_default_context())
    srv.ehlo()
    srv.login("sender@example.org", "mailpassword")
    srv.send_message(msg)
    print("queued")

Второй способ аккуратнее: посредник задаётся только для своего соединения, остальной код процесса работает напрямую. Достаточно переопределить метод _get_socket у класса SMTP.

import smtplib, socks, ssl
from email.message import EmailMessage

PROXY = ("185.24.87.14", 8000, "user5521", "pf39kd")

class ProxiedSMTP(smtplib.SMTP):
    def _get_socket(self, host, port, timeout):
        s = socks.socksocket()
        s.set_proxy(socks.SOCKS5, PROXY[0], PROXY[1],
                    rdns=True, username=PROXY[2], password=PROXY[3])
        s.settimeout(timeout)
        s.connect((host, port))
        return s

msg = EmailMessage()
msg["From"] = "sender@example.org"
msg["To"] = "user@example.com"
msg["Subject"] = "Proxy test 2"
msg.set_content("Second variant, per-connection proxy.")

srv = ProxiedSMTP("mail.example.org", 587, timeout=30)
srv.set_debuglevel(1)
srv.starttls(context=ssl.create_default_context())
srv.login("sender@example.org", "mailpassword")
srv.send_message(msg)
srv.quit()

Строка set_debuglevel(1) печатает весь диалог с сервером, включая коды ответов. Мы держим её включённой при первой отладке и убираем, когда сеанс проходит ровно. Для порта 465 класс берётся другой, SMTP_SSL, и метод starttls не вызывается, потому что шифрование там поднимается с первого байта.

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

PHP: отправка через SOCKS5

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

<?php
$body = "From: Sender <sender@example.org>\r\n"
      . "To: User <user@example.com>\r\n"
      . "Subject: Proxy test\r\n"
      . "\r\n"
      . "Sent through a SOCKS5 tunnel.\r\n";

$fp = fopen('php://temp', 'r+');
fwrite($fp, $body);
rewind($fp);

$ch = curl_init();
curl_setopt_array($ch, [
    CURLOPT_URL            => 'smtp://mail.example.org:587',
    CURLOPT_PROXY          => '185.24.87.14:8000',
    CURLOPT_PROXYTYPE      => CURLPROXY_SOCKS5_HOSTNAME,
    CURLOPT_PROXYUSERPWD   => 'user5521:pf39kd',
    CURLOPT_USE_SSL        => CURLUSESSL_ALL,
    CURLOPT_USERNAME       => 'sender@example.org',
    CURLOPT_PASSWORD       => 'mailpassword',
    CURLOPT_MAIL_FROM      => '<sender@example.org>',
    CURLOPT_MAIL_RCPT      => ['<user@example.com>'],
    CURLOPT_UPLOAD         => true,
    CURLOPT_READDATA       => $fp,
    CURLOPT_INFILESIZE     => strlen($body),
    CURLOPT_TIMEOUT        => 45,
    CURLOPT_VERBOSE        => true,
]);

curl_exec($ch);
if (curl_errno($ch)) {
    echo 'ошибка: ' . curl_error($ch) . PHP_EOL;
} else {
    echo 'код ответа: ' . curl_getinfo($ch, CURLINFO_RESPONSE_CODE) . PHP_EOL;
}
curl_close($ch);
fclose($fp);

Константа CURLPROXY_SOCKS5_HOSTNAME включает резолвинг на стороне посредника, CURLUSESSL_ALL требует обязательного перехода в TLS командой STARTTLS. Для порта 465 схема в адресе меняется на smtps://, и параметр CURLOPT_USE_SSL тогда не нужен.

Популярные библиотеки вроде PHPMailer и Symfony Mailer собственной поддержки SOCKS не имеют: они работают через потоковые сокеты PHP. Их подключают к посреднику вторым способом, через локальный туннель, и в настройках библиотеки указывают адрес 127.0.0.1 с локальным портом. Такая схема разобрана в следующем разделе, и она же выручает с готовым софтом, где полей посредника попросту нет.

Локальный туннель для программ без поддержки посредника

Идея простая. На рабочей машине поднимается слушающий порт, всё пришедшее на него уходит через SOCKS5 до почтового сервера. Программа настраивается на 127.0.0.1 с этим портом и про посредника ничего не знает.

Самый короткий вариант на Linux и macOS даёт socat начиная с версии 1.7.4, где появилась поддержка пятой версии SOCKS.

# слушаем 2587 локально, ведём на порт 587 почтового сервера через SOCKS5
socat TCP4-LISTEN:2587,bind=127.0.0.1,reuseaddr,fork \
  SOCKS5-CONNECT:185.24.87.14:8000:mail.example.org:587

# проверяем туннель, приветствие 220 должно прийти сразу
printf 'EHLO test.example\r\nQUIT\r\n' | nc 127.0.0.1 2587

Второй вариант заворачивает в туннель весь процесс целиком, включая запросы к DNS. Утилита proxychains4 читает конфиг и подменяет системные вызовы сети у запущенной под ней программы.

# proxychains.conf
strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
socks5 185.24.87.14 8000 user5521 pf39kd

proxychains4 -f ./proxychains.conf php send.php
proxychains4 -f ./proxychains.conf python mailer.py

На Windows ту же работу берут на себя программы вроде Proxifier: в них задаётся правило по имени исполняемого файла, и весь трафик выбранного приложения уходит в туннель. Так подключают Outlook и старые почтовые программы без полей посредника. Адреса для туннеля мы берём из общей выдачи: они одинаковы для любой схемы, и пакет прокси IPv4 с доступом к пулу обслуживает и почту, и остальные задачи машины.

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

Отказ соединения на порт: что смотреть по порядку

Разбор идёт снизу вверх, от сети к почтовому серверу. Порядок проверок такой.

Первое: доходит ли соединение до самого посредника. Команда curl -s -x socks5h://адрес:порт https://ifconfig.me возвращает адрес из пула, если туннель жив. Пустой ответ или таймаут означают, что дальше идти незачем.

Второе: принята ли авторизация. Отказ 0x02 в рукопожатии SOCKS5 указывает на пару логина и пароля либо на непривязанный адрес машины. Мы проверяем это по кабинету: список выдаётся в форматах IP:PORT и IP:PORT:LOGIN:PASS, и второй формат нужен там, где адрес машины меняется. Если привязано два адреса, лимит потоков делится между ними пополам, это отдельно учитывается при массовых отправках.

Третье: открыт ли целевой порт. Ответ 0x05 от посредника означает, что почтовый сервер отклонил соединение, ответ 0x04 что машина не отвечает. Порт 25 у части почтовых систем закрыт для входящих соединений от кого попало, поэтому отправка с авторизацией идёт на 587 или 465.

Четвёртое: доходит ли приветствие. Туннель открылся, приветствия 220 нет: почти всегда это неверный порт или требование немедленного TLS на порту, где ожидался открытый старт.

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

Проверка по Received: письмо ушло с ожидаемого адреса

Финальная проверка делается на живом письме. Отправляем письмо на ящик, к которому есть доступ, открываем исходный текст и читаем самую нижнюю строку Received: она относится к моменту, когда письмо приняли от нашего клиента.

Received: from client.example.net (unknown [185.24.87.14])
        by mail.example.org (Postfix) with ESMTPSA id 7C4E2B9A15
        for <user@example.com>; Tue, 13 Aug 09:22:41 +0300

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

Где смотреть исходный текст: в Thunderbird сочетание клавиш открывает исходник письма, в веб-интерфейсах пункт меню называется «Показать оригинал» или «Свойства письма». Некоторые почтовые сервисы прячут нижние строки Received у писем, отправленных через их же веб-интерфейс, поэтому проверять удобнее на ящике другого домена.

Три величины, которые мы фиксируем при проверке: адрес в нижней строке Received, время сеанса и идентификатор очереди из поля id. По этой тройке письмо потом находится в логах почтового сервера за секунды. Если адрес совпал с ожидаемым, настройка закончена, и дальше остаётся следить за самими адресами: пул держится в районе 12 000 активных, ротация внутри него автоматическая, поэтому перед крупной рассылкой список перечитывается заново. Доступ ко всему пулу оформляется на странице, где можно оформить пакет IPv4 и SOCKS5, а список выдаётся ссылкой или файлом.

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

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

Почему отправка не идёт через HTTP-прокси, ведь порт указан верно?

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

Какой тип прокси вы даёте и что выбрать для почты?

В пакете IPv4 и SOCKS5 доступны SOCKS4 и SOCKS5 на выбор, рекомендуем пятую версию. Она принимает логин с паролем и умеет резолвить доменные имена на своей стороне. Протоколы HTTP и HTTPS в пакете тоже есть и работают на тех же адресах, их берут под браузерные задачи.

Как получить список адресов и в каком он виде?

Два формата на выбор: IP:PORT и IP:PORT:LOGIN:PASS. В кабинете список забирается ссылкой или скачивается файлом, обновление идёт в режиме реального времени. Формат без логина работает вместе с привязкой адреса рабочей машины, в пакет входит одновременная привязка 2 адресов со свободной сменой.

Можно ли проверить свою почтовую отправку до покупки?

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

Рядом лежат соседние разборы по протоколам: приём почты по IMAP и POP3 через посредника, что проходит по TCP и UDP через SOCKS5 и сравнение схем в материале про различия HTTP, HTTPS, SOCKS4 и SOCKS5. Подключение обычных программ и серверных сервисов описано в разделе про настройку в программах и на сервере.

Источник: https://kupit-proxy-ipv4.ru/protokoly/smtp-cherez-proxy/

Ниже разобрано, за что отвечает каждый номер, как выглядит обмен на 465 и на 587 построчно, чем implicit TLS отличается от STARTTLS на уровне команд, как проверить доступность порта тремя разными командами и что делать, когда соединение отбивается. В конце порты приёма почты и то, как номер записывается в настройках программы.

За что отвечает каждый порт

Мы разбираем три номера в том порядке, в каком они встречаются на пути письма. Все три закреплены за разными участками этого пути. Порт 25 обслуживает перегон между почтовыми серверами: отправляющий сервер находит MX-запись домена получателя и стучится на 25 к тому хосту, который в ней указан. Порты 465 и 587 обслуживают submission, то есть сдачу письма от программы пользователя своему серверу. Разница по смыслу простая: на 25 сервер разговаривает с сервером, на 465 и 587 программа разговаривает со своим сервером и предъявляет логин.

Разделение на submission и перегон между серверами придумано ради того, чтобы сервер мог по номеру порта понять, с кем говорит. На 587 и 465 он ждёт авторизацию и принимает письма только от своих пользователей. На 25 он принимает почту для собственных доменов от кого угодно снаружи, поэтому там действуют совсем другие проверки: обратная зона, SPF, ограничение частоты, серые списки.

Порт 2525 в реестре IANA за почтой не закреплён. Часть сервисов слушает его дополнительно, чтобы клиенты с прикрытым 587 могли отправлять письма без переезда. Обмен на нём идёт по тем же правилам, что и на 587.

Порт 25: передача между почтовыми серверами

Сеанс на 25 начинается открытым текстом. Сервер отвечает баннером 220, клиентская сторона представляется командой EHLO и получает список расширений. Если оба конца поддерживают STARTTLS, обмен переходит в шифрование, и дальше письмо идёт внутри туннеля. Согласие тут добровольное: когда принимающая сторона расширение не объявила, письмо уйдёт открытым текстом.

220 mx.example.net ESMTP Postfix
EHLO relay.example.org
250-mx.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
MAIL FROM:<sender@example.org>
250 2.1.0 Ok
RCPT TO:<user@example.net>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>

Ключевая деталь для практика: команды AUTH в этом сеансе нет. Принимающий сервер берёт письмо потому, что адрес получателя относится к его домену. Попытка отправить через чужой 25 письмо на сторонний домен закончится ответом 554 5.7.1 Relay access denied.

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

Поэтому серверные скрипты и почтовые программы на 25 наружу не ходят. Сдача письма идёт на submission-порт своего сервера, а уже он от своего адреса перегоняет письмо дальше по 25.

Порт 465: соединение сразу в шифровании

На 465 шифрование поднимается до первой почтовой команды. TCP-соединение установилось, и клиент немедленно отправляет TLS ClientHello. Сервер отвечает своим сертификатом, стороны согласуют шифр, и только внутри готового туннеля приходит баннер 220. Такой порядок называют implicit TLS: договариваться о шифровании не нужно, оно подразумевается самим номером порта.

openssl s_client -connect smtp.example.net:465 -servername smtp.example.net -quiet
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
220 smtp.example.net ESMTP ready
EHLO client.example.org
250-smtp.example.net
250-AUTH PLAIN LOGIN
250-SIZE 52428800
250 8BITMIME
AUTH LOGIN
334 VXNlcm5hbWU6

Обратите внимание на строку 250-AUTH: сервер объявляет доступные механизмы авторизации сразу, потому что канал уже защищён. Логин и пароль уходят внутри туннеля, перехватить их по дороге нечем.

У 465 своя история. Номер выделяли под SMTPS, затем отзывали, затем возвращали уже под именем submissions, и в промежутке часть документации называла его устаревшим. Сегодня это полноценный порт сдачи писем, его слушают Postfix через smtps в master.cf, Exim через tls_on_connect_ports, Dovecot, а также крупные почтовые сервисы. При настройке нового клиента 465 удобен именно предсказуемостью: шифрование либо поднялось, либо соединения нет.

Единственное, что нужно проверить перед выбором 465: слушает ли его ваш сервер. Часть площадок оставляет только 587. Одна команда openssl s_client отвечает на этот вопрос за секунду.

Порт 587: отправка от клиента через STARTTLS

Сеанс на 587 начинается открытым текстом и переходит в шифрование по явной команде. Порядок такой: сервер шлёт баннер 220, клиент представляется EHLO, сервер перечисляет расширения, клиент отправляет STARTTLS, сервер отвечает 220 2.0.0 Ready to start TLS, стороны выполняют рукопожатие. После рукопожатия клиент обязан повторить EHLO, потому что список расширений внутри шифрования другой.

openssl s_client -starttls smtp -connect smtp.example.net:587 -quiet
220 smtp.example.net ESMTP ready
EHLO client.example.org
250-smtp.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
STARTTLS
220 2.0.0 Ready to start TLS

Повторный EHLO часто пропускают при ручной отладке и потом гадают, почему AUTH отсутствует в списке. Механизмы авторизации многие серверы прячут до подъёма шифрования: пока канал открыт, строка 250-AUTH в ответе отсутствует, после рукопожатия она появляется. Postfix делает это директивой smtpd_tls_auth_only = yes.

Второе поведение, о котором полезно знать: сервер на 587 обычно настроен требовать авторизацию для всех отправок. Попытка выполнить MAIL FROM без AUTH возвращает 530 5.7.0 Authentication required. Это нормальный ответ, он говорит о правильно настроенном submission-порту.

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

Implicit TLS и STARTTLS: разница на уровне обмена

Разница видна по первому пакету после установки TCP-соединения. На 465 первым идёт TLS ClientHello от клиента. На 587 первым идёт текстовый баннер от сервера, и до команды STARTTLS весь обмен читается любым наблюдателем на пути.

Из этой таблицы следуют два практических вывода. Первый: на 587 список расширений виден дважды, и содержимое двух списков отличается. Второй: на 587 объявление STARTTLS идёт открытым текстом, поэтому в почтовых программах существует настройка «требовать шифрование». Она заставляет клиента разорвать сеанс, когда расширение в списке отсутствует. На 465 такой настройки не требуется: там нечего подменять, шифрование начинается с первого байта.

Сертификат мы проверяем в обоих случаях одинаково. Имя в сертификате сверяется с тем именем хоста, которое написано в настройках, поэтому openssl s_client полезно запускать с ключом -servername: без него на площадках с несколькими доменами придёт сертификат по умолчанию, и вывод собьёт с толку.

Ещё один момент касается портов приёма. Пара «открытое начало плюс STARTTLS» и «шифрование сразу» повторяется у IMAP и POP3 в точности так же, поэтому, разобравшись один раз на SMTP, вы уже знаете, как устроены 143 и 993.

Как выбрать порт под свой почтовый сервис

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

Отправка через посредника заслуживает отдельного слова. Почтовое соединение это обычный TCP-поток, и посредник переносит его как есть. По HTTP это делается методом CONNECT: клиент просит открыть туннель до пары хост и порт, получает 200 Connection established и дальше гонит по туннелю байты SMTP. Для программ, которые ходят по HTTP-схеме и умеют туннелировать произвольные порты, подойдут прокси HTTP для почтовых программ с доступом по логину либо по привязке своего адреса. Механика самого туннеля разобрана отдельно, если нужны подробности рукопожатия, смотрите материал про туннель CONNECT и работу с шифрованием.

Второй путь, который в почте встречается чаще, это SOCKS5. Он не разбирает содержимое потока и переносит соединение на любой номер порта, поэтому 25, 465, 587, 993 и 995 проходят через него одинаково. Именно поэтому почтовые клиенты в своих настройках сети предлагают SOCKS5 первым: адреса SOCKS5 для произвольных портов закрывают и отправку, и приём одной настройкой. Мы выдаём один и тот же список адресов под оба варианта доступа, меняется только строка подключения в программе.

Проверка доступности порта: telnet, nc и openssl s_client

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

Через посредника команды меняются мало. Утилита nc умеет ходить по SOCKS5 сама, curl принимает адрес посредника ключом -x, а для проверки TLS через туннель удобно поднять локальный проброс и уже к нему обращаться openssl s_client.

# доступность порта через SOCKS5
nc -X 5 -x 185.24.87.14:1080 -vz smtp.example.net 587

# полный SMTP-обмен через SOCKS5 с логином и паролем
curl -v --url smtp://smtp.example.net:587 \
     --proxy socks5h://user5521:pf39kd@185.24.87.14:1080 \
     --mail-from sender@example.org --mail-rcpt user@example.net \
     --upload-file letter.txt

# туннель CONNECT до почтового порта через HTTP-посредник
curl -v --proxy http://185.24.87.14:8000 --url smtps://smtp.example.net:465

Отдельно про telnet. Утилита показывает живой текстовый диалог и потому удобна на 25 и 587, где обмен начинается открытым текстом. На 465 она бесполезна: там первым идёт двоичное рукопожатие, и на экране появится молчание либо мусор. Для 465 берём openssl s_client, он делает ровно то, что нужно.

Отказ соединения на порт: что смотреть по шагам

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

Порядок разбора короткий. Первым делом проверяем TCP командой nc -vz, чтобы отделить сетевую часть от почтовой. Дальше смотрим, поднимается ли TLS: на 465 через прямое подключение, на 587 через ключ -starttls smtp. Если оба уровня прошли, дальнейшие ответы читаются по кодам из таблицы выше, и они уже говорят о настройках почтового сервера.

Когда соединение уходит через посредника, добавляется третий уровень проверки. Сначала убеждаемся, что сам посредник принимает соединение и отдаёт 200 Connection established либо рукопожатие SOCKS5. Только после этого имеет значение ответ почтового сервера. Мы держим приватные серверные адреса на собственном оборудовании и рекомендуем разделять эти два шага при любом разборе: половина запутанных случаев объясняется тем, что обрыв случился на первом уровне, а искали причину на третьем.

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

Порты приёма почты и запись номера в настройках

Отправка это половина работы почтового клиента. Вторая половина, приём, устроена по той же логике портов, поэтому таблица ниже читается как продолжение первой.

Закономерность видна сразу: у каждого почтового протокола есть номер с открытым началом и номер с шифрованием от первого байта. Номера 993 и 995 сегодня стоят по умолчанию почти везде. Устройство самих сеансов приёма и разбор команд FETCH, RETR и DELE вынесены в отдельный материал про приём почты по IMAP и POP3.

Как порт задаётся в строке подключения

В графическом клиенте порт указывается отдельным полем рядом с именем сервера, и рядом же стоит выпадающий список типа шифрования. Соответствие простое: SSL/TLS означает implicit TLS и идёт с 465, 993, 995. Пункт STARTTLS идёт с 587, 143, 110.

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

smtp://smtp.example.net:587     обычное начало, дальше STARTTLS
smtps://smtp.example.net:465    шифрование сразу после соединения
imap://mail.example.net:143     обычное начало, дальше STARTTLS
imaps://mail.example.net:993    шифрование сразу после соединения
pop3s://mail.example.net:995    шифрование сразу после соединения

import smtplib

# порт 587: открываем соединение, поднимаем шифрование командой
s = smtplib.SMTP('smtp.example.net', 587, timeout=20)
s.ehlo()
s.starttls()
s.ehlo()
s.login('user@example.org', 'secret')

# порт 465: шифрование поднимается вместе с соединением
s = smtplib.SMTP_SSL('smtp.example.net', 465, timeout=20)
s.login('user@example.org', 'secret')

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

Отдельного внимания просит число одновременных сеансов. Почтовые серверы ограничивают частоту подключений с одного адреса, и при массовой работе счётчик упирается в потолок быстро. На стандартных пакетах доступно до 1000 потоков, на корпоративном до 3000, а при двух привязанных адресах общая цифра делится пополам. Пул держится в районе 12 000 активных адресов, ротация внутри него идёт автоматически. Полный состав доступа описан на странице, где можно оформить доступ к пулу адресов IPv4.

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

Почему письма не уходят через порт 25 с моего сервера?

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

Что выбрать при равной доступности 465 и 587?

Оба порта рабочие. Порт 587 удобен универсальностью: его слушают все распространённые почтовые сервисы, и библиотеки поддерживают STARTTLS из коробки. Порт 465 удобен предсказуемостью: шифрование поднимается вместе с соединением, подменить объявление расширения по дороге нечем. При настройке нового клиента мы обычно ставим 587, а 465 берём для библиотек, где STARTTLS настраивается тяжело.

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

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

Сколько времени занимает включение пакета после оплаты?

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

Порты это одна деталь почтового обмена, вокруг неё есть смежные разборы. Как устроен сам протокол и из чего складывается путь письма, описано в материале про устройство протокола SMTP. Настройка отправки через посредника, с командами и разбором ответов сервера, собрана в заметке про отправку почты через прокси. Разница между HTTP, HTTPS, SOCKS4 и SOCKS5 при выборе типа доступа разобрана в сравнении четырёх протоколов посредника. А если почтовая программа уже настроена и остаётся подключить её к пулу, начните с материала про подключение в программах и на сервере.

Источник: https://kupit-proxy-ipv4.ru/protokoly/pochtovye-porty/

Ниже мы разбираем оба сеанса по командам, с реальным обменом строками, показываем настройку в почтовом клиенте и в коде на Python, перечисляем порты и приводим способы убедиться, что соединение действительно идёт через посредника. Отправка писем живёт по своим правилам и вынесена в соседний материал.

Чем IMAP отличается от POP3 по устройству работы

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

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

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

Отсюда следует практика по разрыву связи. Порванный сеанс IMAP означает потерю нумерации, и клиент после переподключения повторяет SELECT. Порванный сеанс POP3 в середине выгрузки означает, что команда QUIT не дошла, удаление не подтвердилось и письма остались на сервере. Второй случай безопаснее по данным.

Какой протокол выбрать под какую работу

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

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

Сеанс IMAP по командам: LOGIN, LIST, SELECT, FETCH, STORE, LOGOUT

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

* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS AUTH=PLAIN] Dovecot ready.
a001 LOGIN user@example.org secret
a001 OK [CAPABILITY IMAP4rev1 IDLE NAMESPACE UIDPLUS MOVE QUOTA] Logged in
a002 LIST "" "*"
* LIST (\HasNoChildren) "/" INBOX
* LIST (\HasNoChildren \Drafts) "/" Drafts
* LIST (\HasNoChildren \Sent) "/" Sent
* LIST (\HasNoChildren \Junk) "/" Junk
a002 OK List completed (0.002 + 0.000 secs).
a003 SELECT INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* 1483 EXISTS
* 2 RECENT
* OK [UIDVALIDITY 1571234567] UIDs valid
* OK [UIDNEXT 20194] Predicted next UID
a003 OK [READ-WRITE] Select completed.
a004 SEARCH UNSEEN
* SEARCH 1482 1483
a004 OK Search completed.
a005 FETCH 1483 (FLAGS BODY.PEEK[HEADER.FIELDS (FROM SUBJECT)])
* 1483 FETCH (FLAGS () BODY[HEADER.FIELDS (FROM SUBJECT)] {74}
From: supplier@example.org
Subject: ostatki po skladu
)
a005 OK Fetch completed.
a006 STORE 1483 +FLAGS (\Seen)
* 1483 FETCH (FLAGS (\Seen))
a006 OK Store completed.
a007 LOGOUT
* BYE Logging out
a007 OK Logout completed.

Разберём команды по назначению.

Три детали из этого обмена пригодятся при отладке. Первая: BODY.PEEK[] забирает содержимое без установки флага \Seen, обычный BODY[] письмо помечает прочитанным. Вторая: номера сообщений в папке меняются после EXPUNGE, поэтому длинные скрипты работают через UID и команду UID FETCH. Третья: значение UIDVALIDITY при пересоздании папки на сервере меняется, и локальный кэш клиента после этого перестраивается целиком.

Сеанс POP3 по командам: USER, PASS, STAT, LIST, RETR, DELE, QUIT

POP3 устроен проще: ответы состоят из +OK и -ERR, меток нет, многострочный ответ завершается точкой на отдельной строке.

+OK POP3 ready <18960.6971709@mail.example.net>
USER user@example.org
+OK
PASS secret
+OK Logged in.
STAT
+OK 3 14820
LIST
+OK 3 messages:
1 4210
2 5312
3 5298
.
UIDL
+OK
1 GmM2AV4x1Q3xVQ
2 QhdPYR:00WBw1
3 hUYtQ2kLm9Vc0a
.
TOP 2 5
+OK
From: supplier@example.org
Subject: price list
Content-Type: text/plain; charset=utf-8

Dobryy den, vysylaem preys.
.
RETR 2
+OK 5312 octets
...
.
DELE 2
+OK Marked to be deleted.
QUIT
+OK Logging out, messages deleted.

Самое важное свойство POP3 сидит в паре DELE и QUIT. Команда DELE только ставит пометку, физически ящик очищается на выходе из сеанса. Оборванная связь до QUIT оставляет письма нетронутыми, и повторный запуск скрипта заберёт их снова. Настройка почтовых программ «оставлять копии на сервере» опирается на UIDL: программа помнит идентификаторы уже забранных писем и пропускает их при следующем сеансе.

Почему приём почты через посредника идёт по SOCKS5

IMAP и POP3 это текстовые протоколы поверх обычного TCP, к HTTP они отношения не имеют. Посреднику для их переноса нужно уметь ровно одно: открыть соединение до пары «хост и порт» и переливать байты в обе стороны, не заглядывая внутрь. Так работает SOCKS5.

Рукопожатие занимает два коротких обмена. Клиент отправляет версию 0x05 и список поддерживаемых способов авторизации. Посредник выбирает способ: 0x00 при доступе по привязанному адресу либо 0x02 при доступе по логину и паролю. Затем клиент шлёт запрос CONNECT с типом адреса 0x03 для доменного имени, посредник открывает соединение и отвечает кодом 0x00. Дальше по каналу идут байты IMAP или POP3 в исходном виде.

Разрешение имён заслуживает отдельной строки. Когда клиент передаёт доменное имя внутри запроса CONNECT, имя превращается в адрес на стороне посредника, и запрос к DNS с рабочей машины наружу не уходит. В библиотеках этот режим включается схемой socks5h вместо socks5, в почтовых программах отдельной галкой в настройках сети. Мы советуем включать его сразу: прокси SOCKS5 для почтовых клиентов поддерживают оба варианта, и режим с удалённым разрешением имён даёт цельную картину по маршруту.

По HTTP приём почты тоже переносится, если программа умеет строить туннель методом CONNECT. Тогда клиент просит открыть канал до mail.example.net:993, получает 200 Connection established и работает внутри него. Такой путь встречается у серверных библиотек и у части утилит командной строки, поэтому прокси HTTP с методом CONNECT в почтовых задачах тоже применимы. Почтовые программы с графическим интерфейсом в настройках сети предлагают именно поля SOCKS, и потому в клиентах мы идём по SOCKS5. В пакете доступны SOCKS4 и SOCKS5 на выбор, для почты берём SOCKS5: он добавляет авторизацию по паре логина и пароля и передаёт имя хоста посреднику. Про разницу транспортов есть отдельный разбор про TCP и UDP через SOCKS5.

Порты, шифрование и что писать в настройках

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

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

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

Настройка в почтовом клиенте

В Thunderbird путь короткий: раздел настроек, страница «Основные», кнопка настроек соединения внизу. Там выбирается ручная настройка прокси, в поля узла SOCKS вписывается адрес и порт из списка, включается пятая версия протокола и ставится галка передачи имён DNS через посредник. Логин и пароль программа запросит при первом соединении.

Прокси-узел SOCKS:  185.24.87.14
Порт:               1080
Версия:             SOCKS v5
DNS через прокси:   включено

В eM Client и в других клиентах на своём сетевом слое поля называются похоже и лежат в разделе сети. Клиенты, которые берут системные настройки, заворачиваются через Proxifier или через локальный проброс: поднимается локальный порт, он смотрит на адрес из списка, а в почтовой программе указывается 127.0.0.1 с этим номером.

Учётная запись при этом настраивается обычным порядком: сервер входящей почты, порт 993 для IMAP или 995 для POP3, тип шифрования SSL/TLS, имя пользователя целиком с доменом. После сохранения программа делает пробное соединение, и его результат сразу показывает, работает ли связка.

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

Приём почты в коде: imaplib и poplib через PySocks

В Python приём почты закрывается стандартными модулями imaplib и poplib. Прокси добавляется библиотекой PySocks: она подменяет фабрику сокетов, после чего оба модуля работают без изменений в остальном коде.

import socks, socket, imaplib, email

socks.set_default_proxy(
    socks.SOCKS5, "185.24.87.14", 1080,
    username="user5521", password="pf39kd", rdns=True)
socket.socket = socks.socksocket

m = imaplib.IMAP4_SSL("mail.example.net", 993)
m.login("user@example.org", "secret")
m.select("INBOX")

typ, data = m.search(None, "UNSEEN")
for num in data[0].split():
    typ, raw = m.fetch(num, "(BODY.PEEK[])")
    msg = email.message_from_bytes(raw[0][1])
    print(num.decode(), msg.get("Subject"))
    m.store(num, "+FLAGS", "\\Seen")

m.logout()

Флаг rdns=True включает передачу доменного имени посреднику, и запрос к DNS с машины наружу не уходит. Без него имя разрешается локально, и картина по маршруту получается неполной.

import socks, socket, poplib

socks.set_default_proxy(
    socks.SOCKS5, "185.24.87.14", 1080,
    username="user5521", password="pf39kd", rdns=True)
socket.socket = socks.socksocket

p = poplib.POP3_SSL("mail.example.net", 995, timeout=30)
p.user("user@example.org")
p.pass_("secret")

count, size = p.stat()
print(count, size)

for i in range(1, count + 1):
    resp, lines, octets = p.retr(i)
    body = b"\r\n".join(lines)
    open(f"msg-{i}.eml", "wb").write(body)
    # p.dele(i)   # пометка к удалению применится на quit()

p.quit()

Строка p.dele(i) оставлена закомментированной осознанно. Пока скрипт отлаживается, ящик лучше держать нетронутым: пометки применяются на quit(), и одна невнимательная выгрузка уносит письма из ящика без возврата. Включать удаление стоит после того, как файлы стали появляться на диске в ожидаемом виде.

Подмена socket.socket действует на весь процесс. Когда в одном скрипте живут запросы напрямую и запросы через посредника, аккуратнее работать с socks.socksocket точечно: создать сокет, вызвать у него set_proxy, соединиться и передать готовый объект в imaplib.IMAP4 через параметр. Состав пакета с потоками, форматами выдачи и протоколами описан там, где оформляется пакет с доступом по SOCKS5.

Как убедиться, что соединение идёт через посредника

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

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

# полный сеанс IMAP через SOCKS5 глазами curl
curl -v --url "imaps://mail.example.net:993/INBOX?UNSEEN" \
     --user "user@example.org:secret" \
     --proxy socks5h://user5521:pf39kd@185.24.87.14:1080

# то же самое для POP3
curl -v --url "pop3s://mail.example.net:995/1" \
     --user "user@example.org:secret" \
     --proxy socks5h://user5521:pf39kd@185.24.87.14:1080

# выходной адрес того же канала
curl -s -x socks5h://user5521:pf39kd@185.24.87.14:1080 https://ifconfig.me

Пул держится в районе 12 000 активных адресов, ротация внутри него автоматическая, список обновляется в режиме реального времени. Отсюда практический вывод для почты: соседние сеансы штатно уходят с разных выходов, и удивляться смене адреса между проверками не нужно. Когда почтовому серверу нужна ровная картина по адресам, соединения стоит держать длинными: один сеанс IMAP с командой IDLE живёт часами и остаётся на одном канале. Полный состав доступа с протоколами IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5 описан на странице, где оформляется доступ к пулу IPv4 и SOCKS5.

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

Стабильность канала для почты значит больше, чем пиковая скорость. Выгрузка ящика идёт короткими порциями, а сеанс IMAP с командой IDLE живёт часами и болезненно переносит обрывы: клиент после разрыва повторяет SELECT, заново сверяет UIDVALIDITY и перечитывает список писем. Мы держим серверные адреса на собственном оборудовании и потому время отклика внутри пула ровное от сеанса к сеансу. Трафик безлимитный, поэтому объём выгруженных вложений на работу канала не влияет и считать его не нужно.

Ещё один способ увидеть маршрут снаружи это журнал самого почтового сервера. Dovecot пишет строку входа с адресом клиента в формате imap-login: Login: user=<...>, rip=185.24.87.14, lip=..., и значение rip показывает тот адрес, который сервер увидел на входе. Когда у вас есть доступ к журналам своего почтового сервера, эта строка закрывает вопрос быстрее любых команд на клиентской машине.

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

Какой тип прокси брать под почтовый клиент?

В пакете IPv4 и SOCKS5 доступны SOCKS-4 и SOCKS-5 на выбор, и для почты мы рекомендуем SOCKS-5. Он передаёт произвольный номер порта, поддерживает авторизацию по паре логина и пароля и разрешает доменное имя на своей стороне. Почтовые программы в разделе сетевых настроек предлагают именно поля SOCKS, поэтому настройка сводится к четырём значениям: адрес, порт, версия и галка передачи имён.

В каком формате выдаётся список прокси и как его получить?

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

Подойдут ли прокси под мой почтовый сервис?

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

Сколько одновременных сеансов приёма выдержит пакет?

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

Вокруг приёма почты собрано несколько смежных разборов. Обратная сторона ящика, то есть путь письма от программы отправителя до сервера получателя, описана в материале про протокол SMTP и путь письма. Что переписать в настройках, когда наружу уходят письма, показано в заметке про настройку отправки по SMTP через прокси. Выбор типа доступа под конкретную программу разложен в сравнении HTTP, HTTPS, SOCKS4 и SOCKS5. Настроенный клиент полезно один раз прогнать по общему порядку диагностики, он собран в материале про проверку работы прокси.

Источник: https://kupit-proxy-ipv4.ru/protokoly/imap-i-pop3/

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

Что уже есть на руках к этому моменту

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

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

Ещё одна мелочь: понадобится консоль. На Linux и macOS это терминал, на Windows подойдёт PowerShell или встроенный curl. Первый запрос мы делаем командой, потому что она отвечает однозначно и не тянет за собой настройки браузера, расширений и профилей.

Шаг первый: забираем список адресов из кабинета

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

Форматов тоже два. IP:PORT подходит тем, кто открывает доступ привязкой своей машины. IP:PORT:LOGIN:PASS содержит пару учётных данных прямо в строке и работает с любой машины. Выбор формата на этом шаге равен выбору способа доступа на следующем, поэтому оба вопроса закрываются вместе.

# формат из двух полей
185.24.87.14:8000
185.24.87.15:8000
91.208.132.77:8000

# формат из четырёх полей
185.24.87.14:8000:user5521:pf39kd
185.24.87.15:8000:user5521:pf39kd

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

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

Шаг второй: выбираем способ доступа

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

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

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

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

Шаг третий: собираем строку подключения

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

# доступ по привязанному адресу, протокол HTTP
http://185.24.87.14:8000

# доступ по учётным данным
http://user5521:pf39kd@185.24.87.14:8000

# тот же адрес по SOCKS5
socks5://user5521:pf39kd@185.24.87.14:8000

# SOCKS5 с разрешением имён на стороне выхода
socks5h://user5521:pf39kd@185.24.87.14:8000

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

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

Шаг четвёртый: первый запрос через curl

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

# адрес самой машины, без посредника
curl https://ifconfig.me
203.0.113.45

# тот же запрос через прокси
curl -x http://185.24.87.14:8000 https://ifconfig.me
185.24.87.14

# по учётным данным, пара вынесена отдельным параметром
curl -x http://185.24.87.14:8000 -U user5521:pf39kd https://ifconfig.me
185.24.87.14

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

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

# код ответа целевого сайта и время всего запроса
curl -o /dev/null -s -w "%{http_code} %{time_total}\n" \
     -x http://185.24.87.14:8000 https://example.com/catalog
200 0.612

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

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

# подробный вывод, шифрованный целевой адрес
curl -v -x http://185.24.87.14:8000 https://example.com
* Connected to 185.24.87.14 (185.24.87.14) port 8000
> CONNECT example.com:443 HTTP/1.1
< HTTP/1.1 200 Connection established
* SSL connection using TLSv1.3

Строка 200 Connection established означает, что туннель поднят и дальше данные идут в шифрованном виде. Посредник в этот момент видит только имя площадки и объём переданного, содержимое остаётся закрытым ключами сторон. Ради этой строки первую проверку и стоит делать на адресе с https: она подтверждает работу сразу на том режиме, в котором пойдёт вся дальнейшая работа.

Шаг пятый: браузер и рабочая программа

Тот же адрес в браузере

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

Быстрый способ проверить без правки системных настроек это отдельный профиль, запущенный с явным указанием посредника.

# отдельный профиль Chromium с указанием выхода
chromium --proxy-server="http://185.24.87.14:8000" \
         --user-data-dir=/tmp/proxy-test

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

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

Рабочая программа

Третья проверка идёт в той программе, ради которой всё затевалось. A-Parser, ZennoPoster, Key Collector и антидетект-браузеры принимают адреса в своих полях, и формат ввода у каждого свой. Где-то строка вставляется целиком, где-то адрес, порт, логин и пароль разносятся по четырём отдельным полям.

Первый прогон делаем коротким: 20 запросов на знакомом домене с одним потоком. Задача этого прогона не в скорости. Мы смотрим, принимает ли программа формат, доходят ли запросы и совпадает ли выходной адрес в её логах с тем, что показал curl.

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

Первый запрос не прошёл: разбор по порядку

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

Доступность порта. Проверяем, что до выхода вообще доходит соединение. Утилита nc или telnet отвечают за пару секунд, и ответ отделяет сетевую часть от всего остального.

# порт открыт и принимает соединение
nc -vz 185.24.87.14 8000
Connection to 185.24.87.14 8000 port [tcp/*] succeeded!

# порт молчит, дальше идти незачем
nc -vz 185.24.87.14 8000
nc: connect to 185.24.87.14 port 8000 (tcp) failed: Connection timed out

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

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

# 407 в подробном выводе
curl -v -x http://185.24.87.14:8000 https://ifconfig.me
< HTTP/1.1 407 Proxy Authentication Required

# соединение оборвано на приветствии
curl: (56) Recv failure: Connection reset by peer

Протокол. Доступ открыт, ответ приходит битым или соединение закрывается сразу после установки. Проверяем префикс строки: HTTP-порт с префиксом socks5:// и наоборот дают именно такую картину. Меняем префикс и повторяем ту же команду.

Целевой сайт. Три предыдущих шага зелёные, ifconfig.me показывает адрес из пула, а нужный домен отвечает кодом 403 или отдаёт страницу проверки. Тут дело уже в приёме на стороне сайта, и разбирается оно частотой запросов, заголовками и профилем браузера.

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

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

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

Как сохранить рабочие настройки

Собранная конфигурация стоит десяти минут работы, и терять её при каждой перезагрузке незачем. Самый короткий путь на Linux и macOS это переменные окружения: их читают curl, wget, pip, git и большинство утилит, которые ходят в сеть.

# ~/.bashrc либо ~/.zshrc
export http_proxy="http://185.24.87.14:8000"
export https_proxy="http://185.24.87.14:8000"
export no_proxy="localhost,127.0.0.1,.internal"

# разовый запуск без правки профиля
http_proxy=http://185.24.87.14:8000 curl https://ifconfig.me

Второй путь это файл ~/.curlrc, он касается только curl и не влияет на остальные программы. Третий это отдельный скрипт запуска, который подставляет адрес и сразу стартует прогон. Мы держим все три в одном рабочем каталоге, и переключение между режимами занимает одну команду.

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

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

Что даёт первое подключение дальше

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

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

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

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

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

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

Как подключиться к прокси сразу после покупки?

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

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

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

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

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

Почему выходной адрес меняется от запроса к запросу?

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

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

Источник: https://kupit-proxy-ipv4.ru/podklyuchenie/pervoe-podklyuchenie/

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

Что происходит при привязке адреса

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

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

# строка при доступе по привязке, пары нет вовсе
http://185.24.87.14:8000

# та же машина, доступ по учётным данным
http://user5521:pf39kd@185.24.87.14:8000

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

Как узнать свой внешний адрес

Внешний адрес машины отличается от того, что показывает ipconfig или ifconfig внутри системы. Локально видна цифра из домашней или офисной сети, наружу же машина выходит под адресом, который выдал провайдер или дата-центр. В кабинет вписываем именно внешний, и берём его с той машины, с которой пойдут запросы.

# Linux и macOS, короткий ответ одной строкой
curl -s https://ifconfig.me
203.0.113.45

# то же самое без внешних сервисов, через публичный резолвер
dig +short myip.opendns.com @resolver1.opendns.com
203.0.113.45

# Windows, PowerShell
Invoke-RestMethod https://api.ipify.org
203.0.113.45

# сервер без публичных сервисов вообще
ip route get 1.1.1.1

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

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

Где привязка задаётся в кабинете

Настройки привязки лежат в разделе доступа рядом со списком пакетов. Внутри два поля под адреса, кнопка сохранения и текущий статус каждой привязки. Правка вступает в силу без переоформления пакета: адрес заменяется, сохраняется, и следующий запрос уже проходит проверку по новому значению.

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

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

Две привязки в пакете и деление лимита потоков

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

Считается это в одно действие. Стандартный пакет даёт до 1000 потоков: одна привязка получает всю тысячу, две привязки получают по 500 каждая. Корпоративный пакет с лимитом до 3000 при двух привязках даёт по 1500 на сторону. Пакеты по потокам не складываются, поэтому два стандартных пакета на одном аккаунте работают каждый со своим лимитом.

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

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

Типовые схемы работы с двумя привязками

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

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

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

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

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

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

Провайдер сменил адрес: как это выглядит

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

Картина отказа узнаваемая. Соединение с портом устанавливается, потому что порт открыт для всех, а вот проверка права не проходит. Ответ приходит либо кодом 407 Proxy Authentication Required, либо обрывом соединения сразу после приветствия.

# было вчера
curl -x http://185.24.87.14:8000 https://ifconfig.me
185.24.87.14

# стало утром после перезагрузки роутера
curl -x http://185.24.87.14:8000 https://ifconfig.me
curl: (56) Recv failure: Connection reset by peer

# проверяем свой адрес напрямую, цифра поменялась
curl -s https://ifconfig.me
203.0.113.78

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

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

Привязка и пара учётных данных: где какой способ удобнее

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

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

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

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

Несколько машин через один общий шлюз

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

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

# все машины за одним шлюзом видят один внешний адрес
# station-01
curl -s https://ifconfig.me
203.0.113.45

# station-07
curl -s https://ifconfig.me
203.0.113.45

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

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

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

Что записать, чтобы привязка не подводила

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

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

# proxy-access.txt
# первое поле:  сервер парсинга, 198.51.100.20, сверено при настройке
# второе поле:  пусто, весь лимит идёт серверу
# проверка адреса: curl -s https://ifconfig.me
# доступ: формат IP:PORT, порт 8000

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

# краткая сверка перед запуском
CUR=$(curl -s https://ifconfig.me)
SAVED=198.51.100.20
[ "$CUR" = "$SAVED" ] && echo "адрес прежний" || echo "адрес сменился: $CUR"

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

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

Сколько адресов можно привязать к пакету?

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

Что делать, если у меня динамический адрес?

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

Есть ли лимиты по потокам?

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

Как подключиться к прокси после покупки?

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

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

Источник: https://kupit-proxy-ipv4.ru/podklyuchenie/privyazka-adresa/

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

Из каких полей состоит строка

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

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

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

Короткий вариант выглядит так: http://185.24.87.14:8000. Полный вариант с учётными данными выглядит так: http://user5521:pf39kd@185.24.87.14:8000. Обе записи ведут на один и тот же порт одного и того же посредника, различие сидит только в наличии учётной части. Мы выдаём список сразу в двух форматах, поэтому собрать любую из этих строк можно копированием, без ручной перепечатки цифр.

Схема: какие бывают и что каждая означает

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

Буква h в конце схемы отвечает за то, кто превращает имя домена в адрес. Без неё имя разрешает локальная машина, и наружу через обычный резолвер уходит сам домен. С ней имя уезжает внутрь туннеля и разрешается на выходе. Для работы через посредника вторая форма спокойнее, и в curl она пишется одной буквой. Подробности сокетного протокола разобраны там, где мы описываем прокси SOCKS5 с доступом к общему пулу.

Отличие http от https в схеме путает чаще прочего. Схема http не мешает открывать сайты по шифрованному протоколу: программа просит у посредника туннель методом CONNECT и дальше ведёт шифрованный обмен внутри него. Схема https означает другое: шифруется сам канал до посредника. Разбор туннеля и его поведения мы вынесли в материал про протоколы HTTP, HTTPS и SOCKS, здесь достаточно помнить, что первая часть строки описывает участок до посредника. Если программа умеет шифровать этот участок, ей подойдёт канал до посредника по HTTPS.

Адрес и порт: откуда они берутся

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

# формат из двух полей
185.24.87.14:8000
185.24.87.15:8000

# формат из четырёх полей
185.24.87.14:8000:user5521:pf39kd
185.24.87.15:8000:user5521:pf39kd

Превращение строки списка в строку подключения делается механически. Первое поле идёт в позицию адреса, второе в позицию порта, третье и четвёртое переезжают влево от собаки и меняются местами с хостом. Из строки 185.24.87.14:8000:user5521:pf39kd получается http://user5521:pf39kd@185.24.87.14:8000. Порядок полей в списке и порядок полей в строке подключения различаются, и это единственное место, где новичок путается.

# превращаем строку списка в строку подключения одной командой
awk -F: '{print "http://"$3":"$4"@"$1":"$2}' proxy.txt > urls.txt

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

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

Логин с паролем или доступ по привязке

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

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

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

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

Спецсимволы в пароле и процентное кодирование

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

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

Пароль p@ss:1 записывается как p%40ss%3A1, и строка целиком выглядит так: http://user5521:p%40ss%3A1@185.24.87.14:8000. Правая собака остаётся настоящим разделителем, левая уехала в код и разбор больше не путает. Считать коды руками не нужно, их выдаёт любая среда одной строчкой.

# кодируем пароль перед подстановкой в строку
python3 -c "import urllib.parse,sys;print(urllib.parse.quote(sys.argv[1],safe=''))" 'p@ss:1'
# -> p%40ss%3A1

from urllib.parse import quote
user, pwd = "user5521", "p@ss:1"
url = f"http://{quote(user, safe='')}:{quote(pwd, safe='')}@185.24.87.14:8000"

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

Переменные окружения: HTTP_PROXY, HTTPS_PROXY и NO_PROXY

Переменные окружения задают посредника сразу для всех программ, которые их читают. Это curl, wget, менеджеры пакетов, значительная часть библиотек на python, go и node. Имена пишутся в верхнем и нижнем регистре, часть программ смотрит только на нижний, поэтому выставляют обе формы.

export HTTP_PROXY="http://user5521:pf39kd@185.24.87.14:8000"
export HTTPS_PROXY="http://user5521:pf39kd@185.24.87.14:8000"
export NO_PROXY="localhost,127.0.0.1,.internal.local"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export no_proxy="$NO_PROXY"

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

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

В Windows те же значения выставляются через PowerShell, синтаксис отличается, смысл прежний.

$env:HTTP_PROXY  = "http://user5521:pf39kd@185.24.87.14:8000"
$env:HTTPS_PROXY = "http://user5521:pf39kd@185.24.87.14:8000"
$env:NO_PROXY    = "localhost,127.0.0.1"

Ключ curl и настройки библиотеки запросов

В curl строка подключения передаётся ключом -x либо длинной формой --proxy. Ключ перекрывает переменные окружения, поэтому проверять конкретный адрес удобнее именно им: окружение остаётся нетронутым, а команда работает через нужного посредника.

# доступ по привязанному адресу
curl -x http://185.24.87.14:8000 https://ifconfig.me

# доступ по учётным данным пакета
curl -x http://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

# учётные данные вынесены отдельным ключом, кодировать ничего не нужно
curl -x http://185.24.87.14:8000 -U 'user5521:p@ss:1' https://ifconfig.me

# сокетный вариант с разрешением имени на выходе
curl -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

Ключ -U спасает там, где пароль набит служебными знаками: curl принимает пару отдельным аргументом и сам собирает запрос. Проверить, какая строка ушла в работу, помогает подробный вывод: curl -v показывает установку туннеля и заголовок авторизации.

В python библиотека запросов принимает словарь, где ключом идёт целевой протокол, а значением та самая строка подключения. Схема socks5h требует установленного пакета PySocks, без него библиотека сообщит о неизвестном типе посредника.

import requests

proxies = {
    "http":  "http://user5521:pf39kd@185.24.87.14:8000",
    "https": "http://user5521:pf39kd@185.24.87.14:8000",
}
r = requests.get("https://ifconfig.me", proxies=proxies, timeout=15)
print(r.status_code, r.text)

# сокетный вариант, имя домена разрешает выход
socks = {
    "http":  "socks5h://user5521:pf39kd@185.24.87.14:1080",
    "https": "socks5h://user5521:pf39kd@185.24.87.14:1080",
}

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

Куда ещё вводится строка: конфиги и антидетект-браузер

Мест ввода много, при этом форма записи меняется от программы к программе. Где-то принимают строку целиком, где-то ждут отдельные поля, где-то тип посредника выбирается из списка и схема в тексте становится лишней. Ниже сведены основные места.

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

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

Запись SOCKS в разных программах

Сокетный вариант записывается несколькими способами, и это вторая по частоте причина неработающей настройки. В curl и в библиотеках на его основе схема пишется прямо в строке: socks5:// или socks5h://. В браузерах на движке Gecko тип выбирается радиокнопкой, поля хоста и порта заполняются отдельно, а передача имён на сторону посредника включается флажком. В браузерах на движке Chromium схема указывается ключом запуска. В парсерах и чекерах тип посредника выбирается из выпадающего списка, и в текстовое поле идёт голая пара IP:PORT.

# curl: схема прямо в строке
curl -x socks5h://185.24.87.14:1080 https://ifconfig.me

# Chromium: схема в ключе запуска
chrome --proxy-server="socks5://185.24.87.14:1080"

# git: сокетный посредник для операций с удалённым репозиторием
git config --global http.proxy socks5h://185.24.87.14:1080

# ssh через сокетного посредника
ssh -o ProxyCommand='nc -X 5 -x 185.24.87.14:1080 %h %p' user@target.host

Отдельно про порт. Сокетный посредник часто слушает другой порт, чем HTTP-вариант, поэтому подставлять порт из соседней строки списка бессмысленно. Берём порт из той строки, которую собираемся использовать. В пакете доступны обе версии сокетного протокола, при этом старшая поддерживает учётные данные и передачу имён, поэтому мы рекомендуем именно её. Полный состав того, что открывается вместе с сокетным доступом, описан на странице, где можно купить прокси SOCKS5 для парсеров и скриптов.

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

Типовые ошибки записи и что каждая даёт на выходе

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

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

# показать невидимые символы в конце строк
cat -A proxy.txt | head -3

# убрать возврат каретки
sed -i 's/\r$//' proxy.txt

Ещё одна ошибка живёт вне самой строки: переменные окружения выставлены в одном терминале, а программа запускается из другого. Строка написана верно, при этом процесс её не видит. Проверяется командой env | grep -i proxy в том же окне, откуда идёт запуск. Мы обычно советуем на время отладки вообще отказаться от окружения и передавать посредника ключом: так видно, какая именно строка ушла в работу.

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

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

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

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

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

Какой тип прокси лучше указывать в строке?

В пакете IPv4 и SOCKS5 доступны обе версии сокетного протокола на выбор, и мы рекомендуем старшую: она поддерживает учётные данные и передачу имён на сторону выхода. Для браузеров и парсеров, которые ходят по вебу, ровно так же хорошо работает HTTP-посредник из того же пакета.

Как подключиться к прокси после покупки?

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

Сколько адресов можно привязать к пакету?

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

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

Источник: https://kupit-proxy-ipv4.ru/podklyuchenie/stroka-podklyucheniya/

Ниже разобран каждый путь: где лежат поля в Firefox, как передавать запросы к DNS через посредника, как запускать браузеры на движке Chromium с отдельными профилями и ключами, чем берёт расширение и где у него слабое место. В конце проверка прямо из окна браузера и разбор ситуации, когда вместо страницы появляется окно с запросом логина и пароля.

Три способа задать посредника: что выбрать

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

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

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

Системные настройки: когда они уместны

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

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

Список исключений заслуживает внимания. Внутренние имена, локальный адрес и стенд разработки вписываются туда сразу, иначе часть рабочих инструментов перестанет открываться. Типовой набор: localhost, 127.0.0.1 и внутренний домен компании с точкой впереди.

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

Firefox: где именно лежат поля

Firefox держит собственные сетевые настройки, поэтому системные параметры он умеет игнорировать. Путь такой: меню настроек, раздел «Основные», прокрутка в самый низ до блока «Параметры сети», кнопка «Настроить». Открывается окно с переключателями.

Дальше по шагам. Ставим переключатель «Ручная настройка прокси». Заполняем поле «HTTP прокси» адресом из списка и соседнее поле «Порт». Ставим флажок «Также использовать этот прокси для HTTPS», тогда шифрованные адреса пойдут через того же посредника. Поле «Не использовать прокси для» оставляем под локальные имена.

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

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

network.proxy.socks_remote_dns   -> true
network.proxy.type               -> 1   (ручная настройка)
network.trr.mode                 -> 5   (встроенный резолвер отключён)

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

Сборки на том же движке повторяют это окно почти дословно: расположение блока «Параметры сети» и подписи полей совпадают. Различается только оформление меню.

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

Браузеры на движке Chromium: профиль и ключ запуска

Chrome, Edge, Yandex Browser и прочие сборки на движке Chromium собственных сетевых полей не показывают: кнопка настроек открывает системную панель. Посредник им задаётся ключом запуска, и это удобнее, чем кажется на первый взгляд.

# Windows, ярлык с ключом
chrome.exe --proxy-server="http://185.24.87.14:8000" --user-data-dir="C:\profiles\p1"

# сокетный вариант с разрешением имён на выходе
chrome.exe --proxy-server="socks5://185.24.87.14:1080" --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 185.24.87.14"

# исключения
chrome.exe --proxy-server="http://185.24.87.14:8000" --proxy-bypass-list="localhost;127.0.0.1;*.internal.local"

# Linux, то же самое из терминала
google-chrome --proxy-server="http://185.24.87.14:8000" --user-data-dir=/home/user/profiles/p1

Ключ --user-data-dir тут важнее самого посредника. Он задаёт отдельный каталог профиля: свои куки, своё хранилище, свои расширения. Без него новый процесс присоединяется к уже запущенному окну и наследует его сеть, поэтому ключ посредника молча теряется. Мы всегда указываем каталог профиля рядом с ключом посредника, и вопрос «почему не применилось» снимается сам.

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

Отдельные профили с разными адресами

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

# три параллельных профиля, каждый со своим адресом
chrome --user-data-dir=/opt/p1 --proxy-server="http://185.24.87.14:8000"
chrome --user-data-dir=/opt/p2 --proxy-server="http://185.24.87.15:8000"
chrome --user-data-dir=/opt/p3 --proxy-server="socks5://185.24.87.16:1080"

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

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

Расширение: быстрая смена и её цена

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

Выигрыш заметен там, где адрес меняется по десять раз за смену. Открыл панель, выбрал строку из списка, обновил вкладку. Ни перезапуска, ни ярлыков, ни правки полей. Список строк импортируется из файла выдачи целиком, и формат IP:PORT:LOGIN:PASS большинство расширений разбирает само.

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

Антидетект-браузер: посредник внутри профиля

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

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

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

Как убедиться прямо в браузере, что запросы идут через посредника

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

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

Третья проверка касается WebRTC: этот механизм умеет получать адреса сетевых интерфейсов в обход настроек посредника. В Firefox он выключается ключом media.peerconnection.enabled в служебных настройках, в браузерах на движке Chromium ставится расширение управления политикой WebRTC, в антидетект-сборках есть готовый переключатель в карточке профиля.

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

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

Окно с запросом логина и пароля

Всплывающее окно с полями имени и пароля означает ровно одно: посредник просит авторизацию, потому что в строке её не было. Такое поведение штатно для браузеров на движке Chromium, которые не принимают учётные данные внутри ключа запуска. Вписываем логин и пароль из строки списка формата IP:PORT:LOGIN:PASS, ставим флажок запоминания, и окно перестаёт появляться в этом профиле.

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

# быстрая сверка той же пары вне браузера
curl -x http://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

# если тут приходит 407, дело в паре, а не в настройках браузера
curl -o /dev/null -w "%{http_code}\n" -x http://185.24.87.14:8000 https://example.com

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

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

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

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

Как подключиться к прокси после покупки?

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

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

В кабинете два варианта получения: ссылка и файл. Форматов тоже два: IP:PORT и IP:PORT:LOGIN:PASS. Второй удобен для браузерных расширений и антидетект-профилей, потому что они разбирают его сами и раскладывают поля по местам.

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

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

Можно ли отобрать адреса по стране для браузера?

Выборка по отдельной стране не делается: пул это микс со всего мира, около 12 000 активных адресов, ротация внутри пула автоматическая. География охватывает 200+ стран, поэтому разнообразие подсетей в браузерных профилях получается само собой.

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

Источник: https://kupit-proxy-ipv4.ru/podklyuchenie/v-brauzere/

Дальше идут рабочие куски для оболочки, curl и wget, Python, Node.js, PHP, Java, контейнеров и служб, а следом поля посредника в парсерах и антидетект-браузерах и проверка на сервере, куда реально уходят пакеты. Всё проверяется одной командой, и порядок написан так, чтобы после каждого шага у администратора был ответ на вопрос «работает или нет».

Что нужно собрать до настройки

Перед правкой конфигов на руках должны быть четыре вещи: адрес, порт, протокол и способ доступа. Адрес с портом берём из списка в кабинете. Протокол выбираем под софт: HTTP и HTTPS понимают браузеры и почти все библиотеки, SOCKS4 и SOCKS5 нужны программам, которые ходят по произвольным портам и держат сокеты сами. Способ доступа определяет, будет ли в строке пара логина с паролем.