In recent months, I’ve continued to encounter cases where traditional VPN connections are becoming less reliable or outright blocked. For users who rely on remote access to home infrastructure or private networks, especially from regions with increasing traffic inspection or censorship, this creates a tangible threat to continuity. My own setup — a home server behind a WireGuard endpoint — has, on more than one occasion, suffered from unexplained throughput drops and UDP packet loss, particularly on mobile connections.
The pattern is familiar: your tunnel connects, then stalls, or appears fine but performs suspiciously poorly. In such moments, switching to TCP-based tunneling via SOCKS5 proxies (e.g., over SSH) proves to be the most robust workaround. But even SOCKS5 isn’t a silver bullet unless you have a mechanism for redirecting arbitrary application traffic through it. Many applications lack built-in proxy support, and system-wide proxying is cumbersome — particularly on Windows.
This is where ProxiFyre comes in — a lightweight traffic redirection tool that enables per-application SOCKS5 routing for TCP and UDP connections, all without modifying application binaries or OS-wide proxy settings. With version 2.0.1, we’ve made some important architectural improvements and introduced system-wide redirection via wildcard configuration.
🆕 Wildcard Redirection: SOCKS5 for Everything
Until now, users had to specify appNames for each process whose traffic should be proxied. This offered precision — but at the cost of complexity. Version 2.0.1 introduces a wildcard mechanism: by specifying an empty string ("") as the appNames entry, ProxiFyre will proxy all outgoing application traffic that matches the configured protocols.
This allows for instant system-wide tunneling — for example, to reroute all TCP/UDP traffic through a SOCKS5 endpoint:
{
"logLevel": "Error",
"proxies": [
{
"appNames": [""],
"socks5ProxyEndpoint": "proxy.example.org:1080",
"username": "user1",
"password": "pass1",
"supportedProtocols": ["TCP", "UDP"]
}
]
}
⚠️ Note: DNS queries over UDP port 53 are not captured or proxied. Applications performing their own DNS resolution may leak DNS traffic outside the tunnel unless manually redirected or isolated.
This single change transforms ProxiFyre from a fine-tuned tool for advanced users into a drop-in “soft VPN” solution — provided your SOCKS5 backend supports high throughput and optional authentication.
⚙️ Addressing Performance Under Load
Over time, users reported issues when handling high volumes of concurrent TCP/UDP connections — especially on systems serving multiple simultaneous applications. After digging into the code and performing stress tests, we identified a bottleneck tied to the way ProxiFyre resolved process context for each packet.
Until now, context resolution — which involves determining the originating process of a given network packet — was performed synchronously, directly inside the packet classification logic. On systems under load, this design caused:
- Blocking of the fast-path packet processing thread
- Occasional deadlocks in kernel-to-user-mode callbacks
- Throughput degradation as packet queues backed up
This problem was tracked and documented under issue #62. The solution required significant internal refactoring.
✅ Deferred Process Context Resolution
In v2.0.1, the context lookup logic is now asynchronous and deferred. This means:
- The core packet handler no longer waits for the process name to be resolved
- Packets are enqueued and processed in background threads
- The classification engine stays responsive even during peak loads
Here’s a simplified flow comparison:
| Version | Context Lookup | Performance Impact |
|---|---|---|
| ≤ 2.0.0 | Synchronous (inline) | Blocking, poor under load |
| 2.0.1 | Deferred (async queue) | Non-blocking, resilient |
This architectural improvement may seem subtle, but it provides a major boost in responsiveness and robustness on systems with many active connections.
🔄 Compatibility Note: Windows Packet Filter 3.6.1+
ProxiFyre relies on the underlying Windows Packet Filter driver, which provides the core functionality for capturing and modifying network packets in user space. Starting with v2.0.1, it is essential to use Windows Packet Filter version 3.6.1 or later.
Why this matters:
- The latest driver improves synchronization behavior, reduces kernel overhead, and ensures compatibility with multi-interface setups used by
queued_multi_interface_packet_filter.
You can download the latest version of the driver from github.com.
Failure to use the correct driver version may result in incomplete or unstable behavior, especially under high network load.
🧱 Internals: Better Structure, Better Debugging
As part of the 2.0.1 effort, the project structure also received a long-overdue cleanup:
- Replaced inline logic with the new
queued_multi_interface_packet_filter, enabling consistent packet filtering across multiple interfaces without duplicating logic. - Updated netlib headers from the upstream repository to match current Windows kernel mode standards and avoid known pitfalls.
- On the C# side, logging is now fully structured. Log levels include:
Error,Warning,Info,Debug, andAll
- Removed obsolete legacy fragments that had accumulated over earlier experimental builds.
These changes reduce noise, improve build consistency, and make debugging misconfigurations much more straightforward.
🧪 Real-World Scenarios
For most users, the wildcard configuration will be sufficient — especially if the goal is to “VPN-ify” the system without deploying a full tunnel driver stack. However, the original per-app use cases remain relevant. For example, if you want to proxy only certain tools (e.g., browser + RDP client) over an SSH dynamic tunnel:
{
"logLevel": "Info",
"proxies": [
{
"appNames": ["chrome", "mstsc"],
"socks5ProxyEndpoint": "127.0.0.1:8080",
"supportedProtocols": ["TCP"]
}
]
}
This configuration pairs nicely with PuTTY or ssh -D tunnels and ensures only selected apps use the proxy while the rest operate normally.
🔧 Under the Hood
To recap, ProxiFyre is composed of:
ndisapi.lib– A static library built on Windows Packet Filter, which allows interception and redirection of network traffic at the transport layer.socksify– A C++/CLI .NET class library that performs protocol translation and flow handling for SOCKS5.ProxiFyre– A lightweight .NET console wrapper for parsing configs and coordinating per-process routing.
The architecture avoids kernel-mode development while achieving near-native performance for most workloads. It’s particularly suited for researchers, expats, and power users who need flexible tunneling without complex firewall/NAT traversal setups.
📦 Getting the Release
The latest release is available on GitHub:
👉 ProxiFyre v2.0.1 – Release Page
Source code, binaries, and example configs are all included. Don’t forget to update the Windows Packet Filter driver to version 3.6.1 or higher.
In an era where access to information and infrastructure can no longer be taken for granted, simple and reliable tools like ProxiFyre serve a vital role. v2.0.1 is a step toward broader usability and improved performance — and a foundation for even more flexible tunneling in the future.