Linux 서버를 운영하다 보면 SSH 접속, 웹 서버, 데이터베이스 또는 API 통신 과정에서 Connection reset by peer라는 오류를 자주 만나게 됩니다. 이 오류는 상대방 서버 또는 클라이언트가 TCP 연결을 강제로 종료했을 때 발생하는 대표적인 네트워크 오류입니다.
Connection timed out이나 Broken pipe와 비슷해 보이지만 원인은 조금 다릅니다. Connection reset by peer는 연결이 이미 생성된 이후 상대방이 RST(Reset) 패킷을 보내 연결을 강제로 종료했음을 의미합니다.
이번 글에서는 Linux에서 Connection reset by peer 오류가 발생하는 원인과 해결 방법을 알아보겠습니다.
Connection reset by peer란 무엇인가?
TCP 연결이 정상적으로 이루어진 후 상대방이 강제로 연결을 종료하면 다음과 같은 오류가 발생합니다.
대표적인 오류 예시는 다음과 같습니다.
ssh_exchange_identification: Connection reset by peer
또는
curl: (56) Recv failure: Connection reset by peer
또는
read: Connection reset by peer
즉, 연결은 성공했지만 통신 도중 상대방이 연결을 끊었다는 의미입니다.
Connection reset by peer가 발생하는 대표적인 원인
다음과 같은 경우에 자주 발생합니다.
- 서버 프로그램 비정상 종료
- 방화벽에서 TCP Reset 전송
- KeepAlive Timeout
- 클라이언트 강제 종료
- Reverse Proxy 종료
- SSL/TLS 설정 오류
- 애플리케이션 충돌
- 네트워크 장비 문제
- 최대 연결 수 초과
- Docker 또는 Kubernetes 네트워크 문제
실무에서는 로그와 TCP 연결 상태를 함께 확인하는 것이 중요합니다.
1. 서비스 실행 상태 확인하기
먼저 서비스가 정상적으로 실행 중인지 확인합니다.
SSH
systemctl status sshd
Nginx
systemctl status nginx
Apache
systemctl status httpd
MySQL
systemctl status mysqld
서비스가 반복적으로 종료되고 있다면 연결이 강제로 끊길 수 있습니다.
2. 서비스 로그 확인하기
로그에서 오류 원인을 확인합니다.
journalctl -xe
특정 서비스 로그 확인
journalctl -u nginx
또는
journalctl -u sshd
Crash나 Segmentation fault가 기록되어 있는지 확인합니다.
3. TCP 연결 상태 확인하기
현재 TCP 연결 상태를 확인합니다.
ss -tan
또는
netstat -tan
RESET 또는 CLOSE_WAIT 상태가 반복되는지 확인합니다.
4. 서버 리소스 확인하기
CPU
top
메모리
free -h
디스크
df -h
리소스 부족으로 서비스가 종료될 수 있습니다.
5. 방화벽 확인하기
Firewalld
firewall-cmd --list-all
UFW
ufw status
기업용 방화벽이나 IPS 장비에서 TCP Reset을 보내는 경우도 있습니다.
6. KeepAlive 설정 확인하기
SSH 설정 확인
grep Alive /etc/ssh/sshd_config
설정 예시
ClientAliveInterval 60
ClientAliveCountMax 3
KeepAlive가 없으면 연결이 강제로 종료될 수 있습니다.
7. SSL/TLS 설정 확인하기
HTTPS 환경에서는 인증서 문제도 확인해야 합니다.
openssl s_client -connect example.com:443
TLS Handshake 실패 여부를 확인합니다.
8. 최대 연결 수 확인하기
현재 연결 개수를 확인합니다.
ss -s
또는
netstat -an | wc -l
최대 연결 수를 초과하면 일부 연결이 강제로 종료될 수 있습니다.
9. Docker 및 Kubernetes 확인하기
Docker
docker ps
Kubernetes
kubectl get pods
컨테이너가 재시작되고 있지는 않은지 확인합니다.
10. 패킷 캡처하기
원인을 정확하게 분석하려면 패킷을 캡처합니다.
tcpdump -i any port 22
또는
tcpdump -i any host 서버IP
RST 패킷이 어느 쪽에서 발생하는지 확인할 수 있습니다.
Connection reset by peer 문제를 확인하는 순서
실무에서는 다음 순서대로 점검하는 것이 가장 효율적입니다.
- 서비스 상태 확인
- 서비스 로그 확인
- TCP 연결 상태 확인
- CPU·메모리·디스크 확인
- 방화벽 확인
- KeepAlive 설정 확인
- SSL/TLS 확인
- 최대 연결 수 확인
- Docker/Kubernetes 확인
- tcpdump 분석
이 순서대로 점검하면 대부분의 원인을 빠르게 찾을 수 있습니다.
Broken pipe와의 차이점
| 오류 | 의미 |
|---|---|
| Broken pipe | 이미 끊어진 연결로 데이터를 전송하려고 함 |
| Connection reset by peer | 상대방이 TCP 연결을 강제로 종료함 |
두 오류는 모두 연결 종료와 관련 있지만 발생 시점이 다르므로 원인 분석 방법도 달라집니다.
자주 묻는 질문
SSH에서 Connection reset by peer가 발생합니다.
SSH 서비스 재시작, KeepAlive 설정, /var/log/auth.log 또는 journalctl -u sshd 로그를 확인하는 것이 좋습니다.
웹 서버에서도 이 오류가 발생하나요?
네. Nginx, Apache, Node.js, Tomcat 등에서 클라이언트 연결이 강제로 종료될 경우 자주 발생합니다.
방화벽 때문에 발생할 수도 있나요?
가능합니다. 일부 방화벽이나 IPS 장비는 정책에 따라 TCP Reset 패킷을 보내 연결을 종료할 수 있습니다.
마무리
Connection reset by peer는 Linux 서버에서 자주 발생하는 TCP 연결 종료 오류입니다. 서비스 상태, 시스템 로그, KeepAlive 설정, 방화벽, SSL/TLS 설정 등을 단계적으로 점검하면 대부분의 원인을 찾을 수 있습니다. 특히 tcpdump를 활용하면 어느 쪽에서 연결을 종료했는지 정확하게 분석할 수 있어 실무에서 매우 유용합니다.