Whitelist IP на стороне прокси-провайдера
Стандартная схема доступа к прокси — логин и пароль в URL или заголовке Proxy-Authorization. Альтернатива — IP-whitelist: прокси-gateway принимает соединения только с заранее указанных адресов. Так работают многие корпоративные и серверные сценарии: краулер на VPS, CI/CD pipeline, выделенный worker без хранения credentials в коде.
Как работает whitelist
При подключении к прокси-серверу gateway смотрит на source IP клиента. Если адрес есть в белом списке вашего аккаунта — трафик пропускается без login:pass (или с упрощённой auth). Если нет — соединение отклоняется с 407 Proxy Authentication Required или обрывается на TCP-уровне.
Whitelist привязан к аккаунту или конкретному заказу прокси. Один сервер с фиксированным IP — типичный кейс. Несколько адресов — для кластера воркеров или резервного сервера.
Зачем использовать whitelist вместо login:pass
Безопасность конфигов. Пароль прокси не попадает в переменные окружения CI, логи и stack trace. Достаточно знать host:port — credentials «вшиты» в сетевой уровень доверия.
Совместимость софта. Некоторые legacy-приложения не поддерживают proxy auth или некорректно кодируют спецсимволы в пароле. Whitelist снимает этот барьер.
Аудит. Явный список IP, с которых разрешён доступ — проще расследовать инциденты, чем ротацию общих credentials между десятью разработчиками.
Минус: whitelist бесполезен для домашнего ПК с динамическим IP и для мобильных сценариев. Там остаётся login:pass — см. статью про авторизацию прокси.
Как узнать свой IP для whitelist
С сервера, который будет ходить в прокси, выполните запрос к внешнему сервису или откройте «Мой IP» NEONPROXY в браузере с этой машины. Для VPS это обычно один статический IPv4. Для CI (GitHub Actions, GitLab) — диапазоны published IP ranges провайдера; whitelist по /32 надёжнее, но при смене runner IP придётся обновлять список.
IPv6: если ваш сервер выходит в интернет по v6, добавьте и v6-адрес — иначе трафик может пойти не тем путём, который вы whitelisted.
Настройка в кабинете NEONPROXY
После покупки прокси откройте карточку заказа в личном кабинете или TG-боте. Раздел «Доступ» / «Whitelist» — добавьте IPv4 в формате A.B.C.D без маски (или с /32, если интерфейс поддерживает CIDR). Сохранение обычно применяется за 1–5 минут; старые соединения могут жить до disconnect.
Можно комбинировать: whitelist + резервный login:pass для экстренного доступа с ноутбука — но не оставляйте пароль в публичном репозитории.
Проверка после добавления
С whitelisted-сервера:
curl -x http://proxy.host:port https://api.ipify.org
Должен вернуться exit IP прокси, не IP вашего сервера. Затем прогоните адрес через прокси-чекер: latency, HTTPS, SOCKS5 если нужен.
С не-whitelisted машины тот же curl должен fail — это подтверждает, что защита работает.
Типичные ошибки
NAT и несколько выходов. Сервер за NAT может показывать разные source IP в зависимости от маршрута. Whitelist одного адреса, а реальный egress другой — 407 и часы отладки.
Забыли обновить при миграции. Перенесли краулер на новый VPS — whitelist старый. Добавьте новый IP до cutover.
Whitelist только office IP, crawl с cloud. Разработчик тестирует локально (работает), прод на AWS (не работает).
Слишком широкий CIDR. /16 в whitelist на shared hosting — соседи по подсети теоретически могут использовать ваш прокси, если знают host:port.
Whitelist vs firewall на вашей стороне
Whitelist у провайдера — кто может подключиться к прокси. Firewall на VPS — куда ваш сервер может ходить. Это разные слои. Рекомендуем outbound allow только на порты прокси NEONPROXY и целевые API — defense in depth.
CI/CD и автоматизация
Для GitHub Actions используйте self-hosted runner со статическим IP или прокси-мiddleware на своём сервере с whitelist. Хранить login:pass в GitHub Secrets допустимо, но ротация пароля требует обновления secrets; whitelist стабильнее для dedicated infra.
API v2 NEONPROXY позволяет управлять заказами programmatically — подробнее в гайде по API. Whitelist через API экономит ручные правки при autoscaling (если провайдер поддерживает dynamic update).
Безопасность
Whitelist не заменяет HTTPS к прокси-gateway там, где поддерживается TLS to proxy. Не публикуйте host:port прокси в open source без whitelist — scan брутфорсит открытые порты. При компромиссе сервера из whitelist злоумышленник получает доступ к вашему прокси-пулу — мониторьте аномальный трафик в кабинете.
NEONPROXY придерживается zero logs policy — следите за usage на своей стороне.