Linux Connection Reset by Peer 오류의 원인과 해결 방법

작성자:

Linux 서버를 운영하다 보면 웹 서버, API 서버, 데이터베이스 또는 소켓(Socket) 프로그램에서 Connection reset by peer, ECONNRESET과 같은 오류 메시지를 자주 볼 수 있습니다. 이 오류는 TCP 연결이 정상적으로 종료(FIN)되지 않고 상대방에 의해 RST(Reset) 패킷으로 강제 종료되었음을 의미합니다.

간헐적으로 발생하는 Connection Reset은 일반적인 네트워크 환경에서도 나타날 수 있지만, 특정 서비스에서 지속적으로 발생하거나 대량으로 기록된다면 네트워크 장비, 애플리케이션, 프록시, 방화벽 등의 설정을 함께 점검해야 합니다.

이번 글에서는 Connection Reset by Peer 오류의 원인과 확인 방법, 해결 방법을 실무 중심으로 자세히 알아보겠습니다.

Connection Reset by Peer란?

Connection Reset by Peer는 TCP 연결 상대방이 RST 패킷을 보내 연결을 즉시 종료했을 때 발생하는 오류입니다.

정상적인 연결 종료는 다음과 같습니다.

Client                     Server

FIN ---------------------->

        <----------------- ACK

        <----------------- FIN

ACK ---------------------->

Connection Reset이 발생하는 경우입니다.

Client                     Server

RST ---------------------->

Connection Reset by Peer

즉, 상대방이 더 이상 현재 연결을 유지하지 않겠다고 즉시 통보하는 상황입니다.

Connection Reset이 발생하는 주요 원인

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

  • 클라이언트 강제 종료
  • 웹 브라우저 종료
  • KeepAlive Timeout
  • Reverse Proxy Timeout
  • Load Balancer Timeout
  • 방화벽 연결 차단
  • 애플리케이션 오류
  • Socket 강제 종료
  • 네트워크 장애
  • 비정상적인 TCP 연결

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

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

Nginx

journalctl -u nginx

Apache

journalctl -u apache2

Tomcat

journalctl -u tomcat

대표적인 로그 예시입니다.

Connection reset by peer

ECONNRESET

오류가 어느 시점에 집중되는지 확인합니다.

2. TCP 연결 상태 확인하기

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

ss -s

또는

ss -tan

RST 발생 시 CLOSE_WAIT, FIN_WAIT, TIME_WAIT 상태도 함께 확인합니다.

3. RST 패킷 확인하기

RST 패킷만 캡처합니다.

tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

특정 서비스만 확인하려면

tcpdump -i eth0 port 443

RST를 누가 먼저 보내는지 확인하는 것이 중요합니다.

4. KeepAlive 설정 확인하기

Nginx

keepalive_timeout 65;

Apache

KeepAlive On
KeepAliveTimeout 5

KeepAlive 시간이 너무 짧으면 연결이 예상보다 빨리 종료될 수 있습니다.

5. Reverse Proxy Timeout 확인하기

Nginx Proxy 예시입니다.

proxy_connect_timeout 60;
proxy_send_timeout 300;
proxy_read_timeout 300;

프록시와 백엔드 서버의 Timeout 값이 일치하는지 확인합니다.

6. Load Balancer 설정 확인하기

다음 환경에서는 Timeout 설정을 확인해야 합니다.

  • AWS ALB
  • AWS NLB
  • HAProxy
  • F5 BIG-IP
  • Kubernetes Ingress
  • Nginx Reverse Proxy

로드밸런서가 먼저 연결을 종료하면 Connection Reset이 발생할 수 있습니다.

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

네트워크 인터페이스를 확인합니다.

sar -n DEV 1

또는

ip -s link

패킷 손실이나 오류가 증가하는지 함께 확인합니다.

8. 프로세스 확인하기

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

ss -tanp

또는

lsof -iTCP

특정 프로그램에서만 오류가 발생하는지 분석합니다.

9. 커널 로그 확인하기

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

dmesg | grep TCP

또는

journalctl -k | grep tcp

NIC 드라이버나 커널 관련 오류도 함께 확인합니다.

10. 패킷 흐름 분석하기

전체 TCP 흐름을 분석합니다.

tcpdump -i eth0 -nn -vv

또는 Wireshark에서 Follow TCP Stream 기능을 사용하면 연결이 끊기는 시점을 쉽게 확인할 수 있습니다.

Connection Reset 점검 순서

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

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

Connection Reset 사용 시 주의사항

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

  • 일시적인 Connection Reset은 정상일 수 있다.
  • 브라우저 종료만으로도 발생할 수 있다.
  • Timeout 설정을 일관성 있게 유지한다.
  • 프록시와 백엔드의 Timeout을 맞춘다.
  • 네트워크 장비의 연결 정책을 확인한다.
  • 대량으로 발생하면 반드시 원인을 분석한다.

단순히 오류 개수만 보는 것이 아니라 어떤 환경에서 발생하는지 함께 분석하는 것이 중요합니다.

Broken Pipe와 Connection Reset의 차이

항목Broken PipeConnection Reset by Peer
오류 코드EPIPEECONNRESET
원인종료된 연결에 write() 수행상대방이 RST 전송
발생 위치애플리케이션TCP 연결
주요 원인Socket 종료 후 쓰기강제 연결 종료

Broken Pipe는 종료된 연결에 데이터를 쓰려 할 때 발생하고, Connection Reset은 상대방이 연결 자체를 강제로 종료했을 때 발생합니다.

자주 묻는 질문

Connection Reset은 서버 문제인가요?

항상 그렇지는 않습니다. 클라이언트가 브라우저를 닫거나 네트워크가 일시적으로 끊겨도 발생할 수 있습니다.

Connection Reset을 완전히 없앨 수 있나요?

불가능합니다. TCP 환경에서는 정상적인 상황에서도 발생할 수 있는 오류입니다. 다만 불필요하게 많이 발생하는 경우에는 Timeout 설정과 애플리케이션 구조를 점검해야 합니다.

Connection Reset과 Broken Pipe는 같은 오류인가요?

아닙니다. Connection Reset은 상대방이 연결을 강제로 종료한 상황이고, Broken Pipe는 종료된 연결에 데이터를 쓰려 할 때 발생하는 오류입니다.

마무리

Connection Reset by Peer(ECONNRESET)는 상대방이 RST 패킷을 보내 TCP 연결을 즉시 종료할 때 발생하는 대표적인 네트워크 오류입니다. tcpdump, ss, journalctl, lsof 등을 활용하면 원인을 빠르게 분석할 수 있으며, KeepAlive와 Timeout 설정을 일관성 있게 유지하고 네트워크 장비와 애플리케이션의 연결 정책을 함께 점검하면 안정적인 서비스 운영에 도움이 됩니다.

댓글 남기기