git克隆时，远端意外挂掉

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

这里的问题是什么?

我已经向GIT托管提供商注册了我的SSH密钥

Receiving objects:  13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly
526518 次浏览
小开
最佳答案

快速的解决方案:

对于这种错误，我通常通过提高postBuffer的大小开始:

git config --global http.postBuffer 524288000

(下面的一些评论报告称，该值必须翻倍):

git config --global http.postBuffer 1048576000

(对于npm publish， 马丁·布劳恩报告在评论中将其设置为不超过5 000 000，而不是默认的1 000 000)

# # #更多信息:

在git config手册页中，http.postBuffer大约是:

智能HTTP传输在向远程系统发送数据时使用的缓冲区的最大字节大小。
对于大于这个缓冲区大小的请求，使用HTTP/1.1和Transfer-Encoding: chunked来避免在本地创建一个庞大的包文件。

.缺省值为1个MiB，可以满足大多数请求

即使对于克隆，这也会产生影响，在本例中，OP乔报告:

[克隆]现在工作正常

注意:如果服务器端出现了错误，如果服务器使用Git 2.5+ (Q2 2015)，错误消息可能会更明确。
看到“Git克隆:远程端意外挂起，尝试更改postBuffer，但仍然失败" . < / p >

Kulai (在评论中)指向这个Atlassian疑难解答Git页面，它添加:

Error code 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“解决方案”。

参见提交7 a2dc95， 提交1 b13e90 (22 Jan 2020) by brian m. carlson (bk2204)。
(合并由Junio C Hamano—gitster— in commit 53a8329， 30 Jan 2020)
(Git邮件列表讨论) < / p >

docs:增加http时提到。postBuffer很有价值

署名:布莱恩·m·卡尔森

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

通常这些问题是由于杀毒软件，过滤代理，或其他中间人的情况;其他时候，它们是由于网络的不可靠性造成的。

然而，在线发现的HTTP推送问题的常见解决方案是增加HTTP . postbuffer。

这对上述任何一种情况都不起作用，只在少数高度受限的情况下有用:基本上，当连接不正确地支持HTTP/1.1时。

记录何时提高这个值是合适的，以及它实际做了什么，并劝阻人们将它用作push问题的通用解决方案，因为它在那里并不有效。

因此，git config http.postBuffer的文档现在包括:

http.postBuffer

智能HTTP传输在向远程系统发送数据时使用的缓冲区的最大字节大小。
对于大于这个缓冲区大小的请求，使用HTTP/1.1和Transfer-Encoding: chunked来避免在本地创建一个庞大的包文件。
缺省值是1mib，可以满足大多数请求 请注意，提高此限制仅对禁用分块传输编码有效，因此仅应在远程服务器或代理仅支持HTTP/1.0或不符合HTTP标准的情况下使用。
一般来说，提高这个值并不是大多数推操作问题的有效解决方案，但是会显著增加内存消耗，因为即使对于的小推操作，也会分配整个缓冲区。

小开

http。postBuffer的技巧不为我工作。然而:

对于遇到此问题的其他人，这可能是GnuTLS的问题。如果您设置了Verbose模式，您可能会看到下面代码行所示的基本错误。

不幸的是，到目前为止我唯一的解决方案是使用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
小开

它可能像服务器问题一样简单。如果使用GitHub，检查https://twitter.com/githubstatus。我刚刚第一次看到这个，并发现GitHub出现了问题。几分钟后，它又正常工作了。

小开

奥林匹克广播服务公司。:改变http.postBuffer可能还需要设置Nginx配置文件，让gitlab通过调优client_max_body_size的值来接受更大的客户端身体尺寸。

但是，如果您可以访问Gitlab机器，则有一个解决方案或其网络中的机器，这是通过使用git bundle。

  1. 转到源计算机上的git存储库
  2. 运行git bundle create my-repo.bundle --all
  3. (如转移。， rsync) my-repo。绑定文件到目标计算机
  4. 在目标机器上，运行git clone my-repo.bundle
  5. git remote set-url origin "path/to/your/repo.git"
  6. git push

祝你一切顺利!

小开

我也遇到过类似的问题，不过是竹子做的活。竹是失败的做本地克隆(本地但通过SSH代理)缓存的存储库，我删除了缓存，之后它工作了，但任何时候它试图从本地缓存克隆有一个失败。似乎是bamboo的SSH代理版本的问题，而不是git本身。

小开

这对我来说很有效，设置谷歌的命名服务器，因为没有指定标准的命名服务器，然后重新启动网络:

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

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

在/etc/resolv.conf < p > 将该行添加到文件

的末尾

选择单请求

这固定延迟之前，每个域名解析和git开始工作像一个魅力之后。

小开

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

options single-request
小开

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

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

小开

检查网速。同时检查以下命令:

$ git config --global http.postBuffer 2M
$ git pull origin master
小开

嗯，我想推出一个219 MB的解决方案，但我没有运气

git config --global http.postBuffer 524288000

有一个525mb的后缓冲区有什么意义呢?这是愚蠢的。所以我查看了下面的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想要发布5mb，然后我将post buffer设为6mb，它可以工作

git config --global http.postBuffer 6291456
小开

我正在从我的OS X El Capitan Mac做git推送。我得到了相同的错误，我尝试了所有的方法来修复，我在谷歌/stackoverflow上找到了什么。就版本而言，我使用的是github的最新版本，是2.7.4。我在我的本地系统中创建了一个项目，我想在我的github帐户中公开。项目大小不是8MB左右。我注意到，当我推一些大小约1.5MB的文件时，它是正确的，但对于大尺寸的我来说失败了，同样的错误，

我唯一的选择是在MB块中推送更改。现在我已经推送了所有更改。这是我的工作，直到我得到这个解决方案。

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

希望这将有助于你继续工作的项目。

小开

唯一对我有用的是使用HTTPS链接而不是SSH链接克隆回购。

小开

我发现我的问题是与.netrc文件，如果是这样，那么你也可以做以下:

打开你的.netrc文件并编辑它以包括github凭证。 输入nano ~/netrc或gedit ~/netrc

然后包括以下内容: *机器github.com

登录用户名

密码的秘密

机器api.github.com

登录用户名

密码的秘密*

你可以在那里包含你的原始密码，但出于安全考虑，在这里生成一个认证令牌github令牌，并将其粘贴到你的密码的位置。

希望这对大家有所帮助

小开

我也有同样的问题。这个问题的原因正如Kurtis对GNUTLS的描述。

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

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

如果你正在使用https，你会得到错误。

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

git config --global https.postBuffer 524288000
小开

我有同样的错误，而使用BitBucket。我所做的是从我的回购的URL中删除https，并使用HTTP设置URL。

git remote set-url origin http://mj@bitbucket.org/mj/pt.git
小开
我在elastic beanstalk管理的AWS EC2实例上从远程git repo上克隆数据(通过HTTP)时遇到了这个问题。 克隆本身也是在AWS EC2实例上完成的

我尝试了上述所有的解决方案以及它们的组合:

  • 设置git的http.postBuffer
  • settinghttp.maxrequestbuffer
  • 关闭git压缩并尝试“shallow”git clone和git fetch --unshallow -参见fatal:早期EOF fatal:索引包失败
  • 调优GIT内存设置- packedGitLimit 等，见这里:fatal:早期EOF fatal:索引包失败
  • 调优nginx配置-设置client_max_body_size为大值和0(无限);设置proxy_request_buffering off;
  • 在/etc/resolv.conf中设置options single-request
  • 使用细流限制git客户端吞吐量
  • 使用strace跟踪git clone
  • 考虑git客户端的更新
在所有这些之后，我仍然一次又一次地面对同样的问题，直到我发现问题是在弹性负载均衡器(ELB)切断连接。 在直接访问EC2实例(一个托管git repo)而不是通过ELB之后，我终于成功克隆了git repo! 我仍然不确定ELB(超时)参数中的哪一个是负责这个的，所以我仍然需要做一些研究

更新

似乎通过将超时时间从20秒提高到300秒来更改AWS弹性负载均衡器的连接排水策略为我们解决了这个问题。

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

这是AWS论坛上的相关问题(还没有答案):https://forums.aws.amazon.com/thread.jspa?threadID=258572

小开

我也有同样的问题，这与互联网连接不好有关，所以在尝试了一些git配置后，我刚刚断开了我的网络，并再次连接，它工作了!

似乎在连接丢失(或触发此情况的操作)后，git被卡住了。

我希望这能对更多的人有所帮助。

最好的

小开

Bitbucket也有同样的错误。固定的

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

这可能是因为提交的大小。按以下步骤分解提交的数量:

git log -5
查看最近5次提交，你会知道哪些没有被推送到远程。 选择一个提交id，并将所有提交推到该id:

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

注意:我刚刚检查了我的提交，可以有最大的大小;第一次推到那时。这个把戏成功了!!

小开
我也有同样的问题， 我用试错法解决了这个问题。我改变了core。compression值直到它生效。< / p >

在3次尝试后，我从“git配置-global core.compression 1”开始

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

小开

解决WIFI路由器设置:

当我在wifi设置PPPoE(通过wifi路由器自动登录)时，我也遇到了同样的问题。

Git下载速度非常慢15kb。

packet_write_wait: Connection to 17.121.133.16 port 22: Broken pipe 致命的:对端意外挂机 致命:早期EOF 致命:索引包失败

< p >解决方案: 1. 更改设置为动态IP，重新启动wifi路由器。 2. 从web浏览器登录到Internet服务提供商portal(不配置PPPoE，从wifi路由器自动登录)

修改后的Git下载速度为1.7MiB。

小开
这是由于网络连接问题，我也遇到过同样的问题。 我做了一个浅拷贝的代码使用

git clone --depth 1 //FORKLOCATION

稍后取消浅化克隆使用

git fetch --unshallow
小开
遇到同样的问题，试着与另一个分支合并，并从他们那里吸取教训。

小开

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

小开

基于这个答案，我尝试以下(与https url):

  1. repo初始克隆:

git clone --depth 25 url-here

  1. Fetch每次尝试深度增加两次提交:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

.．.等等

  1. 最终(当我认为获取的足够多时)我运行git fetch --unshallow -它就完成了。

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

乌利希期刊指南:我发现通过ssh获取适用于任何回购大小(偶然发现)，使用git clone <ssh url>完成，假设你已经创建了ssh密钥。一旦获取了repo，我使用git remote set-url <https url to repo>更改远程地址

小开

我也有同样的问题，正在网上搜索解决方案。我发现我们公司的IPv6路由没有维护。

我关闭了(在Windows 10的以太网端口上的IPv6选项)，没有问题。

小开

当我通过ssh克隆存储库时，没有一个建议的解决方案对我有效。然而，我能够使用https进行克隆，然后稍后通过以下方式将远程更改为ssh:

git remote set-url origin git@github.com:USERNAME/REPOSITORY.git
小开

这解决了我的问题:

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

上面的技巧对我没有帮助，因为repo比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
它将遍历master的历史，一次推2000个对象。(当然，您可以在两者中替换不同的分支 如果你喜欢，可以去别的地方。)完成后，你就可以用力了 掌握最后一次，事情就应该跟上时代了。如果2000年太过 很多，你又碰到问题了，你可以调整数字 小。< / p >
小开

我必须移除git clone命令的分支标志。

小开

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

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

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

小开

在MacOSX High Sierra游戏中，我的解决方案是:

brew install git-lfs

我的存储库被克隆了，没有任何错误。

小开

浪费了几个小时尝试这些解决方案，但最终追踪到公司IPS(仪器保护系统)在传输一定量的数据后断开了连接。

小开

增加postBuffer大小和maxRequestBuffer将有助于解决这个问题。按照步骤做就可以了。

步骤:

1 .打开终端或Git Bash，用“cd”转到你想克隆repo的位置。

2.将压缩设置为0

git config --global core.compression 0

3.设置postBuffer大小

git config --global http.postBuffer 1048576000

4.设置maxRequestBuffer大小

git config --global http.maxRequestBuffer 100M

5.现在开始克隆

git clone <repo url>

6.等待克隆完成。

谢谢你！快乐编码!!

小开

唯一对我有用的是:

  1. < p >克隆浅:

    git clone <yourrepo> --depth 10

  2. 编辑。git/config如下:

之前

[remote "origin"]
fetch = +refs/heads/master:refs/remotes/origin/master

后

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*

  1. git config——global http。maxRequestBuffer 100 Git配置——global core.compression 0

  2. < p > Git获取

小开

对我来说，问题是诺顿安全安装在MacOS上。一旦我临时禁用防火墙和其他诺顿保护，我的git push工作正常。

小开

将克隆屏幕中的源树高级选项的深度更改为25对我来说很有效

小开

从Mac终端运行git push...可以解决问题，这与从导致问题的IDE(我的情况是:VSCode)尝试不同。

小开

我的经验是，这肯定是某个地方的连接超时。

最终，我在电脑上插入了一个蹩脚的wifi适配器，并使用了手机的热点。

当我通过有线连接到我的ISP时，向Github上传一个小更改是可以的，所以连接和身份验证在原则上是有效的。 但是当试图推送一个新的80Mb存储库时，发生了错误

在设法通过wifi加密狗/热点推动回购后，小的增量变化很好。


提交答案