CloudSaver 自架搜尋工具，把雲端硬碟分享轉存進自己帳號

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

想在雲端硬碟的分享連結裡找到想看的東西，常見的做法是翻 Telegram 頻道，一則一則往回滑。CloudSaver 把這件事程式化：它定期去爬你指定的 Telegram 公開頻道，把訊息裡出現過的分享連結整理成搜尋得到的清單，找到目標之後按下轉存（把分享連結裡的檔案存進自己的雲端硬碟帳號），檔案就進你的 115 或夸克帳號。整套服務可以裝在自己的機器上，GitHub 倉庫以 MIT 授權公開，累積了超過 9,300 顆星。

先把結論說完。這套工具值得自架的條件很明確：你有 115 或夸克的帳號、你接受把帳號 Cookie 交給自己伺服器上的這支程式、而且你分得清自己裝的是哪一個 CloudSaver。最後一點最容易被忽略，GitHub 上那個 9,316 顆星的倉庫，程式碼停在 2025 年 4 月的 0.2.5 版；持續修 bug、加功能的版本，只以閉源的 Docker 鏡像發佈。接下來是我把開源版原始碼抓下來、在本機跑過一輪之後看到的東西。

九千顆星的倉庫，裝起來並不是最新版

CloudSaver 的開發時間線，從 git 歷史看得很清楚。倉庫 2024 年 12 月建立，125 個 commit 裡，最後一次更動程式碼是 2025 年 4 月 22 日，內容是把寫在程式碼裡的三個預設 Telegram 頻道清單移除。從那天起將近一年，倉庫只剩下 README 與交流群連結的更新，最後一次落在 2026 年 4 月 20 日。根目錄 package.json 的版本號停在 0.2.5。

對照之下，Docker Hub 上的官方鏡像一直活著：2026 年 4 月有 0.8.3，6 月 0.8.4，7 月接連推出 0.8.5 到 0.8.7，8 月 14 日是 0.9.0，8 月 27 日推了 0.9.1，鏡像累積拉取次數已經超過 91 萬。README 頂端的官方宣告也寫得明白：新版本內容不包含在開源倉庫，倉庫停留在 0.2.5，需要新功能請改用 Docker 鏡像。至於原因，官方只給了由於某些原因幾個字，沒有進一步說明。

問題回報管道倒是有人在顧。2026 年 7 月有人回報 123 雲盤轉存失效，作者的回覆是更新到當時最新的 0.8.6 就修好了；5 月有人回報搜尋過程中切換頁面會被強制跳回，這個問題在 8 月關閉。需求面的討論也還在跑，9 月的 issue 有人提出支援移動雲盤轉存，8 月也有人想要 Telegram 機器人搜尋入口，開著待處理的 issue 約 49 個。維護是活的，只是活在鏡像裡。

這對使用者代表兩種各有代價的選擇。照 README 的開發環境流程把原始碼抓下來跑，你跑的是將近一年半前的程式碼，好處是每一行都看得到；拉 jiangrui1994/cloudsaver:latest 鏡像，你得到持續維護的 0.9.1，代價是它沒有對應的原始碼可以審計。要原始碼透明還是要持續更新，這是部署 CloudSaver 的第一個決策。

我在本機跑開源版看到的現況

Node 20 加 pnpm，裝完依賴、起後端與前端，不需要 Docker 就能跑。整個過程沒有要求任何雲端硬碟帳號，登入頁是一張毛玻璃風格的卡片，註冊帳號時要填註冊碼：9527 開普通帳號，230713 開管理員。這兩組數字就寫在資料庫初始化的程式碼裡，對全世界公開。

Pin

另一個現況：裝好之後搜尋是空的，而且這是正常的。2025 年 4 月那個移除預設頻道的更動之後，新部署的 CloudSaver 起手時沒有任何內容來源，頻道設定是空清單。我實測搜尋介面，API 回應是成功狀態帶一個空陣列。想要有東西可搜，頻道要自己找、自己填，官方把這一步整個留給使用者。這個設計與工具的性質有關，來源清單由專案官方預載，法律責任就落在專案身上，留白則移轉給每個自架者，後面風險段會再回到這一點。

還有一個現況與台灣的連線環境有關。榜單功能從豆瓣的公開介面拿片名與評分都正常，但海報圖的圖床從台灣連不上，頁面呈現一片破圖。資料通、圖不通，這是台灣 IP 直連的實際結果。

Pin

搜尋的原料，是別人在 Telegram 貼過的連結

CloudSaver 搜尋的對象不是雲端硬碟本身，而是 Telegram 公開頻道訊息裡出現過的分享連結。後端的做法是帶著一組偽裝成桌機瀏覽器的標頭，去抓頻道的網頁版頁面，拿到 HTML 後解析訊息內容，再用一組網域比對規則抽出分享連結。比對清單涵蓋 115、anxia、夸克、百度、天翼、阿里雲盤、123 與移動雲盤的網域，所以搜尋結果裡看得到各家的連結。

我拿 Telegram 官方頻道當測試對象驗證這條路：後端 log 顯示抓到了頻道頁面、解析出 20 則訊息、抽出 0 個分享連結。官方頻道本來就沒有人貼雲端硬碟連結，結果符合預期，但整條抓取與解析流程從台灣直連就通，不需要任何代理。程式裡留了 HTTP 代理選項，預設指向 127.0.0.1:7890 並且關閉，那是給連不上 Telegram 的網路環境用的。

這種以頻道為單位的設計，也決定了搜尋品質的上限：工具本身不做任何內容驗證或排行，結果新不新、全不全，完全看你訂了哪些頻道、頻道管理員貼得勤不勤。頻道清單既是內容來源，也是品質與風險的來源，訂得越多搜得到越多，但跳出來的內容性質也越難自己把關。

榜單功能的原料則來自豆瓣。後端同樣以偽裝的瀏覽器身分去請求豆瓣的公開資料介面，拿回熱門片單、片名與評分。這部分沒有帳號概念，純粹讀公開資料，我在實跑時看到的行為與原始碼一致。

這裡可以順帶釐清 CloudSaver 的定位。同樣是自架的雲端硬碟周邊工具，AList 做的是把多個雲端硬碟掛載成統一介面，CloudSaver 做的是把散落的分享連結變成搜尋庫，兩者解決的任務不同。而如果你要的只是下載特定平臺的內容，現成的下載工具不需要動到雲端硬碟帳號；如果你手上已有一批分享連結想要確認還能不能用，也有專門的連結檢查工具可以處理。CloudSaver 的獨特位置在搜尋這一步，代價則是它後面必須接你的帳號。

搜尋結果的呈現也有幾個從原始碼與實跑看得到的細節。每筆結果會標記它來自哪個頻道，頻道頭像與訊息圖片預設經由自架後端代理載入（搜尋頁另外提供切換成直連的模式），圖片流量預設走你自己的伺服器；前端同時準備了桌機與手機兩套介面元件，回應式設計不是行銷話術，程式碼裡真的分開維護。多使用者系統把帳號分成管理員與普通兩種角色，用哪組註冊碼決定身分，我實測用管理員碼註冊的帳號可以直接進系統設定。

轉存這一步，等於把帳號鑰匙交給這支程式

轉存的實際流程是：你在設定頁把 115 或夸克的 Cookie 貼進對應欄位，之後每次轉存，都由後端帶著你的 Cookie 向雲端硬碟的介面發請求。官方展示的操作動線，是在搜尋結果點進資源詳情、勾選要的檔案、挑一個自己帳號裡的目標資料夾，再按轉存；資料夾清單同樣是後端用你的 Cookie 去雲端硬碟即時拉的。115 這邊有個值得知道的細節，程式碼裡的請求標頭把來源身分設定成 115 的微信小程式頁面，也就是說對 115 伺服器而言，這些請求看起來像來自官方小程式的使用者。我沒有填入真實帳號去操作轉存，這一段是讀原始碼與官方文件得到的結論；轉存實際的成功率與速度，需要真實帳號才驗得了。

Pin

Cookie 存放的位置，是 SQLite 資料庫裡的使用者設定表，cloud115Cookie 與 quarkCookie 兩個欄位，明文儲存，資料庫就是 data 目錄下的一個檔案。把憑證放在自己機器的資料庫裡是自架工具的常見做法，不算特殊缺陷，但它直接決定兩條底線：這台機器不能暴露在公網上任人存取，以及備份這個資料庫檔案等於備份你的帳號身分。

文件與程式碼之間還有一個落差要指出。README 的功能表寫支援 115、夸克、天翼、123 四家轉存，但開源版程式碼裡的轉存服務只有 115 與夸克兩個，API 路由也只有這兩家。天翼與 123 的轉存存在於 Docker 鏡像版，不在你能審計的原始碼裡。前面提過的連結比對規則認得七種網域，所以開源版的搜尋結果看得到天翼或 123 的分享連結，只是選了也轉不進去。

預設裝好之後，這些事要自己補

安全預設是這套工具最需要使用者自己動手的部分。

註冊碼排第一個，因為它完全沒有保密性。9527 與 230713 寫在開源程式碼裡，也顯示在設定頁上，任何讀過原始碼的人都知道。裝好後的第一個動作，應該是進設定頁把兩組註冊碼換成自己的，否則任何知道預設值的人都能在你的實例開帳號，用管理員碼開的還是管理員。

登入憑證的簽章是另一個洞。這套程式用 JWT 維持登入狀態，token 有效期六小時，密碼在資料庫裡有做雜湊處理，這兩點是及格的；但如果部署時不設定自己的密鑰環境變數，程式會退回一組寫死在原始碼裡的預設字串來簽發 token。我本機測試時完全沒設這個變數，註冊與登入照樣運作，表示那組公開的預設密鑰確實在作用，懂得利用的人可以偽造任意帳號的身分。部署時換成自己的長隨機字串，是一行設定的事。

Cookie 的網路層防護同樣不能省。明文儲存的問題靠不暴露來補：把服務綁在 localhost 或內網，要對外就先過一層帶認證的反向代理。CloudSaver 有多使用者系統，理論上可以開放親友註冊共用同一個實例，但每個使用者都會把自己的雲端硬碟 Cookie 存進你的資料庫，你等於成為他人的憑證託管者。官方 README 自己也用強烈的措辭反對使用別人部署的實例，理由就是 Cookie 等同帳號密碼，這個警告反向閱讀也成立。

還有一條對外連線要記錄下來：鳴謝頁面的贊助名單會向作者方維護的檔案伺服器請求一份 JSON，用的是明文 HTTP。這個請求不帶你的任何憑證，影響有限，但它代表實例並不是完全只連 Telegram 與雲端硬碟，架防火牆規則時別忘了這一條。

從台灣的連線與帳號條件看落差

連線條件反而是台灣這端佔便宜的地方。Telegram 頻道頁從台灣直連就通，前述實測沒有用到代理；程式裡的代理選項是為連不上 Telegram 的環境準備的，台灣一般用不到。豆瓣的資料介面也通，只有圖床不通。

帳號端就沒有這麼樂觀。115 與夸克都是中國大陸的雲端硬碟服務，夸克背後是阿里巴巴體系，115 則是經營多年的獨立服務，兩家的主要使用族群都在對岸。台灣使用者能不能註冊、儲值、長期維持帳號，是工具之外的前置條件，且平台風控政策會變動，這部分我沒有驗證，無法給出保證。開源版能轉存的也只有這兩家，帳號問題等於直接卡住可用性，先確認帳號再考慮部署，順序不要顛倒。

介面語言是簡體中文，沒有提供切換選項。功能上都看得懂，但對繁中讀者來說，設定頁的文案與介面用語需要習慣一下。

風險畫在哪裡：內容、帳號與法律

CloudSaver 本身不儲存任何資源檔，它做的是索引別人貼出來的連結，然後用你的帳號搬檔案。這樣的架構把兩種風險都留在使用者這端。

內容端，資源頻道裡流通的分享連結有相當比例是版權影音，把這類檔案轉存進自己帳號，版權責任由帳號主人承擔，這條線在各地著作權法下的樣貌不同，但都不因為工具是自架的就消失。帳號端，雲端硬碟平台對批次轉存行為有自己的風控規則，帳號被限速或停用的風險同樣由帳號主人承擔。官方在 2025 年 4 月把預設頻道來源移除，時間點與降低專案本身法律暴露的方向一致，這是從時間線做出的推論，官方並沒有說明原因。

工具鏈的上下游可以對照著看：下載類工具把風險留在本機與頻寬，連結檢查工具只讀不寫、風險最低，CloudSaver 這類轉存工具則直接操作你的雲端帳號，風險層級明顯高一階。使用前想清楚自己要的是搜尋的便利，還是帳號的安穩，兩者不見得能兼得。

誰適合自架，誰不必碰

適合的輪廓：已經有 115 或夸克帳號、想把自己的資源搜尋流程自動化、有一台能常年開著的機器，而且願意花半小時把註冊碼、密鑰與網路暴露這三件事處理好的人。對這群人來說，CloudSaver 把翻頻道這件體力活變成一個搜尋框，是實際有用的自動化。

不必碰的情況也很多。沒有這兩家帳號的人，開源版的轉存功能等於沒有；不想讓雲端硬碟 Cookie 離開瀏覽器的人，這套工具的工作方式與你的底線直接衝突；想把實例開放給不特定陌生人的人，前面說過，你會變成別人的憑證保管者，這是 README 明確反對的用法。

部署的概念流程不複雜：準備一台能跑 Docker 的機器，拉官方鏡像並掛載 data 與 config 兩個目錄，開 8008 連接埠，接著進設定頁完成註冊碼更改、密鑰設定與頻道 Cookie 填入。data 目錄放的是 SQLite 資料庫，config 目錄放環境設定，兩個目錄掛出來之後，升級就是換鏡像標籤再重開容器，帳號與設定會留下來。官方另外提供 test 標籤（收最新修正但穩定性較低）與 GitHub 容器登錄的鏡像位址，下載來源有兩個可以選。更具體的指令與參數，README 的部署段落寫得夠詳細，這裡只補決策層的提醒。

鏡像的打包方式從原始碼也看得出骨架：單一容器裡用 Nginx 同時伺服前端靜態檔與後端 API，對外只開 8008 一個連接埠，請求再轉給容器內部的後端行程。後端有實作每個 IP 的請求速率限制，以記憶體計數、每分鐘為視窗，能擋基本的掃描與濫用。另外開源版的依賴清單裡有兩個其實沒有被任何程式碼引用的套件（socket.io 與 rss-parser），對功能沒有影響，這種宣告了卻沒用到的依賴，通常是舊功能拆除後留下的殘跡，也再次提醒這份原始碼已經很久沒有人整理。

授權與專案狀態

授權是 MIT，LICENSE 檔案在倉庫根目錄，商用與修改的法律空間在常見開源授權裡屬於寬鬆的一類。專案狀態整理如下，數字截至 2026 年 9 月，會隨時間變動：倉庫 2024 年 12 月建立，9,316 顆星、781 次 fork；原始碼最後更動 2025 年 4 月 22 日；README 最後更新 2026 年 4 月 20 日；Docker 鏡像最新穩定版 0.9.1，2026 年 8 月 27 日推上 Docker Hub；GitHub 上待處理的 issue 有 48 個，作者仍會回報。

文件與支援管道則多半移出了 GitHub：更新日誌與常見問題放在語雀文件站，進入要填一組通關密語，而這組密語就直接寫在 README 上；官方交流圈以 Telegram 群組與 QQ 群為主。想追版本變化的讀者，看 Docker Hub 的標籤日期比看 git log 有用得多。

名義上開源、實際上以閉源鏡像持續營運，這種模式要押多少信任，每個自架者有自己的答案。我的建議是把它當成一套需要自己看管的自架服務來評估：先確認帳號與內容風險你能接受，再確認安全預設你補得完，最後才輪到搜尋功能好不好用。CloudSaver 把翻頻道找連結這件事自動化得很完整，但它同時要求你交出帳號 Cookie、自己張羅內容來源，並在開源殼與閉源本體之間做選擇，這些交換先看清楚再裝。