Открываешь настройки Яндекс Браузера, ищешь раздел с прокси и не находишь. Его там нет. Браузер собран на Chromium и намеренно не держит собственный прокси-менеджер: параметры он забирает из операционной системы либо из ключей запуска. Понимание этой детали экономит часа два нервов, дальше всё встаёт на свои места.
Я настраивал прокси в Яндексе десятки раз: отдел маркетинга проверяет рекламу по регионам, аналитики собирают выдачу, разработчики тестируют корпоративный шлюз. И каждый раз кто-то ищет волшебную галочку внутри браузера. Её нет. Зато есть три рабочих пути.
Яндекс Браузер держит около 44% как основной браузер у российских пользователей. Это самая массовая аудитория в стране, поэтому вопрос «как прописать прокси» всплывает постоянно, в том числе у людей, которые раньше не думали про сетевую инфраструктуру.
Прокси в Яндекс Браузере берётся из системы, и это не баг
Логика Chromium простая: сетевые настройки это ответственность операционной системы. Браузер спрашивает у Windows, macOS или Linux, какой прокси использовать, и слушается ответа. Плюс есть механизм флагов командной строки для точечного переопределения.
Практическое следствие: настройка подхватится во всех вкладках сразу, но и остальные приложения, которые уважают системные параметры, пойдут через тот же узел. Иногда это ровно то, что нужно. Иногда неприятный сюрприз: трафик другого софта внезапно меняет маршрут.
Windows: пять кликов и один чекбокс
Пуск, Параметры, Сеть и Интернет, Прокси. Дальше блок «Настройка прокси вручную» и кнопка «Нажмите», которая открывает поля ввода. Включаем переключатель «Использовать прокси-сервер», вписываем адрес и порт из настроек вашего узла, сохраняем.
Там же галочка «Не использовать прокси-сервер для локальных адресов». Оставьте её включённой, если работаете с внутренними ресурсами, принтерами и тестовыми стендами в локальной сети. Иначе браузер будет тянуть локальные адреса через внешний узел и получит таймаут вместо страницы.
Важная деталь для тех, у кого прокси с авторизацией. Windows умеет спрашивать логин и пароль, но всплывающее окно появляется не всегда и не во всех сборках. Если браузер молча висит на загрузке, скорее всего дело в этом. В корпоративных сборках Яндекс Браузера авторизацию обычно разруливают на уровне политик, а не руками на каждой машине.
Ещё нюанс: изменения применяются без перезапуска, но открытые вкладки могут держать старые соединения. Открыли новую вкладку, проверили, и только потом делайте выводы. Многие на этом этапе решают, что «прокси не работает», хотя просто смотрят на старую сессию.
macOS и Linux: другой интерфейс, та же логика
На macOS путь такой: Системные настройки, Сеть, активное подключение (Wi-Fi или Ethernet), кнопка «Подробнее», вкладка «Прокси». Там три отдельных протокола: веб-прокси (HTTP), защищённый веб-прокси (HTTPS) и SOCKS. Включаете нужный, вводите адрес и порт.
Типичная ошибка новичка на Mac: включить только HTTP и удивляться, что часть сайтов открывается, а часть нет. HTTPS-трафик идёт отдельным полем. Если ваш узел умеет и то и другое, включайте оба, иначе получите рваное поведение по сайтам и будете искать проблему не там.
Linux в десктопе обычно берёт параметры из GNOME или KDE, а в консольных сценариях живут переменные окружения http_proxy, https_proxy и no_proxy. Для браузера, запущенного из терминала, эти переменные тоже работают. Удобно для тестовых прогонов, когда не хочется трогать систему целиком.
Флаги запуска: когда системных настроек мало
У корпоративной версии Яндекс Браузера есть документированный механизм через переменные окружения. Для всей системы используют YANDEX_BROWSER_FLAGS в файле /etc/yandex-browser/default, для одного пользователя хватает YANDEX_BROWSER_USER_FLAGS, которую выставляют через export в шелле.
Внутри переменной перечисляют параметры командной строки. Базовый набор: флаг proxy-server задаёт адрес узла, proxy-pac-url указывает на PAC-файл, proxy-auto-detect включает автоматическое определение настроек, proxy-bypass-list задаёт список исключений.
Синтаксис простой: к текущему значению дописывают новые флаги через пробел, примерно как YANDEX_BROWSER_FLAGS="$YANDEX_BROWSER_FLAGS --proxy-auto-detect". Подход не ломает существующую конфигурацию, а дополняет её. Откатить легко: убрали строку, вернули как было.
На Windows тот же трюк делают через ярлык: правой кнопкой, Свойства, поле «Объект», и после пути к исполняемому файлу дописывают нужные флаги. Способ хорош для отдельного ярлыка «браузер через рабочий шлюз», не трогая основную установку. Минус в том, что обновление браузера иногда пересоздаёт ярлык, и флаг приходится возвращать вручную.
PAC-файл решает проблему «один прокси на всё»
Когда узлов несколько или часть трафика должна идти напрямую, в дело вступает PAC-файл. Это обычный JavaScript, в котором описана функция, возвращающая тип подключения для конкретного URL. Браузер дёргает её на каждый запрос и решает, куда идти.
В документации Яндекса есть характерный пример: трафик идёт через прокси для всех адресов, кроме поддоменов yandex.ru, зоны example.com и localhost. При этом id.yandex.ru попадёт в исключения, а myyandex.ru уже нет, потому что правило про поддомены не сработало. Вот такие мелочи в правилах и съедают время при отладке.
Практика: держите PAC-файл на внутреннем сервере с обычным HTTPS и версионируйте его. Через месяц вы не вспомните, почему для одного домена сделано исключение. Комментарии внутри файла и короткий changelog спасают от часов раскопок.
Расширения это не то же самое, что системный прокси
В каталогах расширений полно «прокси-менеджеров». Работают они иначе: перехватывают запросы внутри браузера через свой API и не трогают системные настройки. Иногда это удобно, например когда нужно быстро переключиться между несколькими профилями вручную.
Дальше начинаются минусы. Расширение видит все ваши запросы и формально имеет доступ к содержимому страниц. Часть таких плагинов подменяет настройки и не убирает их после удаления. А ещё они конфликтуют с системным прокси, и итоговая маршрутизация становится непредсказуемой.
В корпоративной среде расширения часто запрещены политиками, и это разумно. Нужен управляемый доступ - настраивайте системный уровень или флаги, а не ставьте плагин из непонятного источника с правами на всё сразу.
SOCKS5 и HTTP: разница в архитектуре, а не в «скорости»
HTTP-прокси понимает сам протокол: он разбирает запросы, умеет кэшировать, добавлять заголовки. Для HTTPS он работает в режиме туннеля через CONNECT и содержимое не видит, только факт соединения с хостом. Отсюда и типичная путаница: «прокси же должен видеть, куда я хожу».
SOCKS5 работает на уровень ниже. Он не знает про HTTP, просто устанавливает TCP-соединение до нужного адреса и гоняет байты. Плюс умеет проксировать DNS-запросы и UDP, что важно для WebRTC и части медийного трафика. Задержка обычно ниже: нет разбора и переупаковки запросов.
Шифрования внутри SOCKS5 нет. Трафик защищён только на уровне прикладного протокола, то есть HTTPS. Если схема предполагает передачу чувствительных данных, поверх туннеля нужен либо TLS от самого сайта, либо собственный шифрованный канал до узла.
Для браузерных задач в большинстве случаев достаточно HTTP/HTTPS-прокси. SOCKS5 берут, когда важны UDP, нестандартные порты или минимальная задержка при массовых запросах.
Парсинг, регионы и несколько аккаунтов
Типичный бизнес-сценарий: маркетолог проверяет, как выглядит реклама в пяти городах. Без прокси он видит только свою локацию, а геотаргетинг остаётся загадкой. С прокси по нужному региону картинка становится честной, и решения принимаются по факту, а не по догадке.
Второй сценарий: сбор цен и ассортимента конкурентов. Здесь важна не столько подмена адреса, сколько предсказуемость. Если каждый запрос уходит с нового адреса, сайт быстро покажет капчу. Поэтому в каталогах есть параметр удержания сессии: один адрес на 10, 30 или 60 минут.
Третий сценарий: несколько аккаунтов в рекламных кабинетах или на маркетплейсах. Тут одного прокси мало, важна согласованность отпечатка браузера, часового пояса и языка. Прокси решает только часть задачи, зато самую заметную.
И отдельно про нагрузку. Если вы гоняете сотни параллельных запросов из браузера, узкое место обычно не прокси, а сам браузер с его рендерингом. Для объёмного сбора данных берут отдельный инструмент, а прокси настраивают уже под него.
Профили, ярлыки и раздельные конфигурации
У Chromium есть профили, у каждого своя папка с историей, куками и расширениями. Но системные настройки прокси общие для всех профилей сразу. Разделить конфигурации можно только флагами на разных ярлыках запуска.
Рабочая схема: ярлык «работа» с нужными флагами и ярлык «обычный» без них. Переключение занимает секунду, систему трогать не нужно, коллегам объяснить легко. На macOS то же самое делают через короткий скрипт или запуск из терминала с переменными окружения.
Чего точно не стоит делать: запускать два профиля с разными прокси одновременно и потом удивляться, почему куки и сессии ведут себя странно. Браузерные процессы делят часть сетевых настроек, путаница гарантирована.
Как проверить, что настройка действительно применилась
Самый быстрый способ: открыть страницу, которая показывает ваш IP и геолокацию. Сменились адрес и город - базовая настройка работает. Это только первый уровень, останавливаться на нём рано.
Второй уровень - WebRTC. Через этот механизм браузер может раскрыть локальный и реальный адрес, даже когда прокси включён. Проверяется тестовой страницей с кандидатами ICE. Светится домашний адрес - настройка неполная.
Третий уровень - DNS. Утечка DNS-запросов выдаёт провайдера, даже когда IP подменён. В системных настройках Windows отдельного поля для DNS через прокси нет, поэтому в корпоративных схемах DNS заворачивают на стороне узла.
Четвёртый уровень - сертификаты. Зайдите на сайт, который отдаёт HTTPS. Если вместо страницы приходит ошибка сертификата, кто-то в цепочке подменяет TLS. Для легитимного прокси это ненормально, с таким узлом лучше не работать.
Пять ошибок, на которых спотыкаются почти все
Первая: включили прокси и забыли про исключения для локальных адресов. Внутренние сервисы перестают открываться, человек делает вывод, что «сломался браузер».
Вторая: перепутали HTTP и HTTPS в настройках macOS. Часть сайтов работает, часть нет, и это сбивает с толку сильнее, чем полный отказ.
Третья: не проверили, что узел живой. Мёртвый прокси в браузере выглядит как «интернет пропал»: Chromium терпеливо ждёт ответа и показывает пустую страницу. Нормальная практика - перед настройкой проверить узел отдельным запросом.
Четвёртая: логин и пароль со спецсимволами. В некоторых полях ввода символы вроде собаки или двоеточия нужно экранировать, иначе строка авторизации собирается неправильно и узел отвечает отказом.
Пятая: настройка на уровне браузера, когда нужен уровень системы. Расширение работает в одном браузере, а фоновые приложения продолжают ходить напрямую. Если задача инфраструктурная, начинайте с операционной системы.
Публичный Wi-Fi, свой VPS и корпоративный узел
В кафе и аэропортах трафик без защиты неприятен. Схема со своим узлом на VPS решает это аккуратно. Поднимаете на сервере прокси-сервер, закрываете доступ по логину и паролю, ограничиваете список адресов, с которых разрешены подключения. Дальше прописываете его в системе, и весь браузерный трафик идёт через ваш сервер.
Для команды из пяти человек такой узел обходится дешевле, чем кажется, и даёт предсказуемость: один список разрешённых адресов, один набор логов, понятная ответственность. Настройка занимает вечер по инструкции и пару дней, если разбираться с нуля.
Корпоративный вариант отличается тем, что параметры раскатывают политиками, а не руками на каждом ноутбуке. В документации Яндекс Браузера для организаций как раз описаны переменные окружения и файлы конфигурации: удобно, когда нужно, чтобы у сотрудников всё работало одинаково и без тикетов в поддержку.
Где брать прокси и на что смотреть в каталоге
Когда доходит до выбора, начинается самое интересное. Бесплатные списки живут недолго, скорость непредсказуема, а часть узлов уже кем-то использована и помечена сайтами. Для разовой проверки сойдёт, для рабочей задачи нет.
Я смотрю на несколько параметров. География: есть ли нужный город или хотя бы страна. Тип: HTTP, HTTPS, SOCKS5 под конкретную задачу. Режим сессии: есть ли удержание на 10, 30, 60 минут. Лимиты по трафику и количеству одновременных соединений. И возможность проверить узел до оплаты, хотя бы на минимальном тарифе.
В каталоге 3seller.com/proxy как раз есть фильтры по этим параметрам: страна, тип протокола, срок аренды, количество адресов. Удобно, что можно собрать конфигурацию под задачу, а не брать пакет наугад. Для теста хватает минимального набора, для постоянной работы лучше брать с запасом по количеству адресов.
Отдельно про сроки. Если прокси нужен под сезонную кампанию, нет смысла брать годовой тариф. Каталог это позволяет: выбираете период, подключаете, дальше решаете по результату. Звучит банально, но именно на этом люди теряют деньги.
Что сделать прямо сейчас
Определите уровень, на котором нужен прокси. Если задача в одном браузере, начните с системных настроек ОС: это самый предсказуемый путь, и он работает во всех вкладках сразу. Нужна гибкость по доменам - добавьте PAC-файл. Настраиваете парк машин - идите в сторону флагов и политик.
Потом возьмите один рабочий узел, пропишите его, проверьте IP, WebRTC и DNS. Три минуты проверки экономят полдня переписки с поддержкой. И держите под рукой второй узел: когда основной упадёт, вы не будете искать замену в спешке.
Проверьте один узел сегодня. Через неделю настройка прокси в Яндексе будет занимать у вас пять минут, и вы уже не вспомните, зачем искали галочку в меню.