Downloading large operating system ISOs, virtual machine images, database dumps, or media archives through the Linux terminal is a routine task for developers and system administrators. However, transient Wi-Fi drops, VPN timeouts, accidental terminal closures, or system sleep states can abruptly sever an active HTTP or FTP connection. When a multi-gigabyte transfer fails at 90% completion, starting the download from the beginning is frustrating and wastes significant network bandwidth.
Fortunately, standard Linux networking tools support partial byte-range requests defined by the HTTP/1.1 specification. Using the native command-line utilities wget and curl, you can instruct your system to inspect the partially downloaded file on your disk and resume the transfer from the exact byte where it broke off. This guide explains how to resume interrupted downloads with both tools and how to verify downloaded file integrity.
How HTTP Range Requests Enable Download Resumption
Before attempting to resume a broken transfer, it helps to understand how the process works behind the scenes:
- When you initiate a resume command, your client reads the local file size (e.g.
4,294,967,296 bytes). - The client sends an HTTP
Range: bytes=4294967296-header to the hosting web server. - If the remote server supports byte-range requests, it returns an HTTP 206 Partial Content response code and begins streaming data starting from that byte offset.
- If the remote server does not support byte ranges, it responds with an HTTP 200 OK status and restarts the entire download from byte zero, overwriting or appending to your local file.
Method 1: Resuming Downloads with wget
The wget utility is installed by default on almost all Linux distributions (including Ubuntu, Debian, Fedora, and Arch). It includes a dedicated resume flag designed specifically for recovering broken transfers.
The -c (Continue) Option
To continue a broken download, navigate to the directory containing your incomplete file and execute wget with the -c (or --continue) flag pointing to the original URL:
wget -c https://releases.ubuntu.com/noble/ubuntu-24.04-desktop-amd64.iso
wget scans your working directory, detects the existing partial file matching that filename, checks its current byte size, and requests the remainder of the payload from the server. The terminal progress bar shows a series of plus signs (+++++) or starts directly at the completed percentage, indicating that existing bytes were preserved.
Automating Automatic Retries with wget
If you are on an unstable network connection prone to repeated disconnects, you can configure wget to retry the download automatically whenever the connection drops:
wget -c --tries=10 --timeout=15 --waitretry=5 https://example.com/large-archive.tar.gz
This command instructs wget to:
--tries=10: Retry up to 10 times if a connection failure occurs.--timeout=15: Wait 15 seconds for server responses before considering a read stalled.--waitretry=5: Pause for 5 seconds between consecutive reconnection attempts.
Method 2: Resuming Downloads with curl
While curl is primarily designed for data transfer and API testing rather than background file retrieval, it fully supports range-based resumption using the uppercase -C flag.
The -C – (Auto-Offset) Option
To resume a download with curl, provide the -C - argument alongside the remote file flag (-O) or output destination flag (-o):
curl -C - -O https://example.com/database-backup.sql.gz
The hyphen immediately following -C tells curl to automatically check the size of the local target file and use that number as the starting byte offset for the server request. If you omit the hyphen and specify a number instead (e.g. -C 1048576), curl resumes starting strictly at that manual byte offset.
Maintaining Remote Timestamps and Showing Progress
To view an interactive progress bar while saving the file with its original server timestamp, combine -C - with -# (progress meter) and -R (remote time):
curl -C - -# -R -O https://example.com/dataset.zip
How to Verify if a Server Supports Range Requests
Not all web servers or content distribution networks allow byte-range downloads. Dynamic script endpoints, temporary cloud download links, and legacy proxy services often disallow range headers. You can test server compatibility before downloading by inspecting the HTTP headers with curl -I:
curl -I https://releases.ubuntu.com/noble/ubuntu-24.04-desktop-amd64.iso
Look for the following response header in the terminal output:
Accept-Ranges: bytes
If Accept-Ranges: bytes is present, the server fully supports byte-level resumption. If the header shows Accept-Ranges: none or the header is absent, resuming is not supported, and any interrupted transfer must restart from the beginning.
Verifying File Integrity After Resuming
Whenever a download experiences an interruption and resumption, verifying the completed file’s cryptographic checksum guarantees that no packets were corrupted during the reconnect sequence.
Run the sha256sum command against your downloaded archive:
sha256sum ubuntu-24.04-desktop-amd64.iso
Compare the resulting 64-character hash against the official checksum published by the file author. If the hashes match exactly, your resumed file is byte-for-byte identical to the original server file.
Knowing how to deploy wget -c and curl -C - saves time, eliminates wasted download quotas, and ensures reliable file retrieval across unpredictable network connections.