HypoMux：開源 Windows 多網卡頻寬聚合工具，把下載頻寬合併起來

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把電腦同時接的有線網路、Wi-Fi 與手機熱點合起來用、讓下載變快，是很多人聽到頻寬疊加這四個字時的直覺期待。HypoMux 就是做這件事的 Windows 開源工具，作者在 GitHub 帳號 Hypostasis-Cat 名下以 AGPL-3.0 授權釋出，到 2026 年 8 月初累積約 2231 顆星、76 個 fork。

不過它有一條最容易在動手前被忽略的邊界，值得在最前面就講清楚：HypoMux 官方 README 明白寫著，它聚合的是多個獨立連線，而不是把單一條 TCP 連線拆成多路。這代表它只對會開很多並行連線的下載（Steam 遊戲更新、IDM 多執行緒下載、瀏覽器抓大檔）有效，單一連線的測速、單檔下載不會變快；如果你平常只是用CutCut 這類網頁工具偶爾抓單檔影片，那種場景它幫不上忙。下面依 GitHub 的 repo、README、Releases 與 Issues 把它的機制、兩種運作模式與權限代價拆開講，並標清楚哪些是作者宣稱、哪些是我能親自查證的事實；我並沒有在 Windows 實機安裝操作，所以這是一篇工具認識文，不是實測報告。

連線級分配，跟鏈路聚合是兩回事

很多人把頻寬疊加想像成 100M 加 100M 等於 200M、而且對所有下載都成立。HypoMux 的 README 直接打破這個期待：它做的是連線級的負載分配，不是把多條線路綁成一條、具有單一公用 IP 的鏈路聚合協議。兩者的差異可以這樣理解。

鏈路聚合（bonding）需要兩端配合，把多條實體線路當成同一條邏輯線路，連單一 TCP 串流都能跨線路分攤；電信業者的 MLPPP、企業交換器的 LACP、以及商業服務 Speedify 走的雲端中繼黏合，都屬於這一類。HypoMux 不做這件事。它在每個新連線建立時，由本機的 Go 引擎選一張出口網卡，再用原始碼位址綁定（source-address binding）搭配 Windows 的 IP_UNICAST_IF 把這個 socket 釘到那張實體網卡上。結果是：一條 TCP 連線從頭到尾只走一張網卡，它的速度上限就是那張網卡的原速；只有當應用程式同時開很多連線（例如 IDM 開 32 線、Steam 同時拉多個資料區塊），不同連線才會被分到不同網卡，加總起來才看得到頻寬疊加。

從機制設計來看，HypoMux 不依賴修改全域路由表的 Metric 躳點數，而是靠前述的 source-address binding 在連線層級做分配。這跟早期一些土法煉鋼的工具（手動調 Metric 讓某張網卡優先）走不同路線，優點是對系統網路設定的侵入面比較小、停止或解除安裝時也比較容易還原；代價是所有要被加速的流量，必須先經過 HypoMux 自己的本機代理或虛擬網卡，並不是完全不碰系統。

這裡要分清楚：以上機制描述是作者在 README 的宣稱，我能親自核對的是工程實作面。引擎目錄 engine/go.mod 的直接依賴只有 golang.org/x/net 與 golang.org/x/sys（另有一個間接依賴 golang.org/x/text），也就是 Go 引擎本身只做連線調度與 Windows 系統呼叫；README 提到的 sing-box、Wintun 與 libcronet 並不是 Go 模組依賴，而是放在 repo bin/ 目錄裡的捆綁執行檔與 DLL。換句話說，你裝的不只是 HypoMux 自己，還有它捆綁的 sing-box、Wintun 與 libcronet，這點後面談信任邊界時會再回到。

兩種模式：系統代理與虛擬網卡

HypoMux 提供兩種運作模式，選哪種直接取決於你的下載工具吃不吃 Windows 系統代理。README 把兩種模式整理成一張對照表，重點如下。

Pin

系統代理模式會在本機啟動 HTTP／HTTPS（port 10801）與 SOCKS5（port 10800）服務，然後接管 Windows 的系統代理設定。它比較輕量、不建立虛擬網卡，但只覆蓋會遵循系統代理的應用，例如 IDM、Chrome、Edge、Firefox、Steam。虛擬網卡模式則用 Wintun 搭配 sing-box 接管更廣泛的 TCP／UDP 流量，再結合 WFP、DNS 與路由規則做精細分流；它需要獨立的 Core 服務（管理員權限）與 Wintun／WFP，而且不能跟其他接管預設路由的 TUN（例如另一個 VPN 或代理工具的 TUN 模式）同時運作。

實際選擇的決策點很簡單：如果你只在乎 IDM、瀏覽器、Steam 這種本身就吃系統代理的下載，系統代理模式負擔比較輕；如果你要加速的是 WeGame、或某些不吃系統代理的遊戲平台下載器，就得用虛擬網卡模式，並接受它更重的權限需求與不能跟其他 TUN 並存的限制。v2.5.2 還對常見的本地代理與遊戲加速器加了專門的相容旁路，讓這些程式的流量直接繞過聚合、避免代理回環；不過那份相容名單有明顯的市場偏向，後面會單獨講。

官方怎麼展示它的效果

README 放了幾張官方實測截圖，用來展示連線級聚合的實際表現，分別涵蓋 IDM 多執行緒下載、Steam 遊戲更新、WeGame 下載，以及 Windows 工作管理員裡多張網卡同時有吞吐的畫面。這些截圖有兩點必須先講清楚。

Pin

第一，README 自己標明這些截圖來自早期版本、真實多網卡多連線測試，目的是說明連線級聚合能力，並且加了一句但書：實際速度取決於每條線路、下載源、並行數、磁碟與 CPU，不能視為效能保證。第二，這些是官方提供的測試畫面，不是我重新跑出來的結果，因此它們只能證明工具具備這種能力，不能延伸成在你的環境一定會看到一樣的數字。如果你決定要試，真正能參考的是自己用前後各跑一次同樣的下載任務做對照，而不是直接拿這幾張截圖當預期。

它做不到的事，以及風險訊號

把官方資料無法支持的東西一次攤開，比列完功能更有助於判斷。

在效果這一項，我無法替你保證它裝了會讓你的下載變快。連線級分配的前提是應用程式願意開夠多並行連線，而這件事取決於下載器設定、下載源伺服器有沒有限制單 IP 連線數、以及兩條線路本身的品質。如果你的下載源只允許單一連線，或你的下載器預設只開兩三線，再多網卡也不會出現疊加。

在穩定度這一項，有兩個值得放進判斷的訊號。其一是專案本身的成熟度：repo 建立於 2026 年 6 月 11 日，到 8 月初才七週多，版本從 v1 走到 v2.5.2，而 v2.5.0 是作者把整個網路核心與桌面端從原本的 Python／Qt 與過渡期的 WPF 全部重寫成 Go＋Wails v3＋React＋Fluent UI 之後的第一個正式版。v2.5.2 的 release notes 自己寫了：這個正式版經過一天的集中測試，因為重寫觸及網路引擎、權限模型與桌面框架，仍不能完全排除少數環境出問題；隔天起連發的 v2.5.1、v2.5.2 就是修復管理員權限下代理與 TUN 失效、托盤選單無回應等問題。換句話說，你現在裝到的是一個重寫剛落地、修復還在收尾的版本。

另一個訊號來自 GitHub Issues。編號 43 的議題裡，有使用者反映把 500M 主寬頻與 200M 副寬頻聚合後，當天測速確實有疊加效果，但第二天主網卡不明原因降速到大約一百多 M、跟副寬頻差不多，重置網路與各種修復都救不回來；這個議題是 2026 年 8 月 2 日才提出的，還很新，目前仍開著、尚未有官方回覆。它不代表每個人都會遇到，卻是一個工具可能干擾主網卡速度、且不容易自行回復的已知實例，把這條風險放進決策會比假裝它不存在踏實。

在跟其他工具的定位差異上，最常被拿來相提並論的是 Speedify。Speedify 走的是自家雲端中繼做通道黏合，理論上可以讓單一串流跨多條線路，這跟 HypoMux 本機連線級分配是不同類的機制；Speedify 收月費、流量經過它的伺服器，HypoMux 免費、純本機、沒有雲端中繼。兩者服務的需求其實不同：要真正的單串流黏合、不在意把流量交給第三方與付月費，Speedify 那一類才對應；只想在本機把多連線下載分攤到多張網卡、不想多一個雲端節點，HypoMux 才在這個位置。我不做對稱比較表，因為我沒有兩邊的對稱實測資料，以上的差異都是從兩邊官方文件可以核對的機制描述，不是效能比較。

裝起來要付的代價，與幾條在地邊界

會改變你是否該用的硬限制，集中在這幾項。

平台是 Windows 10／11 限定，repo 的 topics 也明確標了 windows-10 與 windows-11；macOS 與 Linux 不是這個工具的服務對象，想在其他平台做類似的事要找別的路徑。授權是 AGPL-3.0，這是強 copyleft 的條款，任何把這個專案修改後對外提供網路服務的衍生作品，都必須以同樣條款開源；對單純下載使用的個人讀者影響不大，但對想在商業產品裡借用的人是必須看清的代價。

權限上，虛擬網卡模式需要一個獨立的 Core 服務持有網路管理權限（安裝 Wintun、設定 WFP、改 DNS 與路由），桌面介面本身以一般使用者身分運作，這是作者強調的最小權限架構；但這仍代表你會在系統裡裝一個有管理員權限的常駐服務。前面提過，引擎依賴的 sing-box、Wintun 與 libcronet 是被捆綁進 bin/ 的執行檔與 DLL，這幾個都是第三方元件，你對它們的信任等於對這個打包的信任。官方有提到 Windows 發布版本是經由 GitHub Actions 建置、再送到 SignPath 免費簽章，下載時能從發布者欄位看到 SignPath Foundation，這是比未簽章安裝檔可信的一層，但仍建議只從官方 GitHub Releases 頁面抓檔案。

換幾個在地角度看，還有幾條邊界值得注意。最明顯的是 v2.5.2 的第三方代理與遊戲加速器相容名單，遊戲加速器那一塊幾乎是中國大陸市場為主（UU、迅遊、雷神、奇遊），通用代理工具（Clash／Mihomo、v2rayN、Hiddify、Shadowsocks、Proxifier）有涵蓋，所以如果你用的是前述通用代理，會落在相容範圍內，但如果你用的是名單外的在地代理，得自己驗證。另外兩條比較軟性：README 的中文版是簡體中文優先（另有英文版），對習慣繁體的讀者沒有閱讀障礙，但反映了作者的主要受眾；官方 release notes 留的社群管道則是 QQ 群（1002583295），境外讀者要加入回報問題或看社群討論比較不方便，遇到問題主要還是得走 GitHub Issues。

適合誰，以及怎麼低成本驗證

把前面的條件收攏成一個判斷：如果你常做大檔案下載、而且下載工具本身會開很多並行連線（IDM 預設多線、Steam／Epic／Xbox 遊戲更新、瀏覽器抓大檔），身邊又同時有兩條以上的獨立網路（例如宿舍或租屋處的有線網路加手機熱點、或家用 Wi-Fi 加另一張 4G／5G 網卡），HypoMux 對你的潛在價值最高。如果你下載的東西本質上是單一連線（單檔 HTTP 直連、某些只開一條連線的雲端硬碟下載），或你只有一條網路，這個工具對你沒有幫助，不用裝。

想低成本驗證它對你有沒有用，可以先做兩件不用動到系統的事。先確認你常用的下載工具會開多少並行連線：IDM 可以在選項裡看到預設連線數、Steam 在下載設定裡沒有限制時通常會開多連線、瀏覽器下載大多只有一兩條。如果發現主要下載都是單連線，HypoMux 不會讓它們變快，這時候可以先打消念頭。確認過以後，再從官方 GitHub Releases 頁面下載顯示 SignPath Foundation 簽章的安裝包，先在一條小檔案下載上試一次系統代理模式，前後各測一次速度做對照；如果系統代理模式就能涵蓋你的下載工具，就不必急著開權限需求更重的虛擬網卡模式。遇到網路行為異常，README 寫停止聚合或正常退出會還原它接管的設定；前面提過的 issue 43 也提醒，如果主網卡出現不明降速，把工具完全停掉並檢查系統代理與路由是否回到原本狀態，會是第一個該做的排查。

最後的判斷很直白：HypoMux 是一個七週大、剛重寫完、由在學學生在業餘時間維護的開源專案，迭代速度很快，但也代表它還在快速變動期。它解的是一個明確的小問題（多連線下載分攤到多張網卡），不是萬用的網速放大器；理解這條邊界，比記住它的功能列表更能決定它值不值得你花一個晚上試。

如果你對這類本機網路工具的主題有興趣，我們先前也寫過把每台設備走不同出口這件事搬進 Mac 選單的 OpenSurge for Mac，以及把本地服務對外穿透做成開源自架版本的 OutRay，可以對照不同類型網路工具的設計取捨。