ERR_CONNECTION_CLOSED와 ERR_CONNECTION_RESET의 차이는?

서로 다른 TCP 패킷에 대응합니다. Chromium의 net_error_list.h는 ERR_CONNECTION_CLOSED(-100)를 TCP FIN으로 닫힌 연결 — 정중한 '끝났다' — 으로, ERR_CONNECTION_RESET(-101)을 TCP RST로 재설정된 연결 — 거친 강제 종료 — 으로 정의합니다. CLOSED는 응답이 끝나기 전에 무언가가 깨끗이 연결을 마쳤다는 뜻이고, RESET은 거칠게 끊어냈다는 뜻입니다.

같은 페이지가 어떨 땐 되고 어떨 땐 ERR_CONNECTION_CLOSED가 나는 이유는?

간헐적 종료는 보통 keep-alive와 타임아웃 설정을 가리킵니다. 유휴·느린 연결을 닫는 서버(또는 프록시) — Apache의 KeepAliveTimeout, nginx의 client_header_timeout — 는 FIN을 보내고, 재사용되던 연결에서 그 FIN을 만난 Chrome이 ERR_CONNECTION_CLOSED를 표시합니다. URL이 아니라 타이밍에 좌우되니 무작위처럼 보입니다.

백신이나 VPN이 ERR_CONNECTION_CLOSED를 일으킬 수 있나요?

네. HTTPS를 검사하는 보안 소프트웨어는 TLS 핸드셰이크 중간에 끼어듭니다. 그 가로채기 인증서를 서버가 신뢰하지 않거나 핸드셰이크가 마음에 들지 않으면 연결을 닫고 — 브라우저는 백신이 아니라 FIN을 봅니다. HTTPS 검사를 잠시 끄는 것이 이 원인을 가장 빠르게 가려냅니다.

조회수: 18

ERR_CONNECTION_CLOSED 해결 체크리스트

ERR_CONNECTION_CLOSED는 요청 도중 TCP FIN으로 연결이 닫혔다는 뜻입니다. TLS, keep-alive, 백신, 도달성 4가지를 점검. 무료 즉시 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

Chrome이 빈 페이지와 함께 이 사이트에 연결할 수 없음, 상세에 ERR_CONNECTION_CLOSED(때로 net::ERR_CONNECTION_CLOSED)를 표시합니다.

Symptoms

오류가 간헐적입니다 — 새로고침하면 될 때도, 안 될 때도 있습니다.
다른 사이트는 멀쩡하니 네트워크 전체 문제는 아닙니다.
VPN, 새 백신, 또는 서버 설정 변경 이후 시작됐습니다.

ERR_CONNECTION_CLOSED가 실제로 뜻하는 것

오류 이름이 정확하고, 그 정확함이 곧 진단입니다. Chromium의 net_error_list.h는 ERR_CONNECTION_CLOSED(-100)를 “A connection was closed (corresponding to a TCP FIN).”으로 정의합니다. FIN은 TCP 연결을 끝내는 정중한 방식입니다 — 한쪽이 “보낼 건 다 보냈다”라고 말하는 것이죠. 문제는 타이밍입니다 — 그 FIN이 Chrome이 아직 응답을 기다리는 중에 도착했습니다. 경로상의 무언가가, 실제로는 끝나지 않은 대화를 끝났다고 판단한 겁니다.

이 한 가지 사실이 많은 것을 배제합니다. DNS 문제가 아니고(이름은 해석됐습니다), 거부된 연결도 아닙니다(거부는 ERR_CONNECTION_REFUSED, -102, 연결 시점의 RST나 ICMP). 연결은 수립될 만큼 진행됐다가 도중에 닫혔습니다. 시끄러운 사촌인 ERR_CONNECTION_RESET(-101)은 TCP RST — 정중한 FIN이 아니라 거친 재설정입니다. 그리고 ERR_EMPTY_RESPONSE(-324)는 “the server closed the connection without sending any data”, 즉 한 바이트의 응답도 오기 전에 도착한 더 이른 FIN입니다. 이 중 어느 것인지 알면 어디를 봐야 할지가 정해집니다.

Top 3 Causes

보안 소프트웨어의 TLS 가로채기 - HTTPS를 검사하는 백신, 회사 프록시, VPN이 핸드셰이크에 끼어듭니다. 서버가 그 인증서나 재작성된 핸드셰이크를 거부하면 연결이 닫히고 Chrome은 FIN을 표시합니다. 간헐적이고 특정 기기에서만 나는 ERR_CONNECTION_CLOSED의 가장 흔한 원인입니다.
서버 keep-alive·타임아웃이 연결을 닫음 - 브라우저는 연결을 재사용합니다. 서버나 리버스 프록시가 유휴·느린 연결을 닫으면 — Apache의 KeepAliveTimeout·MaxKeepAliveRequests, nginx의 client_header_timeout·keepalive_timeout — 재사용된 소켓의 다음 요청이 FIN을 만납니다. 페이지가 아니라 연결의 나이에 좌우되니 무작위처럼 보입니다.
오리진이나 미들박스가 연결을 끊음 - 방화벽 규칙, 과부하된 백엔드, 경로상의 MTU·프로토콜 불일치가 연결을 도중에 끊을 수 있습니다. 이 경우 종료는 내 기기가 아니라 네트워크에서 오며, 여러 클라이언트에서 재현되는 경향이 있습니다.

Diagnose with DechoNet

HTTP Check를 내 네트워크 밖에서 — 그쪽은 되는데 내 브라우저만 실패하면, 종료는 서버가 아니라 내 기기 쪽(백신·VPN·프록시)입니다.
SSL Check로 오리진과의 TLS 핸드셰이크가 깨끗이 완료되는지 확인해 인증서·가로채기 문제를 가려냅니다.
Port Check로 대상 포트가 실제로 도달 가능한지, 방화벽이 드롭하고 있지 않은지 확인합니다.

Resolution Checklist

두 번째 기기나 네트워크에서 재현해 봅니다. 내 기기만 실패하면 로컬 가로채기를 먼저 의심합니다.
백신의 HTTPS/SSL 검사와 VPN을 잠시 끄고 재시도합니다 — 가장 흔한 원인을 빠르게 가립니다.
외부 HTTP 체크를 실행합니다. 거기서 되면 로컬 환경, 거기서도 실패하면 서버나 경로를 가리킵니다.
부하 시 간헐적이라면, 너무 공격적으로 연결을 닫는 서버·프록시의 keep-alive·타임아웃 설정을 점검합니다.
오리진과의 TLS가 완료되고 인증서 체인이 끝까지 유효한지 확인합니다.
브라우저의 소켓 풀을 비웁니다(chrome://net-internals → 유휴 소켓 닫기)해 재사용된 낡은 연결을 떨굽니다.

When to Escalate

외부 체크도 실패하면 종료는 서버·네트워크 쪽입니다 — 타임아웃, 방화벽 규칙, 프록시 설정을 오리진 담당자에게 넘기세요.
회사·관리형 네트워크에서만 발생한다면 HTTPS를 검사하는 프록시가 유력합니다. 브라우저에서 바꿀 설정이 아니라 IT와의 대화입니다.