Авторизация прокси: login:pass и IP-whitelist
После покупки прокси NEONPROXY вы получаете host, port и credentials — или настраиваете доступ по IP. Без корректной авторизации браузер и скрипты возвращают 407 Proxy Authentication Required или таймаут. Разберём оба метода: когда какой удобнее и как не слить пароль в логи.
Login:pass — универсальный вариант
Формат строки подключения:
http://LOGIN:PASSWORD@HOST:PORT
LOGIN и PASSWORD выдаются в кабинете или TG-боте после оплаты. Для HTTPS-целей используйте схему http:// в proxy URL (CONNECT-туннель), не https:// к самому прокси, если провайдер не указал иное.
SOCKS5: socks5://LOGIN:PASSWORD@HOST:PORT — поддерживается на всех тарифах NEONPROXY наряду с HTTPS. Сравнение протоколов — в материале SOCKS5 vs HTTPS.
Способы передачи credentials
В URL прокси — просто, но пароль виден в process list и иногда в debug-логах HTTP-клиентов. Proxy-Authorization header — Base64(login:pass); requests и curl отправляют автоматически при proxies dict. Отдельные поля — в Playwright, Puppeteer, антидетект-браузерах: username/password без embedding в URL.
Спецсимволы в пароле (@, :, #) нужно URL-encode: %40, %3A, %23. Иначе парсер URL обрежет строку и auth сломается.
Примеры настройки
curl:curl -x "http://user:pass@1.2.3.4:8080" https://example.com
Python requests:proxies = {"http": "http://user:pass@host:port", "https": "http://user:pass@host:port"}
Chrome / Firefox: настройки → прокси → ручная конфигурация host:port + отдельные поля логин/пароль при запросе системы.
ENV-переменные: HTTP_PROXY и HTTPS_PROXY — стандарт для Docker и CI; не коммитьте .env в git.
Больше примеров кода — в статье прокси и Python requests.
IP-whitelist — доступ без пароля в коде
Альтернатива login:pass: в кабинете добавляете source IP сервера, подключаетесь как http://HOST:PORT без credentials. Подробный гайд — whitelist IP у провайдера.
Выбор метода:
Login:pass — ноутбук, домашний IP, антидетект-браузер, команда с разных локаций. Whitelist — VPS, dedicated crawler, CI runner со статическим egress.
Можно включить оба: whitelist для prod-серверов, login:pass для разработчиков — ограничьте силу пароля и ротируйте при увольнении.
Ошибка 407 и диагностика
407 означает: прокси не принял auth. Чеклист: правильный login/pass (копипaste без пробелов), URL-encoding спецсимволов, whitelist содержит ваш реальный egress IP (проверьте через «Мой IP»), не истёк ли срок аренды прокси, верный port (HTTP vs SOCKS).
Таймаут без 407 — чаще firewall или неверный host, не auth. Проверьте прокси в чекере с теми же credentials, что в проде.
Безопасность credentials
Не храните login:pass в frontend JavaScript — пользователь браузера увидит их в DevTools. Secrets manager (Vault, AWS Secrets) для prod. Rotate password при утечке репозитория — смена в кабинете NEONPROXY моментальная.
Zero logs policy NEONPROXY не сохраняет ваш трафик, но пароль в URL может попасть в access log вашего приложения — используйте header auth или whitelist где возможно.
Auth в SOCKS5
SOCKS5 auth — отдельный handshake (RFC 1929): username/password после TCP connect. Библиотеки (PySocks, curl --socks5) принимают user:pass в URL. Некоторые GUI только HTTP auth — тогда используйте HTTPS-прокси на том же порту.
Мультиаккаунтинг и SMM
Один login:pass на аккаунт прокси NEONPROXY = один выделенный IP. Не шарьте credentials между антидетект-профилями: при бане одного «соседа» по паролю пострадают все. Для Instagram и маркетплейсов — отдельный приватный IPv4 на профиль, см. прокси для Instagram.
API и автоматизация заказов
API v2 возвращает connection string после создания заказа — парсите programmatically, не hardcode. Интеграция описана в гайде по API. При autoscaling воркеров каждый инстанс может получить свой login или свой slot в whitelist.
Краткий итог
Login:pass — гибко, работает откуда угодно, требует дисциплины с секретами. IP-whitelist — чище для серверов, бесполезен при динамическом IP. Проверяйте auth до запуска краулера: один успешный curl сэкономит часы отладки 407 в production.