HypoMux: Aggregating Windows NICs at the Connection Level, Not the TCP Level

What HypoMux Actually Solves

HypoMux targets a specific Windows pain point: you have more than one network connection, such as wired broadband plus Wi-Fi or a phone hotspot, but each application only uses one. The tool aggregates these links by assigning each new connection to a selected physical NIC. That means Steam updates, IDM multi-thread downloads, and browser file transfers can spread across interfaces. It does not merge links into a single faster pipe. The README is explicit: aggregation is connection-level load distribution, not a link aggregation protocol with a single public IP. This distinction matters because many users expect a magic speed multiplier. HypoMux does not deliver that for a single TCP stream, and it says so plainly.

The Two Modes and Their Trade-offs

HypoMux offers two operating modes. System proxy mode starts local HTTP/HTTPS (port 10801) and SOCKS5 (port 10800) services and takes over the Windows system proxy. This is lightweight and works for applications that respect the system proxy, such as IDM, browsers, and Steam. Virtual NIC mode uses Wintun and sing-box to capture broader traffic, with WFP, DNS, and routing rules for fine-grained splitting. The trade-off is clear: virtual NIC mode requires a separate Core service with elevated privileges, cannot coexist with another TUN that owns the default route, and is heavier. The README recommends system proxy for proxy-aware downloaders and virtual NIC for game platform updates or complex routing. Choosing between them is not a technical nuance; it is the first decision you make, and the wrong choice can break existing VPN setups.

How the Engine Pins Connections to Physical NICs

The core mechanism is per-connection outbound NIC selection. The Go engine, hypomux-engine.exe, receives traffic from either the local proxy or the virtual NIC. For each new connection, it chooses an egress interface and then uses source address binding combined with the Windows IP_UNICAST_IF socket option to lock that socket to a specific physical link. This is different from a userspace proxy that simply forwards to a default route. The README's diagram shows the application connection splitting into three NICs, with combined throughput at the end. The key detail is that the binding is per-connection, so the same application can have different connections on different NICs. That is how a multi-threaded downloader benefits. The engine also tracks domains that fail on a particular link and avoids sending subsequent connections to that link, which is a practical recovery mechanism for flaky interfaces.

Getting It Running: Commands and Configuration

Installation is straightforward: download the latest HypoMux_Setup_*.exe from GitHub Releases or the CNB mirror. The README's quick start lists six steps: connect at least two networks, launch HypoMux, select the NICs to pool, run the network health check, choose a mode, and start the engine. The health check verifies IPv4, gateway, DNS, and source address binding capability for each link. For developers, building from source requires Windows 10/11, Go 1.26, Node.js 22, pnpm 10, and Wails v3 CLI at version v3.0.0-alpha2.119. The build commands are provided: install wails3, run pnpm install in desktop/frontend, generate bindings with wails3 generate bindings -clean=true -ts -i, run tests with go -C engine test ./..., and build the frontend. The bin/ directory must contain sing-box.exe, wintun.dll, and libcronet.dll. This is a real build chain, not a single-command setup, so expect friction if you are not already familiar with Wails and Go.

Third-Party Proxy and Accelerator Compatibility

Version 2.5.3 added a compatibility bypass for common local proxies and game accelerators, including UU, Xunyou, Leishen, Qiyou, and Clash/Mihomo, v2rayN, Hiddify, Shadowsocks, and Proxifier. The detection prefers full executable path matching and, for local system proxy listeners, resolves the PID by listening port. This is a thoughtful approach because process names change. However, the README lists clear boundaries: two programs should not fight over the Windows system proxy switch, and if a third-party TUN owns the default route, you must close it before starting HypoMux's virtual NIC mode. The tool attempts to detect and block such conflicts before modifying system network settings. But the compatibility is not guaranteed after an accelerator updates its process structure. You may need to check logs and switch modes manually. This is a maintenance point that the README acknowledges.

Limitations and Failure Modes

The most significant limitation is that single TCP connections remain capped by their physical link speed. The README states this repeatedly, but it is easy to overlook. If your download tool opens only one connection, HypoMux will not help. Another limitation is latency: aggregation targets throughput, not reduced ping. The README recommends adding competitive games, voice, and video conferencing to the direct/bypass rule list, or pausing the tool entirely during gameplay. There is also a recovery mechanism: the system proxy state is saved atomically and restored after abnormal exit, startup failure, or reboot. This is good, but it depends on the Core service running with sufficient privileges. If the service fails to start, the tool may not modify system settings, which is safe but means no aggregation. Finally, the tool does not read game memory, inject DLLs, or modify game protocol packets, but third-party anti-cheat rules vary, so users must respect service terms.

Maintenance, Licensing, and Distribution

HypoMux is licensed under AGPL-3.0, which has implications if you modify and redistribute the code. The project is actively maintained, with releases v2.5.6, v2.5.7, and v2.5.8 pushed in August 2026. The desktop frontend migrated from Python/Qt and WPF to Go + Wails v3 + React + Fluent UI in version 2.5.0. This reduces runtime dependencies but introduces a build requirement for Wails v3 alpha. The release process is notable: official Windows builds are signed via SignPath, with the publisher shown as SignPath Foundation. The update channel uses Ed25519 verification, and the client checks package size, SHA-256, and Authenticode signature. This is a strong supply-chain posture for a free tool. However, the README mentions that the author is a student with limited time, and donations are voluntary. You should verify the latest release notes before adopting, especially if you rely on specific proxy compatibility fixes.

Alternatives and When to Choose Them

The closest alternative is a conventional link aggregation protocol like LACP, but that requires hardware support and a single logical link, which HypoMux does not provide. Another alternative is a load-balancing router with policy-based routing, which can split traffic across WANs but typically requires dedicated hardware or a custom router OS. For Windows-only, you could use a simple proxy switcher that routes through one NIC at a time, but that does not split concurrent connections. The real difference is that HypoMux operates at the application connection level with per-NIC binding, which is more flexible than static routing. However, if you need a single TCP connection to exceed link speed, no software can do that without a VPN or proxy that splits the stream, which HypoMux explicitly does not do. For that, you would need a multipath TCP proxy, which is a different technology with its own complexity. HypoMux is the right tool when you have many small connections and want to use all available bandwidth without reconfiguring each application.

Editorial conclusion

Adopt HypoMux if you are on Windows 10/11, have at least two active network interfaces, and your workload is high-concurrency downloads from Steam, IDM, or browser-based file transfers. Do not adopt it if you need a single TCP connection to exceed its physical link speed, or if you rely on a TUN-based VPN that must keep default route ownership. Before deployment, verify that your third-party proxies or accelerators are closed or whitelisted, run the built-in network health check, and confirm that the installer's publisher shows SignPath Foundation. The project is AGPL-3.0, so review your distribution obligations if you plan to modify and redistribute it.

Official sources

1. Official README
2. Project repository
3. Release notes