The response ended prematurely 에러 : 응답을 받기 전에 연결이 닫힌다는 것

🚩개요

외부 서버로 HTTP 요청을 보내는 서비스를 운영하다 보면 대부분의 실패는 익숙한 얼굴입니다. 타임아웃이 나거나, 4xx·5xx 상태 코드가 돌아오거나, 응답 형식이 바뀌어 파싱이 깨집니다.

그런데 최근 에러 로그에서 상태 코드조차 없는, 처음 보는 에러를 만났습니다.

The response ended prematurely. (ResponseEnded)

“응답이 조기에 종료되었다”는 뜻인데, 타임아웃도 아니고 서버가 에러를 응답한 것도 아닙니다.

그래서 이번 글에서는 이 에러가 HTTP 요청의 어느 단계에서, 어떤 방식으로 끊어졌다는 뜻인지, 그리고 왜 하필 POST 요청에서 드러났는지 정리해보겠습니다. 에러 메시지는 .NET(HttpClient)의 것이지만, 내용의 대부분은 TCP·HTTP 이야기라 다른 언어를 쓰시는 분들께도 도움이 될 것 같습니다.

 

 

 

1️⃣ HTTPS 요청 한 번이 거치는 단계

에러를 이해하려면 먼저 요청 한 번이 어떤 단계를 거치는지 알아야 합니다. https:// 로 시작하는 주소에 요청을 보내면 클라이언트는 다음 순서로 일을 합니다.

 

[그림 1] HTTPS 요청 한 번이 거치는 5단계와 이번 에러의 위치

 

HTTP 상태 코드는 5단계에서 응답의 첫 줄(상태 라인)을 받아야만 알 수 있습니다. 그 전에 문제가 생기면 상태 코드는 존재하지 않고, 대신 “어느 단계에서 실패했는가”가 에러의 정체가 됩니다.

 

 

.NET 8부터는 이 구분을 HttpRequestError 라는 열거형으로 제공합니다. 공식 문서에 정의된 값 중 일부를 단계에 맞춰 보면 다음과 같습니다.

단계	HttpRequestError	공식 문서의 설명
1. DNS	NameResolutionError (1)	DNS 이름 확인에 실패
2. TCP	ConnectionError (2)	원격 엔드포인트에 연결하는 동안 전송 수준 오류 발생
3. TLS	SecureConnectionError (3)	TLS 핸드셰이크 중 오류 발생
5. 응답	InvalidResponse (9)	유효하지 않거나 형식이 잘못된 응답을 수신
5. 응답	ResponseEnded (10)	응답이 조기에 종료됨

이번에 만난 에러는 ResponseEnded, 즉 1~4단계는 모두 지나고 5단계 응답 수신에서 일어난 일입니다.

 

 

 

2️⃣ 로그와 에러의 의미

2-1. 로그

외부 사이트에 조회 요청(POST)을 보내다가 발생했습니다. 예외 체인에서 핵심만 추리면 다음과 같습니다.

 

System.Net.Http.HttpRequestException
  : An error occurred while sending the request.
 ---> System.Net.Http.HttpIOException
  : The response ended prematurely. (ResponseEnded)

   at System.Net.Http.HttpConnection.SendAsync(...)

이 요청의 타임아웃은 6초였는데, 실패까지 걸린 시간은 약 0.6초였습니다. 즉 타임아웃이 아닙니다. 기다리다 지친 것이 아니라, 금방 “끝”을 통보받은 것입니다.

 

2-2. SocketException 이 없다는 것이 단서

이 로그에서 눈에 띄는 점이 있습니다. 네트워크가 끊겼을 때 흔히 따라오는 SocketException 이 예외 체인 어디에도 없습니다. 소켓 계층에서는 아무 에러도 나지 않았다는 뜻입니다.

.NET 런타임 소스(HttpConnection.cs)에서 이 예외를 던지는 곳을 보면 이유를 알 수 있습니다. 응답을 읽으려고 소켓에서 read 를 했는데 읽은 바이트 수가 0이면 이 예외를 던집니다.

 

// dotnet/runtime (v8.0.0) HttpConnection.cs 에서 발췌
if (bytesRead == 0)
{
    throw new HttpIOException(HttpRequestError.ResponseEnded, SR.net_http_invalid_response_premature_eof);
}

소켓에서 0바이트 읽기는 에러가 아니라 EOF, 즉 상대가 FIN 으로 연결을 정상 종료했다는 신호입니다. TCP 입장에서는 아무 문제 없는 깔끔한 종료입니다. 하지만 HTTP 입장에서는 요청을 보냈는데 응답이 완성되기 전에 스트림이 끝났으니 비정상입니다.

TCP 연결이 끝나는 방식은 두 가지인데, 받는 쪽에서 보이는 모습이 서로 다릅니다.

 

 

이번 로그는 FIN 쪽입니다. 반대로 RST 로 끊기면 SocketException 이 예외 체인에 나타나는데, 이 차이는 다음 글(The SSL connection could not be established 편)에서 자세히 다룹니다.

 

 

HTTP/1.1 표준(RFC 9112 8절)은 이를 불완전한 메시지(incomplete message) 로 다룹니다. 연결이 조기에 닫혀 불완전한 응답을 받은 클라이언트는 그 메시지를 불완전한 것으로 기록해야 합니다. .NET 은 그것을 ResponseEnded 라는 에러로 표현합니다.

이 에러의 정체는 “요청을 보냈는데, 응답을 다 받기 전에 상대가 연결을 (정상적으로) 닫았다” 입니다.

이 예외는 응답 본문을 읽는 도중에도 발생할 수 있지만, 이번 로그의 스택 트레이스는 HttpConnection.SendAsync, 즉 응답의 상태 라인과 헤더를 받는 구간입니다. 응답 헤더를 다 받기도 전에 연결이 닫힌 것입니다.

 

 

 

3️⃣ 왜 닫혔을까

3-1. 원인 후보 ① : Keep-Alive 연결의 경쟁 상태

HTTP/1.1 은 기본적으로 지속 연결(persistent connection) 을 사용합니다. 요청마다 TCP 연결과 TLS 핸드셰이크를 새로 하면 비싸기 때문에, 한 번 맺은 연결을 닫지 않고 다음 요청에 재사용합니다. 클라이언트는 이런 연결들을 커넥션 풀에 보관합니다.

문제는 서버도 한가한 연결을 무한정 들고 있지는 않는다는 점입니다. RFC 9112 9.5절은 서버가 보통 비활성 연결을 유지하는 타임아웃 값을 가지며, 클라이언트·서버·프록시는 언제든지 전송 연결을 닫을 수 있다고 말합니다.

그리고 바로 이 상황을 예로 듭니다. 서버가 “유휴” 연결을 닫기로 결정한 것과 같은 시점에 클라이언트가 새 요청을 보내기 시작할 수 있다는 것입니다. 서버가 보기에는 유휴 상태의 연결을 닫은 것이지만, 클라이언트가 보기에는 요청이 진행 중인 연결이 닫힌 것이 됩니다.

 

[그림 3] 유휴 연결을 사이에 두고 새 요청과 FIN 이 엇갈리는 경우

 

.NET 런타임 소스에도 해당 위치에 “서버가 자기 쪽에서 연결을 종료했고, 유휴 타임아웃 때문일 가능성이 높다”는 주석이 달려 있습니다(바로 아래 3-2의 코드). 런타임 개발자들도 이 상황의 대표적인 원인으로 유휴 연결 종료를 꼽고 있다는 뜻입니다.

 

 

물론 .NET 도 손을 놓고 있지는 않습니다. 풀에서 연결을 꺼낼 때 그 연결이 이미 닫혔는지(EOF 를 받았는지) 확인하고, 닫힌 연결은 쓰지 않습니다. 하지만 확인한 직후부터 요청이 서버에 도착하기 전 사이에 서버가 닫아버리는 경우는 클라이언트가 원천적으로 막을 수 없습니다.

 

3-2. 그럼 자동으로 재시도해 주면 되지 않나?

실제로 해줍니다. 단, 조건이 있습니다. 이번 로그의 스택에 찍힌 SendAsync 안에 이런 분기가 있습니다.

 

// dotnet/runtime (v8.0.0) HttpConnection.cs (SendAsync) 에서 발췌
if (_readBuffer.ActiveLength == 0)
{
    // The server shutdown the connection on their end, likely because of an idle timeout.
    // If we haven't started sending the request body yet (or there is no request body),
    // then we allow the request to be retried.
    if (request.Content is null || allowExpect100ToContinue is not null)
    {
        _canRetry = true;
    }

    throw new HttpIOException(HttpRequestError.ResponseEnded, SR.net_http_invalid_response_premature_eof);
}

응답을 한 바이트도 받지 못한 채 연결이 닫혔고, 요청 본문이 없거나 아직 본문을 보내기 전이라면 재시도 가능으로 표시합니다. 그러면 커넥션 풀이 예외를 삼키고 새 연결로 요청을 다시 보냅니다. 호출한 쪽은 그런 일이 있었는지도 모릅니다.

반대로 본문이 있는 요청은 이미 본문을 보냈을 수 있으므로 재시도하지 않고 예외를 그대로 올립니다. 이번에 실패한 요청이 정확히 본문이 있는 POST 였습니다. GET 요청에서는 조용히 넘어가던 상황이, POST 에서는 에러로 드러난 것입니다.

 

 

이 동작은 HTTP 표준과도 맞닿아 있습니다. RFC 9110 9.2.2절은 다음과 같이 정리합니다.

• 멱등(idempotent) 메서드(GET, HEAD, PUT, DELETE 등)는 응답을 읽기 전에 통신 장애가 나면 자동으로 다시 보낼 수 있다.
• 멱등하지 않은 메서드(POST 등)는 요청의 의미가 실제로는 멱등하다는 것을 알거나, 원래 요청이 적용되지 않았음을 확인할 수단이 없는 한 자동 재시도하지 않아야 한다(SHOULD NOT).

이유는 단순합니다. 클라이언트는 서버가 요청을 처리했는지 알 수 없기 때문입니다. 요청이 도착하기 전에 닫혔을 수도 있고, 처리를 끝내고 응답을 보내려다 죽었을 수도 있습니다. “결제” 같은 요청을 무턱대고 다시 보내면 두 번 처리될 수 있습니다.

 

3-3. 원인 후보 ② : 서버가 요청을 보고 닫은 경우

유휴 연결 경쟁이 유일한 원인은 아닙니다. 응답을 보내기 전에 연결을 닫는 상황이면 무엇이든 같은 에러가 됩니다.

• 서버 애플리케이션이 요청을 처리하다 비정상 종료되거나 재시작된 경우
• 서버 앞단의 프록시·로드밸런서가 백엔드 문제로 응답 없이 연결을 닫은 경우
• 서버나 보안 장비가 요청 내용을 보고 응답 없이 연결을 닫아버린 경우

클라이언트 예외만으로는 이 연결이 풀에서 재사용된 것이었는지 알 수 없으므로, 발생 패턴으로 구분합니다.

• 간헐적이고, 한동안 요청이 없다가 보낸 요청에서 주로 난다 → 유휴 연결 경쟁
• 특정 요청에서 매번 난다 → 서버가 그 요청을 처리하지 못하거나 거부하는 것
• 특정 시간대에 몰려서 난다 → 서버 배포·재시작·장애

 

해당 에러는 로그에서 집계해 봤을때 매우 간헐적으로 일어났기 때문에 일단은 "유휴 연결 경쟁"로 결론 지었습니다.

 

 

4️⃣ 대응 방법

① 클라이언트의 유휴 타임아웃을 서버보다 짧게

경쟁 상태는 “서버가 먼저 닫는” 구조에서 생깁니다. 클라이언트가 서버보다 먼저 유휴 연결을 버리면 창이 크게 줄어듭니다. .NET 에서는 SocketsHttpHandler 의 두 속성이 관련됩니다.

속성	의미	기본값
PooledConnectionIdleTimeout	연결이 풀에서 유휴 상태로 있어도 재사용 가능하다고 보는 최대 시간	.NET 6 이상 1분 (.NET Core, .NET 5 는 2분)
PooledConnectionLifetime	연결이 수립된 시점부터 풀에서 재사용 가능하다고 보는 최대 시간	무제한

 

var handler = new SocketsHttpHandler
{
    // 상대 서버의 keep-alive 타임아웃보다 짧게
    PooledConnectionIdleTimeout = TimeSpan.FromSeconds(30),
    // 연결을 주기적으로 새로 맺어 DNS 등 네트워크 변화도 반영
    PooledConnectionLifetime = TimeSpan.FromMinutes(2),
};
var client = new HttpClient(handler);

위 숫자는 예시일 뿐이고, 상대 서버의 유휴 타임아웃에 맞춰 정해야 합니다. 참고로 PooledConnectionLifetime 은 Microsoft 의 HttpClient 가이드라인에서 DNS 변경을 반영하기 위해 설정을 권장하는 값이기도 합니다. HttpClient 는 연결을 만들 때만 DNS 를 조회하기 때문입니다.

 

 

② 재시도는 “다시 보내도 되는 요청인가”를 판단한 뒤에

설정으로 창을 줄여도 0 이 되지는 않습니다. RFC 9112(9.3.1절)도 구현체는 예고 없는 연결 종료로부터 복구할 필요를 예상해야 한다고 말합니다. 결국 재시도가 필요합니다.

 

 

런타임이 POST 를 자동 재시도하지 않는 이유는 그 요청이 안전한지 런타임은 모르기 때문입니다. 하지만 애플리케이션은 압니다. RFC 9110 도 요청이 해당 리소스에 대해 안전하다는 것을 (설계나 설정을 통해) 알고 있다면 POST 를 자동으로 반복할 수 있다고 적고 있습니다.

메서드는 POST 지만 실제로는 조회만 하는 요청이라면 재시도해도 됩니다. 반대로 상태를 바꾸는 요청이라면 멱등키 같은 장치 없이는 재시도하면 안 됩니다.

 

try
{
    return await client.SendAsync(request, cancellationToken);
}
catch (HttpRequestException e) when (IsResponseEnded(e) && isSafeToRetry)
{
    // 새 연결로 다시 시도 (요청 객체는 새로 만들어야 함)
}

static bool IsResponseEnded(HttpRequestException e) =>
    e.HttpRequestError == HttpRequestError.ResponseEnded ||
    e.InnerException is HttpIOException { HttpRequestError: HttpRequestError.ResponseEnded };

에러 메시지 문자열을 비교하는 대신 HttpRequestError 값으로 분기할 수 있다는 점이 .NET 8 이후의 장점입니다. 재시도 설계 자체는 이전에 쓴 글들을 참고해 주세요.

• 백엔드 시스템에서의 타임아웃(Timeout)에 대한 이해와 설계 기준
• Timeout·Retry·Fallback 실패 처리 체계
• Jitter(지터)의 이해와 다양한 실무 활용법

 

 

 

5️⃣ 결과 및 배운 점

1. 상태 코드가 없는 에러는 “단계”로 분류한다

• DNS, TCP, TLS, 요청, 응답 중 어디에서 끊겼는지가 곧 원인 후보의 범위입니다.

2. 예외 체인에 무엇이 “없는지”도 단서다

• SocketException 이 없다는 것은 소켓 에러 없이 0바이트 읽기(EOF)로 끝났다는 뜻이고, 상대가 FIN 으로 닫았다는 뜻입니다.

3. 연결은 언제든 끊길 수 있고, 그것은 표준이 허용한 동작이다

• Keep-Alive 연결의 경쟁 상태는 버그가 아니라 구조적으로 존재하는 틈입니다. 클라이언트는 이를 전제로 설계해야 합니다.

4. 재시도의 기준은 “실패했는가”가 아니라 “다시 보내도 되는가”다

• 런타임이 GET 은 조용히 재시도하고 본문이 있는 POST 는 그대로 예외를 올리는 이유가 여기에 있습니다.

5. 연결 설정만 보지 말고 실제로 보낸 요청도 본다

• 요청을 받은 뒤에 닫혔다면, 상대가 그 요청의 무엇을 보고 닫았는지도 원인 후보입니다.

 

이 글이 비슷한 에러를 처음 만난 분들에게 도움이 되었으면 합니다.

 

 

 

참고 자료

• Microsoft Learn - HttpClient guidelines for .NET
• Microsoft Learn - SocketsHttpHandler.PooledConnectionIdleTimeout
• Microsoft Learn - SocketsHttpHandler.PooledConnectionLifetime
• dotnet/runtime v8.0.0 - HttpConnection.cs
• RFC 9112 - HTTP/1.1 (8. Handling Incomplete Messages, 9.3.1 Retrying Requests, 9.5 Failures and Timeouts)