Git Push失败：HTTP 413 Request Entity Too Large的问题排查和完整解决做法实用指南

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“Git Push失败：HTTP 413 Request Entity T……”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

引言

实际处理时，在采用 Git 推送包含较大编译产物的项目时，你是否遇到过 HTTP 413 Request Entity Too Large 错误？这通常同时不是 Git 的问题，而是 Web 服务器（如 Nginx）拒绝接收大体积请求。本文将借助一个完整案例，演示如何采用 curl 工具验证服务器限制，最后借助宝塔面板修改 Nginx 设置解决问题，实现大文件 Git 推送成功。适用来采用 Gitblit、Gitea 或任何基于 Nginx 部署的私有 Git 服务环境。

一、问题描述

在采用 Git 推送一个包含编译产物的仓库时，推送失败，报错如下所示：

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 GUI (SourceTree) 中显示：

POST git-receive-pack (287021804 bytes)
error: RPC failed; HTTP 413

二、初步分析

从实现思路看，HTTP 413 代表“请求体过大”，通常是服务端拥有上传大小限制。可能的源有两个：

• Git 服务本身限制 (Gitblit/Gitea/GitLab)
• Web 服务器如 Nginx 或 Apache 进行的前置限制

为便于确认问题所在，我们进行下面的演示性测试。

三、演示测试: curl 模拟上传

步骤1: 新建大文件 (300MB)

在 PowerShell 中执行：

fsutil file createnew bigfile.test 314572800

步骤2: 采用 curl.exe 模拟 POST 上传

curl.exe -v -X POST http://域名/ -H "Expect:" --data-binary "@bigfile.test"

结果：

HTTP/1.1 413 Request Entity Too Large
Server: nginx

确认限制来自 Nginx，Git 本身无问题。

步骤3: 新建小文件 (1KB)

fsutil file createnew smallfile.test 1024

理解这一步时，重复 curl POST 测试，结果成功，显示 Gitblit 网页内容，证明小文件能正常处理。

四、解决方案：修改 Nginx 设置 (宝塔面板)

操作步骤

1. 打开宝塔面板后台 (（链接已移除）)
2. 点击左侧「软件商店」，找到 Nginx
3. 点击「设置修改」或「设置文件」
4. 找到 http { 块，加入：

client_max_body_size 512m;  # 允许最大上传体积为 512MB

1. 保存设置
2. 回到 Nginx 设置界面，重载设置或重启 Nginx

实际设置示意图

http {
    include       mime.types;
    default_type  application/octet-stream;

    client_max_body_size 512m;

    sendfile        on;
    keepalive_timeout  60;
    ...
}

五、重试 Git 推送

理解这一步时，设置重载后，再次执行 Git push，推送包大小达 274MB，已成功，问题解决。

六、总结与建议

建议:

• 尽量不要推送编译产物 (.dll/.lib/.pdb)
• 采用 .gitignore或 Git LFS 管理大文件
• 一旦推送无法成功，优先检查 Nginx/选项设置

从实现思路看，以上就是Git Push失败：HTTP 413 Request Entity Too Large的问题排查和完整解决方法的详细内容，更多关于Git Push失败:HTTP 413 Request Entity Too Large的资料请关注脚本之家其它相关文章！