Первое подключение прокси IPv4: от включённого пакета до рабочего запроса

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

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

Что уже есть на руках к этому моменту

К первому подключению у нас есть три вещи: активный пакет, доступ в кабинет и понимание, с какой машины пойдут запросы. Пакет включается примерно за 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:[email protected]:8000

# тот же адрес по SOCKS5
socks5://user5521:[email protected]:8000

# SOCKS5 с разрешением имён на стороне выхода
socks5h://user5521:[email protected]: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 адресов, список обновляется в реальном времени. Для задач вроде сбора открытых данных и проверки выдачи такое устройство пула даёт разнообразие подсетей само по себе.

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