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

Моя собственная схема — домашний сервер за WireGuard-эндпоинтом — уже не раз демонстрировала странности: внезапные падения скорости, потеря UDP-пакетов (особенно в мобильных сетях). Всё вроде работает, но как-то не так: туннель подключается, но затем «виснет» или показывает подозрительно низкую пропускную способность. В таких случаях надёжным обходным путём становится туннелирование TCP-трафика через SOCKS5-прокси, например, поверх SSH.

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

Здесь на помощь приходит ProxiFyre — инструмент для перенаправления трафика от выбранных приложений через SOCKS5-прокси. Он поддерживает как TCP, так и UDP, не требует модификации бинарников приложений и работает без изменения глобальных настроек системы. В версии 2.0.1 были реализованы важные архитектурные улучшения, включая поддержку маршрутизации трафика всех активных сетевых приложений используя универсальную маску.

? Универсальная маршрутизация: SOCKS5 для всех

Ранее необходимо было вручную перечислять имена всех процессов, трафик которых должен был перенаправляться. Это давало гибкость, но и усложняло настройку. В версии 2.0.1 появилась поддержка «маски»: теперь, если указать пустую строку "" в поле appNames, ProxiFyre будет перехватывать весь исходящий трафик приложений, соответствующий указанным протоколам.

Пример конфигурации:

{
  "logLevel": "Error",
  "proxies": [
    {
      "appNames": [""],
      "socks5ProxyEndpoint": "proxy.example.org:1080",
      "username": "user1",
      "password": "pass1",
      "supportedProtocols": ["TCP", "UDP"]
    }
  ]
}

⚠️ Важно: DNS-запросы по UDP на порт 53 не перехватываются и пойдут напрямую.

Эта небольшая по сути настройка превращает ProxiFyre в «мягкий VPN» — без дополнительных сетевых интерфейсов, маршрутов и сложных конфигураций, но с полной маршрутизацией сетевых приложений через SOCKS5-прокси.


⚙️ Производительность под нагрузкой

При росте числа подключений некоторые пользователи начали замечать, что под высокой нагрузкой ProxiFyre теряет в производительности. Причина оказалась в архитектуре: до этой версии определение контекста (процесса-источника пакета) происходило синхронно, прямо в обработчике пакетов.

Это вызывало:

  • Блокировку критического потока обработки пакетов

  • Потенциальные дедлоки между ядром и user-mode

  • Резкое снижение пропускной способности при пиковых нагрузках

Эта проблема подробно зафиксирована в issue #62 и потребовала серьёзной переработки внутренних механизмов.


✅ Отложенное определение контекста

Начиная с версии v2.0.1, определение контекста вынесено в асинхронную очередь, что обеспечивает:

  • Немедленную обработку трафика без задержек на определение процесса

  • Перемещение ресурсоёмких операций в фоновые потоки

  • Повышение стабильности и отзывчивости при высоких нагрузках

Версия

Определение контекста

Поведение

≤ 2.0.0

Синхронное (inline)

Блокирует, плохо под нагрузкой

2.0.1

Асинхронное (очередь)

Не блокирует, устойчива


? Важно: поддержка Windows Packet Filter 3.6.1+

ProxiFyre работает поверх Windows Packet Filter — NDIS драйвера для перехвата сетевого трафика. Начиная с версии 2.0.1, обязательно использовать Windows Packet Filter версии 3.6.1 или новее.

Почему это критично:

  • В новых версиях улучшена синхронизация, снижена нагрузка на ядро и добавлена совместимость с обработкой трафика со всех доступных сеетвых интерфейсов с использованием queued_multi_interface_packet_filter.

Загрузить актуальный драйвер можно с github.com.

Использование старого драйвера может привести к нестабильной или частично неработающей функциональности.


? Внутренние изменения

В 2.0.1 также произведена масштабная чистка и рефакторинг:

  • Новый класс queued_multi_interface_packet_filter для обработки трафика на нескольких интерфейсах

  • Обновлены заголовки библиотеки netlib до актуальных версий

  • В .NET-компоненте введены уровни логирования (Error, Warning, Info, Debug, All)

  • Удалён устаревший и неиспользуемый код

Всё это упростило отладку и повысило читаемость кода как для разработчиков, так и для тех, кто собирает проект вручную.


? Пример: проксификация Chrome и RDP через SSH-туннель

Хотя wildcard-настройка подходит большинству, исходная логика «по приложениям» остаётся полезной. Например, вы можете настроить перенаправление трафика только от Chrome и mstsc через локальный SSH-tunnel (например, PuTTY или ssh -D):

{
  "logLevel": "Info",
  "proxies": [
    {
      "appNames": ["chrome", "mstsc"],
      "socks5ProxyEndpoint": "127.0.0.1:8080",
      "supportedProtocols": ["TCP"]
    }
  ]
}

Такой подход позволит изолировать критичные каналы, не меняя поведение остальной системы.


? Архитектура ProxiFyre

Состоит из трёх основных компонентов:

  • ndisapi.lib — статическая библиотека на основе Windows Packet Filter

  • socksify — C++/CLI-библиотека, реализующая маршрутизацию через SOCKS5

  • ProxiFyre — консольное .NET-приложение, управляющее маршрутизацией по конфигу

Проект не требует написания собственного драйвера и работает полностью в user-mode. Это делает его особенно удобным для разработчиков, исследователей и просто продвинутых пользователей.


? Где скачать

Актуальная версия доступна на GitHub:
? ProxiFyre v2.0.1 — страница релиза

В комплекте — исходники, бинарники и пример конфигурации.

Не забудьте обновить драйвер Windows Packet Filter до версии 3.6.1 или новее.


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

Комментарии (8)


  1. Mupok
    21.07.2025 08:19

    Спасибо вам за вашу программу. Другие прокси блокируются защитами от онлайн игр (например easy anti cheat), а ваша нет. Благодаря ей сидим с друзьями в дискорде


    1. SerpentFly Автор
      21.07.2025 08:19

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


  1. Johan_Palych
    21.07.2025 08:19

    Удаленный SSH-сервер в качестве SOCKS5-прокси с Chrome:
    ssh -ND 1080:IP(remote_server) user@IP(remote_server)
    ssh Windows Command line reference

    start chrome.exe --profile-directory=TestProfile ^
                     --user-data-dir=c:\TEMP\TestUser ^
                     --proxy-server="socks5://localhost:1080"

    Можно запускать Chrome без туннелируемого трафика параллельно с DefaultProfile(chrome://version)


    1. Mupok
      21.07.2025 08:19

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


      1. FSA
        21.07.2025 08:19

        Я раньше выборочно пускал не работающие сайты через плагин в Chrome. Но в текущей версии всё сломали. Если сломанный блокировщик рекламы ещё можно пережить, но неработающий интернет уже нет. Пришлось экстренно мигрировать на Firefox. Оказалось не всё так страшно. И все плагины работают. Интернет снова починен.


    1. Vindicar
      21.07.2025 08:19

      Очень не везде заработает - по ощущения, скорость SSH уже давно режут так, чтобы хватало только на консоль, но не на прокси.


  1. Metotron0
    21.07.2025 08:19

    Ещё есть proxychains4


    1. SerpentFly Автор
      21.07.2025 08:19

      Под Windows?