Git Clone Works Through the Proxy, but Git LFS Fails

Trace Git LFS metadata and object downloads separately from the Git clone before changing an otherwise working proxy.

A clone can finish transferring Git objects while its LFS content is still missing. Git stores pointer files; the LFS client makes separate requests for the large objects.

In the affected checkout with Git LFS installed, inspect its endpoint and last failure:

git -C project lfs env
git -C project lfs logs last

Review the output locally; repository URLs and logs can expose identifying or authentication information. Identify the first failed stage:

  1. Contacting the LFS API.
  2. Obtaining the Batch API's download action.
  3. Reaching that action's download URL, which may use a different object-storage host and supplied headers.
  4. Transferring the object body.

Check repository LFS endpoint overrides as well as the actual URL. LFS has its own HTTP implementation, configuration and inherited proxy environment. For Git LFS 3.7.0, follow its proxy-selection order for the actual request URL. Reaching the ordinary Git HTTPS host does not exercise every later object route. An object-host authentication failure is also distinct from proxy 407.

When you intend the downloads, a separate fetch in a controlled repository can expose the failure without another clone:

git -C project lfs fetch

This transfers objects; it is not a read-only settings query. Confirm the required content is available afterward. A small pointer remaining in a partial checkout is not the large file, and an earlier successful Git command cannot establish that the LFS transfer completed.

Tënë sô zo