Прокси-порт не пускает подключение без авторизации — иначе им пользовался бы кто угодно, кто узнал адрес и порт. Провайдеры дают два способа сказать порту «это свой»: закрепить пару логин-пароль или внести внешний IP клиента в whitelist. Способы не взаимозаменяемы: у каждого свой отказ, своя точка утечки и своё удобство при командной работе. Разберём, какой брать под конкретную инфраструктуру.
Как работают оба способа
Логин-пароль передаётся в самом запросе на подключение — либо в URL прокси (login:password@host:port), либо отдельным заголовком авторизации. Порт проверяет пару при каждом соединении, независимо от того, откуда пришёл запрос. Это классическая проверка «кто ты», привязанная к учётным данным, а не к месту подключения.
Whitelist по IP работает иначе: порт заранее знает список внешних адресов, которым разрешено подключаться без пароля. Проверка идёт не «кто ты», а «откуда ты» — сверяется IP, с которого пришёл TCP-запрос к прокси. Если внешний адрес клиента не совпадает со внесённым в список, соединение отклоняется ещё до попытки авторизации.
Когда удобнее whitelist по IP
Whitelist экономит время там, где внешний адрес клиента стабилен: выделенный сервер, офисный канал со статическим IP, VPS в облаке. Один раз внести адрес в кабинете — и дальше подключение идёт без пароля в каждом скрипте, что упрощает конфиги и снимает риск случайно закоммитить пару в репозиторий. Для серверной автоматизации, где скрипт работает годами с одного и того же хоста, это самый низкотрудозатратный вариант. Прежде чем полагаться на whitelist, стоит убедиться, что сам канал даёт стабильные метрики — иначе за стабильностью адреса легко не заметить деградацию самого соединения.
Минус ровно один, но фатальный: если внешний IP сервера меняется — провайдер хостинга выдал новый адрес после перезагрузки, переезд на другой дата-центр, смена тарифа у оператора — whitelist перестаёт узнавать клиента мгновенно и без предупреждения. Скрипт начинает получать отказ в соединении, а не ошибку авторизации, и это дольше диагностируется: код выглядит рабочим, прокси выглядит оплаченным, а трафик просто не идёт.
Когда обязателен логин-пароль
Динамический внешний адрес делает whitelist бесполезным в принципе. Домашний интернет с переподключением по DHCP, мобильный доступ, ноутбук, который каждый день выходит в сеть из нового места, — в этих сценариях IP-адрес клиента меняется чаще, чем успевает обновиться список в кабинете провайдера. Логин-пароль в этой ситуации — единственный работающий способ: авторизация не зависит от того, откуда физически пришёл запрос.
Второй случай — много машин с одной парой доступа. Когда с прокси работают несколько сотрудников или несколько серверов с разными и непредсказуемыми адресами, вносить в whitelist каждый IP вручную неэффективно, а при облачной инфраструктуре с автоскейлингом — вообще невозможно: новые инстансы получают новые адреса динамически. Похожая логика в командах, которые ведут аккаунты через антидетект-браузер: у каждого сотрудника свой профиль и свой IP, и закреплять адрес в whitelist под каждого не имеет смысла.
Риски утечки пары логин-пароль
У логин-пароля есть слабое место, которого лишён whitelist: пара доступа — это секрет, который может утечь. Она попадает в логи приложения при отладке, в историю команд шелла, в публичный репозиторий при случайном коммите конфига, в переписку при передаче доступа коллеге. Получивший пару подключается с любого IP — прокси не проверяет, откуда пришёл запрос, только кто назвал правильный пароль.
Whitelist в этом смысле устойчивее: даже если кто-то узнает адрес и порт прокси, без внесения его собственного внешнего IP в список подключиться не получится. Секрета, который можно скопировать и унести, здесь нет — есть привязка к инфраструктуре, которую посторонний не контролирует.
Что выбрать для командной работы
Смешанный подход обычно точнее одного универсального решения. Для стабильной серверной инфраструктуры — whitelist: меньше секретов в конфигах, ниже риск утечки. Для сотрудников с разъездным или домашним доступом, для тестовых окружений и для интеграций через API — логин-пароль, но с обязательной ротацией: если пара передавалась в переписке или использовалась в тесте, её стоит сменить, а не оставлять бессрочной. Проверить, какой способ доступен на конкретном порту и в каком объёме трафика, можно в кабинете при выдаче адреса.
Частые вопросы
Можно ли использовать оба способа одновременно на одном порту?
Обычно порт применяет одну схему проверки, заданную при выдаче, но ничто не мешает держать несколько портов под разные сценарии: часть с whitelist для серверов, часть с логин-паролем для мобильных и разъездных задач.
Почему прокси вдруг перестал пускать без изменений в коде?
Самая частая причина — сменился внешний IP клиента, который был внесён в whitelist. Проверьте текущий исходящий адрес сервера и сверьте его со списком в кабинете; провайдер хостинга может менять адрес при перезагрузке или миграции.
Что безопаснее хранить в конфиге — пароль или расчёт на whitelist?
Если инфраструктура стабильна, whitelist безопаснее: в конфиге не остаётся секрета, который можно скопировать. Если адрес клиента меняется, логин-пароль неизбежен — тогда его стоит хранить в переменных окружения или менеджере секретов, а не в открытом виде в репозитории.
Выбрать тип авторизации и оформить доступ под свою инфраструктуру можно в разделе прокси. Там же видно, какие каналы держат whitelist, а какие выдаются только по логин-паролю — это стоит сверить до оплаты, а не после первого отказа в соединении.