Git Push HTTP 400 에러 해결: "unexpected disconnect while reading sideband packet"

문제 상황

Local 에서 작업중인 Spring Boot Project를 git에 최초로 푸시하던 중 다음과 같은 에러가 발생했습니다.

$ git push -u origin master
Enumerating objects: 127, done.
Counting objects: 100% (127/127), done.
Delta compression using up to 10 threads
Compressing objects: 100% (102/102), done.
error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400
send-pack: unexpected disconnect while reading sideband packet
Writing objects: 100% (127/127), 1.09 MiB | 1.64 MiB/s, done. 
Total 127 (delta 26), reused 0 (delta 0), pack-reused 0
fatal: the remote end hung up unexpectedly
Everything up-to-date

| Everything up-to-date. 실제로는 push 되지 않음, 인증 문제인지, 저장소 문제인지 원인 파악이 어려움

문제 원인 분석

대용량 파일?

Github는 100MB 이상 파일을 제한하므로 먼저 Project를 확인 : X 대용량 파일이 원인이 아님 (Git)

Git HTTP Buffer 크기 제한

Writing objects: 100% 127개 파일 압축 후 1.09MB
send-pack : unexpected disconnect while reading sideband packet

실제 원인

• Git의 기본 HTTP POST Buffer 의 크기는 1MB
• 127개 파일 압축 결과가 1.09MB로 버퍼 크기 초과
• 파일 개별 크기가 작아도 전체 압축 크기가 문제가 된 것

---

Git 소스 코드로 확인하는 에러 원인

Git의 공식 소스 코드를 통해 왜 http.postBuffer 설정이 이 에러를 해결하는지 정확히 확인할 수 있습니다.

1. 기본값 정의: 약 1MB

 

 

Git 소스코드 http.c 파일에서 기본값이 정의되어 있습니다.

ssize_t http_post_buffer = 16 * LARGE_PACKET_MAX;

 

여기서 LARGE_PACKET_MAX는 pkt-line.h에 정의되어 있습니다.

#define LARGE_PACKET_MAX 65520

 

계산: 16 × 65,520 = 1,048,320 bytes ≈ 1 MiB

2. 설정값 처리 로직

사용자가 git config http.postBuffer로 값을 설정하면 다음 코드가 처리합니다.

if (! strcmp("http.postbuffer", var)) {
    http_post_buffer = git_config_ssize_t(var, value, ctx->kvi);
    if (http_post_buffer < 0)
        warning(_("negative value for http.postBuffer; defaulting to %d"), LARGE_PACKET_MAX);
    if (http_post_buffer < LARGE_PACKET_MAX)
        http_post_buffer = LARGE_PACKET_MAX;
    return 0;
}

 

핵심 포인트:

• LARGE_PACKET_MAX(65,520 bytes)보다 작은 값을 설정해도 자동으로 최소값으로 조정됨
• 음수 값 설정 시 경고 메시지 출력

3. 버퍼 크기 초과 시 동작

remote-curl.c의 post_rpc 함수에서 push 데이터가 버퍼를 초과하면 large_request 플래그가 설정됩니다.

static int post_rpc(struct rpc_state *rpc, int stateless_connect, int flush_received)
{
    // ... 
    int err, large_request = 0;

    /* Try to load the entire request, if we can fit it into the
     * allocated buffer space we can use HTTP/1.0 and avoid the
     * chunked encoding mess.
     */
    if (! flush_received) {
        while (1) {
            size_t n;
            enum packet_read_status status;

            if (! rpc_read_from_out(rpc, 0, &n, &status)) {
                large_request = 1;  // Buffer Overflow  
                use_gzip = 0;
                break;
            }
            if (status == PACKET_READ_FLUSH)
                break;
        }
    }

4. 버퍼 공간 부족 감지

rpc_read_from_out 함수에서 남은 버퍼 공간이 LARGE_PACKET_MAX보다 작으면 0을 반환합니다.

static int rpc_read_from_out(struct rpc_state *rpc, int options,
                             size_t *appended,
                             enum packet_read_status *status) {
    size_t left;
    // ... 

    if (rpc->write_line_lengths) {
        left = rpc->alloc - rpc->len - 4;
        buf = rpc->buf + rpc->len + 4;
    } else {
        left = rpc->alloc - rpc->len;
        buf = rpc->buf + rpc->len;
    }

    if (left < LARGE_PACKET_MAX)
        return 0;  // ⚠️ 공간 부족 → large_request = 1 설정됨

 

5. 버퍼 할당

실제 버퍼는 rpc_service 함수에서 http_post_buffer 값만큼 할당됩니다.

rpc->alloc = http_post_buffer;
rpc->buf = xmalloc(rpc->alloc);
rpc->in = client. in;

 

6. 공식 문서 설명

Git 공식 문서에서도 이 설정에 대해 명확히 설명하고 있습니다.

http. postBuffer:: 
    Maximum size in bytes of the buffer used by smart HTTP
    transports when POSTing data to the remote system. 
    For requests larger than this buffer size, HTTP/1.1 and
    Transfer-Encoding: chunked is used to avoid creating a
    massive pack file locally.  Default is 1 MiB, which is
    sufficient for most requests. 
+
Note that raising this limit is only effective for disabling chunked
transfer encoding and therefore should be used only where the remote
server or a proxy only supports HTTP/1.0 or is noncompliant with the
HTTP standard.  Raising this is not, in general, an effective solution
for most push problems, but can increase memory consumption
significantly since the entire buffer is allocated even for small
pushes.

 

동작 흐름 다이어그램

┌─────────────────────────────────────────────────────────────────┐
│                    Git Push HTTP 전송 흐름                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. 커밋 데이터 압축 (예: 1. 09 MB)                                 │
│           ↓                                                     │
│  2. http_post_buffer 크기 확인 (기본값: ~1 MB)                      │
│           ↓                                                     │
│  3. 데이터 크기 > 버퍼 크기?                                         │
│           ↓                                                     │
│     ┌─────┴─────┐                                               │
│     │ YES       │ NO                                            │
│     ↓           ↓                                               │
│  large_request=1   단일 HTTP POST 요청                            │
│     ↓                    ↓                                      │
│  Chunked Transfer     정상 전송 완료 ✓                             │
│  Encoding 사용                                                   │
│     ↓                                                           │
│  서버/프록시가 HTTP/1.1 Chunked 미지원?                              │
│     ↓                                                           │
│  HTTP 400 에러 발생!  ✗                                           │
│                                                                 │
│  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  │
│  해결:  http.postBuffer 값 증가                                    │
│        → 버퍼 크기 > 데이터 크기                                     │
│        → 단일 HTTP POST 요청으로 전송                               │
│        → Chunked Encoding 우회                                   │
└─────────────────────────────────────────────────────────────────┘

주의사항

공식 문서에서 말하듯이 http.postBuffer를 무조건 늘리는 것이 해결책은 아니다.

"Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes."

의미:

• 버퍼 값을 늘리면 모든 push 작업에서 해당 크기만큼 메모리가 할당됨 (작은 push도 마찬가지)
• 효과는 오직 Chunked Transfer Encoding을 비활성화하는 것
• 서버나 프록시가 HTTP/1.1을 제대로 지원하지 않을 때만 효과적

---

해결 방법

해결책 : HTTP Buffer 크기 증가

# 10MB
git config http.postBuffer 10485760

# Push
git push -u origin master

# 정말 간단하게 이번 push에서만 변경할 수 있다.
git -c http.postBuffer=10485760 push -u origin master

결과

Branch 'master' set up to track remote branch 'master' from 'origin'.
To https://github.com/shchae04/biz-*... 

설정 확인 및 관리

해결 후 설정 원복 - 권장
문제가 해결되었다면 버퍼 크기를 기본값으로 되돌리는 것이 좋다.

# 설정 삭제 (기본값 1MB)
git config --global --unset http.postBuffer

# 현재 설정 확인 
git config http.postBuffer

왜 원복해야 하는지?

- 대부분의 push는 1MB 미만
- 버퍼 크기만큼 매 push마다 메모리 할당
- 10MB 설정 유지 시, 작은 커밋 하나에도 10MB 메모리 사용

대용량 push가 필요하다면, 임시 설정으로 처리하는 게 더 효율적.,

git -c http.postBuffer=10485760 push -u origin master

---

추가 해결 방법

HTTP -> SSH 사용

SSH는 HTTP Buffer 크기 제한이 없음

# SSH URL 변경
git remote set-url origin git@github.com:shchae04/biz-*... 

# SSH Push
git push -u origin master

그렇다고 SSH 사용이 항상 HTTP 보다 장점이 있을까?

장점

• HTTP Buffer 크기 제한 없음
• 안정적인 전송
• git 인증 토큰 만료 문제 X

단점

• SSH 키 설정 필요
• SSH(22) port 막힌 경우 사용 불가
• Github Enterprise에서 SSH 비활성화된 경우 존재함

다른 방법

Git LFS

# Git LFS 설치
$ git lfs install

# 대용량 파일 타입 추적
$ git lfs track "*.psd"
$ git lfs track "*.zip"

---

요약

문제	원인	해결책
HTTP 400 에러	Git HTTP 버퍼(1MB) 초과	git config http.postBuffer 10485760
대용량 전송	HTTP 프로토콜 제한	HTTPS → SSH로 변경

---

참고 자료

• Git Documentation: http.postBuffer
• GitHub: About large files
• Git LFS
• Git 소스코드 - http.c
• Git 소스코드 - remote-curl.c

---

환경 정보:

• OS: macOS (Sequoia 15.3.1)
• Git 버전: 2.x
• 프로젝트: Spring Boot 3.5.3 + Gradle