Synology QuickConnect で 50GB 超のダウンロードが失敗する場合

Synology QuickConnect の大容量ダウンロードが繰り返し失敗する場合は、**既存の単一ファイル、事前作成した ZIP、同じフォルダーの「ZIP としてダウンロード」**を、同じローカルディスクへ保存して比較してください。その後、失敗した条件を LAN 内でも試します。ハードウェアやサービスを変更する前に、圧縮処理、保存先、遠隔経路を切り分けられます。

50GB の動画や CAD データを渡すときに必要なのは、相手が開ける完全なファイルです。共有ページが開くことや、進捗表示が完了に近いことだけでは、受け渡し全体の成功は確認できません。

Synology の遠隔ファイル転送で変わる経路

File Station は、受信者のダウンロード中に NAS からファイルを提供し続けます。QuickConnect はブラウザーがその NAS に接続するための仕組みです。一度アップロードして共有するサービスでは別のコピーを保持するため、NAS がオフラインになった後も受信者は取得できます。2 拠点の Synology を同じ状態に保つのは別の作業です。その方法はオフィス間の Synology NAS 同期ガイドで比べています。

Synology の対応サービス一覧には File Station と共有リンクが含まれます。QuickConnect は SMB、AFP、FTP、NFS、WebDAV のネットワークドライブ接続方法ではありません。

File Station のダウンロード文書では、個別ファイルと ZIP 選択を区別しています。Chrome の Download では個別ファイルを非圧縮で取得でき、Download as .zip ではまとめたアーカイブを作ります。他のブラウザーの Download は複数ファイルを ZIP にまとめる場合があります。ブラウザー名だけでなく、選んだ操作も記録してください。

二つの障害報告から分かること

2021 年 10 月の QuickConnect の投稿では、35GB の圧縮フォルダーを最後まで取得できず、展開もできないと報告されています。同じ投稿者は、フォルダー共有リンクで渡した動画に欠落や破損があると顧客から言われたとも説明しています。2024 年 12 月までの返信には、再現可能な解決手順がありません。この報告は比較テストの参考になりますが、現在のファイルサイズ制限や原因を確定するものではありません。

一方、2022 年 7 月のスナップショット復元の投稿には成功した変更が記録されています。DS920+ の所有者が、Firefox で約 180GB の復元フォルダーを NAS 上の別のディレクトリーへダウンロードしようとしていました。失敗時には大きな部分ダウンロードが残りましたが、保存先を PC の内蔵ドライブへ変えると完了したと報告しています。

後者はローカルの復元作業であり、QuickConnect の障害と確認された事例ではありません。ただし、保存先と転送経路を別々に変えるという診断方法は役立ちます。再試行の成功だけでは、原因がストレージの競合、ネットワーク共有、ブラウザーのどれだったかまでは分かりません。

直接接続か中継かを確認する

QuickConnect は複数の経路を使います。公式ホワイトペーパーは、LAN/WAN の検出、ホールパンチング、中継サービスを説明しています。共有リンクでは、中継が必要になる前に、利用可能な LAN または WAN アドレスへブラウザーを転送できます。

これは経路を判断する手掛かりです。中継だから必ず失敗するわけではなく、直接接続に見える URL でも保存先ディスクの性能は保証されません。次の接続で経路が変わる可能性があるため、各テストで記録します。診断情報を公開する際は、非公開のホスト名、アクセストークン、共有 ID を取り除いてください。

50GB が失敗する主な理由

1. ブラウザーに障害が表れる

ブラウザーのバージョン、エラー、停止位置を記録します。メモリー使用量が増え続けるなら、別の現行ブラウザーで不要な拡張機能を無効にし、同じファイルと保存先を比較します。一般的な診断として端末の保護機能を停止するのではなく、ファイルのブロックが報告されている場合はその警告を確認してください。

フォルダー取得にはアーカイブ処理が加わります。事前に ZIP を作れば、内容が変わらない既存ファイルの転送と、取得中にアーカイブを生成する処理を分けて試せます。追加の保存領域と準備時間は必要で、リンクが自動的に再開対応になるわけではありません。

2. 送信側の上り回線が上限になる

NAS のギガビット接続は LAN の仕様であり、設置場所のインターネット上り速度ではありません。以下は十進の 50GB に対するネットワーク転送だけの下限計算です。秒数 = 50 × 10⁹ × 8 ÷（Mbps × 10⁶）。

圧縮、プロトコルのオーバーヘッド、検証、再試行には追加時間がかかります。数時間の処理では、スリープや接続変更に遭う時間幅も長くなります。ジョブ中の継続的な通信量を測ってください。ダウンロードが速くてもアップロードが遅い理由も参考になります。

3. 送信元 NAS がほかの処理で忙しい

バックアップ、インデックス作成、スクラブ、編集作業はリソースを奪い合う場合があります。障害が出ている間に Synology Resource Monitorで CPU、メモリー、ディスク使用率、ネットワーク通信量を確認します。ファイルと受信側を固定し、負荷の低い時間帯と高い時間帯を比較してください。高負荷の NAS からファイルを渡すガイドで詳しく説明しています。

4. 保存先が書き込みに追いつかない

十分な空き領域がある内蔵ディスクに保存し、展開用の領域も別に確保します。NAS の共有、外付けドライブ、同期フォルダーには追加の処理があります。内蔵ディスクで成功すれば元の保存処理へ範囲を絞れますが、NAS のハードウェア故障とは断定できません。

5. 再開がうまく働かない

ブラウザーの再試行は最初からやり直す場合があります。納期前に不要なコピーで中断を試してください。送信元を変えず、進捗を引き継いだように見えても完成したファイルを検証します。

再現可能な診断手順

まず機密情報を含まない小さなサンプルを使い、有望な設定を実際の受け渡しに近い負荷で再確認します。その行で変更する項目以外は、ブラウザー、経路、保存先を固定してください。

通常のファイルと事前作成 ZIP の両方が LAN 内でも失敗するなら、遠隔中継の変更を最初に試す理由は弱くなります。元ファイルの読み取り、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 拠点間でのエンドポイントの導入と監視は、Synology 拠点間のファイル転送で説明しています。

ブラウザーで受け取る相手には、WarpShareへ一度アップロードしてリンクを渡せます。以降のダウンロードはそのコピーを読み、元の NAS を繰り返し読みません。料金にはアップロード量と保持期間が関係し、繰り返しのダウンロードに追加のダウンロード料金はかかりません。現在のプラン、アクセス制御、保持期間を受け渡しの要件と比較してください。

障害の段階を分けられる最小の比較から始めましょう。検証済みの事前作成アーカイブや保存先の変更だけで、システム全体を変えずに今回の受け渡しを完了できるかもしれません。

よくある質問

QuickConnect で大容量ファイルを共有できますか？

はい。QuickConnect は File Station とファイル共有リンクに対応しています。実際のファイル、受信者のブラウザー、接続経路で確認してください。小さなファイルの成功だけでは、数時間の受け渡しを検証できません。

個別ファイルは取得できるのに、フォルダーの ZIP が失敗するのはなぜですか？

フォルダーのダウンロードには、アーカイブを生成する処理が加わります。同じブラウザー、経路、保存先で、事前に作成・検証した ZIP と比較してください。事前作成した ZIP だけ成功するならフォルダー取得の処理を調べますが、特定の DSM 不具合が原因とは断定できません。

再試行をクリックすれば QuickConnect のダウンロードを再開できますか？

必ずしも再開できません。その応答とクライアントの両方が再開に対応する必要があります。不要なテスト用コピーで中断し、取得済みデータが再利用されるか、完成したファイルが正しいかを確認します。新しく生成したフォルダー ZIP に古い部分ダウンロードを流用できるとは限りません。

端末間転送や、一度アップロードして共有する方式はいつ使いますか？

双方がクライアントを導入でき、中断からの明確な復旧手順が必要なら端末間転送が候補です。受信者がブラウザーを使う場合や、アップロード後に NAS をオフラインにしたい場合は共有サービスにコピーを置きます。実際の負荷で安定して完了するなら QuickConnect を継続できます。