Подключение прокси в браузере: настройка по шагам

Посредника в браузере задают тремя путями: системными настройками, встроенными настройками самого браузера и расширением. Первый путь разворачивает все программы машины разом, второй работает только внутри браузера, третий переключает адреса в один клик и удобен там, где строка меняется часто.

Ниже разобран каждый путь: где лежат поля в Firefox, как передавать запросы к DNS через посредника, как запускать браузеры на движке Chromium с отдельными профилями и ключами, чем берёт расширение и где у него слабое место. В конце проверка прямо из окна браузера и разбор ситуации, когда вместо страницы появляется окно с запросом логина и пароля.

Три способа задать посредника: что выбрать

Разница между способами держится на охвате и скорости переключения. Системные настройки меняют поведение всей машины: почтовый клиент, менеджер обновлений и любая программа, которая читает системные параметры, пойдут через посредника вместе с браузером. Встроенные настройки браузера ограничивают охват одним приложением. Расширение живёт внутри браузера и переключает адреса без перезапуска.

Мы обычно советуем начинать со встроенных настроек браузера: охват предсказуемый, ничего лишнего в систему не уезжает, и откатить настройку можно за десять секунд. Системный путь берут тогда, когда через посредника должен идти весь рабочий стол. Строку подключения при любом способе собирают одинаково, разбор полей мы вынесли в материал про строку подключения.

Отдельно про то, что видит целевой сайт. Браузер отдаёт адрес выхода, заголовки запроса и набор свойств окна. Посредник меняет адрес, всё остальное остаётся браузерным. Про то, какие заголовки уходят и как они выглядят со стороны сайта, подробнее написано там, где мы описываем анонимные прокси без служебных заголовков.

Системные настройки: когда они уместны

В Windows поля лежат в параметрах сети, раздел настройки посредника. Там задаются адрес, порт и список исключений, который разделяется точкой с запятой. В macOS то же самое живёт в настройках сети внутри выбранного сетевого интерфейса, причём каждый протокол настраивается отдельной строкой. В Linux с графической оболочкой поля лежат в сетевых параметрах, при этом консольные программы читают переменные окружения независимо от них.

Плюс системного пути один и он весомый: настроил один раз, и через посредника пошло всё. Минус в том же самом. Обновления системы, телеметрия и фоновые службы поедут туда же, и на прогонах с высокой частотой запросов это добавляет посторонний трафик. Трафик у нас безлимитный, поэтому счётчиков тут никто не считает, при этом лишний шум усложняет разбор логов.

Список исключений заслуживает внимания. Внутренние имена, локальный адрес и стенд разработки вписываются туда сразу, иначе часть рабочих инструментов перестанет открываться. Типовой набор: localhost, 127.0.0.1 и внутренний домен компании с точкой впереди.

Ещё один момент касается порядка применения. Часть программ читает системные поля при старте и больше к ним не возвращается, поэтому после правки настроек их перезапускают. Браузер сюда попадает не всегда: свежие сборки подхватывают изменение на лету, старые продолжают ходить по прежнему пути до закрытия последнего окна. Проверка простая: закрыть браузер целиком, открыть заново, посмотреть адрес выхода. Для постоянной работы с одним адресом такой путь удобен и требует минимума движений, а строку под него берут из выдачи пакета, где доступен HTTP-посредник для повседневной работы.

Firefox: где именно лежат поля

Firefox держит собственные сетевые настройки, поэтому системные параметры он умеет игнорировать. Путь такой: меню настроек, раздел «Основные», прокрутка в самый низ до блока «Параметры сети», кнопка «Настроить». Открывается окно с переключателями.

Дальше по шагам. Ставим переключатель «Ручная настройка прокси». Заполняем поле «HTTP прокси» адресом из списка и соседнее поле «Порт». Ставим флажок «Также использовать этот прокси для HTTPS», тогда шифрованные адреса пойдут через того же посредника. Поле «Не использовать прокси для» оставляем под локальные имена.

Флажок передачи запросов к DNS стоит того, чтобы про него сказать отдельно. Без него браузер сам превращает имя сайта в адрес через провайдерский резолвер, и наружу уходит имя домена мимо туннеля. С флажком имя разрешает выход посредника. В Firefox этот флажок работает вместе с сокетным вариантом, и включается он одной галочкой в том же окне.

Для варианта с полями HTTP тот же эффект даёт параметр в служебных настройках. Открываем страницу about:config, подтверждаем предупреждение, ищем ключ и переводим его в положение истины.

network.proxy.socks_remote_dns   -> true
network.proxy.type               -> 1   (ручная настройка)
network.trr.mode                 -> 5   (встроенный резолвер отключён)

Утечку запросов к DNS мы разбираем отдельно, вместе с проверкой и способами закрыть её насовсем: смотрите материал про утечку запросов к DNS. Здесь достаточно включить флажок и один раз убедиться, что домены резолвятся на выходе.

Сборки на том же движке повторяют это окно почти дословно: расположение блока «Параметры сети» и подписи полей совпадают. Различается только оформление меню.

Смена адреса в Firefox идёт через то же окно. Открыли, переписали хост и порт, нажали подтверждение, обновили вкладку. Перезапуск браузера при этом не требуется, настройка применяется к следующему запросу. Если адресов много и они меняются каждые несколько минут, ручной путь начинает утомлять, и тогда переходят на расширение. Для двух или трёх постоянных адресов встроенных полей хватает с запасом, и мы держим на рабочих машинах именно такую схему: одна строка в полях, остальные лежат в файле выдачи на случай замены.

Браузеры на движке Chromium: профиль и ключ запуска

Chrome, Edge, Yandex Browser и прочие сборки на движке Chromium собственных сетевых полей не показывают: кнопка настроек открывает системную панель. Посредник им задаётся ключом запуска, и это удобнее, чем кажется на первый взгляд.

# Windows, ярлык с ключом
chrome.exe --proxy-server="http://185.24.87.14:8000" --user-data-dir="C:\profiles\p1"

# сокетный вариант с разрешением имён на выходе
chrome.exe --proxy-server="socks5://185.24.87.14:1080" --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 185.24.87.14"

# исключения
chrome.exe --proxy-server="http://185.24.87.14:8000" --proxy-bypass-list="localhost;127.0.0.1;*.internal.local"

# Linux, то же самое из терминала
google-chrome --proxy-server="http://185.24.87.14:8000" --user-data-dir=/home/user/profiles/p1

Ключ --user-data-dir тут важнее самого посредника. Он задаёт отдельный каталог профиля: свои куки, своё хранилище, свои расширения. Без него новый процесс присоединяется к уже запущенному окну и наследует его сеть, поэтому ключ посредника молча теряется. Мы всегда указываем каталог профиля рядом с ключом посредника, и вопрос «почему не применилось» снимается сам.

Учётные данные внутрь ключа --proxy-server браузеры на этом движке не принимают. Строка пишется без логина и пароля, а пара запрашивается всплывающим окном при первом запросе. Обойти окно помогает расширение либо доступ по привязанному адресу, механику которого мы разобрали в материале про привязку своего адреса.

Отдельные профили с разными адресами

Схема с каталогами профилей закрывает работу с несколькими независимыми сессиями. Каждому профилю свой каталог, своя строка посредника, свой ярлык. Профили запускаются одновременно и живут параллельно, куки между ними не пересекаются.

# три параллельных профиля, каждый со своим адресом
chrome --user-data-dir=/opt/p1 --proxy-server="http://185.24.87.14:8000"
chrome --user-data-dir=/opt/p2 --proxy-server="http://185.24.87.15:8000"
chrome --user-data-dir=/opt/p3 --proxy-server="socks5://185.24.87.16:1080"

Ярлыки под такие запуски удобнее готовить заранее. Один ярлык на профиль, в свойствах прописан каталог и строка посредника, подпись содержит номер профиля. Дальше работа сводится к двойному щелчку, и путать окна перестаёшь: у каждого профиля своя тема оформления и свой набор закладок. Список адресов при этом остаётся общим, мы берём для профилей соседние строки выдачи.

Схема выдерживает несколько профилей на машине. Дальше начинает мешать оперативная память: каждый процесс тянет свой набор вкладок и расширений. Для десятков параллельных сессий берут инструмент, который умеет управлять профилями списком. Про адреса под такую работу мы пишем на странице, где предлагается купить HTTP-прокси для браузеров.

Расширение: быстрая смена и её цена

Расширение ставится в браузер и берёт на себя маршрутизацию вкладок. Внутри держится список строк подключения, переключение идёт кликом из панели, учётные данные подставляются автоматически, поэтому всплывающее окно авторизации больше не появляется. Многие расширения умеют правила: этот домен через первый адрес, тот через второй, остальное напрямую.

Выигрыш заметен там, где адрес меняется по десять раз за смену. Открыл панель, выбрал строку из списка, обновил вкладку. Ни перезапуска, ни ярлыков, ни правки полей. Список строк импортируется из файла выдачи целиком, и формат IP:PORT:LOGIN:PASS большинство расширений разбирает само.

Слабое место у расширения одно, и оно техническое. Правила расширения работают внутри браузерного слоя, поэтому часть трафика проходит мимо: сюда попадают соединения WebRTC и обращения самого браузера к служебным адресам. Дополнительно расширение хранит учётные данные внутри своего профиля, и при переносе профиля они уезжают вместе с ним. Отсюда наша практика: расширение берём для ручной работы и быстрых переключений, а для прогонов, где важна полнота охвата, ставим посредника ключом запуска либо в системных полях.

Антидетект-браузер: посредник внутри профиля

Антидетект-браузеры построены вокруг профилей, и посредник там задаётся в карточке профиля вместе с остальными параметрами окна. Порядок обычный: создать профиль, открыть блок настроек сети, выбрать тип из списка, заполнить хост и порт, затем логин и пароль отдельными полями. Многие сборки принимают вставку строки IP:PORT:LOGIN:PASS целиком и раскладывают её по полям сами.

Дальше нажимается кнопка проверки. Она делает запрос через указанного посредника и показывает адрес выхода. Проверять стоит до первого входа в аккаунт: профиль, стартовавший без посредника, успевает сходить на сайт с адресом машины. Про настройку конкретных сборок мы пишем на странице про антидетект-браузеры и прокси, а отдельный разбор популярной сборки лежит там, где описан профиль в Dolphin с посредником.

Сокетный вариант в таких сборках обычно предпочтительнее: тип выбирается из выпадающего списка, имя домена разрешается на выходе, произвольные порты проходят без оговорок. В пакете доступны обе версии сокетного протокола, и мы рекомендуем старшую. Полный состав того, что открывается вместе с ней, описан там, где можно взять прокси SOCKS5 для профилей.

Как убедиться прямо в браузере, что запросы идут через посредника

Первая проверка занимает полминуты. Открываем любой сервис, который показывает адрес обратившегося, и сравниваем цифры с адресом из списка выдачи. Совпало, значит посредник применился.

Вторая проверка точнее и делается внутри инструментов разработчика. Открываем панель клавишей F12, вкладку «Сеть», обновляем страницу и щёлкаем по первому запросу. В свойствах соединения есть строка удалённого адреса: при работе через посредника там стоит адрес посредника, при прямом соединении там адрес целевого сервера. Это самый честный ответ, потому что он берётся из самого соединения.

Третья проверка касается WebRTC: этот механизм умеет получать адреса сетевых интерфейсов в обход настроек посредника. В Firefox он выключается ключом media.peerconnection.enabled в служебных настройках, в браузерах на движке Chromium ставится расширение управления политикой WebRTC, в антидетект-сборках есть готовый переключатель в карточке профиля.

Полезен и обратный тест: открыть адрес из списка исключений и убедиться, что он пошёл напрямую. Настройка, где через посредника уходит вообще всё, включая локальный стенд, обычно означает опечатку в поле исключений. Разделители там разные в разных браузерах: запятая в Firefox, точка с запятой в системных полях Windows, точка с запятой в ключе Chromium. Мы проверяем это первой же строкой после правки настроек.

Отдельно советуем сверять картину до и после. Запоминаем адрес машины без посредника, включаем настройку, обновляем страницу. Изменившиеся цифры отвечают на вопрос надёжнее любых логов. Команды и сервисы для полноценной проверки собраны в материале про проверку прокси.

Окно с запросом логина и пароля

Всплывающее окно с полями имени и пароля означает ровно одно: посредник просит авторизацию, потому что в строке её не было. Такое поведение штатно для браузеров на движке Chromium, которые не принимают учётные данные внутри ключа запуска. Вписываем логин и пароль из строки списка формата IP:PORT:LOGIN:PASS, ставим флажок запоминания, и окно перестаёт появляться в этом профиле.

Если окно возвращается после каждого обновления страницы, причин обычно три. Первая: пара введена с опечаткой, чаще всего с лишним пробелом при копировании из файла. Вторая: копировали строку целиком вместе с адресом и портом, и в поле логина уехали лишние поля. Третья: профиль запущен без своего каталога, поэтому сохранённая пара каждый раз теряется вместе с временным профилем.

# быстрая сверка той же пары вне браузера
curl -x http://user5521:[email protected]:8000 https://ifconfig.me

# если тут приходит 407, дело в паре, а не в настройках браузера
curl -o /dev/null -w "%{http_code}\n" -x http://185.24.87.14:8000 https://example.com

Когда пара верна и всё равно приходит отказ, смотрим на способ доступа. Доступ по привязанному адресу работает без логина, и тогда всплывающее окно закрывается пустым: посредник узнаёт клиента по адресу машины. Обратный случай: привязка оформлена на прежний адрес, машина переехала в другую сеть, права по адресу больше нет. Привязку можно поменять прямо в настройках кабинета без ограничений, в пакет входит одновременная привязка 2 адресов.

Полезно помнить, что запомненная пара живёт внутри профиля браузера. Переустановили браузер, завели новый каталог профиля, вычистили хранилище: окно вернётся, и это нормально. Вводим пару заново и работаем дальше. Тем, кто держит десяток профилей, проще один раз перейти на доступ по привязке: строка становится короче, окно не появляется вовсе.

Ещё один сценарий даёт то же окно при работающих настройках: расширение и системные поля включены одновременно и спорят между собой. Оставляем один способ, второй выключаем полностью. Мы держим это правило как обязательное при разборе любой странной сетевой картины в браузере.

Частые вопросы

Как подключиться к прокси после покупки?

Всё делается в кабинете: после регистрации и оплаты указывается свой адрес в настройках, пакет включается примерно за 5 минут. Дальше берётся строка из списка выдачи и вписывается в поля браузера либо в ключ запуска. Список обновляется в реальном времени, поэтому перед работой его стоит перечитать.

В каком виде выдаётся список адресов?

В кабинете два варианта получения: ссылка и файл. Форматов тоже два: IP:PORT и IP:PORT:LOGIN:PASS. Второй удобен для браузерных расширений и антидетект-профилей, потому что они разбирают его сами и раскладывают поля по местам.

Подойдут ли прокси под мою задачу в браузере?

Заранее предугадать поведение каждого целевого сайта нельзя, поэтому перед покупкой доступен бесплатный тест до 2 часов под ваш запрос. За это время удобно проверить именно тот браузер и тот профиль, которые пойдут в работу. Порядок запуска теста описан в кабинете, и оператору достаточно сообщить логин и тип прокси.

Можно ли отобрать адреса по стране для браузера?

Выборка по отдельной стране не делается: пул это микс со всего мира, около 12 000 активных адресов, ротация внутри пула автоматическая. География охватывает 200+ стран, поэтому разнообразие подсетей в браузерных профилях получается само собой.

Дальше по разделу: первое подключение по шагам проводит от оплаты до первого рабочего запроса, подключение в программах и на сервере показывает настройку вне браузера, смена привязанного адреса пригодится при переезде на другую машину. Если браузер начал отдавать отказы, разбор кода есть в материале про ошибку 403 через прокси.