IIS HTTP Err Connection_Dropped 오류의 원인 분석과 실제 해결 사례

IIS HTTPERR 로그의 Connection_Dropped 오류란?

IIS 서버를 운영하다 보면 HTTPERR 로그에서 Connection_Dropped 메시지를 확인할 때가 있습니다. 많은 개발자와 운영자들이 이 오류를 서버 문제로 오해하지만, 실제로는 거의 대부분 클라이언트 측에서 연결을 먼저 끊는 경우에 발생하는 현상입니다.

Connection_Dropped
서버가 최종 응답을 보내기 전에 클라이언트가 먼저 연결을 종료한 경우 발생한다.

즉, 서버가 응답을 보내려는 순간 이미 클라이언트가 떠났기 때문에 서버에서는 “전송할 곳이 없음” 상태가 되어 오류처럼 기록되는 것입니다.

---

문제 상황: 피크타임에 Connection_Dropped 증가

대형 서비스를 운영하던 중, 어느 날 피크타임에 Connection_Dropped 로그가 폭증했고 특히 안드로이드 모바일 웹에서 페이지 로딩 실패가 빈번하게 발생했습니다.

• iPhone에서는 문제 없음
• Android 브라우저(특히 WebView 포함)가 연결을 빨리 끊는 경향
• 고객 VOC 폭주 예상 → 빠른 원인 분석 필요

---

1차 점검: 서버·네트워크 문제 아님

처음에는 서버 문제라고 생각했습니다.

• 리소스 누수 여부 점검 → 문제 없음
• HTTPS 부담을 줄이려고 HTTP로 전환 → 변화 없음
• IIS 튜닝/커넥션 제한 조정 → 효과 없음

Google과 기술 문서를 아무리 찾아봐도 Connection_Dropped의 정확한 원인을 찾기 어려웠습니다. 결국 직접 소스 레벨 모니터링을 하며 문제를 추적했습니다.

---

원인 발견: 비정상적인 ServerXMLHTTP 타임아웃 설정

문제는 특정 비동기 처리 코드에서 발생했습니다.

Set objXmlHttp  = Server.CreateObject("Msxml2.ServerXMLHTTP.3.0")
objXmlHttp.setTimeouts 1000000, 1000000, 1000000, 1000000

1000000ms(=1000초)라는 비정상적으로 큰 타임아웃 값이 설정되어 있었던 것입니다.

이 코드는 평소에는 문제가 잘 보이지 않았지만, 트래픽이 급증하는 피크타임에 하나의 요청이 길게 잠기면서 Connection Queue를 압박했고, 대기하던 모바일 클라이언트가 시간 초과로 연결을 먼저 끊어버리는 현상을 유발했습니다.

→ 즉, 표면적으로는 “클라이언트가 연결을 끊었다”이지만 실제 근본 원인은 서버 내부의 비효율적인 타임아웃 설정이었습니다.

---

해결 방법: 정상적인 타임아웃 값으로 수정

문제가 된 코드를 모두 찾아 다음과 같이 수정했습니다.

xmlhttp.setTimeouts 5000, 60000, 10000, 10000

※ 의미

• ResolveTimeout = 5000ms
• ConnectTimeout = 60000ms
• SendTimeout = 10000ms
• ReceiveTimeout = 10000ms

정상적인 타임아웃 값으로 조정한 후 모니터링 결과:

• 피크타임 Connection_Dropped 로그 → 거의 사라짐
• w3wp.exe의 TCP 커넥션 수 → 250 → 60 수준으로 감소
• 모바일 웹 로딩 실패 현상 → 해결

소스 코드에서 타임아웃을 과도하게 길게 잡아둔 것이 피크 타임 서비스 장애를 유발한 것입니다.

---

정리: Connection_Dropped의 올바른 해석

• Connection_Dropped는 “서버 문제”처럼 보이지만 대부분 클라이언트가 먼저 끊은 연결이다.
• 하지만 근본 원인은 서버 내부 코드나 타임아웃 설정이 원인이 될 수 있다.
• ServerXMLHTTP / WebRequest 등 외부 호출이 병목을 만들면 클라이언트 대기 시간이 길어져 연결을 끊게 된다.
• 특히 모바일 브라우저는 대기 시간이 길면 매우 빠르게 접속을 종료한다.

📌 결론

Connection_Dropped는 “클라이언트가 먼저 끊은” 결과일 뿐이며, 원인 자체는 서버 내부 병목일 수 있다.

따라서 반드시 다음을 점검해야 한다:

• 서버 내부 외부 API 호출 타임아웃
• DB 쿼리 지연
• 불필요하게 길어진 비동기 호출
• 스레드 풀 부족
• Connection Queue 증가

이번 사례처럼 단순한 타임아웃 설정 하나로 대형 서비스 장애가 발생할 수 있으니, 실제 운영 환경에서는 주기적인 모니터링이 중요합니다.

(2025년 업데이트)