远程结束在 Git 克隆时意外挂断

Question

我的 git 客户端在尝试克隆存储库一段时间后，反复出现以下错误。

这里可能出了什么问题？

注意：我已经将我的 SSH 密钥注册到了 GIT 托管提供商。

Receiving objects:  13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly

- Joe

---

你能检查一下你的Git托管提供商是否在线吗？ - Caps

您能否检查一下 git config --global http.postBuffer 524288000 对您的克隆操作是否有任何影响？是否有额外的错误信息，比如 "error: RPC failed; result=56, HTTP code = 0"？ - VonC

@VonC - 上述命令执行得很好，控制台上没有看到任何输出。 - Joe

@Joe 你能在执行 git config --global http.postBuffer 524288000 命令后进行克隆吗？ - VonC

根据在另一个 SO 帖子 中提到的，@Joe 应该尝试切换到 ssh 而不是 https。 - Buzut

Answer 1

快速解决方案：

对于这种错误，我通常会通过增加postBuffer的大小来解决：

git config --global http.postBuffer 524288000

（一些下面的评论报告说需要将值加倍）：

git config --global http.postBuffer 1048576000

（对于npm publish，Martin Braun在评论中报告说，将其设置为不超过50,000,000而不是默认的1,000,000）

更多信息：

从git config手册页面中，http.postBuffer大约是：

智能HTTP传输在向远程系统POST数据时使用的缓冲区的最大大小（以字节为单位）。 对于大于此缓冲区大小的请求，使用HTTP/1.1和Transfer-Encoding: chunked来避免在本地创建一个巨大的包文件。默认值为1 MiB，对于大多数请求足够。

即使对于克隆体，这也可能产生影响，在这种情况下，OP Joe的报告如下：[clone]现在正常工作。

---

注意：如果服务器端出现问题，并且服务器使用的是Git 2.5+（2015年第二季度），错误信息可能会更明确。
请参阅“Git克隆：远程端意外断开连接，尝试更改postBuffer但仍然失败”。

---

Kulai (在评论中) 指出了 这个 Atlassian Git 故障排除页面, 它补充道:

错误代码 56 表示 curl 接收到 CURLE_RECV_ERROR 的错误，这意味着在克隆过程中存在一些问题导致数据无法接收。
通常情况下，这是由网络设置、防火墙、VPN客户端或终止连接之前未传输完所有数据的防病毒软件引起的。

它还提到了以下环境变量，以帮助调试过程。

# Linux
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

---

使用Git 2.25.1（2020年2月）版本，你可以更多地了解关于这个http.postBuffer的“解决方案”。

查看提交 7a2dc95，提交 1b13e90（2020年1月22日）由brian m. carlson (bk2204)完成。
^{（由Junio C Hamano -- gitster --合并于提交 53a8329，2020年1月30日）}
（Git 邮件列表讨论）

docs：提到增加http.postBuffer的价值

^{签名：brian m. carlson}

在各种情况下，用户都会遇到HTTP推送问题。

通常，这些问题是由于防病毒软件、过滤代理或其他中间人攻击等原因引起的；而有时，它们是由于网络的不可靠性导致的。

然而，在网上找到的解决HTTP推送问题的常见方法是增加http.postBuffer。

这对于前述情况都没有作用，只在一小部分高度受限的情况下才有用，即当连接不正确支持HTTP/1.1时。

记录何时适合提高此值以及其实际作用，并劝阻人们将其作为推送问题的通用解决方案使用，因为它在那里并不有效。

所以现在git config http.postBuffer的文档包括：

http.postBuffer

使用智能HTTP传输进行POST数据到远程系统时，缓冲区的最大字节数。 对于大于此缓冲区大小的请求，将使用HTTP/1.1和Transfer-Encoding: chunked来避免在本地创建庞大的打包文件。 默认为1 MiB，对大多数请求来说足够。

请注意，提高此限制只对禁用分块传输编码有效，因此仅应在远程服务器或代理仅支持HTTP/1.0或不符合HTTP标准的情况下使用。 提高此限制通常不是解决大多数推送问题的有效方法，但可能会显着增加内存消耗，因为即使对于小的推送，整个缓冲区也会被分配。

- VonC

---

这对我也起作用了，尽管我有些困惑，不知道在通过ssh://进行传输时何时涉及“智能HTTP传输”。 - CodeClown42

谢谢，这个技巧行得通，但需要将给出答案的值加倍。 - Lolitha Ratnayake

文档可能有误，但当你通过 HTTP 获取/克隆时，POST 不是所发生的事情。我对为什么“postBuffer”设置会影响克隆或获取感到困惑。 - void.pointer

@Astravagrant 好的，我已经更新了答案，使该值更加明显。 - VonC

注意：当我提高postBuffer时，使用npm publish时遇到了几个问题。当我将其设置为50000000时，问题消失了。默认值是1000000。 - Martin Braun

Answer 2

在Bitbucket上出现了相同的错误。通过修复

git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0

- wizawu

---

尝试了这里发布的所有解决方案，但只有这个方案有效！ - Rich

非常感谢，完美地运作了。 - user10053673

Answer 3

http.postBuffer并没有为我解决问题，然而：

对于其他遇到此问题的人来说，可能是GnuTLS引起了问题。如果你设置了详细模式，你可能会看到底层错误信息类似于以下代码。

不幸的是，目前我的唯一解决方案就是使用SSH。

我在其他地方看到了一个解决方案，即通过OpenSSL编译Git而不是GnuTLS。这个问题有一个活跃的bug报告 在这里。

GIT_CURL_VERBOSE=1 git clone https://github.com/django/django.git

Cloning into 'django'...
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * Connected to github.com (192.30.252.131) port 443 (#0)
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> GET /django/django.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept: */*
Accept-Encoding: gzip

Pragma: no-cache
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:14 GMT

< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
* Connection #0 to host github.com left intact
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> POST /django/django.git/git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept-Encoding: gzip

Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 2299
* upload completely sent off: 2299out of 2299 bytes

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:15 GMT

< Content-Type: application/x-git-upload-pack-result
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
remote: Counting objects: 232015, done.
remote: Compressing objects: 100% (65437/65437), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

- Kurtis

---

我得到了与你一样冗长的日志，但是通过增大postBuffer值解决了这个问题。 - suiwenfeng

git config --global http.postBuffer 10000000000000000000000000000000这行命令用于配置Git，将全局的http.postBuffer属性设置为10000000000000000000000000000000。 - suiwenfeng

较新版本的Git由于“fatal: bad numeric config value '100000000000' for 'http.postbuffer': out of range”而失败，但在我的情况下设置配置值并没有帮助。 - Kalle Richter

我能达到的最大尺寸是100000000000000。 - nhoxbypass

Answer 4

参考这个回答，我尝试了以下步骤（使用 https url）：

1. 克隆仓库：

git clone --depth 25 url-here

2. 增加深度每次获取提交信息：

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

......以此类推

3. 最终当我认为已经获取了足够多的提交信息时，运行 git fetch --unshallow 命令 - 完成操作。

这个过程显然需要更多时间，但在我的情况下设置 http.postBuffer 和 core.compression 并没有帮助。

更新：我发现通过ssh拉取可以适用于任何仓库大小（偶然发现的），使用命令 git clone <ssh url> ，前提是你已经创建了 ssh 密钥。一旦仓库被获取，我会使用 git remote set-url <https url to repo> 命令改变远程地址。

- Андрей Саяпин

---

git clone --depth 25 url-here 对我来说可行，而无需使用 fetch - Sideeg MoHammed

这个答案真是太棒了，而且是唯一一个对我有用的。我一直在使用Bitbucket，在克隆较小的存储库时可以正常工作，但在克隆较大的存储库时就不行了。这种分块获取的方法完全奏效了。 - Tim Biegeleisen

对我来说从Bitbucket获取工作得非常好。特别是因为我的存储库总共只有56个提交。 - Adam Harte

Answer 5

在带宽共享情况下，尝试在负载较少时进行克隆。否则，请使用高速连接再次尝试。如果仍无法解决问题，请使用以下命令：

git config --global http.postBuffer 2048M
git config --global http.maxRequestBuffer 1024M
git config --global core.compression 9

git config --global ssh.postBuffer 2048M
git config --global ssh.maxRequestBuffer 1024M

git config --global pack.windowMemory 256m 
git config --global pack.packSizeLimit 256m

再次尝试克隆。您可能需要根据可用内存大小更改这些设置。

- Sazzad Hissain Khan

Answer 6

对我而言唯一有效的方法是使用HTTPS链接而不是SSH链接克隆仓库。

- Ayan

Answer 7

这是由于互联网连接问题导致的，我也遇到了同样的问题。 我使用浅复制代码。

git clone --depth 1 //FORKLOCATION

稍后使用未被禁止的方法卸载克隆。

git fetch --unshallow

- Srikanth Josyula

---

这似乎可以解决问题。 - alfonzjanfrithz

在这里，我已经过去了6年以上的时间 - 这似乎是唯一有效的方法。谢谢！ - Chris Parker

Answer 8

注意：更改http.postBuffer可能还需要设置Nginx配置文件以便gitlab接受客户端更大的请求体大小，可以通过调整client_max_body_size的值来实现。 但是，如果您可以访问Gitlab机器或其网络中的一台机器，则有一个变通方法，即利用git bundle。

1. 进入源机器上的git存储库。
2. 运行git bundle create my-repo.bundle --all
3. 将my-repo.bundle文件传输到目标机器（例如，使用rsync）
4. 在目标机器上运行git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

祝您好运！

- Ruxandra T.

Answer 9

如果你正在使用https并且遇到了错误。

我使用https而不是http解决了我的问题。

git config --global https.postBuffer 524288000

- Aransiola Oluwaseun

---

如果我正在使用ssh呢？我无法转移到http/https。 - RobisonSantos

Answer 10

我使用以下命令解决了问题： git repack -a -f -d --window=250 --depth=250

- hmjha

---

克隆还没有创建本地git仓库，那你该如何运行它？ - lucidbrot

终于解决了这个问题，之前所有的方法都不起作用，但是这个命令 git push origin main 终于成功了。谢谢。 - Osama Mohammed