В последние месяцы я всё чаще сталкиваюсь с ситуациями, когда привычные 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 Filtersocksify
— C++/CLI-библиотека, реализующая маршрутизацию через SOCKS5ProxiFyre
— консольное .NET-приложение, управляющее маршрутизацией по конфигу
Проект не требует написания собственного драйвера и работает полностью в user-mode. Это делает его особенно удобным для разработчиков, исследователей и просто продвинутых пользователей.
? Где скачать
Актуальная версия доступна на GitHub:
? ProxiFyre v2.0.1 — страница релиза
В комплекте — исходники, бинарники и пример конфигурации.
Не забудьте обновить драйвер Windows Packet Filter до версии 3.6.1 или новее.
В эпоху, когда доступ к информации и цифровой инфраструктуре больше не гарантирован, такие простые и надёжные инструменты как ProxiFyre могут оказаться ключевыми. Версия 2.0.1 — это шаг к большей универсальности, стабильности и гибкости в условиях неопределённости.
Комментарии (8)
Johan_Palych
21.07.2025 08:19Удаленный SSH-сервер в качестве SOCKS5-прокси с Chrome:
ssh -ND 1080:IP(remote_server) user@IP(remote_server)
ssh Windows Command line referencestart chrome.exe --profile-directory=TestProfile ^ --user-data-dir=c:\TEMP\TestUser ^ --proxy-server="socks5://localhost:1080"
Можно запускать Chrome без туннелируемого трафика параллельно с DefaultProfile(chrome://version)
Mupok
21.07.2025 08:19Ну смысл не в том чтобы хром пустить по туннелю, а приложения, в которых отсутствует данная возможность
FSA
21.07.2025 08:19Я раньше выборочно пускал не работающие сайты через плагин в Chrome. Но в текущей версии всё сломали. Если сломанный блокировщик рекламы ещё можно пережить, но неработающий интернет уже нет. Пришлось экстренно мигрировать на Firefox. Оказалось не всё так страшно. И все плагины работают. Интернет снова починен.
Vindicar
21.07.2025 08:19Очень не везде заработает - по ощущения, скорость SSH уже давно режут так, чтобы хватало только на консоль, но не на прокси.
Mupok
Спасибо вам за вашу программу. Другие прокси блокируются защитами от онлайн игр (например easy anti cheat), а ваша нет. Благодаря ей сидим с друзьями в дискорде
SerpentFly Автор
Спасибо большое за добрые слова! Рад, что программа помогает. В новой версии немного поработал над сетевой частью — если будет возможность, посмотрите, пожалуйста, как сейчас обстоят дела с пингом. Я сам немного потестировал, но очень хотелось бы услышать новости с полей :)