Linux Broken Pipe 오류(Broken pipe, EPIPE)의 원인과 해결 방법

작성자:

Linux 서버를 운영하다 보면 웹 서버, API 서버, 데이터베이스 또는 소켓(Socket) 기반 프로그램에서 Broken pipe, write: Broken pipe, EPIPE와 같은 오류를 자주 볼 수 있습니다. 이 오류는 프로그램이 이미 종료된 연결에 데이터를 전송하려고 할 때 발생하는 대표적인 TCP 소켓 오류입니다.

간헐적으로 발생하는 Broken Pipe는 정상적인 네트워크 환경에서도 나타날 수 있지만, 지속적으로 발생하거나 대량으로 기록된다면 애플리케이션 구조나 네트워크 환경에 문제가 있을 가능성이 높습니다.

이번 글에서는 Broken Pipe(EPIPE)의 원인과 확인 방법, 해결 방법을 실무 중심으로 자세히 알아보겠습니다.

Broken Pipe(EPIPE)란?

Broken Pipe는 이미 종료된 Socket에 데이터를 쓰려고 할 때 발생하는 오류입니다.

예를 들어 클라이언트가 먼저 연결을 종료했는데 서버가 계속 데이터를 보내려고 하면 Linux 커널은 EPIPE 오류를 반환합니다.

동작 과정은 다음과 같습니다.

Client                      Server

Connection OK
      │
      ▼
Client 종료
(FIN 또는 RST)

               Server가 write()

               ↓

Broken Pipe(EPIPE)

즉, 상대방이 더 이상 연결을 유지하지 않는데 데이터를 전송하려 했기 때문에 발생하는 오류입니다.

Broken Pipe가 발생하는 주요 원인

대표적인 원인은 다음과 같습니다.

  • 클라이언트가 먼저 연결 종료
  • KeepAlive Timeout
  • Reverse Proxy Timeout
  • Load Balancer Timeout
  • 네트워크 장애
  • 애플리케이션 처리 지연
  • Socket 재사용 오류
  • 프로그램 버그
  • 방화벽 연결 종료
  • 대용량 응답 전송 중 연결 종료

웹 서버에서는 사용자가 브라우저를 닫아도 자주 발생하는 정상적인 상황입니다.

1. 애플리케이션 로그 확인하기

먼저 로그에서 Broken Pipe 오류를 확인합니다.

예를 들어

journalctl -u nginx

또는

journalctl -u apache2

Tomcat

journalctl -u tomcat

다음과 같은 메시지가 자주 나타납니다.

Broken pipe

write: Broken pipe

EPIPE

2. TCP 연결 상태 확인하기

현재 연결 상태를 확인합니다.

ss -s

또는

ss -tan

CLOSE_WAIT, FIN_WAIT, TIME_WAIT 상태가 함께 증가하는지 확인합니다.

3. 패킷 캡처하기

클라이언트가 먼저 연결을 종료하는지 확인합니다.

tcpdump -i eth0 tcp

또는 특정 포트를 확인합니다.

tcpdump -i eth0 port 443

FIN 또는 RST 이후에 서버가 데이터를 전송하는지 분석합니다.

4. KeepAlive 설정 확인

Nginx 예시입니다.

keepalive_timeout 65;

Apache

KeepAlive On
KeepAliveTimeout 5

KeepAlive 시간이 너무 짧으면 Broken Pipe 발생이 증가할 수 있습니다.

5. Reverse Proxy 설정 확인

Nginx Proxy 예시입니다.

proxy_read_timeout 300;
proxy_send_timeout 300;
proxy_connect_timeout 60;

Timeout 값이 너무 짧으면 Backend 서버와의 연결이 끊어질 수 있습니다.

6. Load Balancer Timeout 확인

다음 장비를 사용하는 경우 Timeout 값을 확인합니다.

  • AWS ALB
  • AWS NLB
  • HAProxy
  • F5
  • Nginx Proxy
  • Kubernetes Ingress

로드밸런서가 먼저 연결을 종료하는 경우 Broken Pipe가 발생할 수 있습니다.

7. 네트워크 상태 확인하기

인터페이스 상태를 확인합니다.

sar -n DEV 1

또는

ip -s link

패킷 드롭이나 오류가 발생하는지 함께 확인합니다.

8. 프로세스 확인하기

문제가 발생하는 프로세스를 확인합니다.

ss -tanp

또는

lsof -iTCP

특정 프로세스에서만 오류가 집중되는지 확인합니다.

9. strace로 write() 확인하기

write() 호출 시 오류가 발생하는지 확인합니다.

strace -p PID

또는

strace -e write -p PID

EPIPE 발생 시점을 분석할 수 있습니다.

10. 커널 로그 확인하기

TCP 관련 오류를 확인합니다.

dmesg | grep TCP

또는

journalctl -k | grep tcp

드라이버나 네트워크 오류가 있는지도 함께 확인합니다.

Broken Pipe 점검 순서

실무에서는 다음 순서대로 점검하는 것이 좋습니다.

  1. 애플리케이션 로그 확인
  2. TCP 상태 확인
  3. 패킷 캡처
  4. KeepAlive 설정 확인
  5. Reverse Proxy Timeout 확인
  6. Load Balancer 설정 확인
  7. 네트워크 상태 확인
  8. 프로세스 확인
  9. strace 분석
  10. 커널 로그 확인

Broken Pipe 사용 시 주의사항

다음 사항을 고려해야 합니다.

  • Broken Pipe는 항상 오류를 의미하지 않는다.
  • 사용자가 브라우저를 닫아도 발생할 수 있다.
  • Timeout 설정을 적절히 조정한다.
  • Reverse Proxy와 Backend 설정을 함께 확인한다.
  • 장시간 응답하는 서비스는 Timeout 값을 충분히 크게 설정한다.
  • 로그가 급증하면 애플리케이션 구조를 점검한다.

일시적인 Broken Pipe는 정상일 수 있지만, 지속적으로 증가한다면 반드시 원인을 분석해야 합니다.

Broken Pipe와 Connection Reset의 차이

항목Broken Pipe(EPIPE)Connection Reset(RST)
발생 위치write() 수행 시TCP 연결 자체
주요 원인종료된 Socket에 쓰기상대방의 강제 종료
오류 형태애플리케이션 오류TCP Reset
해결 대상프로그램 로직네트워크 및 애플리케이션

Broken Pipe는 대부분 애플리케이션이 종료된 연결에 데이터를 전송하려고 할 때 발생합니다.

자주 묻는 질문

Broken Pipe는 치명적인 오류인가요?

아닙니다. 웹 서버에서는 사용자가 페이지를 닫거나 다운로드를 취소할 때도 자주 발생하는 정상적인 상황입니다.

Broken Pipe를 완전히 없앨 수 있나요?

불가능합니다. 클라이언트가 언제든 연결을 종료할 수 있기 때문입니다. 다만 불필요하게 많이 발생하는 경우에는 Timeout과 애플리케이션 구조를 개선하여 줄일 수 있습니다.

Broken Pipe와 EPIPE는 같은 의미인가요?

네. EPIPE는 Linux 시스템 콜에서 반환하는 오류 코드이며, Broken Pipe는 해당 오류를 사람이 이해하기 쉽게 표현한 메시지입니다.

마무리

Broken Pipe(EPIPE)는 종료된 TCP 연결에 데이터를 전송하려 할 때 발생하는 대표적인 소켓 오류입니다. journalctl, ss, tcpdump, strace 등을 활용하면 원인을 빠르게 분석할 수 있으며, KeepAlive와 Timeout 설정을 적절히 조정하고 애플리케이션의 예외 처리를 개선하면 안정적인 서비스 운영에 도움이 됩니다.

댓글 남기기