net-merge spreads new connections across every network adapter

Every new connection goes to one link, and that is the whole idea

net-merge takes the network adapters your machine already has and treats them as a pool. The mechanism is stated plainly in the project documentation: net-merge gives every new connection to one of your links, so when an application opens many connections they spread over all your links. The unit of work is the connection, not the byte, and that distinction is the single most important thing to understand before installing it. A browser with thirty connections can use three links, a download manager with ten parallel transfers can use three links, and a game client with a handful of sockets can sit on the fastest one. The project lists Steam and game downloads, browsers, system updates, cloud uploads to Google Drive, download managers such as IDM and torrents as the workloads that benefit. It also states that it works for every application, TCP and UDP, IPv4 and IPv6, with no proxy to configure, and that faster links receive more connections while a link with no internet receives none until it comes back.

A local TUN device, with no account, no server and no VPN

The architecture is a local one. net-merge runs on your own machine, creates a virtual network interface through the TUN layer, and steers the connections your applications make into that interface, where they are distributed across the physical adapters. The project states that there is no account, no server and no VPN, and the repository topics name the two tunnelling implementations involved, TUN and Wintun, the latter being the Windows driver. The dependency list in `go.mod` shows the shape of the implementation.

module net-merge

go 1.27

The direct dependencies are a desktop tray library, `fyne.io/systray`, for the menu that shows the per adapter speeds, `github.com/vishvananda/netlink` for netlink based configuration on Linux, `github.com/xjasonlyu/tun2socks/v2` for tunnelling traffic, `golang.org/x/net` and `golang.org/x/sys`, a WireGuard Go implementation and `gvisor.dev/gvisor` as the network stack. The Windows driver appears as an indirect dependency, `golang.zx2c4.com/wintun`. Everything runs on the machine that holds the adapters, which is why no remote component is needed and why the traffic never leaves your own links.

Installing on macOS, Linux and Windows

On macOS and Linux the documented install is a single line to paste into a terminal.

curl -fsSL https://raw.githubusercontent.com/rohit267/net-merge/main/install.sh | sh

On Windows the same idea is expressed for PowerShell.

irm https://raw.githubusercontent.com/rohit267/net-merge/main/install.ps1 | iex

That script uses your package manager on Linux, with apt, dnf, zypper, apk and pacman all named, and Homebrew on macOS when you have it, so net-merge then updates along with the rest of your system. Where you would rather see each command, the documentation lists one block per distribution, and the Homebrew path on macOS looks like this.

brew install rohit267/tap/net-merge && sudo "$(brew --prefix)/bin/net-merge" install && net-merge tray

The Debian family block installs a repository key and a source list, then the package.

curl -fsSL https://rohit267.github.io/net-merge/apt/key.gpg | sudo tee /usr/share/keyrings/net-merge.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/net-merge.gpg] https://rohit267.github.io/net-merge/apt stable main" | sudo tee /etc/apt/sources.list.d/net-merge.list
sudo apt update && sudo apt install -y net-merge

After installation the icon appears in the menu bar or tray, and you start it with the `net-merge tray` command on Linux and macOS or from the Start menu on Windows. To have it start at sign-in, the documentation gives the `net-merge autostart on` command.

The tray menu reports per adapter speed and flow

The user interface is a tray or menu bar icon, and the project ships screenshots of it on Windows and macOS. The Windows tooltip shows the merging state, the speed of each adapter and the total, while the Windows menu adds the per adapter flows, an IPv6 option, a pause merging entry and quit. The macOS menu shows the total, the interfaces in use with their flows, for example `en0` and `feth0` in the project example, and the same pause and quit entries. The demo assets make the effect visible: the animated demo shows a speed test on a Mac with Wi-Fi and an Android phone, where the menu shows both connections carrying traffic and the download reaches about 326 Mbit/s. The project also reports a test with Wi-Fi, an Android USB tether and an iPhone hotspot, nine downloads at once, reaching 232 to 303 Mbit/s, where the fastest connection alone gave about 121 Mbit/s. Those are the project's own numbers, and the useful reading of them is that they describe parallel connections rather than a single one.

A single connection never gets faster

This is the limitation the project is most explicit about, and it deserves to be stated before anything else in an evaluation. The documentation has a section titled Not for, and it says one single connection: one connection always uses one link, so one big file from one connection does not get faster. If your workflow is one HTTP request for a large file, or one BitTorrent torrent with a single peer connection, or a video call, net-merge will not help. The workload has to be parallel by nature, which is why the list of good uses is dominated by downloaders, browsers with many tabs and asset fetches. The same reasoning explains the CPU figure the project quotes, about 0.18 CPU cores per 100 Mbit/s, and the safety claim that if net-merge crashes your internet keeps working. The tool is also honest about hardware: the project warns that browser and device limits still apply, and the list of supported systems is Windows, macOS and Linux rather than anything more exotic.

Root level capabilities, an unsigned Windows build and a v0 release line

Running the tool needs privileges, and the install instructions show where. The Linux instructions set the `cap_net_admin` and `cap_net_raw` capabilities on the binary with `setcap`, including in the generic any CPU path, and the macOS Homebrew path runs an install step under `sudo` before launching the tray. The project also states that the Windows installer may warn because the app is not signed yet, with the instruction to click More info and then Run anyway, and it offers a portable zip alongside the setup executable. On maintenance, the release line is young and moving fast: v0.3.0 on 2026-10-17, v0.3.1 on 2026-10-18 and v0.3.2 on 2026-10-19, with the last push on 2026-10-19 as well. The licence is MIT, and the repository carries a `SECURITY.md`, a `CHANGELOG.md`, a `THIRD-PARTY-NOTICES.md` for the vendored dependencies and a `CONTRIBUTING.md`. A version string of 0.3.x is a signal that the behaviour may still change between minor releases, so pin a version if you depend on it.

Local link pooling against a bonded VPN

There is another way to combine links, and the difference in approach is worth being clear about. A bonded VPN or a commercial aggregation client sends your traffic to a remote server, which reassembles the streams and sends them out over one or more of your connections, so the aggregation happens off the machine and a single flow can benefit from several uplinks. net-merge does the opposite: it keeps everything local, splits at the connection level on your own machine, and never contacts a server. The consequences follow directly. Because it is local, there is no account to create, no service to pay for and no extra hop to add latency, and your traffic goes straight out over the physical links. Because it splits at connection level, one flow cannot be accelerated, and because it is local, the result cannot be shared with other devices on your network. A team that needs one aggregated link available to a whole household or a shared office connection is looking at a different category of product, while a single laptop with a spare hotspot is exactly the case net-merge is built for.

Editorial conclusion

Adopt net-merge if your bottleneck is the single link your downloader is stuck on and you have a second connection, such as a phone hotspot, sitting idle, and if you can install a TUN driver and grant the tool the network capabilities it needs. Skip it if your workload is a single long lived connection, since one connection always uses one link and gets no faster, and skip it if you need to share one aggregated link across several devices, which this local design does not do. Verify three things first: that the `cap_net_admin` and `cap_net_raw` capabilities can be granted on your machines, that your platform has a TUN driver available, Wintun on Windows and the built in one elsewhere, and that the release you install matches the version your distribution package provides, since the line is still at v0.3.2 and the project publishes tagged releases roughly daily.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rohit267/net-merge on GitHub