ERR_CONNECTION_RESET 해결 가이드

Problem

페이지가 ERR_CONNECTION_RESET(Chromium net error -101, “Error 101”)로 실패합니다. TCP 연결은 열렸고 — 핸드셰이크가 완료됐고 — 그 뒤에 RST 세그먼트가 도착해 연결을 끊었습니다. errno로는 ECONNRESET, “connection reset by peer”입니다. FIN을 주고받으며 처리 중인 데이터를 흘려보내는 graceful close와 달리, RST는 abortive close입니다. RFC 9293은 이를 연결을 즉시 닫고 상태를 모두 버리라는 지시로 규정합니다. 기다리던 데이터는 사라집니다.

형제 오류들과의 차이가 진단의 전부입니다. 거부(ERR_CONNECTION_REFUSED)는 보낸 SYN에 대한 RST로, 연결이 아예 열리지 않습니다. 타임아웃(ERR_CONNECTION_TIMED_OUT)은 SYN에 응답이 없는 경우입니다. 재설정은 들어갔다가 쫓겨난 것입니다.

Symptoms

• 페이지가 로드를 시작하거나 일부 로드되다가 끊깁니다. 즉시 “연결할 수 없음”이 아닙니다.
• curl이 Recv failure: Connection reset by peer 또는 Empty reply from server를 출력합니다.
• 한 네트워크(휴대폰 데이터)에서는 되고 다른 네트워크(회사·ISP Wi-Fi)에서는 재설정되는 경우가 많습니다.
• 오류가 ERR_CONNECTION_REFUSED(즉시, 열리지 않음)나 ERR_CONNECTION_TIMED_OUT(긴 멈춤)이 아닙니다.

Top 3 Causes

1. 서버가 연결을 중단함 - 오리진 앱이 요청 처리 중 크래시했거나 OOM으로 죽었거나, worker가 하드 타임아웃에 걸렸거나, 코드가 소켓을 abortive하게 닫은 경우입니다. SO_LINGER를 0으로 설정해 닫은 소켓은 FIN 대신 RST를 보내고 송수신 버퍼를 버립니다. 핸드셰이크는 성공했으니 거부보다 더 진행된 것입니다. 연결은 열렸고, 그 뒤 오리진이 끊었습니다.
2. 경로의 미들박스가 RST를 주입함 - 방화벽, IPS, DPI 장비가 SYN은 통과시킨 뒤 요청을 들여다보고(TLS SNI, HTTP Host 헤더, 또는 페이로드) RST를 위조합니다. 이 reset은 off-path라서 클라이언트도 서버도 아닌 장비에서 나옵니다. 같은 URL이 다른 네트워크에서는 되고 특정 조직의 egress 뒤에서만 재설정되는 것이 신호입니다.
3. 프로토콜 또는 포트 불일치 - TLS 포트에 평문 HTTP로 말하거나, 서버가 비활성화한 TLS 버전·cipher를 제시하면 일부 서버는 깔끔한 TLS alert 대신 연결을 재설정합니다. 핸드셰이크 중의 하드 reset은 여기에 해당하고, 깔끔한 alert였다면 ERR_SSL_PROTOCOL_ERROR로 나타났을 것입니다.

Diagnose with DechoNet

• HTTP Check를 외부 관점에서 실행합니다. 내 네트워크 밖에서도 요청이 재설정되면 문제는 서버나 그 edge입니다. 내 네트워크에서만 재설정되면 나와 서버 사이의 미들박스가 RST를 주입하는 것입니다.
• Port Check로 TCP 핸드셰이크가 완료되는지부터 봅니다. 포트가 열림(SYN에 SYN/ACK로 응답)인데 요청은 여전히 재설정되면, TCP 계층은 정상이고 reset은 요청·TLS 단계에서 발생하는 것입니다. 기본 도달성이 아니라 애플리케이션이나 내용을 검사하는 미들박스를 가리킵니다.
• DNS Lookup으로 낯선 트래픽을 재설정하는 이전 IP나 엉뚱한 edge가 아니라 의도한 오리진에 접속하고 있는지 확인합니다.

연결이 아예 열리지 않으면(즉시 거부) ERR_CONNECTION_REFUSED 해결을 보세요. 멈췄다가 응답이 없으면 ERR_CONNECTION_TIMED_OUT 해결로 갑니다. 실제 실패가 깔끔한 TLS alert라면 ERR_SSL_PROTOCOL_ERROR 해결을 참고하세요.

Resolution Checklist

• 두 번째 네트워크(휴대폰 핫스팟, 다른 ISP)에서 재현해 봅니다. 거기서 되면 첫 네트워크의 미들박스가 reset을 주입하는 것이고 서버는 정상입니다.
• reset 시점에 오리진·애플리케이션 로그에 크래시, OOM kill, worker 타임아웃이 있는지 확인합니다.
• 스택의 abortive close를 찾습니다. SO_LINGER 0, 죽은 업스트림을 재설정하는 리버스 프록시, 또는 idle keepalive 연결에 RST를 보내는 로드 밸런서·stateful NAT.
• 로컬 간섭을 하나씩 끄고 재시도합니다. VPN, 백신의 “HTTPS 검사”, 회사 프록시.
• 프로토콜·포트를 확인합니다. HTTPS는 443, 평문은 평문 포트에만, 그리고 서버가 클라이언트가 제시하는 TLS 버전을 여전히 지원하는지 확인합니다.
• 변경할 때마다 HTTP Check를 다시 실행해 요청이 재설정되지 않고 완료되는지 확인합니다.

When to Escalate

• Port Check에서 포트는 열려 있는데 여러 외부 네트워크에서 reset이 재현되면 서비스 담당자에게 에스컬레이션합니다. 연결이 열렸다가 끊기는 것은 경로가 아니라 애플리케이션이나 그 edge를 가리킵니다.
• reset이 특정 조직의 방화벽·DPI 뒤에서만 나타나면 네트워크·보안 담당자에게 문의합니다. 서버 쪽에서는 고칠 수 없는 주입된 RST이며, 검사 계층에서 허용해야 합니다.