cobalt 開源下載器實測：免費引擎還能用，YouTube 自架才通

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

在貼連結就能下載的網頁型工具裡，cobalt 是最受矚目的開源選項：GitHub 上 44,815 顆星、3,948 次 fork，授權條款是 AGPL-3.0（數字查詢於 2026 年 10 月）。但它現在的樣子，和大多數人印象裡「打開網站、貼上連結、按下載」的印象已經有段距離。我這輪把官方網頁端、官方 API、以及用官方 Docker 映像檔自己架的處理引擎三條路都實際測過一輪，結論先講：cobalt 的價值已經從一個網站，搬進一份可以自己架的引擎裡。官方網頁還活著，但進門要先過 Cloudflare 人機檢查；官方 API 對匿名呼叫直接關門；同一套引擎跑在自己機器上，今天免金鑰就把 YouTube 影片完整抓了下來。

三條路之間的落差，比任何一條路本身都值得注意。

同一套引擎的兩種命運：官方端掛鎖，自架端免鑰匙

cobalt 的架構分成兩層：瀏覽器裡的前端，和真正去各平台抓檔案的處理引擎（API）。前後端的原始碼都放在同一個 monorepo 裡，官方自己經營的實例是 cobalt.tools 這個網站加上背後的處理引擎。

直接打官方處理引擎的資訊端點，它會誠實回報自己的狀態。我拿到的回應是：版本 11.7.1，跑在 fix-redis 這個分支上，開啟的服務有 20 個，清單裡沒有 YouTube，而且帶著一組 Cloudflare Turnstile 的 sitekey。對照倉庫裡的服務支援表，原始碼層支援的服務是 21 個，YouTube 也在表上。讀引擎的環境變數處理原始碼可以找到原因：服務清單是用 DISABLED_SERVICES 這個設定值過濾出來的，也就是說，官方實例是在設定層主動把 YouTube 關掉的，不是模組壞了。

匿名直接呼叫官方 API 的話，回應是 HTTP 400，錯誤碼 error.api.auth.jwt.missing。官方 API 文件也把話講明了：託管實例有機器人防護，沒有獲得明確許可，不該拿去用在別的專案裡。想要走 API 這條路，文件給的答案是自己架一套。

那自己架是什麼景象？我把官方映像檔 ghcr.io/imputnet/cobalt:11 拉下來跑，只給了一個 API_URL 環境變數（這是官方文件列出的唯一必填值），引擎就起來了。它的自我介紹是：版本同樣 11.7.1，跑在 main 分支，服務清單 21 個，YouTube 在裡面，而且沒有 Turnstile sitekey 這個欄位。同一份引擎，官方端和自架端的差別一目瞭然。

把官方 Docker 映像檔跑起來：七個服務的實測成績單

自架流程照官方文件走：裝好 Docker，一份 docker-compose 設定指到官方映像檔，連接埠開在本機 9000，啟動就完成了。官方範例還掛了 watchtower，映像檔有新版會自己更新。

引擎起來後，我用它實際送了七個服務的連結進去，成績單如下。

YouTube 是最意外的通過者。丟進一支知名老歌的 MV 連結，引擎回給一組 tunnel 連結和檔名（標示 720p、h264）；另一次請求 360p 畫質，我從 tunnel 實際收下了 11,839,320 個位元組，將近 11.8 MB，檔頭檢驗是標準的 MP4 容器。也就是說，一台乾淨的自架實例、一把自家的家用網路 IP，沒有設定任何 YouTube 工作階段伺服器，下載當下是完整可用的。

SoundCloud 也通了，丟一首公開音軌進去，回來的是 Flickermood.mp3 的 tunnel 連結。

回應裡的 tunnel 連結本身也有設計值得一提：帶著簽章與到期參數，從產生到失效只有 90 秒上下，過了時間就得重新請求。檔案不是被複製到伺服器上等你慢慢抓，而是即時流過去，這也是官方敢說「從不快取任何內容」的技術底氣。

引擎的輸出旋鈕比網頁介面露出來的多：畫質從 144p 一路指到 4320p（也就是 8K），模式有完整影片、純音軌、靜音影片三種，音軌格式能選 mp3、opus、wav 等，檔名格式也有四種風格。這些全部反映在 API 的請求參數裡，自架的好處之一就是這些旋鈕全歸你。

還有一個低調但關鍵的設計：官方前端本身就留了「自訂處理實例」的設定欄位。你可以繼續用 cobalt.tools 的介面，但把背後的引擎指到自己架的機器上，前端不必自己架。等於說官方把「介面」和「引擎」拆乾淨了，兩邊可以自由組合，這在同類工具裡並不常見。

另外五個服務在取得階段就失敗：Bilibili 兩次都回 error.api.fetch.empty，Reddit 和 Vimeo 回 error.api.fetch.fail，TikTok 回「貼文無法取得」，Dailymotion 也是取得內容為空。這份成績單是單一網路環境、單一時點的快照：失敗可能是各平台對非瀏覽器流量的防護，也可能是專案靜默期模組慢慢鏽掉的結果，兩種原因從外部無法完全切開。官方文件也提到，部分服務即使看公開內容也要求登入憑證，自架時要自己準備 cookies.json。

比較確定的判讀是：服務可用度已經分層了。最大的平台（YouTube）因為使用者基數大、路徑被反覆修過，自架反而能通；中型平台各自看緣分。這份成績單每過幾週都可能變，依賴它之前要有這個心理準備。

44,815 顆星的專案，重心搬去了瀏覽器

看治理時間線，會更理解上面那些現象。

cobalt 是開發者 wukko 在 2022 年 7 月開的個人專案。2024 年 5 月前後，倉庫從個人帳號搬進 imputnet 這個組織（網頁存檔服務對舊址的最後成功快照是 2024 年 5 月 10 日，對新址的第一筆快照是 5 月 18 日）。2024 年 10 月，API 的 JWT 驗證機制進入原始碼，這是匿名濫用開始被擋的時間錨點。

接著是資源移轉：2025 年 2 月中，同一個組織開了 helium 倉庫，那是一套以 Chromium 為基礎的隱私瀏覽器，官方給自己的定位是「Private, fast, and honest web browser」。cobalt 這邊，官方更新日誌的最後一篇停在 2025 年 6 月 30 日的 11.2 版；原始碼的 main 分支最後一筆提交是 2026 年 4 月 6 日，內容是把 redis 依賴回退到 4.7.1，對應 PR 的描述只有一個詞：oops，官方實例至今跑的就是那前後的版本。而 helium 那邊，wukko 本人在 2026 年 10 月上旬還幾乎天天提交，內容包括把整套碼合併到 Chromium 155。

Pin

把這些擺在一起，我的判斷（這是推論，不是官方聲明）：開發重心已經移到瀏覽器上了。佐證還有一件：cobalt 為了通過 YouTube 檢查而維護的工作階段產生器 yt-session-generator，最後一次更新停在 2025 年 3 月。倉庫的議題區現在還有社群成員送新功能、修錯誤，但 4 月之後沒有任何人合併它們。

這不代表專案死了。引擎能用、映像檔能跑、官方實例持續運作，這篇的實測本身就是證據。但「遇到平台改版幾天內就會修」的期待，在目前的人力配置下已經不成立，它更像一台還在運轉、但維修班底已經調去別條生產線的機器。

免費的閘門是怎麼築起來的：人機檢查與 YouTube 貓鼠

cobalt 打的招牌是沒有廣告、沒有追蹤器、沒有付費牆。這三件事到今天都還成立，但它沒說的是「免費」的入口長了閘門。

官方網頁端載入後，會先顯示一段「Cloudflare Turnstile 正在確認你不是機器人」的狀態訊息，有時一閃即過，通過之後才進入正常操作。看前端原始碼可以確認流程：瀏覽器先解一題 Turnstile 挑戰，拿著證明去換一組短效期的 JWT 權杖（預設效期 120 秒），之後的每次下載請求都帶著這組權杖。對一般使用者這是背景程序，多數時候無感；對想把官方端當成免費 API 來打的程式來說，這道牆就是斷頭路。

Pin

另一道牆在檔案落地的方式。cobalt 從 11.2 版起把「本機處理」預設打開：串流到位後，合併影音軌、補 metadata、加字幕這些後段工作，是在你的瀏覽器裡用 WebAssembly 版的轉檔工具完成的。好處是下載速度和檔案相容性都更好，伺服器也不必碰完整的媒體處理；代價是舊瀏覽器可能吃力，官方在更新說明裡也承認會持續改善舊裝置的支援。

YouTube 那側則是另一種貓鼠。要在不登入的狀態下拿 YouTube 的串流，得模擬各種用戶端身分，處理平台逐步加上的證明機制。cobalt 的原始碼裡，只有 YouTube 模組引用了一個隔離沙箱套件，專門用來在伺服器端執行 YouTube 自己下的反機器人腳本，這個細節本身就說明了這條戰線的強度。官方 11.2 版更新日誌當時寫得很直白：主實例的 YouTube 下載恢復了，但接下來幾週到幾個月，這件事會明顯變得更麻煩。事後來看，這句預告相當準：2025 年 11 月起，議題 #1475 記錄了自架者也拿不到 YouTube 檔案的長期破損，社群不斷換用戶端身分繞路，2026 年 9 月底最新的繞法又被 403 打回來，議題至今開著。我這次自架實測能通，說明這條戰線仍有來有回，但把 YouTube 下載當成穩定依賴，風險自己評估。

授權、責任，和下載之前要想清楚的事

授權面：cobalt 採 AGPL-3.0，自己用沒有任何問題；想改程式碼、包成服務對外提供，修改後的原始碼有對應的公開義務，商用整合前值得先讓懂授權的人看一眼。

責任面，官方 README 的立場寫得罕見地直白，大意是：cobalt 對下載的內容「不承擔任何責任」，它「從不快取任何內容」，運作方式像「一個講究的代理器」，而且自稱「絕不是盜版工具，只能下載免費且公開可取得的內容」，同樣的東西用任何現代瀏覽器的開發者工具都拿得到。這段自述是不是每個使用場景都成立，讀者可以自行檢驗；但把「工具零責任」和「下載版權內容的責任在使用者」放在一起讀，意思是清楚的：拿它存什麼、怎麼用，帳都算在你頭上。下載自用和重新散布在法律上是兩件事，後者的風險明確高得多，這條線自己拿捏。

隱私面：官方前端設定裡有一個「停用統計」的開關，預設是關的，也就是預設會收匿名統計；自架整套前後端的話，資料流就在你自己的機器上，這條疑慮直接消失。

三種人，三條路

如果你只是偶爾要存一支公開影片，官方網站 cobalt.tools 仍是零門檻的選擇：過一下人機檢查、貼連結、存檔，清單上仍列著 20 個服務（各服務實際可用度，前面那份成績單是參考）。想要的是批次、自動化或隱私保證，路線是自架：一份 docker-compose 加一個環境變數就能起步，照顧好憑證檔和反向代理就是一個長期服務，這也是官方現在最鼓勵的用法。要的是最穩、最跟得上平台變化的下載能力，老牌命令列工具仍是保險的選擇，我們先前寫過 yt-dlp 的腳本化用法；若是 B 站或抖音的單站需求，Bilibili 專用下載器和抖音無水印下載這類專文更貼身；跨站通用的網頁入口則可以併著 SnapAny 一起看，一個走自架引擎、一個走線上服務，剛好是同一個需求的兩種解法。

cobalt 最打動我的地方，在於它把「下載器」這件事做成了公共財：原始碼、映像檔、文件全部攤開，任何人都能把同一套引擎搬回家。它的限制也同樣清楚：服務可用度會漂、YouTube 要自己承擔貓鼠風險、維修節奏已經放慢。把它當一份可以自架的引擎來用，它今天仍然稱職；把它當一個理所當然永遠順暢的免費網站，遲早會在某次平台改版後失望。