В последние месяцы я всё чаще сталкиваюсь с ситуациями, когда привычные 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, определение контекста вынесено в асинхронную очередь, что обеспечивает:

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

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

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

🔄 Важно: поддержка 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 — это шаг к большей универсальности, стабильности и гибкости в условиях неопределённости.