Total 848 (delta 279), reused 676 (delta 184), pack-reused 0 fatal: the remote

Question

在执行 `git clone` 或 `git pull` 时，出现错误提示：“Total 848 (delta 279), reused 676 (delta 184), pack-reused 0\r\nfatal: the remote end hung up unexpectedly”。该问题常见于网络不稳定、SSH连接中断或远程仓库服务异常。可能原因包括：Git服务器超时、本地带宽限制、SSH配置不当或仓库过大导致传输中断。尤其在克隆大型仓库时，若未调整缓冲区大小或使用 HTTPS/SSH 协议兼容性差，易触发此错误。如何稳定复现并解决该通信中断问题？

Answer 1

让【宝码香车】来帮您解答，本回答参考DeepSeek编写，并整理提供。

如果答案能帮助您，请采纳，非常感谢！
.
每日一句正能量，让它带给您好心情：努力不是为了取悦谁，而是为了让自己活得更有底气。
.

您好！这是一个在 Git 操作中非常经典的网络通信错误。错误信息 fatal: the remote end hung up unexpectedly 直译为“远端意外挂断”，它明确指出了问题的核心：在数据传输过程中，您的客户端与 Git 服务器之间的连接被异常切断了。

下面我将为您详细分析问题的原因，并提供一套从易到难的解决方案。

问题根本原因分析

错误信息前的 Total ... pack-reused 0 表明 Git 已经开始了数据传输（计算出了对象数量和增量压缩信息），但在传输过程中连接中断。主要原因可以归结为以下几类：

1. 网络不稳定：这是最常见的原因。包括本地网络波动、Wi-Fi 信号弱、路由器问题，或者是您与 Git 服务器之间的网络链路质量差（尤其是在跨国际访问时）。
2. 服务器端限制：

• 超时设置过低：Git 服务器（如 GitHub, GitLab, Gitee）有为每个连接设置的超时时间。如果您的网络速度较慢，传输大量数据的时间超过了服务器允许的阈值，服务器会主动关闭连接。
• 速率限制：某些免费的代码托管服务可能对克隆/拉取速率有隐性限制。

1. 客户端配置限制：

• HTTP 缓冲区大小：Git 默认的 HTTP 缓冲区大小可能不足以应对大型仓库或慢速网络，导致传输失败。
• SSH 连接超时：如果使用 SSH 协议，SSH 客户端本身也可能因为空闲而超时。

1. 仓库过大：尝试克隆一个体积巨大（几个 GB 甚至更大）的仓库时，上述所有问题都会被放大。

---

解决方案（从易到难）

请按照以下顺序尝试解决。

方案一：基础网络与协议调整（首先尝试）

这些方法最简单，通常能解决大部分问题。

1. 切换网络环境

• 尝试连接一个更稳定、速度更快的网络。例如，从 Wi-Fi 切换到有线网络，或使用手机热点试试。

1. 更换 Git 协议

• 如果您使用的是 HTTPS，尝试切换到 SSH，或者反之。有时公司的防火墙或代理对特定协议的策略不同。
• HTTPS 转 SSH：git remote set-url origin [e-mail]:username/repository.git
• SSH 转 HTTPS：git remote set-url origin https://github.com/username/repository.git

1. 使用浅层克隆

• 如果您只需要最新的代码，而不需要整个历史记录，浅层克隆是首选。它只下载最近的提交，数据量小得多。

   git clone --depth 1 https://github.com/username/repository.git
   ```


* `--depth 1` 表示只克隆最近一次提交。之后如果需要完整历史，可以执行 `git fetch --unshallow`。


#### 方案二：调整 Git 配置（解决传输中断）


当基础方法无效时，通常是传输层需要优化。


1. **增加 HTTP 缓冲区大小**
这个配置显著提升了在慢速或不稳定网络下传输大文件的成功率。


```bash
   git config --global http.postBuffer 524288000
   ```


这将缓冲区设置为 500 MB。这个值对绝大多数仓库都足够了。


2. **禁用 SSL 验证（临时方案）**
* 如果问题出在 SSL 证书验证上（例如在某些内部网络或代理后），可以临时关闭它来进行测试。**注意：这会带来安全风险，仅用于诊断，问题解决后请重新启用。**


```bash
   git config --global http.sslVerify false
   ```


* **恢复命令**：`git config --global --unset http.sslVerify`


3. **启用压缩**
在传输时对数据进行压缩，虽然会增加一些 CPU 开销，但能减少传输量。


```bash
   git config --global core.compression 9
   ```


#### 方案三：针对大型仓库和深度优化


如果仓库特别大，或者上述方法依然无效，请尝试以下组合拳。


1. **分批拉取**
先进行浅层克隆，然后再逐步获取剩余的历史记录。


```bash
   # 1. 浅层克隆
   git clone --depth 1 https://github.com/username/large-repository.git
   cd large-repository


   # 2. 逐步获取更早的历史
   git fetch --depth=10 # 再获取最近的10次提交
   git fetch --depth=100 # 再获取最近的100次提交
   # ... 直到你获取到全部历史
   ```


2. **使用 `GIT_TRACE` 进行调试**
开启 Git 的跟踪功能，可以清楚地看到连接在哪一步失败了。


```bash
   GIT_TRACE=1 git pull
   # 或者更详细的信息
   GIT_TRACE_CURL=1 GIT_CURL_VERBOSE=1 git pull
   ```


查看输出日志，寻找错误发生前的最后几条信息，这能帮助定位是 DNS 解析、连接建立还是数据传输阶段出的问题。


#### 方案四：系统级与 SSH 配置


1. **SSH 连接保持**
对于 SSH 协议，可以配置客户端定期发送“保活”信号，防止连接因空闲而被防火墙断开。
* 编辑 SSH 客户端配置文件 `~/.ssh/config`（Linux/macOS）或 `C:\Users\YourUserName\.ssh\config`（Windows），为你的 Git 服务器添加以下配置：

Host github.com
    HostName github.com
    User git
    TCPKeepAlive yes
    ServerAliveInterval 60
    ServerAliveCountMax 10
```

• ServerAliveInterval 60 表示每 60 秒向服务器发送一次保活包。
• ServerAliveCountMax 10 表示如果连续 10 次没有收到服务器响应，则断开连接。

1. 检查系统代理/防火墙

• 如果您在公司网络或使用了代理，请确保 Git 正确配置了代理。

   # 设置 HTTP 代理
   git config --global http.proxy http://proxy.company.com:port
   # 设置 HTTPS 代理
   git config --global https.proxy https://proxy.company.com:port
   ```


---


### 稳定复现方法


要稳定复现此问题，可以模拟一个**高延迟、低带宽、易丢包**的网络环境：


1. **使用网络模拟工具**：在本地计算机上，使用如 `clumsy`（Windows）或 `netem`（Linux）等工具，人为地制造网络延迟（如 500ms）、限制带宽（如 100kbps）和丢包率（如 5%）。
2. **在这样的网络环境下**，尝试去克隆一个较大的 Git 仓库（例如 Linux Kernel 的镜像仓库）。在这种恶劣的网络条件下，很大概率会触发服务器或客户端的超时机制，从而复现 `the remote end hung up unexpectedly` 错误。


### 总结与推荐步骤


对于大多数用户，我推荐的解决步骤是：


1. **首先尝试**：切换网络、更换协议（HTTPS/SSH）。
2. **立竿见影**：设置 `http.postBuffer` 为一个较大的值（500MB）。
3. **针对大型仓库**：结合使用 `浅层克隆（--depth 1）` 和 `分批拉取（git fetch --depth ...）`。
4. **深度排查**：使用 `GIT_TRACE=1` 查看详细日志，并检查 SSH 配置或系统代理。


通过以上方法，绝大多数 “remote end hung up” 的问题都能得到有效解决。