Смена привязанного адреса прокси и переезд на другую машину

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

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

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

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

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

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

Порядок смены в кабинете: пять шагов

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

Шаг первый. Узнаём внешний адрес новой машины. Запрос делается с той самой машины, с которой пойдут запросы через пул. Адрес вида 192.168.0.15 или 10.8.0.3 в настройки не годится, кабинету видна только внешняя точка выхода.

# Linux и macOS
curl -s https://ifconfig.me
curl -s https://api.ipify.org

# то же самое, если curl отсутствует
wget -qO- https://ifconfig.me

# Windows PowerShell
(Invoke-RestMethod https://ifconfig.me/ip).Trim()

# внутренние адреса машины, для сверки
Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, InterfaceAlias

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

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

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

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

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

# код ответа и время, без тела страницы
curl -x http://178.62.203.41:8000 -sS -o /dev/null \
  -w "code=%{http_code} connect=%{time_connect}\n" https://example.com

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

Отказ по привязке или другая причина: как отличить

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

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

# 1. проверка прямого выхода: адрес машины сейчас
curl -s https://ifconfig.me; echo

# 2. проверка через пул: обрыв здесь при рабочем шаге 1 указывает на доступ
curl -sS -x http://178.62.203.41:8000 https://ifconfig.me; echo

# 3. подробный вывод, видно на каком этапе оборвалось
curl -v -x http://178.62.203.41:8000 https://example.com 2>&1 | head -20

Типичный вывод при отказе по привязке выглядит как curl: (56) Recv failure: Connection reset by peer либо как обрыв сразу после Connected to 178.62.203.41. Ошибка 407 Proxy Authentication Required говорит о другом: запрос дошёл, проверка права сработала и ждёт пару логина с паролем. Разбор этой ошибки по шагам мы вынесли отдельно, здесь достаточно понимать разницу между двумя картинами.

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

Динамический адрес провайдера: переход на логин с паролем

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

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

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

# формат с парой логина и пароля
178.62.203.41:8000:usr8830:t4mq7v
178.62.203.42:8000:usr8830:t4mq7v

# тот же запрос с учётными данными в строке
curl -x http://usr8830:[email protected]:8000 https://ifconfig.me

# пара вынесена отдельным ключом, удобно при служебных символах в пароле
curl -x 178.62.203.41:8000 --proxy-user 'usr8830:t4mq7v' https://ifconfig.me

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

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

Две привязки в пакете: как освободить одну

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

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

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

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

Лимит потоков в момент смены

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

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

# короткая серия запросов, видно где начинаются отказы
for i in $(seq 1 20); do
  curl -sS -o /dev/null -w "%{http_code} " \
    -x http://178.62.203.41:8000 https://example.com
done; echo

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

Смена привязки во время запущенного прогона

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

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

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

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

#!/usr/bin/env bash
# следим за внешним адресом машины во время прогона
STATE=/var/lib/collector/wan.ip
cur=$(curl -s --max-time 10 https://ifconfig.me)
old=$(cat "$STATE" 2>/dev/null || echo "")

if [ -n "$cur" ] && [ "$cur" != "$old" ]; then
  echo "$(date '+%H:%M:%S') внешний адрес сменился: ${old:-нет данных} -> $cur"
  echo "$cur" > "$STATE"
fi

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

Переезд на сервер: порядок действий

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

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

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

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

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

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

Переезд на новую машину и работа из другого места

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

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

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

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

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

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

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

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

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

Есть ли лимиты по потокам после смены привязки?

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

Как подключиться к прокси после смены привязки?

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

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