Git LFS把大文件内容存放在独立对象服务中，Git仓库只保存指针。于是会出现一种典型现象：git clone成功，检出时却卡在“Downloading LFS objects”。这通常说明仓库元数据链路已通，但LFS批处理API、对象存储或下载认证仍有问题。
一、Git与LFS可能走两条路径
| 对象 | 常见协议 | 重点检查 |
|---|---|---|
| Git仓库 | HTTPS或SSH | Git代理、SSH与仓库凭据 |
| LFS批处理API | 通常HTTPS | LFS URL、认证与407 |
| LFS对象文件 | HTTPS或对象存储地址 | 重定向、签名URL、超时和校验 |
二、先查看LFS实际环境
记录Git与Git LFS版本，使用LFS环境诊断查看端点与配置，但分享前删除用户名、令牌和内部主机。仓库可能通过.lfsconfig、Git配置或服务端响应决定LFS URL，不应只根据git remote -v推断。
三、SSH仓库为何还会看到HTTPS
SSH可用于Git对象和引用传输，LFS大文件常通过独立HTTPS API与存储下载。因而HTTP代理仍可能影响LFS。反过来，设置Git HTTP代理也不会修复SSH本身的连接问题。
Git远程与代理层级见Git HTTP代理和SSH配置。
四、LFS代理从哪里读取
Git LFS可受Git HTTP配置、环境变量和自身版本行为影响。应查询当前仓库、用户和系统配置来源，避免旧全局代理覆盖新设置。只对特定LFS主机需要代理时，优先缩小规则范围，而不是影响全部Git服务。
五、407、401和403怎样区分
407属于代理认证；401或403可能来自Git托管平台、LFS服务、签名URL过期或资源权限。仓库令牌与代理账号是两套秘密。日志中不要显示Authorization头、Cookie或完整预签名对象URL。
六、为什么对象下载会跳到另一个域名
LFS批处理API可以返回对象的下载动作，该URL可能指向CDN或对象存储，并带短期签名。企业代理、防火墙、DNS和CA必须覆盖实际下载主机。若代理改写Host、路径或查询参数，还可能导致签名验证失败。
七、大文件超时应该调整什么
先判断超时发生在连接、首字节还是传输中。再检查对象大小、并发传输数、代理带宽、连接上限和空闲超时。降低并发有时比单纯增加超时更稳定；提高并发前应测量高分位延迟和失败率。
八、重试与完整性如何保证
LFS对象由OID与大小标识，客户端应在下载后验证。网络中断时由支持的机制重试，不能手工把部分文件移动到对象缓存冒充完成。连续失败应保留脱敏请求ID、对象大小和错误阶段，便于服务端核对。
九、证书错误不要关闭校验
确认Git LFS运行环境使用的CA、系统时间、企业TLS检查和目标证书链。Git、LFS二进制和系统工具的TLS后端可能不同。应修复信任链，不要长期设置跳过证书验证。
十、缓存为何让部分机器正常
已经存在于本地LFS缓存的对象无需再次下载，所以开发者机器成功不代表新CI节点可用。验证应选择当前缓存缺失且允许测试的对象，或从日志确认真实网络传输。共享缓存需要控制来源与写权限。
十一、排查顺序
- 记录Git、LFS版本及远程协议；
- 查看脱敏后的LFS端点和配置来源；
- 区分仓库、批处理API和对象下载阶段；
- 判断407、服务认证、TLS与超时；
- 核对重定向或签名对象主机；
- 测量单对象与并发下载；
- 确认OID完整性并清理调试凭据。
十二、结论
Git LFS代理问题不能只看git clone。沿仓库、LFS API和对象存储三段验证，明确真实端点、认证和大文件传输限制，才能稳定解决检出后仍缺少大文件的问题。
