Приложение игнорирует прокси: как завернуть трафик

Вы прописали прокси в настройках Windows, перезапустили программу — а она всё равно ходит с домашнего IP. Или наоборот: браузер честно ушёл через прокси, а десктопный клиент рядом с ним продолжает светить реальным адресом. Это не баг прокси и не кривые креды. Это фундаментальное свойство того, как операционные системы обращаются с «системным прокси»: он не принуждает, а только предлагает.

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

Почему системный прокси не работает: короткая техническая правда

В Windows нет одного «системного прокси». Их как минимум два независимых набора настроек. Первый — WinINET: то, что вы правите в «Параметры → Сеть и Интернет → Прокси-сервер». Его читают Internet Explorer/Edge, часть приложений на .NET и всё, что использует стандартный пользовательский HTTP-стек. Второй — WinHTTP, которым пользуются системные службы и фоновые процессы. И вот ключевое: WinHTTP не использует настройки WinINET, пока вы их явно не импортируете. Делается это командой netsh winhttp import proxy source=ie, и — важная деталь из документации Microsoft — команда берёт снимок текущих настроек. Поменяли прокси в параметрах позже? Снимок не обновится сам, команду надо выполнить заново.

Но даже импорт не спасает от главной категории проблем. Огромное количество программ вообще не спрашивает систему: они используют собственный сетевой стек и открывают TCP-сокеты напрямую. Так устроены многие desktop-клиенты соцсетей и мессенджеров, игровые лаунчеры, торренты, часть Electron-приложений с зашитой конфигурацией, скомпилированные Go- и Rust-утилиты. Для них строка «прокси» в настройках ОС просто не существует как понятие.

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

Шаг 0: убедитесь, что проблема именно в этом

Запустите приложение и посмотрите, какой IP оно показывает (профиль аккаунта, служебная страница сервиса, любой встроенный индикатор).
Параллельно откройте браузер через тот же прокси и сверьте адрес. Разные IP = приложение игнорирует системную настройку.
Проверьте, есть ли у программы собственные настройки прокси — часто они спрятаны в «Сеть», «Соединение» или в конфиг-файле. Нативная поддержка всегда лучше внешнего перехвата: меньше слоёв, меньше поломок.
Отдельно проверьте DNS. Если приложение резолвит имена локально, а трафик идёт через прокси, ваш реальный провайдер всё равно видит, куда вы ходите.

Способ 1. Proxifier — коммерческий стандарт для Windows и macOS

Proxifier перехватывает соединения приложений и разворачивает их на указанный прокси по правилам: можно задать «этот exe — через прокси A, тот — через прокси B, остальное — напрямую», разделить по портам и адресам назначения, выстроить цепочку из нескольких прокси.

Актуальные версии на момент написания: 4.14 для Windows (релиз 23 апреля 2025) и 3.15 для macOS (18 сентября 2025). Лицензия — $39.95 за копию, разовая покупка, бессрочная, с бесплатными минорными обновлениями; есть 31-дневный полнофункциональный триал, оптовые скидки от двух копий и возврат в течение 30 дней.

Практика настройки:

Proxy Servers → Add: укажите адрес, порт, протокол SOCKS5 и креды. Нажмите Check — тест должен пройти до создания правил, иначе вы будете отлаживать две проблемы сразу.
Proxification Rules → Add: в Applications выберите конкретный исполняемый файл, в Action — ваш прокси.
Правило Default оставьте Direct, если не хотите завернуть вообще всю машину. Это самая частая ошибка новичков: Default → Proxy кладёт в туннель и апдейтер ОС, и антивирус, и лишний трафик, за который вы платите по гигабайтам.
Смотрите вкладку Connections в реальном времени: там видно, какое соединение ушло через прокси, а какое — напрямую.

Сильные стороны — зрелость, стабильные правила и понятная диагностика. Слабые — платность и то, что при агрессивных античит-системах драйверный перехват может быть замечен.

Способ 2. ProxiFyre — бесплатная альтернатива под Windows с поддержкой UDP

Если бюджет нулевой, а платформа Windows, есть открытый проект ProxiFyre (лицензия AGPL-3.0). Он построен на NDISAPI/Windows Packet Filter — то есть работает на уровне драйвера фильтрации пакетов и умеет то, чего часто не хватает: прозрачно заворачивать не только TCP, но и UDP по каждому приложению отдельно. Это принципиально для всего, что живёт на UDP и QUIC — голосовых каналов, игровых клиентов, части современных браузерных соединений.

Из полезного в свежих версиях: поддержка IPv6 появилась в v2.3.0, SOCKS5-over-TLS — в v2.4.0, есть правила-исключения для приложений и catch-all для всех остальных. Требования: установленный Windows Packet Filter, runtime-библиотеки Visual Studio и права администратора.

Настройка ведётся через конфигурационный файл со списком приложений и привязанных к ним SOCKS5-эндпоинтов. Порог входа выше, чем у Proxifier, зато вы не платите и получаете UDP.

Способ 3. proxychains-ng — быстрый вариант для Linux, с оговорками

Классика для Unix-систем: proxychains4 curl https://example.com. Механизм — LD_PRELOAD: библиотека подменяет вызовы сокетов в динамически слинкованной программе и уводит их в SOCKS.

Ограничения, которые надо знать до того, как вы построите на этом рабочий процесс:

Только TCP. UDP и ICMP не заворачиваются вообще — ping через proxychains не проверяет ничего осмысленного.
Только динамически слинкованные бинарники. Статически собранные утилиты (типичная ситуация для Go) LD_PRELOAD игнорируют молча — трафик пойдёт напрямую, и вы этого не заметите.
На macOS упирается в SIP. System Integrity Protection блокирует подгрузку библиотеки в системные бинарники: proxychains4 ssh user@host не сработает. Рабочий обходной путь — скопировать бинарник в свой каталог (cp /usr/bin/ssh ~/.local/bin/) и запускать копию. Отключать SIP ради удобства я не советую: вы ослабляете защиту всей системы ради одной утилиты.

Для точечных задач (curl, python-скрипт, консольная утилита) proxychains остаётся самым быстрым способом — ставится одной командой и не требует root.

Способ 4. TUN-режим: перехват на уровне виртуального интерфейса

Самый универсальный класс решений. Создаётся виртуальный сетевой интерфейс, маршруты системы заворачиваются в него, а пользовательский TCP/IP-стек разбирает пакеты и выдаёт их наружу через SOCKS5. Так работают tun2socks (использует стек gVisor, умеет TCP и UDP, есть под все платформы) и sing-box в режиме TUN.

Ключевое преимущество перед LD_PRELOAD: перехватывается вообще всё, включая статические бинарники и приложения с собственным стеком. У sing-box дополнительно есть маршрутизация по процессам — поля process_name, process_path и process_path_regex, что даёт настоящие per-app правила; по документации это поддерживается на Linux, Windows и macOS (на мобильных платформах правила задаются по package name или bundle ID).

Две ловушки, на которых спотыкаются практически все:

Маршрутная петля. Если весь трафик уходит в TUN, то и соединение к самому SOCKS5-серверу пытается уйти в TUN — туннель начинает заворачивать сам себя. Лечится явным маршрутом-исключением до IP прокси через физический интерфейс. Это известная и регулярно всплывающая проблема конфигураций sing-box.
Права. Создание TUN-интерфейса и правка таблицы маршрутизации требуют root/администратора. На корпоративной машине с политиками это может быть недоступно.

На Linux есть ещё два родственных подхода: redsocks — перехват через правила iptables с редиректом на локальный порт (только Linux, нужен root), и sshuttle, который поднимает VPN-подобную маршрутизацию поверх обычного SSH-доступа, обходя классическую проблему «TCP поверх TCP».

Что ломается чаще всего

DNS-утечка. Даже с корректно настроенным SOCKS5 приложение может резолвить домены локально. Проверяйте, что резолв уходит на сторону прокси, а не вашего провайдера.
Выбран SOCKS4 вместо SOCKS5. SOCKS4 не поддерживает UDP в принципе и не умеет передавать доменное имя в ряде реализаций. Для перехвата произвольного трафика берите только SOCKS5 — почему именно так, подробно разобрано в материале о принципах работы SOCKS5.
HTTP-прокси вместо SOCKS. HTTP-прокси умеет проксировать HTTP и через CONNECT — TLS-соединения. Произвольный TCP-трафик игрового клиента или мессенджера он не заворачивает.
Default-правило на весь трафик. Заворачивая всю машину, вы сжигаете трафик резидентного пула на обновлениях и телеметрии.
Отсутствие проверки после настройки. Всегда перепроверяйте фактический выходной IP из самого приложения, а не из браузера рядом.

Какой тип прокси брать под перехват

Технически перехват работает с любым SOCKS5-эндпоинтом, но выбор типа определяет, доживёт ли ваш сценарий до результата.

Резидентные — когда приложение работает с сервисом, который оценивает репутацию IP: соцсети, маркетплейсы, рекламные кабинеты, платёжные формы. Датацентр-адрес там опознаётся почти мгновенно. Подойдут резидентные прокси с поддержкой SOCKS5 и sticky-сессий — последнее критично, потому что смена IP посреди активной сессии выглядит для антифрода хуже, чем «чужой» IP изначально.
Датацентр — для технических задач без строгого антифрода: доступ к API, внутренние сервисы, тестовые стенды, всё, где важна скорость и стабильность канала, а не «жилой» вид адреса. Здесь датацентр-прокси дают лучший пинг и предсказуемость.
Мобильные — когда приложение мобильное по природе (эмулятор, клиент соцсети) и требуется максимальное доверие площадки.

Отдельно: перехват на уровне приложения — это не VPN, и подменять одно другим не стоит. Если вам нужен именно один защищённый канал для всей машины, а не разные IP для разных программ, сравнение подходов есть в разборе WireGuard против прокси.

Как выбрать способ за минуту

Приложение имеет свои настройки прокси → используйте их, ничего не перехватывайте.
Windows, нужен результат сегодня, бюджет есть → Proxifier.
Windows, нужен UDP и бесплатно → ProxiFyre.
Linux, разовая задача с консольной утилитой → proxychains-ng.
Нужно перехватить статический бинарник, игру или всё сразу с per-app правилами → TUN-режим (sing-box, tun2socks), не забыв про маршрут-исключение до прокси.

Главный вывод простой: «прокси не работает» в девяти случаях из десяти означает «прокси настроен не на том уровне». Системная настройка — это вежливая просьба к приложению, а перехват на уровне драйвера, LD_PRELOAD или TUN-интерфейса — принуждение. Выберите слой правильно, проверьте фактический выходной IP из самого приложения и не забудьте про DNS — и проблема закрывается один раз, а не всплывает после каждого обновления программы.