git克隆时远端意外挂断

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

这可能是什么问题？

注意：我已经在GIT托管提供商处注册了SSH密钥

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

快速解决方案：

遇到这种错误时，我通常首先将postBuffer大小增加：

git config --global http.postBuffer 524288000

（下面的一些评论指出该值必须加倍）：

git config --global http.postBuffer 1048576000

更多信息：

在git config手册页中，http.postBuffer有关：

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

即使对于克隆，也可能会产生影响，在这种情况下，OP Joe报告：

[clone]现在工作正常

注意：如果服务器端出现问题，并且服务器使用Git 2.5+（2015年第二季度），则错误消息可能更明确。
请参阅“ Git克隆：远端意外挂起，尝试进行更改postBuffer但仍然失败 ”。

古来（在评论中）指出此Atlassian疑难解答Git页面，其中添加：

Error code 56 表示卷曲接收到错误 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“解决方案”。

参见brian m的commit 7a2dc95和commit 1b13e90（2020年1月22日）。卡尔森（bk2204）。
^{（通过合并JUNIOÇ滨野- gitster-在提交53a8329，2020年1月30日）}
（Git的邮件列表讨论）

docs：在增加http.postBuffer有价值时提及

^{签字人：brian m。卡尔森}

各种情况下的用户都发现自己遇到了HTTP推送问题。

这些问题通常是由于防病毒软件，过滤代理或其他中间人情况引起的；其他时候，它们是由于网络的简单可靠性。

但是，在线发现HTTP推送问题的常见解决方案是增加http.postBuffer。

这不适用于上述任何情况，并且仅在少数情况下，在高度受限的情况下才有用：本质上是当连接不正确支持HTTP / 1.1时。

在提高此值时记录下来是适当的，它的实际作用是，并劝阻人们不要将其用作推送问题的一般解决方案，因为在此无效。

因此，目前的文档git config http.postBuffer包括：

http.postBuffer

将数据发布到远程系统时，智能HTTP传输使用的缓冲区的最大大小（以字节为单位）。
对于大于此缓冲区大小的请求，HTTP / 1.1和Transfer-Encoding：chunked用于避免在本地创建大型打包文件。
默认值为1 MiB，足以应付大多数请求。

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

与Bitbucket相同的错误。固定于

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

该http.postBuffer招确实不适合我的工作。然而：

对于其他遇到此问题的人，可能是GnuTLS的问题。如果设置了详细模式，则可能会看到下面的代码沿线显示了基本错误。

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

我已经看到了在其他地方发布的一种解决方案，可以使用OpenSSL而不是GnuTLS编译Git。没有为这个问题的主动漏洞报告在这里。

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

观察：更改http.postBuffer可能还需要通过调整client_max_body_size的值来设置gitlab的Nginx配置文件以接受客户端的较大主体尺寸。

但是，如果您可以访问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

祝一切顺利！

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

如果使用的是https，则会收到错误消息。

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

git config --global https.postBuffer 524288000

基于此答案，我尝试了以下操作（使用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并没有帮助。

UPD：我发现，通过ssh进行提取可适用于任何回购大小（偶然发现），git clone <ssh url>只要您已创建ssh密钥即可完成。获取回购文件后，我使用git remote set-url <https url to repo>

使用以下命令后，我得到了解决方案：

git repack -a -f -d --window=250 --depth=250

我遇到了同样的问题，我用试错法解决了这个问题。我更改了core.compression值，直到它起作用为止。

经过3次尝试，我从“ git config --global core.compression 1”开始

“ git config --global core.compression 4”对我有用。

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

git clone --depth 1 //FORKLOCATION

后来取消克隆使用

git fetch --unshallow

在/etc/resolv.conf该行添加到文件的末尾

options single-request

好吧，我想推出219 MB的解决方案，但是我没有运气

git config --global http.postBuffer 524288000

无论如何，拥有525 MB的后缓冲区有什么意义？真傻 所以我看了下面的git错误：

Total 993 (delta 230), reused 0 (delta 0)
POST git-receive-pack (5173245 bytes)
error: fatal: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054

所以git想要发布5 MB，然后我将发布缓冲区设置为6 MB，就可以了

git config --global http.postBuffer 6291456

我遇到了同样的问题，这与互联网连接不良有关，因此在尝试了一些git configs之后，我刚刚从网络上断开连接并再次连接，它就可以工作了。

似乎在连接丢失（或引发这种情况的动作）之后，git卡住了。

我希望这可以对这里的其他人有所帮助。

最好，

我也遇到了同样的问题，原因是Kurtis对GNUTLS的描述。

如果您有相同的原因，并且您的系统是Ubuntu，则可以通过从安装最新版本的git来解决此问题ppa:git-core/ppa。命令如下。

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get git

从通过弹性beantalk管理的AWS EC2实例上托管的远程git repo克隆数据（通过HTTP）时，我遇到了这个问题。克隆本身也在AWS EC2实例上完成。

我尝试了所有上述解决方案及其组合：

• 设置git的 http.postBuffer
• 设置http.maxrequestbuffer
• 关闭git压缩并尝试“浅” git clone，然后git fetch --unshallow-参见致命的：早期的EOF致命的：索引包失败
• 调整GIT内存设置- packedGitLimit 等，请参见此处：致命：早期EOF致命：索引包失败
• 调整Nginx配置-设置 client_max_body_size为大值和0（无限制）；设置proxy_request_buffering off;
• 设置 options single-request在/etc/resolv.conf中
• 用细流限制git客户端的吞吐量
• 使用strace进行跟踪 git clone
• 考虑更新git client

在完成所有这些操作之后，我仍然一遍又一遍地面临着相同的问题，直到发现该问题出在Elastic Load Balancer（ELB）切断连接的地方。在直接访问EC2实例（一个托管git repo的实例）之后，而不是通过ELB，我终于设法克隆了git repo！我仍然不确定是由哪个ELB（超时）参数引起的，因此我仍然必须进行一些研究。

更新

似乎通过将超时从20秒增加到300秒来更改AWS Elastic Load Balancer的连接排放策略可以为我们解决此问题。

之间的关系 git clone错误与“连接消耗”对我们来说很奇怪，也不是显而易见的。连接耗尽超时更改可能导致ELB配置中的一些内部更改，从而解决了过早关闭连接的问题。

这是AWS论坛上的相关问题（尚无答案）：https : //forums.aws.amazon.com/thread.jspa?threadID=258572

我有一个类似的问题，但是工作很简单。Bamboo未能对缓存的存储库进行本地克隆（本地但通过SSH代理），我删除了缓存，然后缓存起作用了，但是任何时候尝试从本地缓存克隆的操作都会失败。似乎是Bamboo的SSH代理版本本身不是git的问题。

使用BitBucket时出现相同的错误。我所做的就是从仓库的URL中删除https，然后使用设置URL HTTP。

git remote set-url origin http://mj@bitbucket.org/mj/pt.git

解决与WIFI路由器设置：

使用设置PPPoE（通过wifi路由器自动登录）进入wifi时，我遇到了同样的问题。

Git的下载速度非常慢15kb。

packet_write_wait：连接到17.121.133.16端口22：管道损坏致命：远端意外挂断致命：早期EOF致命：索引包失败

解决方案：1.将设置更改为动态IP，重新启动wifi路由器。2.从Web浏览器登录到Internet服务提供商门户（不要配置PPPoE，从wifi路由器自动登录）。

更改Git后，下载速度为1.7MiB。

这解决了我的问题：

git clone --depth=20 https://repo.git -b master

上面的技巧对我没有帮助，因为仓库超过了github允许的最大推送大小。起作用的是来自https://github.com/git-lfs/git-lfs/issues/3758的建议，建议一次推动一点：

如果您的分支机构历史悠久，则可以尝试使用以下方式一次（例如2000年）推送少量提交：

git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master

那将遍历母版的历史，一次推送2000个对象。（当然，您可以根据需要在两个地方替换一个不同的分支。）完成之后，您应该可以将master压入最后一个时间，并且事情应该是最新的。如果2000太多，而您又遇到问题，则可以将数字调整为较小。

尝试使用其中一些解决方案花费了几个小时，但最终导致这种情况的原因是企业IPS（入侵防护系统）在传输了一定数量的数据后中断了连接。

对于共享带宽，请尝试在负载较小时克隆。否则，请尝试高速连接。如果仍然无法使用，请使用以下命令，

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

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

它可能像服务器问题一样简单。如果使用GitHub，请检查https://twitter.com/githubstatus。我现在才第一次看到它，发现GitHub出现了摆动。几分钟后，它再次正常运行。

这对我有用，因为未指定标准名称服务器，所以设置了Google的名称服务器，然后重新启动网络：

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

我在Kubuntu中使用git遇到了这个问题。我还注意到网络整体不稳定，并找到了解决方案。

在/etc/resolv.conf中，将行添加到文件末尾

选项单一请求

此固定延迟在每个域名解析和git之后开始像魅力一样起作用之前。

我发现我的问题与.netrc文件有关，如果您也是如此，则可以执行以下操作：

打开您的.netrc文件，然后对其进行编辑以包含github凭据。类型nano ~/netrc或gedit ~/netrc

然后包括以下内容：* machine github.com

登录用户名

密码SECRET

机器api.github.com

登录用户名

密码SECRET *

您可以在此处包含原始密码，但出于安全目的，请在此处生成auth令牌github令牌，并将其粘贴到您的密码中。

希望这可以帮助某人

可能是由于提交大小的原因。.通过以下步骤细分提交数量：

git log -5

查看最近5次提交，您将知道哪些未提交到远程。选择一个提交ID，并将所有提交推到该ID：

git push <remote_name> <commit_id>:<branch_name>

注意：我只是检查了我的提交，它可能是最大的。首先推高直到那时。俩奏效了！！

我正在从OS X El Capitan Mac执行git push。我遇到了同样的错误，我尝试了所有修复方法，这些都是在google / stackoverflow上找到的。就版本而言，我使用的是github的最新版本，即2.7.4。我已经在本地系统中创建了一个项目，并且希望在我的github帐户中将其公开。项目大小不超过8MB。我注意到，当我推送一些大小约为1.5MB的文件时，它可以正常推送，但是对于我来说，大容量文件失败，出现相同的错误，

我唯一的选择是按MB推送更改。现在，我推动了所有更改。在我获得此解决方案的修复之前，这是我的解决方法。

因此，您也可以尝试在多个提交中推动更改。或者，如果您有多个文件夹，则可以按每个文件夹推送更改（如果文件夹大小不大）。

希望这会帮助您继续进行项目。

面对相同的问题，请尝试与另一个分支合并并从中吸取教训。它对我也一样。

使用ssh代替http，不是这个问题的好答案，但至少对我有用