Synology QuickConnect 大檔下載失敗？50GB 以上排查指南

Synology QuickConnect 大檔下載反覆失敗時，先把**一個現成檔案、預先打包的 ZIP，以及同一資料夾的「下載為 ZIP」**都存到同一顆本機磁碟，再透過區域網路重試失敗的項目。這樣能先區分打包、目的端儲存與遠端路徑，再決定是否更換硬體或服務。

交付 50GB 影片或 CAD 檔案時，真正需要的是收件者能開啟的完整檔案。分享頁能載入，或進度列快到終點，只表示部分流程正常。

Synology 遠端檔案傳輸有哪些路徑

File Station 會在收件者下載時持續從 NAS 提供檔案；QuickConnect 協助瀏覽器連到 NAS。先上傳再分享的服務則保留一份副本，NAS 離線後仍能供收件者下載。讓兩個據點的 Synology 保持一致是另一件事，相關做法可參考Synology NAS 跨辦公室同步指南。

Synology 服務支援矩陣包含 File Station 與分享連結。QuickConnect 並不是 SMB、AFP、FTP、NFS 或 WebDAV 網路磁碟的存取方式。

File Station 下載文件也區分個別檔案與 ZIP。Chrome 的「下載」可分別取得未壓縮的檔案，「下載為 .zip」則合併成壓縮檔；其他瀏覽器的「下載」可能將多檔打包成 ZIP。因此除了瀏覽器名稱，也要記下選用的下載選項。

兩個失敗案例提供的線索

在 2021 年 10 月的 QuickConnect 討論中，一位收件者表示 35GB 壓縮資料夾始終下載不完，也無法解壓縮。同一位發文者也提到，客戶透過資料夾分享連結接收影片時，曾遇到缺檔或損毀。後續直到 2024 年 12 月的回覆，仍未提供可重現的解法。這則案例適合用來設計測試，不能據此認定現在存在檔案大小限制或特定原因。

另一則 2022 年 7 月的快照還原討論有不同結果。DS920+ 使用者透過 Firefox 下載約 180GB 的還原資料夾，原本把結果存到 NAS 的另一個目錄；失敗後留下很大的部分下載檔。後來改存電腦內部磁碟，使用者回報下載成功。

第二個案例是本機還原流程，並非已確認的 QuickConnect 故障。但它提供了有用的做法：把儲存位置與傳輸路徑分開測試。成功重試並未證明原始原因究竟是儲存資源競爭、網路分享路徑，還是瀏覽器行為。

判斷直連或中繼

QuickConnect 可以選擇不同路徑。官方白皮書說明 LAN／WAN 偵測、打洞與中繼服務。分享連結可以先將瀏覽器導向可用的 LAN 或 WAN 位址，必要時才使用中繼。

這些型態是判斷線索。中繼不代表下載一定失敗，看似直連的位址也不保證目的端磁碟跟得上。每次測試都記錄路徑，因為下一次連線可能不同。對外提供診斷資料時，移除私人主機名稱、存取權杖與分享識別碼。

50GB 為什麼會失敗

1. 瀏覽器是看得見的故障點

記錄瀏覽器版本、錯誤與停止位置。若記憶體持續增加，可以比較另一個目前版本的瀏覽器，停用不必要的擴充套件，但維持相同檔案與儲存位置。不要把關閉端點防護當作一般排查步驟；若安全軟體攔截檔案，應檢查它的警示。

資料夾下載多了壓縮檔處理。事先打包可以用一個既有、內容不變的檔案，區分傳輸與下載時產生 ZIP 的流程。這需要額外來源空間與準備時間，也不會自動讓分享連結具備續傳能力。

2. 傳送端上傳才是上限

NAS 的 gigabit 連線描述的是區網，不是所在位置的網際網路上傳。以下是十進位 50GB 的純網路傳輸時間下限計算：秒數 = 50 × 10⁹ × 8 ÷（Mbps × 10⁶）。

打包、協定額外開銷、驗證與重試會增加時間。數小時的工作也有更長的時間可能遇到睡眠或連線變更。請量測工作期間的持續流量；可參考為什麼下載快、上傳卻慢。

3. 來源 NAS 正在忙碌

備份、索引、資料清理與剪輯工作可能爭用資源。問題發生時，在 Synology Resource Monitor觀察 CPU、記憶體、磁碟利用率與網路流量。保持檔案與收件端不變，比較空閒與忙碌時段。忙碌 NAS 的交付指南有更完整的說明。

4. 目的端無法持續寫入

先存到有足夠空間的內部磁碟，並另外預留解壓縮空間。NAS 網路分享、外接碟或同步資料夾會增加其他活動。本機磁碟成功，只能把範圍縮小到原本的儲存流程，不能直接認定 NAS 硬體故障。

5. 路徑無法順利續傳

瀏覽器的「重試」可能從頭開始。正式交付前，先用可捨棄的副本測試中斷。保持來源不變；即使介面看似沿用進度，也要確認最終檔案完整。

可重現的排查順序

先用不含敏感資料的小樣本，再以具代表性的交付內容重試可行的設定。除非該列明確要求改變，否則固定瀏覽器、路徑與目的端。

如果一般檔案和預先打包 ZIP 在本機都失敗，改遠端中繼路徑通常不是第一個有用的測試。先查來源可讀性、NAS 提供檔案的流程、瀏覽器及本機儲存。

保留經過時間、已傳位元組與完整錯誤。每次停在同一位元組位置，與每次經過相同時間就失敗，會引導不同的測試，但兩者都不足以單獨證明大小限制或逾時。

把續傳與完成驗證分開檢查

HTTP 的 Range 請求可取得檔案的一部分。相符的 206 Partial Content 回應搭配 Content-Range，能證明該次要求的區段已被提供。伺服器可以忽略 Range，單看 Accept-Ranges: bytes 也不能保證下一次請求成功。RFC 9110：範圍請求。

使用客戶端紀錄或瀏覽器網路工具時，查看實際下載回應，而非 HTML 分享頁。確認續傳起點，以及是否收到完整回應而從頭開始。不要在公開截圖中留下私人下載 URL。

續傳還必須對應同一份內容。HTTP 的 If-Range 機制在驗證標記不再相符時，允許回傳完整的替代內容。不要因為檔名一樣，就將一次產生的部分壓縮檔接上另一次回應的位元組。RFC 9110：If-Range。

完成後比較位元組數；可取得時，再比對密碼學雜湊值。壓縮檔也要執行完整性測試，並把解壓後的檔案清單與預定選取內容比較：結構完整的 ZIP 仍可能包錯檔案。可參考傳輸卡在 100% 時要檢查什麼。

直傳或暫存分享連結

實際工作量能完整傳完、驗證通過，也符合收件者期限時，就可以保留 QuickConnect。

反覆在端點間交付時，如果雙方能使用支援的客戶端，並需要傳輸專用的中斷恢復，WarpDirect是一種選擇。成功建立直連通道時不需雲端暫存；自動選路也可能使用加密暫存。若有禁止暫存的需求，交付前需確認所選傳輸確實使用直連路徑。這些端點如何安裝與監看，請見Synology 據點之間的檔案傳輸。

若收件者用瀏覽器，WarpShare可先上傳一次，再發分享連結。後續下載讀取的是暫存副本，不必反覆讀取來源 NAS。計費與上傳量、保留時間有關，重複下載沒有額外下載費；請依交付需求比較目前方案、存取控制與保留期限。

先做能區分故障環節的最小對照。經過驗證的預先打包檔，或不同儲存位置，可能就能完成眼前的交付，不必更換整套系統。

常見問題

QuickConnect 可以分享很大的 Synology 檔案嗎？

可以。QuickConnect 支援 File Station 與檔案分享連結。請用實際檔案、收件者的瀏覽器和連線路徑測試；小檔成功不代表數小時的交付也能完成。

為什麼個別檔案能下載，整個資料夾的 ZIP 卻失敗？

資料夾下載多了產生壓縮檔的步驟。維持相同瀏覽器、路徑與儲存位置，比較即時打包與事先建立、驗證過的 ZIP。後者成功時，應繼續查資料夾下載流程，但不能直接認定是某個 DSM 缺陷。

按下重試就能續傳 QuickConnect 下載嗎？

不一定。續傳需要該下載回應與客戶端共同支援。先用可捨棄的測試檔中斷下載，確認先前位元組是否重用，並驗證完成的檔案。重新產生的資料夾 ZIP 不一定能沿用舊的部分下載。

什麼時候改用直傳或先上傳再分享？

雙方能安裝客戶端、需要明確的中斷恢復流程時，可考慮端點傳輸。收件者只用瀏覽器，或 NAS 上傳後需要離線時，可先存一份到分享服務。QuickConnect 若能穩定完成實際工作量，就可以繼續使用。