Главная ловушка прокси-расширений для браузера — охват: они берут на себя только трафик браузера и могут уйти в прямое соединение, если ни одно правило не совпало. В статье расширения разделены по назначению, перечислены критерии оценки — протокол, аутентификация, разрешения, состояние поддержки, — а также даны шаги самопроверки исходящего IP и утечек WebRTC.
У прокси-расширений для браузера есть граница, о которой часто забывают: они перехватывают только запросы, которые отправляет сам браузер. Обновления системы, настольные клиенты и другие приложения продолжают идти прежним путём. Сначала решите, что именно должно идти через прокси, и только потом выбирайте инструмент — это избавит от множества последующих разбирательств.
Сначала разделите их по трём сценариям
Самая частая задача — переключение по отдельным сайтам: несколько доменов идут через прокси, остальное подключается напрямую. Такой сценарий управляется списком правил, а ценность расширения в быстром переключении и разделении по доменам.
Второй тип — глобальный прокси, когда весь трафик браузера выходит через единственную точку выхода. Настройка самая простая, но и цена очевидна: если выход откажет, браузер фактически останется без сети, что делает повседневную работу нестабильной.
Третий тип привязан к окружению: каждый профиль браузера закреплён за одним выходом, и профили не влияют друг на друга. Так поступают при работе с несколькими аккаунтами или несколькими проектами параллельно; расширение здесь скорее дополнение, потому что сам выход обычно настраивается на более низком уровне.
На что смотреть при оценке расширения
Поддержка протоколов стоит на первом месте. Прокси HTTP и HTTPS работают только с TCP, тогда как SOCKS5 универсальнее, но поддержка UDP зависит от реализации, и многие расширения либо пропускают UDP как есть, либо отбрасывают его полностью. Это важно дальше, поскольку напрямую связано с утечками WebRTC.
Внимательно изучите способ аутентификации. Вход по логину и паролю удобен, но учётные данные, сохранённые в расширении, лежат локально в открытом виде или со слабым шифрованием, поэтому любой, кто пользуется этим компьютером, может их прочитать; аутентификация по списку разрешённых IP ничего не хранит в расширении, но зато список приходится обновлять при каждой смене сети.
Охват — место, где проблемы возникают чаще всего. В режиме правил домены, не подошедшие ни под одно правило, по умолчанию идут напрямую, а вы можете не знать, какие домены страница запрашивает на самом деле. После установки соединения с HTTPS-сайтом расширение видит только домен, но не конкретный путь, поэтому идея разделения по путям практически не работает.
Посмотрите и на объём разрешений. Если прокси-расширение дополнительно запрашивает доступ к данным всех сайтов, информации о вкладках или буферу обмена, спросите себя, связаны ли эти разрешения с заявленной функцией. Обновления версии манифеста браузерных расширений тоже сужают доступные интерфейсы, из-за чего часть старых расширений была вынуждена менять архитектуру.
Что касается активности поддержки, смотрите не на количество записей в списке изменений, а на то, отслеживает ли кто-то изменения на стороне источника. Среди прокси-расширений магазинная версия Proxy SwitchyOmega была снята с публикации, и дальнейшую адаптацию взял на себя форк, поддерживаемый сообществом (например, линия ZeroOmega); у расширений вроде FoxyProxy есть версии для нескольких браузеров. Это лишь нейтральные примеры; что подойдёт лучше, по-прежнему зависит от пунктов выше.
Трафик, который оно не покрывает
После установки расширения сам браузер идёт через прокси, но другие программы на том же компьютере, фоновые службы обновления и часть трафика внутри браузера, не следующая по пути запросов расширения, могут по-прежнему выходить через локальный узел. Проверять согласованность сети нельзя, глядя только на панель расширения. Для полной изоляции нужно решать задачу на уровне системного прокси или выше.
Самопроверка: сначала выход, потом утечки
Первый шаг — проверить исходящий IP. Откройте несколько страниц, которые показывают IP посетителя и его местоположение, проверьте один раз в обычном окне и один раз во вкладке, подпадающей под ваши правила, и сравните результаты. Если правило задаёт прокси, а отображается локальный адрес, значит правило не сработало или домен не совпал. Проверка нескольких сайтов выявляет случаи, когда через прокси идёт лишь часть запросов.
Второй шаг — проверить WebRTC. Специальные страницы показывают локальные и публичные адреса-кандидаты, которые получает браузер; если среди публичных оказывается ваш реальный IP вместо прокси-выхода, значит UDP идёт не через прокси и скрипты страницы по-прежнему могут определить ваше фактическое положение в сети.
Третий шаг — проверить DNS. Если расположение DNS-резолвера сильно отличается от расположения выхода, некоторые сайты сочтут окружение подозрительным.
Последний шаг — повторить проверку в окне инкогнито. Многие расширения по умолчанию не работают в режиме инкогнито, и их нужно разрешить вручную в настройках; если пропустить этот шаг, выводы окажутся полностью неверными.
После проверок решите, как использовать
Результаты самопроверки надёжнее описания расширения. Когда фактический выход, расположение DNS-резолвера и раскрытие WebRTC согласованы, решайте: продолжать пользоваться расширением или опустить выход на более низкий уровень. В сценариях с несколькими параллельными окружениями каждому лучше выделить отдельный фиксированный выход, а не использовать один выход на нескольких машинах.
