ERR_CONNECTION_CLOSED 오류 원인과 해결 방법

ERR_CONNECTION_CLOSED란?

ERR_CONNECTION_CLOSED는 Chrome과 Edge에서 '사이트에 연결할 수 없음. example.com에서 예기치 않게 연결을 종료했습니다.'(영문: "This site can't be reached. example.com unexpectedly closed the connection.")라고 표시되는 오류입니다. Chromium에서는 네트워크 오류 -100이며, "a connection was closed (corresponding to a TCP FIN)", 즉 TCP FIN에 해당하는 연결 종료로 정의되어 있습니다.

FIN은 TCP 연결을 정중하게 끝내는 방법입니다. 리셋과는 정반대입니다. 무언가가 크래시하거나 강제로 종료된 것이 아니라, 한쪽이 '이제 끝'이라고 말하고 연결을 끊은 것입니다. 문제는 타이밍입니다. 상대편이 브라우저가 페이지를 받기 전에 연결을 끊었기 때문에 보여 줄 것이 없었던 것입니다.

무언가가 연결을 일찍 끝내기로 한 것입니다. 웹사이트의 서버일 수도, 그 앞단의 CDN일 수도, 내 네트워크의 필터일 수도, 내 컴퓨터의 소프트웨어일 수도 있습니다. 아래 해결 방법으로 어느 쪽인지 알 수 있습니다.

연결이 끊기는 지점: 주로 HTTPS 핸드셰이크

Chromium의 네트워크 코드를 보면 어디를 살펴봐야 하는지 알 수 있습니다. TLS(HTTPS) 핸드셰이크 도중 연결이 끝나면 암호화 계층이 이를 ERR_CONNECTION_CLOSED로 바꿉니다. 새 연결로 요청이 전달된 뒤 서버가 응답 없이 연결을 닫으면 Chrome은 대신 ERR_EMPTY_RESPONSE를 표시합니다.

또한 Chrome은 재사용하던 기존 연결이 도중에 닫히면 요청을 자동으로 재시도하므로, 그런 경우에는 오류를 거의 볼 수 없습니다. 그래서 HTTPS 사이트에서 ERR_CONNECTION_CLOSED 페이지가 보인다면 보통 보안 연결을 설정하는 도중 무언가가 연결을 끊었다는 뜻입니다. 이는 경로상에서 TLS를 처리하는 무언가를 가리킵니다. 백신의 HTTPS 검사기, VPN이나 프록시, 네트워크의 필터링 장비, 사이트의 CDN, 또는 웹 서버의 TLS 설정입니다.

ERR_CONNECTION_CLOSED의 원인

해결 방법 1: 다른 네트워크로 원인 찾기

휴대폰에서 모바일 데이터(Wi-Fi 끄기)로, 또는 다른 네트워크에 연결된 다른 컴퓨터에서 페이지를 열어 보세요.

• 다른 곳에서는 열림: 연결 종료는 내 기기나 네트워크에서 오는 것입니다. 해결 방법 2~6을 계속 진행하세요.

• 어디서나 실패: 웹사이트의 서버나 CDN이 연결을 끊고 있습니다. 운영자만 해결할 수 있습니다. 내 사이트라면 아래 웹사이트 운영자 섹션으로 건너뛰세요.

• 외부에서 인증서 확인: DNS Robot의 SSL 인증서 확인 도구는 저희 서버에서 사이트에 연결해 HTTPS 핸드셰이크가 성공하는지, 어떤 인증서가 제공되는지 보여 줍니다.

해결 방법 2: VPN과 프록시 끄기

VPN 서버와 프록시는 내가 만드는 모든 연결을 처리하며, 과부하 상태이거나 차단되면 핸드셰이크 단계에서 연결을 끊는 경우가 많습니다. VPN 연결을 완전히 끊은 뒤 프록시를 확인하세요:

• Windows 11: 설정 → 네트워크 및 인터넷 → 프록시 → 수동 프록시 설정에서 프록시 서버 사용을 끄세요.

• macOS: 시스템 설정 → 네트워크 → 사용 중인 연결 → 세부사항… → 프록시 → 모두 끄세요.

• VPN이나 프록시 역할을 하는 브라우저 확장 프로그램도 해당됩니다. 확장 프로그램이 기본적으로 꺼져 있는 시크릿 창에서 테스트하세요.

해결 방법 3: 백신 HTTPS 검사 일시 중지

암호화된 트래픽을 검사하는 보안 제품은 모든 HTTPS 핸드셰이크의 중간에 자리 잡습니다. 새로운 TLS 기능이나 특이한 인증서 때문에 검사기가 사이트와 협상하지 못하면, 그냥 연결을 닫아 버리는 경우가 많습니다.

HTTPS 검사, 웹 실드(Web Shield), SSL/TLS 프로토콜 필터링, 암호화된 연결 검사 같은 이름의 설정을 찾아 그것만 끄고 새로고침하세요. 페이지가 열린다면 해당 사이트를 예외로 추가하고 검사를 다시 켜세요. 백신을 업데이트하면 영구적으로 해결되는 경우가 많습니다.

해결 방법 4: DNS를 바꿔 필터링 여부 확인

일부 ISP와 네트워크 필터는 도메인을 자체 서버로 연결하는 방식으로 사이트를 차단하는데, 그 서버는 처리할 수 없는 HTTPS 연결을 끊어 버립니다. DNS Robot의 DNS 조회 결과가 내 컴퓨터의 결과(nslookup example.com)와 다른 IP 주소를 반환한다면, 리졸버가 나를 다른 곳으로 보내고 있는 것입니다.

Cloudflare(1.1.1.1), Google(8.8.8.8), Quad9(9.9.9.9) 같은 공용 리졸버로 바꾼 뒤 DNS 캐시를 플러시하고 다시 시도하세요. 네트워크가 암호화된 DNS까지 차단한다면 이 네트워크가 암호화된 DNS 트래픽을 차단하고 있습니다를 참고하세요.

해결 방법 5: SSL 상태, 소켓 풀, 브라우저 데이터 지우기

• Chrome 소켓 풀: chrome://net-internals/#sockets를 열고 Flush socket pools를 클릭해, Chrome이 오래되었을 수 있는 연결을 재사용하지 않도록 하세요.

• Windows SSL 상태: Win + R을 누르고 inetcpl.cpl을 입력한 뒤, 내용 탭에서 SSL 상태 지우기를 클릭하세요.

• 사이트 데이터: 주소창 왼쪽 아이콘 → 사이트 설정 → 데이터 삭제를 클릭해 해당 사이트의 쿠키와 캐시 데이터를 새로 시작하세요.

• 브라우저 업데이트: chrome://settings/help로 이동하세요. 오래된 버전은 최신 TLS 기능을 쓰는 서버와의 핸드셰이크에 실패할 수 있습니다.

해결 방법 6: 네트워크 스택 초기화 및 공유기 재시작

한 기기에서만 여러 사이트가 실패한다면 그 기기의 네트워크 구성을 초기화하세요. 공유기도 재시작하면 연결 테이블이 비워집니다. Windows에서는 관리자 권한 명령 프롬프트에서 다음을 실행한 뒤 재시작하세요:

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Windows 11에는 설정 → 네트워크 및 인터넷 → 고급 네트워크 설정 → 네트워크 초기화도 있으며, 네트워크 어댑터를 다시 설치합니다. Mac에서는 시스템 설정 → Wi-Fi에서 Wi-Fi 네트워크를 삭제한 뒤 다시 연결하세요.

Android와 iPhone에서 ERR_CONNECTION_CLOSED 해결하기

• 네트워크 전환: Wi-Fi에서 모바일 데이터로, 또는 그 반대로 바꿔 네트워크 필터가 관련되어 있는지 확인하세요.

• VPN, 광고 차단, '보안' 앱을 끄세요. 상당수가 로컬 VPN으로 트래픽을 우회시켜 검사합니다.

• Android 비공개 DNS: 설정 → 네트워크 및 인터넷 → 비공개 DNS → 자동. 각 옵션의 의미는 비공개 DNS 가이드를 참고하세요.

• 앱 스토어에서 Chrome이나 Safari를 업데이트하고, 운영체제가 여러 버전 뒤처져 있다면 운영체제도 업데이트하세요.

• 네트워크 설정 초기화: iPhone은 설정 → 일반 → 전송 또는 iPhone 재설정 → 재설정 → 네트워크 설정 재설정. Android는 설정 → 시스템 → 재설정 옵션 → 블루투스 및 Wi-Fi 재설정(Reset Bluetooth & Wi-Fi), 모바일 데이터도 실패한다면 모바일 네트워크 설정 재설정(Reset Mobile Network Settings)까지 실행하세요.

웹사이트 운영자용: 서버가 연결을 끊는 이유

여러 네트워크의 방문자가 ERR_CONNECTION_CLOSED를 겪는다면, 내 네트워크 밖의 컴퓨터에서 TLS 핸드셰이크를 직접 테스트하세요. openssl s_client는 핸드셰이크가 정확히 어디서 멈추는지 보여 줍니다:

• SNI와 인증서: 방문자가 쓰는 모든 호스트 이름, 즉 example.com과 www.example.com 모두에 server_name 항목과 이를 포함하는 인증서가 있어야 합니다. 인증서 없는 기본 server 블록으로 들어가는 호스트 이름은 핸드셰이크가 닫히는 경우가 많습니다.

• 프로토콜: TLSv1.2와 TLSv1.3을 제공하세요. TLS 1.0/1.1만 제공하는 아주 오래된 설정이나 특이한 암호 목록은 최신 브라우저에서 실패합니다. SSL 인증서 확인 도구로 방문자가 받는 인증서와 체인을 확인할 수 있습니다.

• 연결 제한: nginx가 worker_connections are not enough를 기록하거나 방화벽의 connlimit 또는 DDoS 규칙이 작동하면, 부하가 높을 때 새 연결이 버려지거나 닫힙니다. 제한을 올리거나 트래픽의 출처를 찾으세요.

• CDN과 WAF: 영향을 받은 방문자에 대해 CDN의 보안 이벤트를 확인하세요. 봇 방어와 지역 차단 규칙은 지역 전체의 연결을 닫을 수 있습니다.

• 로그: 신고가 들어온 시간대의 웹 서버 오류 로그에서 SSL_do_handshake() failed 줄을 찾으세요. nginx는 클라이언트 측 핸드셰이크 실패 대부분을 info 수준으로 기록하므로 기본값인 error 수준에서는 아무것도 보이지 않을 수 있습니다. 조사하는 동안 잠시 error_log /var/log/nginx/error.log info;로 설정하세요.

# SNI(방문자가 사용하는 호스트 이름)를 포함한 전체 핸드셰이크
openssl s_client -connect example.com:443 -servername example.com </dev/null

# 정상: 인증서 체인, "Verify return code: 0 (ok)", TLSv1.3 또는 TLSv1.2 프로토콜 줄
# 비정상: "unexpected eof while reading" 또는 "no peer certificate available"
#      = 서버(또는 그 앞단의 무언가)가 핸드셰이크를 닫음

# 특정 프로토콜 버전 테스트
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

그다음 다음 항목을 순서대로 확인하세요:

ERR_CONNECTION_CLOSED vs RESET vs EMPTY_RESPONSE vs SSL 오류

관련 가이드: ERR_CONNECTION_RESET, ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH, ERR_CONNECTION_REFUSED.