ProxiFyre: Windows Per-App SOCKS5 Routing with UDP Support

What ProxiFyre Routes on Windows

ProxiFyre solves a specific Windows networking problem: an application may have no SOCKS5 setting, or its traffic may include UDP and QUIC connections that a conventional application-level proxy configuration does not cover. The project routes selected applications through one or more SOCKS5 proxies, or can route applications that remain unmatched by using a catch-all rule. It is aimed at Windows users who need transparent per-application routing rather than a proxy client that requires every program to be configured manually.

The supported destination types are broader than a TCP-only HTTP proxy arrangement. The README documents IPv4 and IPv6 destinations over TCP, UDP, or both. Rules can select applications, protocols, address families, and transport. Local network traffic can remain direct through LAN bypass, which helps prevent routine local destinations from being sent through a remote SOCKS5 endpoint.

This is a Windows system-level network component rather than a general cross-platform proxy library. Based on the repository layout, the implementation includes `ProxiFyre/`, `socksify/`, `netlib/`, `ndisapi/`, configuration projects, an installer, tests, and the `ProxiFyreUI/` GUI. The engine uses NDISAPI and builds on the Windows Packet Filter `socksify` demo, as the README states. The GUI manages the engine, service registration, configuration, and logs, but it does not process packets itself.

ProxiFyre also supports unattended operation as `ProxiFyreService`. The installer registers that service but leaves it stopped until a valid configuration is available. This split between GUI and service makes the project suitable for a managed Windows workstation, although it also introduces service installation, permissions, and restart considerations that an ordinary per-application proxy setting would not have.

How the Rule Engine Selects Traffic

Configuration is stored in `app-config.json` beside `ProxiFyre.exe`. The file defines logging, LAN bypass, proxy entries, application names, endpoint settings, transport, protocols, address families, and exclusions. Rules are evaluated from top to bottom, and the first match wins. A catch-all rule is represented by an empty application name and must therefore be placed last when later matching behavior is not intended to intercept everything.

Exclusions have higher priority than routing rules. Unsupported destination address families are blocked rather than allowed to connect directly, so a configuration that omits IPv6 support does not silently turn unsupported IPv6 traffic into an unproxied route. That policy is significant for users who expect a catch-all rule to provide complete coverage: the configuration must explicitly account for the protocol and address-family combinations it intends to proxy.

The GUI offers `Validate` and `Apply & Restart` as separate operational steps. `Save` writes the configuration without restarting a running service. `Apply & Restart` saves the configuration and waits for the Windows service result. Engine log level changes also require a service restart, while the Logs-tab filter changes only the displayed view. This distinction prevents an administrator from assuming that a saved setting is already active.

SOCKS5 transport can remain TCP or change to TLS. In TLS mode, the README states that the SOCKS5 TCP connection and the UDP `ASSOCIATE` control channel are protected. Public certificates use normal Windows certificate and hostname validation. For a self-signed endpoint, the documented preference is an exact `tlsPinnedSha256` leaf-certificate pin rather than turning certificate validation off.

Installing ProxiFyre and Validating the First Rule

The README directs users to the architecture-matched package on GitHub Releases. Online setup packages are named `ProxiFyre-<version>-win-x86-setup.exe`, `...-x64-setup.exe`, and `...-arm64-setup.exe`. These packages acquire verified Visual C++ and Windows Packet Filter prerequisites when needed. MSI packages are intended for managed deployment after prerequisites are already provisioned. ZIP packages contain the application payload and require the protected manual staging procedure documented in `docs/zip-staging.md`.

Before running setup, x86 and x64 systems need .NET Framework 4.7.2 or later, while ARM64 systems need .NET Framework 4.8.1 or later. Setup does not install .NET Framework. The README also says that the first-party packages are deliberately unsigned, so Windows may show `Unknown publisher`. The selected artifact should be checked against its `.sha256` sidecar before elevation.

The first real use is configuration through the GUI:

1. Open `ProxiFyre` from the Start menu. 2. Add a routing rule with the SOCKS5 endpoint and optional credentials. 3. Select protocols, address families, and transport. 4. Choose `Validate`, then `Apply & Restart`. 5. Confirm that the header reports `Running`.

A minimal configuration has this shape:

{
  "logLevel": "Info",
  "bypassLan": true,
  "proxies": [
    {
      "appNames": ["chrome", "firefox"],
      "socks5ProxyEndpoint": "proxy.example.com:1080",
      "socks5Transport": "TCP",
      "supportedProtocols": ["TCP", "UDP"],
      "supportedAddressFamilies": ["IPv4", "IPv6"]
    }
  ],
  "excludes": []
}

This file uses application names, endpoint syntax, and keys exactly as documented. The rule must be validated before relying on it because an invalid configuration can prevent the installer from starting the service.

Administrator Boundaries and Process Attribution

The normal installation path is designed around an elevated management model. The GUI can install or remove only the service registration, start and stop the service, edit configuration, follow logs, and inspect resolved paths and versions. This is a deliberate separation between configuration management and the packet-processing engine, but it means the project is not equivalent to a simple portable SOCKS5 client.

The README documents an optional console mode for portable launchers:

ProxiFyre.exe --allow-not-admin

The switch is exact and case-sensitive. This mode cannot install, start, stop, or remove the Windows service, and it cannot send custom service-control commands. More importantly, process attribution is best effort without administrator rights. Traffic whose owner cannot be resolved, including protected, elevated, system, or other-user processes, may remain direct even when a catch-all rule is configured.

That limitation rules out `--allow-not-admin` as a strict security boundary. It is described as a compatibility mode for selected applications. An administrator who needs predictable interception of system-wide traffic should use the elevated service model and verify the process-resolution behavior in the GUI logs rather than assuming that a catch-all rule covers every process.

The README also documents Windows 7 support only with Service Pack 1 and recommends a fully patched image with current servicing-stack and SHA-2 support updates, followed by a reboot where applicable. Exact legacy behavior is delegated to `docs/installer.md#windows-7-baseline`, so the installer documentation should be checked before deploying on that platform.

Limitations, Licensing, and Alternative Approaches

ProxiFyre has clear boundaries. It is Windows-specific, depends on Windows Packet Filter and NDISAPI-related components, and requires a suitable Visual C++ and .NET Framework environment. The ZIP package is not an offline installer. The MSI package does not download prerequisites, so managed deployment must provision those dependencies separately. First-party packages may trigger `Unknown publisher` because they are deliberately unsigned.

The repository identifies AGPL-3.0 as its license. That affects how source code and modified versions may be distributed under the license's terms, but this review does not provide legal advice. The presence of `LICENSE` confirms the stated project license; operational compliance still requires reading the license and considering how a deployment incorporates the code.

An alternative is a conventional application-level SOCKS5 client. That approach requires the target application to support proxy configuration, but it avoids system-wide interception, service installation, and administrator-level process attribution. It is a better fit when the application supports SOCKS5 directly and only TCP needs to be proxied. ProxiFyre is the more relevant choice when UDP, QUIC, IPv6, per-application selection, or transparent routing is required and the Windows host can support the elevated networking model.

The project also points to Alighieri as a companion SOCKS5-over-TLS listener. That is a different role from ProxiFyre. Alighieri supplies a compatible TLS-enabled SOCKS5 listener, while ProxiFyre performs the Windows-side routing and management.

Maintenance and Release Surface

The repository is not archived, and its last push was on 2026-10-14. The release list records ProxiFyre 2.6.4 on 2026-10-14, 2.6.3 on 2026-10-13, and 2.6.2 on 2026-10-06. These dates indicate recent repository activity and recent published versions, but they do not by themselves establish compatibility with a particular Windows image, network driver, or SOCKS5 endpoint.

The repository contains `ProxiFyre.Tests/` and `netlib-tests/`, along with a solution named `socksify.sln`. The README does not document a command for running those tests, so this review cannot provide a verified test invocation. Upgrade planning should focus on the architecture-specific package, prerequisite provisioning, configuration compatibility, and service behavior. In particular, a release can change a component involved in filtering, TLS, or service management without changing the basic JSON shape shown in the README.

The GUI can inspect versions and resolved paths, while the engine log can expose the loaded-rule summary when logging is set to `Info`, `Debug`, or `All`. Those features make version and rule verification part of an upgrade check. The project documentation does not state a rollback procedure, so an operator should not assume that downgrading a package or restoring an older file is safe. The available installer and service artifacts should be treated as a coordinated deployment.

Editorial conclusion

Adopt ProxiFyre when Windows applications need transparent TCP or UDP routing through SOCKS5 and you can provision its Windows prerequisites. Do not choose it for a non-Windows host or when every process must be reliably identified without administrator rights. Verify architecture-specific package compatibility, certificate handling, service permissions, and the configured rule order first.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. wiresock/proxifyre on GitHub