无论 HTTP 版本设置如何为 HTTP/1.1，推送到 Azure DevOps GIT LFS 都会中止

Question

我尝试使用 Azure DevOps 中的 GIT LFS 推送非常大的文件，但推送总是在 120 秒后中止。目前只有 ~2.4 GB 的 ISO，但后来我计划上传大约最大 50 GB 的内容。

我在 Azure DevOps 中创建了一个空存储库，并为 GIT LFS 做好了准备。我还将 HTTP 版本设置为 HTTP/1.1。

git lfs install
git config --global http.version HTTP/1.1
git clone <SOME_COOL_PROJECT> test
cd test
# move big file into test directory
git lfs track directory_with_big_files/*
git add .
git commit -m 'initial commit'
git push origin main

当我执行

git push origin main

时，它将在 120 秒后中止上传到 GIT LFS，并显示

503 Fatal error: Server error

。

我非常确定，我已将过去的大文件推送到 Azure DevOps 中的 GIT LFS。我在 Windows 和 Linux 上尝试过此操作，但行为似乎相同。我也尝试过更改

lfs.dialtimeout

和

lfs.activitytimeout

，但总是在120秒后中止。

也许有人有想法？

---

https://learn.microsoft.com/en-us/azure/devops/repos/git/manage-large-files?view=azure-devops#limitations

https://github.com/MicrosoftDocs/azure-devops-docs/issues/4179

Answer 1

503 HTTP 状态表示服务不可用。与其他 5xx 状态代码一样，这表明服务器端出现客户端无法控制的问题。如果您可以采取一些措施来影响问题，您将收到 4xx 状态代码，这是客户端错误，然后您将采取适当的操作来执行不同的操作。

请注意，建议设置

http.postBuffer

的评论没有用。 Git LFS 根本不使用该选项，并且 Git FAQ 明确表示 Git 不需要它，除非远程服务器或代理严重损坏。我认为 Azure DevOps 团队至少具备最低限度的能力，并且使用了可以正确处理分块传输编码的 HTTP 服务器。

但是，您很可能有一个代理（包括非默认防病毒或防火墙，或监控软件）正在篡改您的连接并发送 503。在 Git Bash 中，您可以在推送之前使用

GIT_TRACE=1 GIT_TRANSFER_TRACE=1 GIT_CURL_VERBOSE=1

查看有关操作的更多信息，包括 HTTP 请求和响应。如果您认为它可能是某种代理，您应该尝试另一个网络，如果您在计算机上使用此类软件，您应该完全卸载它并重新启动，然后重试看看是否可以解决问题。 （通常简单地禁用它是没有效果的。）

您还可以尝试在 WSL 下查看是否可以解决问题。如果是这样，它很可能是某种代理软件，但至少您将获得有关可能相关内容的更多信息。