Linux TCP RST 패킷이 발생하는 원인과 해결 방법

작성자:

Linux 서버를 운영하다 보면 tcpdump나 Wireshark로 패킷을 분석할 때 RST(Reset) 패킷이 반복적으로 발생하는 것을 볼 수 있습니다. RST 패킷은 TCP 연결을 정상적으로 종료(FIN)하는 대신 즉시 연결을 강제로 종료하는 데 사용됩니다.

간헐적으로 발생하는 RST는 정상적인 상황일 수 있지만, 지속적으로 발생하거나 대량으로 발생한다면 애플리케이션 오류, 네트워크 문제, 방화벽 설정, 포트 문제 등을 의심해야 합니다.

이번 글에서는 TCP RST 패킷이 발생하는 원인과 확인 방법, 해결 방법을 실무 중심으로 알아보겠습니다.

TCP RST 패킷이란?

RST(Reset)는 TCP 연결을 즉시 종료하기 위한 제어 패킷입니다.

정상적인 종료 과정은 다음과 같습니다.

Client                    Server

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

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

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

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

RST를 사용하는 경우는 다음과 같습니다.

Client                    Server

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

FIN과 달리 즉시 연결을 종료하며, 남아 있는 데이터는 폐기될 수 있습니다.

TCP RST가 발생하는 주요 원인

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

  • 존재하지 않는 포트 접속
  • 애플리케이션 강제 종료
  • Socket 오류
  • 방화벽 차단
  • KeepAlive Timeout
  • Reverse Proxy 설정 오류
  • Load Balancer 연결 종료
  • 커널에서 비정상 연결 감지
  • TCP Timeout
  • 프로그램 버그

1. RST 패킷 확인하기

RST 패킷만 확인합니다.

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

특정 포트를 확인하려면 다음과 같이 실행합니다.

tcpdump -i eth0 port 80

RST가 어느 방향에서 발생하는지 확인하는 것이 중요합니다.

2. TCP 연결 상태 확인하기

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

ss -s

또는

netstat -s

비정상 종료가 증가했는지 확인합니다.

3. 어떤 프로세스인지 확인하기

RST를 발생시키는 프로세스를 찾습니다.

ss -tanp

또는

lsof -iTCP

PID와 프로그램 이름을 함께 확인합니다.

4. 포트 상태 확인하기

서비스가 정상적으로 Listen 중인지 확인합니다.

ss -tln

또는

netstat -tln

서비스가 실행되지 않은 상태에서 접속하면 RST가 발생할 수 있습니다.

5. 방화벽 확인하기

iptables 규칙을 확인합니다.

iptables -L -n

firewalld를 사용하는 경우

firewall-cmd --list-all

방화벽 정책으로 인해 연결이 종료되는지 확인합니다.

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

프로그램 오류를 확인합니다.

예를 들어 Nginx

journalctl -u nginx

Apache

journalctl -u apache2

Tomcat

journalctl -u tomcat

Socket 관련 오류가 있는지 확인합니다.

7. 커널 로그 확인하기

커널 메시지를 확인합니다.

dmesg | grep TCP

또는

journalctl -k | grep tcp

네트워크 오류나 드라이버 문제도 함께 분석합니다.

8. KeepAlive 설정 확인하기

KeepAlive Timeout이 너무 짧으면 RST 발생이 증가할 수 있습니다.

Nginx

keepalive_timeout 65;

Apache

KeepAlive On
KeepAliveTimeout 5

애플리케이션 환경에 맞게 적절히 설정합니다.

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

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

sar -n DEV 1

또는

ip -s link

패킷 드롭이나 오류가 있는지 확인합니다.

10. 패킷 흐름 분석하기

RST 발생 전후의 TCP 흐름을 분석합니다.

tcpdump -i eth0 -nn -vv

또는 Wireshark에서 TCP Stream 기능을 이용하면 연결 종료 원인을 쉽게 파악할 수 있습니다.

TCP RST 점검 순서

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

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

TCP RST 사용 시 주의사항

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

  • RST는 항상 오류를 의미하지 않는다.
  • 존재하지 않는 포트 접속 시에도 발생한다.
  • 애플리케이션 강제 종료 시 발생할 수 있다.
  • 방화벽 정책도 원인이 될 수 있다.
  • KeepAlive Timeout을 적절히 설정한다.
  • 패킷 캡처를 통해 실제 원인을 확인한다.

단순히 RST 개수만 보고 문제를 판단하기보다 발생 위치와 원인을 함께 분석하는 것이 중요합니다.

FIN과 RST의 차이

항목FINRST
종료 방식정상 종료즉시 종료
데이터 처리남은 데이터 전송즉시 폐기 가능
사용 목적정상 연결 종료오류 또는 강제 종료
TCP 상태순차적 종료즉시 종료

FIN은 정상적인 TCP 종료 과정이며, RST는 연결을 즉시 종료해야 하는 상황에서 사용됩니다.

자주 묻는 질문

RST 패킷이 보이면 반드시 문제가 있는 건가요?

아닙니다. 존재하지 않는 포트 접속이나 클라이언트의 연결 취소 등 정상적인 상황에서도 RST는 발생할 수 있습니다. 다만 특정 서비스에서 지속적으로 발생한다면 원인 분석이 필요합니다.

RST를 완전히 없앨 수 있나요?

불가능합니다. RST는 TCP 프로토콜의 정상적인 제어 기능 중 하나입니다. 중요한 것은 불필요한 RST가 반복되지 않도록 애플리케이션과 네트워크 설정을 최적화하는 것입니다.

RST가 많으면 서버 성능이 저하되나요?

일반적으로 소량의 RST는 성능에 큰 영향을 주지 않습니다. 하지만 대량으로 발생하면 애플리케이션 오류나 공격, 네트워크 문제를 의심하고 원인을 분석해야 합니다.

마무리

TCP RST 패킷은 비정상적인 연결이나 즉시 연결 종료가 필요한 상황에서 사용되는 TCP 제어 패킷입니다. tcpdump, ss, lsof, journalctl 등을 활용하면 RST 발생 원인을 빠르게 분석할 수 있으며, 애플리케이션 설정, 방화벽 정책, KeepAlive 설정 등을 함께 점검하면 안정적인 TCP 연결 관리가 가능합니다.

댓글 남기기