一、问题现象

在执行 git push 推送大量代码/大体积提交记录时，终端抛出完整报错信息，本地打包成功、上传远端失败，报错日志如下： Total 1000 (delta 151), reused 1000 (delta 151), pack-reused 0 (from 0) error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 send-pack: unexpected disconnect while reading sideband packet fatal: the remote end hung up unexpectedly 核心特征：本地 Git 打包完成（生成1000个提交对象），无本地代码问题，上传阶段被远端拦截断开。

二、报错根因解析

1. 核心错误码含义

HTTP 413 = Payload Too Large（请求体过大） HTTP 协议对单次请求包体大小有限制，本次推送的 Git 打包文件体积超过了反向代理（Nginx）或代码仓库服务的限制，服务端直接拒绝连接、断开推送。

2. 衍生报错说明

send-pack: unexpected disconnect：连锁报错，服务端拦截后强制断开数据传输通道
fatal: the remote end hung up unexpectedly：远端服务主动关闭连接，推送终止
pack-reused 0：本次需要完整上传所有打包对象，无复用数据，包体体积极大

3. 常见误区（90%开发者踩坑）

很多人仅配置客户端 Git 缓冲区，无法根治问题： git config --global http.postBuffer 1G 该参数仅修改本地客户端内存缓冲区，无法突破服务端 Nginx、Git 仓库的上传大小限制，因此配置后依然报错。

三、分层解决方案（从简易到根治，按顺序执行）

方案一：临时客户端优化（缓解问题）针对当前仓库调大 HTTP 传输缓冲区，不影响全局配置：

设置当前仓库缓冲区为1G

git config http.postBuffer 1073741824

关闭压缩，减少传输异常

git config http.compression 0 git config core.compression 0 方案二：分批增量推送（无需改服务配置）一次性推送上千个提交包体过大，拆分批次推送，规避413拦截：

先推送部分提交（按需调整数值，500/300均可）

git push origin HEAD~500:main

推送剩余所有提交

git push origin main 适用场景：无服务器权限、临时紧急推送代码。方案三：大文件专项处理（存在二进制文件必做）若仓库包含压缩包、镜像、二进制文件，普通 Git 无法承载，必须使用 Git LFS 托管大文件：

安装LFS

git lfs install

托管常见大文件格式

git lfs track ".zip" ".tar" ".iso" ".bin" "*.pdf"

提交配置文件

git add .gitattributes git commit -m "feat: 开启大文件LFS托管" git push 方案四：Nginx服务端配置修复（自建Git仓库核心解法）如果是自建 GitLab / Gitea + Nginx 反向代理环境，必须修改 Nginx 配置放开请求体限制，这是本地配置无法替代的核心步骤。

配置文件位置 & 写法找到站点配置文件（路径一般为 /etc/nginx/conf.d/xxx.conf 或 /etc/nginx/sites-available/xxx.conf）将 client_max_body_size 1G; 写入 server 层级（核心！不要写在 location 内）： server { listen 80; server_name 你的Git服务域名;

核心配置：放开最大请求体为1G

client_max_body_size 1G;

location / { proxy_pass http://127.0.0.1:3000; # 你的Git服务内网地址 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }
GitLab专属特殊配置（Omnibus安装）官方一键安装的 GitLab，禁止直接改 Nginx 配置，需修改专属配置文件：编辑 /etc/gitlab/gitlab.rb

放开Nginx上传限制

nginx['client_max_body_size'] = '1G' 重载配置生效： gitlab-ctl reconfigure 3. 配置校验 & 生效命令

校验Nginx配置语法是否正确

nginx -t

重载Nginx（不中断服务）

systemctl reload nginx 方案五：终极根治：HTTPS切换SSH协议 HTTP/HTTPS 协议天生存在请求体大小限制，而 SSH 协议无此限制，彻底规避413报错，适用于所有场景。

替换仓库远程地址为SSH地址

git remote set-url origin git@你的仓库地址:项目路径.git

正常推送

git push 前提：本地配置 SSH 密钥，并将公钥添加至代码仓库平台。四、补充：Git服务本身限制优化修改Nginx后仍报错，需同步放开Git服务内部限制：

Gitea：配置文件设置 [repository] MAX_PUSH_SIZE = 1024（单位MB）
GitLab：后台项目设置 → 通用 → 限制 → 调大「最大推送大小」五、问题排查总结

快速排错逻辑
本地打包成功、上传失败 → 100% 是服务端拦截
公网平台（GitHub/Gitee）→ 直接换SSH/分批推送
自建Git平台 → 优先修改Nginx client_max_body_size
存在大文件 → 必须启用Git LFS
避坑清单

不要只改客户端 http.postBuffer，无法突破服务端限制
client_max_body_size 必须配置在 Nginx server 层级
禁止将大二进制、压缩包直接提交Git仓库，必须LFS托管六、最终最优解决方案长期使用推荐：SSH协议 + Git LFS托管大文件 + 服务端放开上传限制，彻底杜绝413报错，适配所有大小的代码推送场景。

注意：本文归作者所有，未经作者允许，不得转载

Git Push 报错413完整解决方案：RPC failed、send-pack断开、远端挂断问题根治