Downloading Files Through a Proxy: Resuming with HTTP Range After a Connection Drop

When downloading files through a proxy, the connection may drop before all the data has been received. If the download tool always starts over, users must transfer data they already have, increasing download time and generating unnecessary traffic.

HTTP Range allows you to request part of a resource instead of its entire contents. However, to resume a download safely, you must confirm that the server actually returns the correct data range and that the source file has not changed. This article explains how to perform checks, handle responses, and organize a download resumption workflow when a proxy connection drops.

How Does HTTP Range Help Resume Downloads?

In a typical download, the client requests the entire file. If the connection is interrupted, the local file contains only the data successfully received and written. Rather than discarding that data, the client can send a new request for only the missing portion.

For byte ranges, the Range header specifies the starting position and may include an ending position. When resuming a download through the end of a resource, the request usually only needs to specify the starting byte.

This position is measured from the beginning of the file and is zero-indexed. If the local file already contains a contiguous segment of data, the starting position for the next request equals the size of the saved segment in bytes.

A crucial requirement is that the source file remain unchanged between download attempts. If the content has changed, combining the beginning of an old version with the remainder of a new version will produce an invalid file, even if its final size appears correct.

How Does a Proxy Affect Download Resumption?

A proxy is an intermediary that forwards traffic. When the proxy connection drops, the current transfer session may end, but this does not automatically prevent the download from being resumed. The client can open a new connection and request the missing data.

This capability depends on the entire connection path: the server providing the file, the proxy, and the download software. The server must handle Range requests appropriately; the proxy must forward them correctly; and the download software must check the response before appending data.

Distinguishing Forwarding Proxies from TLS-Terminating Proxies

With HTTPS over a standard CONNECT tunnel, the proxy does not directly read or modify HTTP headers inside the TLS connection. In this case, Range support primarily depends on the destination server and the client.

If the proxy terminates TLS or processes HTTP content, it can affect headers, caching, or the resource representation. Therefore, you should test through the same proxy route you will use for the download, rather than testing only a direct connection.

How to Check Whether a Server Supports Resuming Downloads

Check Headers with a HEAD Request

A HEAD request lets you inspect headers without explicitly downloading the response body. With curl, you can use the following command template, replacing the example addresses with your actual details:

curl --head --location --proxy http://proxy.example:PORT https://download.example/archive.zip

The Accept-Ranges: bytes header indicates that the server advertises support for byte-range retrieval. If the response contains Accept-Ranges: none, the server is indicating that it does not support ranges for that resource.

However, the absence of Accept-Ranges is not enough to conclude that a download cannot be resumed. Some servers handle Range requests without advertising this capability. HEAD may also be handled differently from GET, so this is only an initial check.

Send a GET Request for a Small Range

A practical test is to request a very short segment of the file and inspect the response. The example below requests the first byte and saves the headers and body to separate files:

curl --location --proxy http://proxy.example:PORT --range 0-0 --dump-header range-headers.txt --output range-probe.bin https://download.example/archive.zip

The server may ignore Range and return the entire contents. You should therefore run this test in an environment with appropriate time or traffic limits, while monitoring the response so you can stop it if necessary.

If redirects occur, inspect the headers of the final response containing the file data. Do not draw conclusions from the headers of an intermediate redirect response.

Understanding Important HTTP Range Responses

206 Partial Content: Partial Content Returned

The 206 Partial Content status code indicates that the server is returning partial content. For a single-range request, the Content-Range header describes the byte range returned and may indicate the resource's total size.

Before appending data, you must check that the starting position in Content-Range matches the requested resume offset. Seeing a 206 status alone is not enough to ensure that the data can be combined correctly.

200 OK: Do Not Automatically Append

If you send Range but receive 200 OK, the response may contain the entire resource. This commonly happens because the server ignores Range or the version validation condition no longer matches.

Do not append this response body directly to the incomplete file. Stop to investigate or restart the download in a new file. Otherwise, the file may contain a duplicated beginning.

416 Range Not Satisfiable: Recheck the Current State

A 416 Range Not Satisfiable response indicates that the requested range cannot be fulfilled. This can happen when the starting position falls outside the current resource or the local file already contains all the data.

Do not automatically treat this as a successful download. Check the size reported by the server in Content-Range, if available, compare versions, and verify integrity before drawing a conclusion.

A Workflow for Resuming Downloads After a Proxy Connection Drops

Save a Temporary File and Version Information

During the download, use a temporary filename so other applications do not mistake the incomplete file for a complete one. Also save the URL, ETag, Last-Modified, and total size if the server provides them.

An ETag helps identify a resource version. To use it with If-Range, you need a strong ETag; do not use a weak ETag with the W/ prefix. A modification timestamp can also be used under the appropriate HTTP conditions, but it is generally not the preferred choice when a strong ETag is available.

Determine How Much Data Was Successfully Written

After the connection drops, close or synchronize the file before checking its size. The resume offset must be based on the number of bytes actually saved to disk, not the number of bytes the program has received into memory.

This approach works for sequential downloads, where the temporary file contains a contiguous segment from the beginning of the resource. For multithreaded downloads, the file size does not prove that every region contains data; you must track completed segments separately.

Send Range with an If-Range Condition

In the new request, Range specifies the resume position, while If-Range carries the validator for the version already downloaded. If the version still matches, the server can return the requested data segment.

If the version has changed, the server may return the entire resource instead of the missing portion. The client must recognize this response and avoid combining it with the old data.

Append Only After Validating the Response

• Check the status code and Content-Range before opening the file in append mode.
• Compare the starting position with the size of the data already saved.
• Check version information and the content representation.
• Handle error responses, login pages, or non-file content separately.
• If another interruption occurs, recalculate the resume offset from the actual saved data.

Resuming File Downloads Through a Proxy with curl

curl supports resuming a download based on the size of an existing output file using the --continue-at - option. A basic command template is:

curl --location --proxy http://proxy.example:PORT --continue-at - --output archive.zip.part https://download.example/archive.zip

If the connection drops, you can rerun the command with the same output file. curl will determine the resume offset from the local file and request the corresponding data.

However, this command does not by itself guarantee that the source file has not changed. For important data, you need to manage version information, If-Range conditions, and post-download verification. Do not use shell append redirection to combine HTTP responses without checking them.

If the proxy requires authentication, use an appropriate credential management mechanism. Avoid exposing passwords in command history, logs, or process listings that other people may be able to read.

Common Issues That Prevent Downloads from Resuming Successfully

An Expired URL or Login Session

Signed download links and login sessions may expire during a download. When an authentication error occurs, you need to renew access. If you must obtain a new URL, confirm that it still points to the same resource version before resuming.

A Changed Content Representation

HTTP Range applies to the representation sent by the server. If the content is compressed or transformed differently between download attempts, byte positions may no longer be compatible.

Keep content negotiation headers consistent. For binary files that need resumable downloads, you can request Accept-Encoding: identity and check the actual Content-Encoding. Do not use the size of decompressed data as the resume offset for a compressed representation.

Switching Proxies Changes the Response

Switching proxies does not necessarily prevent download resumption, but it may affect authentication, server selection, or the content received. After changing the connection route, you must still check the version and the returned range.

Verify Completion Before Using the File

A file with the expected size does not necessarily contain the correct data. After the download finishes, compare its hash with the value published by a trusted distribution source, if available. For digitally signed software packages, verify the signature according to the publisher's instructions.

An ETag is not necessarily a content hash and should not automatically be used as a checksum. Rename the temporary file to its final name only after completing the appropriate checks.

Downloading files through a proxy using HTTP Range works effectively when three conditions are met: the local data segment is identified accurately, the server returns the correct range, and the resource remains the same version. Following all these steps helps you resume downloads after connection failures without compromising data integrity.