ERR_EMPTY_RESPONSE와 ERR_CONNECTION_REFUSED는 어떻게 다른가요?

ERR_CONNECTION_REFUSED는 TCP 연결 자체가 열리지 않은 것 — 아무것도 리스닝하지 않습니다. ERR_EMPTY_RESPONSE(Chromium net error -324)는 정반대입니다: 연결은 멀쩡히 열렸고 서버가 받아들였는데, HTTP 응답을 한 바이트도 — 헤더조차 — 보내지 않고 끊었습니다. 하나는 잠긴 문이고, 다른 하나는 열렸다가 면전에서 닫히는 문입니다.

다른 브라우저에서는 되는 사이트인데 왜 이게 뜨나요?

그렇다면 오리진 문제가 아닐 가능성이 큽니다. 브라우저 확장, 로컬 프록시·VPN, 트래픽을 검사하는 백신이 Chrome에 닿기 전에 응답을 떼어낼 수 있습니다. 확장을 끈 시크릿 창에서 테스트하거나 URL에 curl -v를 실행해 보세요 — curl은 응답을 받는데 Chrome은 못 받으면 문제는 클라이언트 쪽입니다.

HTTP를 HTTPS 포트에 보내면 이게 날 수 있나요?

네, 전형적인 경우입니다. TLS만 쓰는 포트에 http://로 요청하면, 서버는 당신의 평문을 쓰레기로 읽고 진짜 HTTP 오류 없이 연결을 끊는 일이 많습니다. 예컨대 Node.js는 이 상황에서 깔끔한 400 대신 ERR_EMPTY_RESPONSE를 냅니다. 스킴을 https://로 바꾸면 '빈' 응답이 대개 사라집니다.

조회수: 7

ERR_EMPTY_RESPONSE 해결

ERR_EMPTY_RESPONSE는 서버가 응답 없이 연결을 끊었다는 뜻. 서버 크래시인지 HTTPS 포트 착각인지 3단계로 가립니다. 무료 즉시 진단으로 바로 확인.

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

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

Problem

브라우저가 ERR_EMPTY_RESPONSE — Chromium net error 코드 -324 — 를 표시하고 페이지가 끝내 안 뜹니다.

Symptoms

Chrome/Edge에서 “ERR_EMPTY_RESPONSE” 또는 “데이터를 보내지 않았습니다”라는 빈 오류 페이지가 뜹니다.
새로고침하면 가끔 뜨거나, 남들은 되는데 나만 안 됩니다.
다른 건 다 멀쩡한데 한 사이트에서만 발생합니다.

ERR_EMPTY_RESPONSE가 실제로 뜻하는 것

이건 브라우저가 내는 오류 중 꽤 정직한 축에 듭니다. 일어난 일을 정확히 묘사하니까요: TCP 연결이 열렸고, 서버가 받아들였고, 그다음 서버가 HTTP 응답을 전혀 보내지 않고 끊었습니다 — 상태 줄도, 헤더도, 아무것도 없이. Chrome은 완전한 대화 채널을 확보했는데 상대가 한마디도 하기 전에 전화를 끊은 셈이죠.

그 한 가지 사실이 진단의 전부입니다. 한 부류의 문제를 바로 배제해 줍니다. 네트워크 경로는 됩니다(핸드셰이크가 끝났으니까). DNS도 풀렸습니다(IP에 닿았으니까). 포트도 리스닝 중입니다(거부가 아니라 수락됐으니까). 깨진 건 연결 이후의 모든 것 — 응답을 써야 했던 서버 프로세스가 죽었거나, 쓰기를 시작도 못 했거나, 그 출력이 중간의 무언가에 의해 버려졌습니다.

Top 3 Causes

서버 프로세스가 요청 도중 크래시되거나 종료됨 - 워커가 segfault 나거나, OOM killer가 거두거나, 처리 안 된 예외가 프로세스를 내리거나 — 소켓을 받아들인 뒤, 응답을 쓰기 전에 죽습니다. 연결은 빈 채로 닫힙니다. 오리진 쪽 원인 중 가장 흔하고, 대개 간헐적입니다. “새로고침하면 된다”가 그토록 익숙한 증상인 이유죠.
TLS 전용 포트에 평문 HTTP로 말하고 있음 - http://host:443(또는 HTTPS 전용 포트)로 요청하면, 서버는 당신의 평문 GET을 TLS ClientHello로 파싱하려다 실패하고 진짜 HTTP 오류 없이 연결을 끊습니다. 해결은 https://로 바꾸는 것. 로컬 개발 환경과 잘못된 리다이렉트에서 끊임없이 걸려 넘어집니다.
중간의 무언가가 응답을 먹고 있음 - 업스트림이 깨진 리버스 프록시, 트래픽을 검사·차단하는 회사 방화벽이나 백신, 브라우저 확장, VPN이 응답을 브라우저에 닿기 전에 삼킬 수 있습니다. 남들은 되는데 나만 안 되면 클라이언트 쪽부터 의심하세요.

Diagnose with DechoNet

HTTP Check를 당신 네트워크 밖에서 실행합니다 — 정상 상태 코드와 헤더가 나오는데 당신 브라우저만 ERR_EMPTY_RESPONSE면, 오리진은 멀쩡하고 문제는 당신 PC·네트워크에 국한됩니다.
Port Check로 포트가 실제로 열려 연결을 받는지 확인합니다 — ERR_EMPTY_RESPONSE는 받는다는 뜻이지만, 따로 확인하면 진짜 “받고 끊음”과 가끔만 리스닝하는 펄럭이는 서비스를 구분할 수 있습니다.

Resolution Checklist

스킴을 확인합니다: TLS 포트에 http://로 입력했거나 리다이렉트됐다면 https://로 바꿉니다.
모든 확장을 끈 시크릿 창에서 재현합니다 — 사라지면 확장이 응답을 먹고 있던 것입니다.
깨끗한 네트워크에서 curl -v https://yoursite.com을 실행합니다. HTTP 응답이 없으면 오리진 문제, 정상 응답이면 클라이언트 쪽 문제입니다.
오리진에서 프로세스 로그를 확인해 실패한 요청 시각에 맞춰 크래시·OOM·재시작이 있었는지 봅니다 — 빈 응답 뒤에는 거의 항상 죽은 워커가 있습니다.
앞단에 리버스 프록시가 있다면, 업스트림이 건강한지, 응답을 전달하지 않고 연결을 끊지는 않는지 확인합니다.
HTTP Check를 다시 실행해 서버가 이제 진짜 상태 코드를 반환하는지 확인합니다.

When to Escalate

외부 HTTP Check도 응답을 못 받으면 오리진 운영자에게 넘깁니다 — 서버가 연결을 끊고 있고, 해결은 브라우저가 아니라 서버 쪽에 있습니다.
부하 상황에서 간헐적으로 실패하면 안정성 문제로 다룹니다: 브라우저 설정을 쫓지 말고 워커 크래시, 메모리 한도, 요청 타임아웃을 조사하세요.