GDownload：開源免費下載管理器，連百度網盤連結都收

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

講到免費開源的下載管理器，Motrix 大概是搜尋時最先浮現的名字。這篇要介紹的 GDownload 走了另一條路：同樣以 aria2 引擎為核心，但它用 C++ 與 Qt 開發成原生桌面程式，並且多了兩樣 Motrix 沒有的東西，一是完整的 eD2k 電驢協定支援，二是能把百度網盤、夸克網盤這類分享連結解析成下載任務的插件系統。專案 2024 年 9 月出現在 GitHub，採 AGPL 授權、完全免費，到本文查證時累積 464 顆星，穩定版是 2026 年 7 月底的 v2.2.1，倉庫最近一次推送停在 2026 年 9 月 10 日，還在動。

先把判斷的位置說清楚。這套軟體本身不收錢，原始碼全程公開，我把整包原始碼抓下來逐檔翻過，沒有找到遙測或統計元件，幾處安全設計做得比同類用心。真正的代價在另外兩個地方：網盤解析功能要你把帳號的登入 Cookie 整串貼進設定，速度上限也由網盤官方會員資格決定；安裝檔本身則還沒有開發者簽名，macOS 第一次開啟會被系統判定為損毀而擋下，Windows 則會跳未知發行者的警告。要不要用它，先想清楚這兩點再說。

與 Motrix 的差異，從介面爭議講到引擎選擇

兩者像不像，不用我說。專案的 issue #6 就有人直接貼出並排截圖，問作者是不是參考了 Motrix 的介面，側邊欄加任務卡的佈局確實神似。作者的回覆也很乾脆：對，參考了它的介面。不過相似停在表層：Motrix 是 Electron 應用，等於打包一份瀏覽器引擎來跑桌面程式；GDownload 是 C++ 加 Qt 的原生應用，這是兩者最根本的技術分岔。順帶更正一個常見印象，Motrix 並沒有停更，它 2026 年 9 月還在發布 v2.0.0 的 beta 版，只是節奏放在測試通道。所以把兩者放在同一個需求上比較，看到的是兩條都活著的路線在競爭，沒有誰接誰班的問題。

GDownload 在引擎層做的兩件事，決定了它的性格。一件是把 aria2c 這個命令列下載引擎包進程式裡，HTTP、FTP、BitTorrent、Metalink 與磁力連結都由它處理，多執行緒分段與續傳這些能力直接繼承過來。另一件更少見：作者自己寫了一套程式內的 eD2k 引擎（獨立放在 ed2k-engine-cpp 專案），支援 ed2k 連結下載、連 eMule 伺服器、上傳分享與 Kad 網路搜尋。eD2k 是上個世代驢子時代的協定，主流下載器早就陸續拔掉，願意在 2026 年從零寫一套的專案非常少，對還需要碰老資源的人是稀缺能力。

這裡稍微解釋「aria2 引擎」是什麼意思，因為它決定了這類工具的能力邊界。aria2 是一套存在將近二十年的開源命令列下載工具，多執行緒分段、續傳、BT 支援這些硬功夫都在引擎層，但它在終端機裡跑，指令與設定檔對一般使用者不友善。所以市面上有一整類「aria2 圖形外殼」：引擎用 aria2，前面套一層自己的介面，差別只在殼做得用心程度，以及殼之外額外加了什麼。這兩件事後面分開看：先談網盤插件要你付出什麼，再回頭看引擎層的細節。

Pin

eD2k 那套引擎的設定頁也值得單獨看一眼，因為它保留了不少驢子時代的老講究。設定裡有身分與網路的欄位（暱稱、伺服器連線狀態），有協定混淆的開關，這是當年 eMule 社群用來對付 ISP 封鎖 eD2k 流量的手段；Kad 節點清單會從社群維護的 nodes.dat 更新（翻譯檔裡那條未完成的字串，就是這個更新網址）。上傳分享有佇列與統計，等於你拿它下載老資源時，也在履行 P2P 網路互相餵養的義務，記得把上傳限速設在自己能接受的程度。BT 端的舊帳也翻一下：早期版本曾被回報種子與磁力連結加了任務卻不動（issue #2，來回 11 則討論後結案）；現在的版本除了 tracker 清單自動同步，還會固定拉一份公開的 tracker 黑名單，把死掉的伺服器擋在外面。

介面有淺色與深色兩種主題，官方倉庫附的截圖就是同一個任務在兩種主題下的樣子，下載中的 ubuntu 映像檔顯示已傳輸量、速度、預估時間與連線數，該有的資訊都在。

Pin

把命令列引擎搬進桌面程式，補的是便利性。設定裡可以調全域上下載限速、單伺服器連線數、分段大小與磁碟快取；BT 下載有 tracker 清單自動同步，來源是 ngosang 與 XIU2 這兩份社群維護的公開清單，也能自訂來源；下載完成後的動作從系統通知、打開資料夾、執行自訂指令到關機休眠都有，懶人掛大檔下載的情境算照顧得周到。剪貼簿監聽也是內建選項，複製到的連結會自動被抓進新增任務視窗。這些功能單獨看都不稀奇，稀奇的是它們出現在一個 2025 年 3 月才發第一個正式版的年輕專案上，版本節奏也穩定，2026 年 7 月一個月內連發 v2.0.0 到 v2.2.1 三個版本。

網盤解析不收錢，收的是你的 Cookie

多數人會注意到這個專案，是因為它能解析網盤分享連結。這部分的做法值得攤開看：它不是把解析邏輯寫死在程式裡，而是做成 JavaScript 插件，安裝後從作者放在 GitHub 上的插件登錄檔拉清單，遇到連線困難會自動改走鏡像站。插件市場目前提供百度網盤、夸克網盤、阿里雲盤、123 雲盤與藍奏雲五家，插件架構支援沙箱執行與熱更新。

免費的邊界就畫在這裡。以百度網盤插件為例，官方設定指南寫得很明白：你要先在瀏覽器登入 pan.baidu.com，按 F12 打開開發者工具，把請求標頭裡的 Cookie 值整串複製，貼進插件的設定欄位，插件才能以你的帳號身分呼叫網盤介面去轉存檔案、取直接連結。這串 Cookie 等同你的登入憑證，官方文件自己也這樣警告。Cookie 只存在本機的 plugin_configs.json，程式碼裡沒有把它往外送的邏輯，但你要相信的是兩層：作者的程式碼，加上你從 GitHub 下載插件時走的那條供應鏈。

速度這件事也要先講明白，免得期待錯方向。README 在網盤章節直接標註：百度網盤僅支援標準速度，高速下載請開通百度官方的 SVIP 會員。換句話說，這個工具處理的是「把分享連結變成下載任務」這一步，下載速度的上限仍然掌握在網盤官方手裡，跟百度網盤限速的各種傳聞與解法是同一個結構：帳號等級決定速度，工具只是換個入口。夸克插件同樣要貼 Cookie，機制是先把分享檔案複製一份到你帳號底下再取連結，下載完可以把那份副本自動清掉；夸克相關的批次工具我們先前也介紹過，需求相同的人可以對照。

還有一條官方自己畫的線要抄下來：README 的免責聲明寫明，解析網盤分享連結的功能僅供合法取得你自己的檔案，不得用於侵犯他人權利。這不是免責套話，網盤方對非官方客戶端的容忍度向來有限，觸發風控時應用會跳出驗證畫面要你完成，帳號被限制的風險由使用者自己承擔。拿主力帳號去試一個需要貼 Cookie 的第三方工具，永遠比拿次要帳號謹慎一點。

插件架構對未來的意義比眼前的五家更大。作者把插件系統的設計文件與開發規範直接放在倉庫裡，第三方可以照著 SDK 寫新的網盤插件丟進市場，這代表支援清單有機會長過今天的五家，也代表插件品質未來會參差不齊，安裝前看一眼插件的來源與更新紀錄會是必要習慣。

原始碼裡看得到的安全功課

把原始碼整包抓下來翻，是這個專案最讓我意外的部分，幾個細節看得出作者有在做功課。

本機引擎的通訊介面（aria2 的 RPC）只綁在 127.0.0.1：隨附的 aria2.conf 裡雖然留著對外傾聽的舊值，但程式啟動引擎時用命令列參數強制覆蓋成只聽本機，外面的機器連不進來。更關鍵的是身分驗證：程式碼裡的 token 沒有寫死在程式裡，每次安裝時由亂數產生器生成 32 字元的字串（config_ini.cxx 的 GenerateRpcSecret 函式），早期版本用過固定字串，現在的程式碼偵測到舊值會自動換新的。配套的瀏覽器擴充功能就是拿這組 token 透過 WebSocket 連進來接管下載，等於說「網頁上的東西丟進下載器」這條路有做授權，連接埠不是裸開的。

更新機制也有簽章把關。Windows 的更新清單是 JSON 檔，裡面附了安裝檔的 sha256 雜湊與 Ed25519 簽章，下載來源被限制在白名單網域（github.com、GitHub 的資產網域與 gdownload.uk），不在名單上的重導向會被拒絕並回報失敗。v2.2.1 的版本說明裡甚至坦白記錄了一次三重故障：白名單沒跟上 GitHub 資產網域搬家、鏡像開關失效、傳輸沒有逾時設定，三個問題疊起來讓更新畫面永遠停在 0KB，修正後現在 30 秒無資料會明確報錯。把根因攤開來寫的版本說明，在個人專案裡並不常見。

隱私方面我做了能做的核對：對整個原始碼樹搜尋遙測、統計與追蹤相關的關鍵字，零命中。程式對外的連線主要幾類：檢查更新（走上述白名單）、抓插件清單（GitHub 與鏡像）、同步 BT tracker 清單（ngosang 與 XIU2 這兩份公開清單）、你主動使用網盤插件時對網盤介面的請求，還有 eD2k 功能預設會在每次啟動時從 emule-security.org 更新伺服器與節點清單、並連上 eD2k 伺服器與 Kad 網路（不想連可以在 eD2k 設定裡關掉自動同步）。「不收集任何用戶隱私」是 README 的宣稱，我看到的程式碼與之一致，但一個下載器本來就會連網，這句話不該被讀成「完全不對外連線」。

官網文案有兩處跑在實作前面

對照官網、README 與程式碼，有兩個地方值得提醒。

第一處是瀏覽器擴充功能的連線方式。官網首頁寫著透過 Native Messaging 一鍵接管網頁下載，但我下載擴充功能的原始碼檢查，manifest 權限清單裡沒有 nativeMessaging，背景程式實際上是走 WebSocket 連本機 aria2 的 JSON-RPC 介面，README 描述的才是對的那個。功能本身不受影響，只是行銷文案用了聽起來更高級的詞。

這個擴充功能本身的姿態也要知道：它還沒上架 Chrome 線上應用程式商店，安裝方式是把下載回來的資料夾用開發者模式手動載入，README 自己也標註為實驗功能。它的原理是資源嗅探，內容腳本會掛在所有網頁上，靠 webRequest 權限觀察頁面裡的媒體與檔案連結，再讓你挑選丟給 GDownload。等於是你主動雇了一個坐在瀏覽器裡、盯著全部頁面流量的助手，方便與隱私的取捨非常透明，但裝之前要想一下自己平常瀏覽的頁面性質。

第二處是簽名。官網標榜安全自動更新具備平台程式碼簽署的雙重校驗，現實是：更新清單的 Ed25519 簽章是真的，但穩定版安裝檔本身沒有開發者簽署。macOS 版因此會被 Gatekeeper 以「檔案已損毀」擋下，README 教學是到系統設定點「仍要開啟」，不行就在終端機手動移除隔離屬性；Windows 的安裝執行檔未簽名，SmartScreen 會跳未知發行者警告。開發者在 2026 年 9 月開始導入 SignPath 的免費程式碼簽署服務（目前只做 Windows 的 Authenticode 簽署，macOS 還沒跟上），測試的版本標籤刻意壓在 v0.9.9，理由寫在提交訊息裡：號碼低於穩定版，使用者才不會被推送測試版。也就是說簽署工程在動，但你在 Releases 頁面下載到的穩定版，目前仍是未簽署狀態。

macOS 的應用內更新摔過一大跤。v2.2.1 的版本說明把根因寫得很清楚：應用內更新先前有兩個疊加的問題，Sparkle 更新框架的安裝進度元件從來沒有被打進應用裡（一條忽略規則從自動更新功能上線當天就把它擋在版本庫外），而 DMG 打包過程把框架的符號連結全部解開，破壞了應用簽章，兩者相加的結果是更新下載完成後永遠安裝失敗。修正後打包改用保留符號連結的工具，最終簽章驗不過就直接讓打包失敗。既有的 macOS 安裝救不了自己，得手動下載 DMG 重裝一次，之後自動更新才恢復正常。把這段寫出來的原因很簡單：問題確實出過，修復的過程也確實攤得開。

打開它之前，台灣使用者會遇到的事

介面語言是第一個小障礙。程式支援簡體中文、繁體中文、英文、日文與韓文，繁中翻譯的完整度很高，我數過語言檔，902 條字串只有 3 條還沒翻好，其中一條還是網址。問題在預設值：設定檔的預設語言是簡體中文，程式碼裡也沒有依系統地區自動挑語言的邏輯，台灣使用者第一次打開就是簡中介面，要到設定裡手動切換成繁體中文。

安裝檔的選擇比想像中多，先認清楚再下載。Windows 是一個 61.7MB 的安裝程式；macOS 分成 Universal（約 95MB，同時包 Apple Silicon 與 Intel）和 arm64、x64 各自的 DMG，拿 M 系列晶片機器的人裝 arm64 版會小一些；Linux 是免安裝的 AppImage，約 80MB。安裝檔統一由 GitHub Releases 提供，官網 gdownload.uk 的下載按鈕連過去的是同一個地方，另外官網自己托管了應用內更新檢查用的清單檔當備源，但清單裡的安裝檔網址仍指回 GitHub。換句話說，連不上 GitHub 的環境連官網下載也會卡住，這點先有心理準備。前面提到的簽章與網域白名單就是掛在更新這條路上。

安裝體驗則延續前面講的簽名現況。macOS 要下載 DMG、拖進應用程式資料夾，接著面對 Gatekeeper 的攔截與一段終端機指令；Windows 裝完後通過 SmartScreen 的方式是點「仍要執行」。另外 Windows 端有幾個尚未關閉的 issue 值得知道：有回報 v1.0.7 安裝後主程式打不開的（#9），有新增任務後沒反應的（#8），還有 tracker 自訂來源的刪除按鈕會消失的（#11）。這些都在追蹤清單上，但代表 Windows 體驗還有毛邊。

規模感也誠實交代：v2.2.1 的 Windows 安裝檔在 GitHub 上被下載了約 700 次，這是個小眾專案，遇到問題時能依靠的主要是作者本人與 issue 版，不像老牌的 Free Download Manager 有商業公司撐著。反過來說，回報問題真的會被作者看到。

換過一次授權：從 Apache 到 AGPL

這個專案的授權換過一次。v1.0.8 及更早的版本採 Apache-2.0，之後的版本改為 AGPL-3.0。對一般個人使用者的影響是零，下載、安裝、改來自己用都不用錢也不用登記。差別在拿它做二次利用的場景：AGPL 要求你把修改後的原始碼以相同授權公開，連「把它包成網路服務對外提供」都算；想在 AGPL 義務之外使用（例如閉源整合、不想公開服務端原始碼），才需要另行洽談作者提供商業授權，單純公司內部使用並沒有這道門檻。挑選下載工具時多數人不會碰到這條線，但它解釋了作者對這個專案的定位轉變。

適合誰，看你願不願意餵出那串 Cookie

最後一個定位問題：你需要的到底是桌面下載器，還是網頁型下載站？偶爾存一條短片，GreenVideo 那種貼上連結就走的網頁工具最省事；但需求一旦變成常態性搬大檔、要斷點續傳、要排隊批次、要掛 BT 與 eD2k，瀏覽器分頁撐不住，桌面管理器才是對的工具類型。GDownload 賣的就是後面這一群人：願意花一次安裝的功夫，換一個長期放在工作列的下載工作台。

我的整體判斷：GDownload 是 Motrix 之外一個做得很認真的原生路線選項，版本說明、故障根因與原始碼都攤開讓人查證的作法，在個人專案裡屬於少數，把它當通用下載器的替代品來評估是合理的。但它目前的信任模型是「原始碼公開、你可以自己看」，加上「安裝檔未簽名、網盤功能要交出 Cookie」這兩個現實，我的建議是折衷的：一般下載需求直接用，風險不大；要動網盤解析，先用你不心疼的次要帳號，等穩定版完成簽署（開發者已經在導入 SignPath）再考慮主力帳號。保存自己擁有權利的內容、遵守網盤服務條款，這條底線在哪個下載工具上都一樣。