Продление прокси через API: автоматизация NEONPROXY

Прокси с истёкшим сроком — простой парсера, разрыв SMM-сессии, падение рекламного кабинета в момент запуска кампании. Ручное продление десятков адресов каждую неделю отнимает время и создаёт риск человеческой ошибки: забыли один proxy_id — утром scraper молчит. API NEONPROXY позволяет продлевать заказы программно: по расписанию, по событию или при падении баланса ниже порога.

Базовый сценарий prolong

Каждый заказ имеет ID. Метод prolong принимает идентификатор и период продления, списывает средства с баланса и обновляет date_expire. Перед вызовом получите список активных прокси — интеграция API описывает аутентификацию Bearer-токеном и форматы ответа JSON. Храните API-ключ в переменных окружения или secrets manager, не в репозитории и не в Slack.

После prolong перепроверьте credentials: иногда меняется порт или пароль — прогоните чекер. Обновите конфиг scraper'а из того же API-эндпоинта, а не вручную.

Канал SVYAZVPN Открыть бота

Cron и мониторинг

Типичный cron: раз в сутки проверять прокси, у которых до истечения меньше 3 дней, и вызывать prolong. Логируйте HTTP-коды и тело ответа в structured logs (JSON). При 402 (недостаточно средств) — алерт в Telegram или email. Свяжите с ротацией: если IP не продлён, исключите его из пула до ручной проверки, иначе половина запросов упадёт на expired адресах.

Для Kubernetes используйте CronJob; для bare metal — systemd timer. Idempotency: повторный prolong на уже продлённый заказ не должен ломать пайплайн — обрабатывайте 409 gracefully.

Баланс и автопополнение

Автопродление бессмысленно при нулевом балансе. Настройте порог: при balance < X — уведомление ответственному и блокировка deploy новых воркеров. Для команд с высоким оборотом рассмотрите партнёрскую программу — партнёрка NEONPROXY. Безопасная оплата — в статье про безопасную оплату.

Оптовые закупки с prolong — см. опт IPv4. Считайте runway: (баланс / средний дневной расход на prolong) — сколько дней до остановки.

Интеграция в пайплайны

DevOps-команды встраивают prolong в Ansible/Terraform или GitHub Actions: перед деплоем scraper проверяется, что все proxy_id из конфига активны и expire > 7 дней. Python — пара строк requests с Bearer-токеном. Node.js — axios, см. Node.js и прокси. Ruby Faraday и Go net/http — аналогично через proxy URL только для исходящих вызовов к API, не путать с прокси-пулом проекта.

Staging-среда может использовать короткие сроки аренды — отдельный cron с другим порогом expire. Не смешивайте staging и production proxy_id в одном secrets файле.

Обработка ошибок

404 — заказ не найден или уже удалён. 409 — конфликт статуса. Retry с exponential backoff при 5xx. Не вызывайте prolong в tight loop — уважайте rate limits API. При повторяющихся 401 — ротация скомпрометированного ключа. Логируйте proxy_id, timestamp, response code — без паролей прокси в plaintext.

После массового prolong запустите smoke test: curl через каждый 10-й IP или sampling 5% пула. Отладка сетевых ошибок — отладка прокси.

Webhook и уведомления

Настройте webhook или polling статуса заказов: за 7, 3 и 1 день до expire шлите уведомление в Slack/Telegram. Интеграция с PagerDuty для production-пулов — prolong failed в 3 ночи не должен ждать утра. Храните историю prolong в таблице audit: кто, когда, какой proxy_id, результат.

Для агентств с клиентскими кабинетами привяжите prolong к биллингу клиента: автопродление IP только при активной подписке клиента на ваши услуги. Иначе маржа уходит на прокси простаивающих аккаунтов.

Безопасность API-ключа

Ключ с правами prolong не должен лежать на машине SMM-менеджера. Выделите management VPC или CI runner с egress только к API NEONPROXY. Ротация ключа — раз в квартал или при offboarding. Логи API без паролей прокси — только proxy_id и HTTP status.

Тестируйте prolong на staging proxy_id перед включением cron в production — один ошибочный период списания лучше обнаружить на дешёвом IP, чем на пуле из 100 адресов.

Чеклист

API-ключ в secrets. Cron за 2–3 дня до expire. Алерты на баланс и ошибки. Лог prolong в централизованное хранилище. Документация: какой proxy_id за какой аккаунт отвечает. Регулярный audit неиспользуемых IP — не продлевайте «мёртвые» адреса автоматически без review.