ERR_EMPTY_RESPONSE

직접 답변

`ERR_EMPTY_RESPONSE`는 연결은 설정되었지만 브라우저가 사용할 수 있는 HTTP 응답 헤더나 본문 데이터를 받기 전에 연결이 종료되었다는 의미입니다. 다른 브라우저나 네트워크에서 문제가 발생한 URL을 테스트한 다음, verbose 클라이언트와 상호 연관된 웹 서버, PHP-FPM, 애플리케이션, 프록시 및 시스템 로그를 사용해 어느 계층에서 연결을 종료했는지 확인하세요. 일반적인 원인으로는 애플리케이션 worker 충돌, Nginx 또는 파일 디스크립터 용량 고갈, 사용할 수 없는 upstream, 호환되지 않는 프록시 keepalive 설정 등이 있습니다.

핵심 요점

ERR_EMPTY_RESPONSE는 사용할 수 있는 HTTP 응답 없이 연결이 종료되었다는 의미이며, connection refused 및 timeout과는 다릅니다.
서버 설정을 변경하기 전에 다른 브라우저, 기기 또는 네트워크에서 오류가 발생한 정확한 경로를 테스트하세요.
verbose 명령줄 요청과 정확한 타임스탬프를 사용해 클라이언트 동작을 프록시, 웹 서버, PHP-FPM, 애플리케이션 및 시스템 로그와 대조하세요.
일반적인 서버 측 원인으로는 종료된 PHP-FPM worker, 애플리케이션 오류, 고갈된 Nginx 또는 파일 디스크립터 용량, upstream 연결 reset 등이 있습니다.
upstream이 프록시가 재사용하려는 연결을 종료할 때 reverse proxy에서 keepalive 또는 timeout 불일치가 드러날 수 있습니다.
서비스를 재시작하거나 제한을 늘리기 전에 증거를 수집하고, 운영 환경 변경은 승인된 운영 절차를 통해서만 수행하세요.

업데이트: 2026-09-25 · 편집 검토 대기 중 HTTP 및 서버 오류

Site Administrator

이 오류의 의미와 확인 방법

브라우저에 200, 404, 500과 같은 HTTP 상태 대신 ERR_EMPTY_RESPONSE가 표시됩니다.
브라우저가 응답 헤더, HTML 또는 애플리케이션 오류 페이지를 받기 전에 요청이 실패합니다.
worker, connection pool 또는 upstream 서비스가 복구되면 새로 고침 후 간헐적으로 성공할 수 있습니다.
다른 사이트에는 계속 접근할 수 있지만 특정 호스트 이름이나 경로만 실패할 수 있습니다.
verbose 명령줄 요청에서 TCP 연결이 열린 다음 응답 헤더 없이 종료되는 것을 확인할 수 있습니다.
reverse proxy를 통한 public URL은 실패하지만 upstream 서비스에 대한 승인된 요청은 다르게 동작할 수 있습니다.
오류가 특정 브라우저, 기기, source network, VPN 또는 프록시 경로에만 영향을 줄 수 있습니다.

가능성이 높은 순서의 주요 원인

응답을 보내기 전에 애플리케이션 또는 PHP-FPM worker가 종료되었습니다. 치명적인 애플리케이션 오류, worker 충돌, 프로세스 제한, 메모리 부족 또는 의존성 오류로 인해 정상적인 HTTP 응답이 생성되기 전에 요청이 종료될 수 있습니다.
Nginx 또는 호스트가 연결 용량이나 파일 디스크립터 용량에 도달했습니다. 유효한 worker_connections, open-file 제한, 활성 연결 수 및 사용 가능한 메모리는 요청과 upstream 연결이 완료될 수 있는지에 영향을 줍니다.
reverse proxy가 유효한 upstream 연결을 유지하지 못합니다. 호환되지 않는 keepalive 동작, 연결 재사용, timeout 값 또는 프록시 설정으로 인해 upstream 헤더가 도착하기 전에 클라이언트 연결이 종료될 수 있습니다.
upstream 서비스를 사용할 수 없거나 연결을 reset합니다. 서비스가 실행 중이더라도 요청을 수락, 처리 또는 완료하지 못할 수 있습니다.
방화벽, VPN, WAF, load balancer 또는 기타 네트워크 장치가 연결을 종료합니다. 오류가 클라이언트 네트워크, source address 또는 경로에 따라 달라질 때 가능성이 높습니다.
브라우저 로컬 상태가 요청을 방해합니다. 다른 클라이언트가 정상적으로 작동할 때 확장 프로그램, 캐시된 연결 상태, 로컬 프록시, VPN 또는 보안 소프트웨어가 유사한 증상을 일으킬 수 있습니다.

해결 방법

Diagnostic flow at a glance — full detail in the steps below.

1. 오류 범위 확인

호스트 이름, 정확한 경로, time zone이 포함된 대략적인 발생 시간, 클라이언트, 네트워크 및 오류가 지속적인지 여부를 기록하세요. 동일한 경로를 private window, 다른 브라우저, 다른 기기 및 허용되는 경우 다른 네트워크에서 테스트하세요.

한 브라우저 또는 기기에서만 실패한다면 먼저 확장 프로그램, 로컬 프록시 설정, VPN 소프트웨어, 캐시된 연결 상태 및 endpoint 보안 제어를 조사하세요. 홈페이지가 대표적인 상태라고 가정하지 말고, 실패하는 특정 route를 테스트하세요.

2. 클라이언트가 응답 헤더를 받는지 확인

영향을 받은 클라이언트 또는 가까운 클라이언트에서 승인된 대상에 read-only 요청을 보냅니다. 대괄호로 표시된 값을 실제 호스트 이름과 경로로 바꾸세요.

text

curl -v https://[your hostname]/[path]

응답 헤더 없이 연결이 종료되면 empty response 진단을 뒷받침합니다. HTTP 상태가 반환되면 해당 상태, redirect, TLS 동작 또는 브라우저 렌더링을 조사하세요. 가능하면 정상 클라이언트와 오류 클라이언트의 verbose 출력을 비교하세요.

3. 요청을 서버 로그와 대조

정확한 시간과 경로를 사용해 다음 항목을 확인하세요.

Nginx 또는 해당 웹 서버의 access 및 error 로그
route에서 PHP를 호출하는 경우 PHP-FPM 로그
치명적 오류, 처리되지 않은 예외 및 실패한 의존성을 확인할 수 있는 애플리케이션 로그
out-of-memory 이벤트, 프로세스 종료, 파일 디스크립터 고갈 및 서비스 오류를 확인할 수 있는 운영 체제 로그

완료된 upstream 응답 없이 access-log 항목만 존재하는 경우, upstream reset 또는 worker 종료 메시지는 어느 계층에서 연결을 종료했는지 파악하는 데 도움이 됩니다. 브라우저 오류만으로는 담당 컴포넌트를 식별할 수 없습니다.

4. PHP-FPM 및 애플리케이션 상태 확인

dynamic route의 경우 PHP-FPM에 사용 가능한 worker가 있는지, worker가 반복적으로 종료되거나 설정된 제한에 도달하거나 운영 체제에 의해 종료되는지 확인하세요. 최근 배포, 치명적 오류, 메모리 부족, 느린 데이터베이스 호출 및 차단된 기타 의존성을 확인하세요.

관련 증거를 확인하고 용량 및 운영 영향을 평가한 후에만 PHP-FPM 제한, 애플리케이션 코드 또는 서비스 상태를 변경하세요. 재시작으로 실패한 worker가 일시적으로 정리될 수 있지만, 반복되는 충돌, 리소스 고갈 또는 애플리케이션 결함이 해결되는 것은 아닙니다. 재시작이 승인된 경우 실행하기 전에 로그와 프로세스 상태를 수집하세요.

5. Nginx 연결 및 파일 디스크립터 용량 확인

영향을 받은 서비스의 유효한 Nginx 설정과 운영 체제 제한을 검토하세요. worker_connections, worker-process 동작, 활성 연결 수, open-file 제한, 사용 가능한 메모리 및 리소스 제한에 도달했음을 나타내는 오류 메시지를 확인하세요.

단순히 worker_connections를 늘리지 마세요. 운영 체제의 파일 디스크립터 제한과 사용 가능한 메모리가 변경 사항을 지원해야 합니다. 현재 값과 트래픽 상태를 기록하고 승인된 변경 절차를 따르며, 승인된 경우 제어된 reload 또는 restart 후 결과를 확인하세요.

6. reverse proxy 또는 upstream 오류 분리

애플리케이션 앞에 CDN, load balancer, ingress 또는 Nginx reverse proxy가 있는 경우 다음을 비교하세요.

프록시를 통한 public 요청
프록시 호스트 또는 동등한 내부 테스트 지점에서 upstream으로 보내는 승인된 요청
동일한 타임스탬프의 프록시 error 로그와 upstream 애플리케이션 로그

프록시가 upstream에서 이미 종료한 연결을 재사용하는지, keepalive 설정이 호환되는지, proxy 및 upstream timeout이 해당 route에 적합한지 확인하세요. 한 번에 관련 설정 하나만 변경하고 예상되는 영향을 문서화한 다음 동일한 테스트를 반복하세요.

7. 네트워크 및 보안 제어 확인

오류 발생 시각에 웹 서버 로그 항목이 없다면 방화벽, VPN, WAF, load balancer, 라우팅 및 클라이언트 측 보안 경로를 확인하세요. 정상 source network와 오류가 발생하는 source network를 비교하고, 타임스탬프와 일치하는 정책 결정, 연결 reset 또는 idle 연결 처리를 찾으세요.

웹 서버에 도달하기 전에 연결이 사라진다면 애플리케이션 코드를 변경하기보다 네트워크 또는 호스팅 팀에 에스컬레이션하세요.

8. 증거를 보존하며 수정 사항 검증

승인된 애플리케이션, 설정 또는 네트워크 변경 후 동일한 경로와 클라이언트 테스트를 반복하세요. 브라우저에 원래 메시지가 더 이상 표시되지 않는 것뿐 아니라 응답에 헤더와 적절한 HTTP 상태가 포함되는지 확인하세요. 프록시, 웹 서버, upstream, 애플리케이션 및 시스템 로그를 검토하고 비교 또는 rollback을 위해 변경 전후 설정 값을 보관하세요.

예방 및 해결 확인 방법

웹 서버 오류, upstream reset, PHP-FPM worker 가용성, 프로세스 종료, 메모리 부족, open-file 사용량 및 연결 제한 경고를 모니터링하세요.
reverse proxy, upstream keepalive 및 timeout 정책을 문서화하고 인프라 변경 후 테스트하세요.
프록시, 웹 서버 및 애플리케이션 로그를 대조할 수 있도록 인시던트 보고서에 request identifier 또는 time zone이 포함된 정확한 타임스탬프를 기록하세요.
트래픽을 늘리거나 worker 수를 변경하기 전에 연결 및 파일 디스크립터 설정을 용량 테스트하세요.
rollback 계획과 함께 애플리케이션을 배포하고, 직후 치명적 오류, worker 충돌 및 의존성 오류를 확인하세요.
public endpoint와 upstream 서비스를 각각 테스트하기 위한 승인된 절차를 유지하세요.
서비스 재시작 및 운영 환경의 제한 변경은 승인된 변경 프로세스 안에서 수행하세요.

외부 도움을 받아야 할 때

오류가 여러 클라이언트 또는 네트워크에 영향을 주거나 worker 충돌, 리소스 고갈 또는 반복적인 upstream reset과 함께 발생한다면 서버 또는 호스팅 팀에 에스컬레이션하세요. 웹 서버 로그 항목이 없고 방화벽, VPN, WAF, load balancer 또는 라우팅 계층이 연결을 종료했을 가능성이 있다면 네트워크 팀에 문의하세요.

호스트 이름과 경로, time zone이 포함된 타임스탬프, 클라이언트 및 네트워크 비교 결과, verbose 요청 출력, 관련 프록시, 웹 서버, PHP-FPM, 애플리케이션 및 시스템 로그 발췌 내용을 제공하세요. 특히 오류 증거를 수집하기 전에 승인 없이 반복적으로 재시작하거나 운영 환경 설정을 변경하지 마세요.

웹사이트 확인

자주 묻는 질문

ERR_EMPTY_RESPONSE는 connection refused와 같은 오류인가요?

아닙니다. connection refused는 일반적으로 해당 지점에 listener가 없거나 access rule에 의해 연결 시도가 거부되었다는 의미입니다. ERR_EMPTY_RESPONSE는 사용할 수 있는 HTTP 응답 없이 연결이 종료되었다는 의미이므로, 연결이 설정된 후 웹 서버, upstream, 프록시 또는 네트워크 장치가 연결을 종료했을 수 있습니다.

ERR_EMPTY_RESPONSE는 timeout과 같은 오류인가요?

아닙니다. timeout은 필요한 네트워크 또는 HTTP 교환이 완료되지 않은 상태로 클라이언트가 예상된 시간을 초과해 기다렸다는 의미입니다. ERR_EMPTY_RESPONSE에서는 일반적으로 응답 헤더 없이 연결이 종료되지만, 정확한 브라우저 동작은 오류가 발생한 위치에 따라 달라집니다.

PHP-FPM이 ERR_EMPTY_RESPONSE를 일으킬 수 있나요?

예. PHP-FPM worker가 충돌하거나 종료되거나 요청을 완료하지 못하면 정상적인 응답이 생성되기 전에 웹 서버와 애플리케이션 사이의 경로가 종료될 수 있습니다. PHP-FPM이 원인이라고 가정하지 말고 PHP-FPM, 애플리케이션, 웹 서버 및 시스템 로그에서 이를 확인하세요.

Nginx worker_connections를 확인해야 하는 이유는 무엇인가요?

Nginx가 유효한 연결 또는 파일 디스크립터 용량에 도달하면 신규 연결이나 upstream 연결을 안정적으로 처리하지 못할 수 있습니다. 설정을 변경하기 전에 오류 로그와 운영 체제 제한을 확인하세요. 시스템 용량을 맞추지 않고 값을 늘리면 또 다른 리소스 문제가 발생할 수 있습니다.

reverse proxy가 empty response를 어떻게 만들 수 있나요?

upstream 연결이 reset되거나 upstream이 이미 종료한 연결을 재사용하거나, 호환되지 않는 keepalive 또는 timeout 동작으로 인해 연결이 종료되면 프록시가 클라이언트 연결을 닫을 수 있습니다. 프록시 로그를 승인된 upstream 테스트와 비교하고 양쪽의 연결 설정을 확인하세요.

도움을 요청하기 전에 무엇을 수집해야 하나요?

정확한 호스트 이름과 경로, 오류 발생 타임스탬프, 두 개 이상의 클라이언트 또는 네트워크에서의 결과, verbose 요청 출력 및 상호 연관된 프록시, 웹 서버, PHP-FPM, 애플리케이션 및 시스템 로그를 수집하세요. 이를 통해 어느 계층에서 연결을 종료했는지 파악하고 추측을 피할 수 있습니다.

추가 문서

권위 있는 후속 자료는 사용 중인 웹 서버, PHP-FPM, reverse proxy 또는 load-balancing 제품 및 운영 체제의 연결과 파일 디스크립터 제한 문서를 참조하세요. 제품의 error-log reference, upstream 및 keepalive 설정, worker 또는 연결 제한, timeout 동작, 서비스 변경 및 rollback 절차에 중점을 두세요.