Skip to content
Advanced / 2 min read

Как использовать SOCKS5-прокси в Chrome с именем пользователя и паролем (метод локального моста)

Chrome не может передавать учётные данные SOCKS5, поэтому прокси с аутентификацией не работают «из коробки». В этом руководстве создаётся локальный мост с помощью gost или Privoxy, который хранит ваше имя пользователя и пароль IPRoyal и направляет трафик Chrome через прокси.

Windows macOS SOCKS5 Приватность/Анонимность

Обзор

Chrome и другие браузеры на Chromium могут использовать SOCKS5-прокси через флаг --proxy-server, но не могут передавать имя пользователя и пароль SOCKS5. В Chrome нет диалога ввода учётных данных для SOCKS5, а распространённые прокси-расширения аутентифицируют только HTTP- и HTTPS-прокси. Если ваш прокси требует входа, Chrome либо завершается ошибкой ERR_PROXY_CONNECTION_FAILED, либо подключается без учётных данных и получает отказ.

Решение — локальный мост: небольшой форвардер, который слушает 127.0.0.1, принимает неаутентифицированный трафик от Chrome и пересылает его на аутентифицированный upstream-эндпоинт SOCKS5. Chrome никогда не видит учётные данные, а сетевой стек браузера никогда не обращается к upstream напрямую.

Как каждый способ проксирования ведёт себя в Chrome

Способ Обрабатывает учётные данные SOCKS5 Примечания
Флаг --proxy-server="socks5://..." Нет Разрешает DNS на прокси, но не работает, когда upstream требует аутентификацию
Настройка прокси в ОС или системе Нет Та же ограниченность, к тому же влияет на все приложения, а не на один профиль браузера
Прокси-расширение Нет Большинство расширений поддерживают только аутентификацию HTTP и HTTPS
Список разрешённых IP у провайдера Не требуется Работает только если ваш тариф и конфигурация это поддерживают
Локальный мост (это руководство) Да Учётные данные остаются на вашей машине; Chrome обращается к localhost

Предварительные требования

  • Установленный Chrome или Chromium, который можно запустить из командной строки
  • Учётные данные IPRoyal SOCKS5: хост шлюза, порт, имя пользователя, пароль из вашей панели управления
  • Локальный форвардер: gost (рекомендуется) или Privoxy
  • Права на запуск слушателя, привязанного к 127.0.0.1

Шаги

  1. Проверьте, не снимает ли проблему полностью разрешение по IP. Некоторые провайдеры позволяют авторизовать фиксированный IP-адрес вместо отправки учётных данных. Откройте панель управления IPRoyal и уточните, есть ли такая опция для используемого вами тарифа. Если есть и ваш публичный IP стабилен, можно пропустить мост и использовать флаг --proxy-server напрямую.

  2. Установите локальный форвардер. gost поддерживает SOCKS5 в обоих направлениях и поставляется одним бинарным файлом, что делает его самым простым выбором.

  • Windows: скачайте бинарный файл gost со страницы официальных релизов и добавьте его в PATH
  • macOS: установите gost через ваш пакетный менеджер, если пакет доступен, иначе скачайте бинарный файл
  • Linux: установите бинарный файл со страницы релизов или воспользуйтесь пакетом дистрибутива, если он доступен
  1. Запустите мост. Он слушает локальный порт без аутентификации и пересылает всё на аутентифицированный upstream.
gost -L socks5://127.0.0.1:1080 -F 'socks5://USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT'

В Windows PowerShell заключите URL upstream в кавычки:

gost -L socks5://127.0.0.1:1080 -F "socks5://USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT"

Оставьте этот процесс работать в отдельном окне терминала, пока вы работаете в браузере.

  1. Проверьте мост, прежде чем трогать Chrome. Этот запрос идёт через мост, поэтому возвращённый адрес должен быть IP-адресом выхода прокси, а не адресом вашего интернет-провайдера.
curl --socks5-hostname 127.0.0.1:1080 https://api.ipify.org

Если команда зависает, мост не пересылает трафик. Если возвращается ошибка аутентификации, учётные данные upstream неверны.

  1. Запустите Chrome через мост. Используйте отдельный профиль, чтобы повседневный браузинг остался нетронутым и флаг не попал в вашу обычную сессию.

macOS:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --proxy-server="socks5://127.0.0.1:1080" \
  --user-data-dir="$HOME/.chrome-proxy-profile"

Linux:

google-chrome \
  --proxy-server="socks5://127.0.0.1:1080" \
  --user-data-dir="$HOME/.chrome-proxy-profile"

Windows:

& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --proxy-server="socks5://127.0.0.1:1080" `
  --user-data-dir="$env:TEMP\chrome-proxy-profile"

  1. Подтвердите IP-адрес выхода внутри Chrome. Откройте страницу определения IP в новом окне и сравните адрес с тем, который вернул curl. Они должны совпадать. Если Chrome показывает ваш реальный IP, см. раздел устранения неполадок.

  2. Сделайте переиспользуемый лаунчер, чтобы не вводить флаги заново. В macOS или Linux сохраните команду в shell-скрипте или алиасе. В Windows создайте ярлык, цель которого включает флаги и путь --user-data-dir.

  3. Меняйте IP, перезапуская мост с новой upstream-идентичностью. Мост сохраняет одну upstream-идентичность, пока работает, поэтому смена IP-адреса выхода или переход на эндпоинт конкретной страны из панели управления означает остановку gost, повторный запуск с новой строкой таргетинга и перезагрузку Chrome.

Альтернатива: Privoxy как фронтенд

Если вам нужен HTTP-прокси перед upstream SOCKS5, потому что используемый инструмент или расширение поддерживает только HTTP-прокси, Privoxy может выполнить преобразование.

Добавьте эти строки в его файл конфигурации:

listen-address 127.0.0.1:8118
forward-socks5t / USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT .

Затем направьте Chrome на локальный HTTP-слушатель:

google-chrome --proxy-server="http://127.0.0.1:8118" --user-data-dir="$HOME/.chrome-privoxy-profile"

forward-socks5t сохраняет разрешение DNS на стороне прокси, что важно, когда вы проверяете контент, привязанный к региону.

Устранение неполадок

  • ERR_PROXY_CONNECTION_FAILED: мост не запущен, указан неверный порт или Chrome направлен на upstream-эндпоинт вместо 127.0.0.1.
  • Chrome игнорирует флаги: существующий процесс Chrome мог перехватить новое окно. Закройте все окна Chrome и фоновые процессы, затем запустите снова. Отдельный --user-data-dir предотвращает это.
  • Страницы загружаются, но показывают ваш реальный IP: убедитесь, что вы в профиле, который запустили с флагом. Расширения, управляющие настройками прокси, корпоративная политика и PAC-скрипты могут переопределять прокси из командной строки.
  • Учётные данные отклонены upstream: закодируйте специальные символы в пароле процентным кодированием (@ становится %40, : становится %3A) или передайте upstream отдельными параметрами, если ваш форвардер это поддерживает.
  • Некоторые сайты зависают при первой загрузке: пересылка SOCKS5 покрывает TCP, но не UDP, а Chrome может пытаться использовать QUIC поверх UDP. Запускайте с --disable-quic, если сайт отваливается по тайм-ауту до отрисовки.
  • WebRTC раскрывает локальные адреса: проксирование SOCKS5 не покрывает WebRTC. Установите обработку IP-адресов WebRTC в disable_non_proxied_udp через корпоративную политику или управляйте этим с помощью политики браузера либо расширения.
  • Мост доступен из вашей сети: всегда привязывайтесь к 127.0.0.1, никогда к 0.0.0.0. Любой, кто может достучаться до слушателя, сможет использовать вашу прокси-учётную запись.

Итог

Chrome не может передавать учётные данные SOCKS5, поэтому практичное решение — локальный мост: gost или Privoxy слушает на loopback, хранит имя пользователя и пароль IPRoyal и пересылает трафик Chrome на аутентифицированный upstream SOCKS5. Проверьте IP-адрес выхода с помощью curl перед запуском браузера, используйте отдельный --user-data-dir и перезапускайте мост всякий раз, когда нужен новый IP или другая страна.