Настройка прокси в Proxifier: профиль, правила и проверка соединений

Раздел 3.1 · Рабочие программы

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

1. Что понадобится

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

Понадобится строка подключения. Я забираю её в кабинете сервиса в одном из двух форматов: IP:PORT, когда адрес рабочей машины уже привязан, и IP:PORT:LOGIN:PASS, когда авторизация идёт по паре логин и пароль. Список выдаётся ссылкой или файлом, обновляется в реальном времени, и я обычно скачиваю файл, чтобы копировать значения без ручного набора. Для Proxifier удобнее всего работает список адресов SOCKS5 из кабинета: пятая версия протокола умеет и TCP, и передачу доменных имён на сторону сервера, а это пригодится в разделе про DNS.

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

2. Добавление прокси-сервера в профиль поле за полем

Открываю Profile → Proxy Servers → Add. Форма короткая, полей шесть, и каждое стоит заполнить осознанно.

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

Протокол выбирают по задаче. SOCKS Version 5 забирает любой TCP-поток, включая почтовые клиенты, FTP и игровые протоколы. HTTPS в терминологии Proxifier означает HTTP-посредник с поддержкой метода CONNECT, и он подойдёт, когда через программу гонится только веб. Если вам ближе второй вариант, берите адреса под протокол HTTP и ставьте в поле Protocol значение HTTPS: путаницы тут больше всего, потому что название пункта в интерфейсе описывает тип туннеля, а схема самого адреса остаётся прежней.

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

3. Чем прокси-сервер отличается от цепочки

Прокси-сервер это одна запись в списке Proxy Servers. Цепочка это последовательность таких записей, где трафик проходит через несколько посредников подряд. Собирается она в том же окне: выделяю два или больше серверов, жму Create в нижней части, получаю запись Chain и перетаскиванием задаю порядок узлов сверху вниз.

Разница ощущается на трёх вещах. Задержка в цепочке складывается: два узла по 200 миллисекунд дают около 400 на установку соединения, и это уже заметно на страницах с сотней запросов. Устойчивость падает, потому что отказ любого узла роняет весь путь. Зато цепочка позволяет собрать связку из посредников разного типа, например HTTPS-вход и SOCKS5-выход, и это иногда требуется для доступа к внутреннему контуру, куда пускают только с конкретного узла.

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

Одна тонкость про таймауты. При цепочке Proxifier ждёт ответа от каждого звена по отдельности, и общий таймаут соединения складывается так же, как задержка. В Profile → Advanced → Connection Timeout я поднимаю значение до 60 секунд, когда работаю через два узла. На одиночном сервере хватает стандартных 30.

4. Правила и порядок их применения сверху вниз

Список правил открывается через Profile → Proxification Rules. Каждое правило состоит из четырёх частей: имя, набор приложений, набор целей, действие. Соединение сверяется с правилами по порядку, и как только совпало первое, дальше список не читается. Нижняя строка Default неудаляемая, она ловит всё, что не подошло ни к одному правилу выше.

Три действия доступны всегда. Direct отправляет соединение мимо посредника, напрямую через сетевой адаптер. Proxy уводит его на выбранный сервер или цепочку. Block рвёт соединение сразу, и приложение получает отказ, как при отсутствии сети.

Синтаксис полей стоит запомнить, он экономит время. Разделитель это точка с запятой. Звёздочка заменяет любую последовательность символов, знак вопроса заменяет один символ. Диапазон портов пишется через дефис. Подсети принимаются в записи CIDR. Пустое поле означает «любое значение». Вот как выглядит рабочий набор из моего профиля:

1  Localhost      any app   localhost; 127.0.0.1; %ComputerName%   Direct
2  LAN            any app   10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16   Direct
3  Telemetry      any app   *.telemetry.internal   Block
4  Worker         parser.exe   any host   Proxy SOCKS5 198.51.100.7:1080
5  Default        any app   any host   Direct

Порядок здесь несёт весь смысл. Перенесите строку Worker выше строки LAN, и обращения парсера к внутреннему серверу тоже уйдут на посредник, откуда они, разумеется, не вернутся. Перетаскивание мышью работает прямо в списке, стрелки справа делают то же самое. Я после каждой перестановки закрываю окно кнопкой OK и заново смотрю вкладку соединений: правила применяются к новым соединениям, уже открытые остаются на прежнем маршруте.

5. Направление одного приложения при прямом выходе остальных

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

Сначала правлю строку Default. Двойной щелчок по ней, в поле Action ставлю Direct. Теперь любое соединение, которое не описано отдельным правилом, идёт напрямую. Обновления Windows, почтовый клиент, мессенджер, всё остаётся на прямом маршруте и не тратит потоки пакета.

Дальше добавляю правило для нужной программы. Кнопка Add, имя пишу человеческим языком, например Scraper. В поле Applications жму Browse и указываю исполняемый файл. Proxifier подставит полный путь, но я почти всегда сокращаю его до имени файла: путь ломается при переустановке программы в другую папку, имя переживает переезд. Для браузеров вписываю обе формы разрядности:

Applications:  chrome.exe; chrome.exe *64
Target Hosts:  (пусто, любой хост)
Target Ports:  (пусто, любой порт)
Action:        Proxy SOCKS5 198.51.100.7:1080

Правило ставлю выше строки Default и ниже правил про локальную сеть. После сохранения запускаю программу заново. Уже запущенный процесс Proxifier подхватит, но соединения, открытые до применения правила, доживут свой век на старом маршруте, и картина в журнале получится смешанная.

Отдельная деталь для браузеров на движке Chromium. Они запускают несколько процессов с одним именем, и сетевой стек живёт в отдельном процессе. Именно поэтому в поле приложений указывается имя без пути и с вариантом *64: иначе часть соединений уйдёт мимо правила. Для тяжёлых прогонов с десятками вкладок мне пригождаются серверные адреса на собственном оборудовании, они держат ровный отклик при 1000 одновременных потоков на обычном пакете.

6. Исключение локальных адресов и своей сети

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

Содержимое поля Target Hosts для этого правила я держу таким:

localhost; 127.0.0.1; ::1; %ComputerName%; *.local; *.lan;
10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; 169.254.0.0/16

Переменная %ComputerName% раскрывается в сетевое имя машины, её понимает сам Proxifier. Диапазон 169.254.0.0/16 это адреса, которые система назначает себе при отсутствии DHCP, через посредник им делать нечего. Если у вас есть корпоративный контур с публичными адресами, допишите его подсеть в ту же строку: маршрут до внутренних сервисов должен оставаться прямым.

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

curl -s -o nul -w "%{http_code}\n" http://192.168.1.1/

Ответ с кодом статуса и строка Direct во вкладке соединений говорят, что правило отработало. Пустой ответ и строка с именем сервера в колонке Proxy означают, что правило стоит ниже, чем нужно, или подсеть в него не попала.

7. Разрешение имён и куда уходит запрос к DNS

Этот пункт вызывает больше всего вопросов, потому что настройка спрятана в отдельном окне. Открывается оно через Profile → Name Resolution. Внутри три переключателя и одна галочка, и их сочетание определяет, кто узнаёт, какие домены вы открываете.

Механика следующая. При выключенном разрешении через посредник Proxifier сначала превращает домен в IP-адрес силами системного распознавателя, и только потом просит посредник соединиться с готовым числовым адресом. Провайдер и владелец DNS-сервера видят список ваших доменов. При включённом режиме программа передаёт посреднику само имя в теле запроса SOCKS5, и разрешение выполняет уже удалённая сторона. Пятая версия протокола такое умеет по спецификации, четвёртая нет, поэтому смена Protocol на SOCKS Version 4 молча вернёт вас к системному DNS. Ради этого режима я и держу в профиле прокси с поддержкой SOCKS версии 5: передача имени на удалённую сторону снимает половину вопросов о том, кто видит ваши домены.

Я держу включённым Resolve hostnames through proxy и рядом первое правило про локальную сеть с действием Direct. Тут возникает нюанс: локальные имена вроде nas.lan при таком режиме тоже попробуют разрешиться на стороне посредника. Спасает шаблон *.lan в поле хостов первого правила, потому что сопоставление с правилами идёт по строке имени до всякого разрешения. Проверяется всё одной командой в консоли:

nslookup example.org

Если вывод показывает адрес вашего домашнего DNS-сервера в строке Server, разрешение идёт локально. Сама утилита nslookup работает по UDP и через Proxifier не проходит, поэтому она честно показывает системную картину. Для сравнения смотрю журнал программы: строка вида example.org:443 open through proxy 198.51.100.7:1080 SOCKS5 с доменом вместо цифр подтверждает, что имя ушло на удалённую сторону.

8. Проверка после настройки

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

Журнал соединений это главная вкладка окна программы. Колонок там пять: время, приложение, целевой узел, правило, статус. Колонка Rule показывает имя сработавшего правила, и это самое ценное поле во всей программе. Открываю нужную программу, делаю в ней запрос и смотрю появившиеся строки. Совпало ожидаемое имя правила, в колонке с посредником стоит адрес сервера, статус зелёный: маршрут собран верно. Внизу окна вкладка Traffic показывает объём в обе стороны, по ней видно, что данные реально идут: счётчик прибавляет на каждом запросе.

Вторая проверка идёт через само приложение. Для консольных утилит хватает запроса к сервису, который отдаёт видимый адрес:

curl -s https://api.ipify.org

Команда curl попадёт под правило по имени curl.exe, и в ответе вы увидите адрес посредника из списка. Для браузера открываю ту же страницу вручную. Совпадение адреса из ответа с адресом в колонке журнала закрывает вопрос. Расхождение означает, что часть трафика идёт мимо, и почти всегда виновато правило с пустым полем приложений, стоящее выше нужного.

Третья проверка самая недооценённая. Я временно добавляю первой строкой правило с действием Block и целью в виде домена, который точно открывается. Обновляю страницу. Браузер сообщает об ошибке сети, в журнале появляется строка со статусом Blocked и именем этого правила. Значит перехват работает и порядок правил читается так, как задумано. После проверки правило удаляю. Без этого шага легко принять за успех ситуацию, когда драйвер перехвата не встал и весь трафик спокойно идёт мимо программы.

Отдельно смотрю вкладку Statistics. Она показывает счётчик активных соединений, и при работе парсера в 200 потоков там будет соответствующее число. Резкое падение счётчика до единиц при работающей программе говорит об исчерпании потоков пакета. На тяжёлых прогонах мне спокойнее работается, когда за спиной стоит пакет с безлимитным трафиком и запас потоков до 3000 на корпоративном тарифе: счётчик тогда упирается в возможности самой программы.

9. Разбор ошибок

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

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

Настройки соседних программ разобраны на отдельных страницах справочника: сбор кластеров в KeyAssort с прогоном через посредник, запросы к API через Postman с собственными полями прокси, загрузка данных в Excel и Power Query для табличных выгрузок. Когда нужно завернуть весь исходящий трафик машины разом, пригодятся системные настройки прокси в Windows 11: два подхода отлично уживаются на одной станции, и Proxifier в такой паре берёт на себя точечную маршрутизацию по приложениям.