Connection aggregation
These are separate choices: the operating mode determines how application traffic enters HypoMux, while the scheduler assigns new pooled connections to adapters. Choose an operating mode first; adjust the four scheduling strategies after multiple paths are working.
How it works
HypoMux chooses an outbound adapter when each new connection begins. Source-address binding and the Windows interface index keep that connection on its physical path, so independent connections can be distributed across adapters.
Think of it as assigning a path to each new connection—not splitting one connection into pieces. More concurrent requests give HypoMux more opportunities to use multiple networks.
Four scheduling strategies
The scheduler assigns new pooled connections to adapters. Version 2.7.0 offers four strategies; none splits one TCP connection or migrates established TCP connections merely because you changed strategy.
| Strategy | Behavior | When to use |
|---|---|---|
| Maximum speed first (default) | Rotates new connections across eligible links without manual weights | A baseline or similarly fast links; the name does not imply automatic speed measurement |
| Schedule by weight | Uses relative manual weights, integers from 1–100 | Explicit control of new-connection shares |
| Adaptive speed | Starts evenly and gradually learns from sustained throughput and connection turnover, preserving a minimum share | Sustained concurrent downloads; low demand may leave shares balanced |
| Low latency first | Uses target latency, jitter, and loss, with public-probe estimates when samples are insufficient | Latency-sensitive workloads; use TUN for games and compare actual results |
Configuration and hot updates
- Choose the scheduler beside Start. Version 2.7.0 supports live strategy and weight changes; stop before changing mode or participating adapters.
- Enter weights on selected adapters for manual scheduling. Other strategies do not use those values. Handle unsupported Core, unavailable adapters, and save errors before assuming a change took effect.
- Create fresh connections for the same workload, inspect Active connections, and compare sustained rates. Established connections keep their previous egress, so the full effect is not immediate.
For links sustaining roughly 300 and 100 Mbps, try 3:1 as an initial comparison. 3:1 and 30:10 have the same relative shares, but connection shares are not traffic ratios, bandwidth limits, or data caps. Weight 1 still consumes mobile data; stop and deselect that adapter to exclude it.
Adaptive and latency boundaries
Adaptive speed requires observations and new connections. One or two long-running connections cannot be redistributed. A marked throughput drop rolls back adjustments and introduces cooldown; it is not guaranteed to beat round-robin.
Low latency first uses hold times and switching thresholds. UDP with no replies may rebuild its upstream only with repeated failed-probe evidence and an available backup. It does not replay old packets or proactively migrate healthy connections or existing TCP. A changed public egress may reconnect a game. To pin a stable path, use TUN routing rules.
Operating modes
| Mode | Best for | Key behavior |
|---|---|---|
| System Proxy | Proxy-aware apps such as browsers, IDM, and Steam | Lightweight; can avoid system proxy takeover; does not create a virtual adapter |
| Virtual Adapter | Broader TCP/UDP and apps that cannot use a proxy | Uses Wintun, WFP, DNS, and routes for system-level routing |
System Proxy mode
HypoMux exposes local HTTP/HTTPS and SOCKS5 proxy services and can take over the Windows system proxy. It suits apps that follow the system proxy or allow a local proxy to be configured. It does not create a virtual adapter and is normally the best first choice for downloads.
For manual proxy configuration, the default local address is 127.0.0.1, with HTTP/HTTPS on port 10801 and SOCKS5 on 10800. Ports are configurable; use the values currently shown in Settings. Start HypoMux before reconnecting the app. With system-proxy takeover disabled, apps without a manual proxy configuration do not automatically enter aggregation.
Virtual Adapter mode
This mode uses Wintun, WFP, DNS, and routing rules to cover broader traffic. It runs safety checks before start. Exit or disable other TUN, VPN, or accelerator tools that already take over the default route.
TUN stack selection
Open Settings → Advanced network / special network environment → TUN stack to select the stack used by Virtual Adapter mode:
| Option | How it works | When to use it |
|---|---|---|
system (default) | Uses the operating system stack | Keep the default when there are no compatibility problems |
mixed (hybrid) | System TCP with gVisor UDP | Compare behavior when troubleshooting UDP application compatibility |
gvisor (userspace) | Uses a full userspace stack | Try it if compatibility problems persist with the other stacks |
The selection saves automatically and applies the next time TUN starts. If Virtual Adapter mode is running, stop aggregation normally and start it again. This setting does not affect System Proxy mode or how aggregation assigns adapters to connections.
There is no universal speed ranking. Change only the stack, then compare connectivity, latency, and resource use with the same application and network paths. Return to system if there is no improvement.
The TUN stack handles local virtual-adapter traffic; switching it does not directly change your router's or ISP's NAT policy. Use NAT type detection to inspect a physical egress path.
Speed and latency
Connection aggregation increases combined throughput across concurrent connections. One TCP connection remains limited by its assigned path, and aggregation does not guarantee lower latency. Use direct-routing rules for competitive games, meetings, and voice apps.
WARNING
Aggregation does not create one public IP or turn several lines into a single-link bonding protocol. Do not judge it from a single-connection speed test; use a multi-connection download or several concurrent tasks.