Windows에서 연결이 갑자기 끊길 때 Wireshark로 TCP RST 원인 찾는 방법

연결이 갑자기 끊긴다면 TCP 패킷부터 확인할 수 있다

Windows에서 네트워크 연결 문제를 진단하다 보면 아래 증상을 만날 수 있습니다.

웹 페이지가 로딩 중 갑자기 실패

API 요청 중 Connection Reset 발생

SSH 세션이 갑자기 종료

프로그램에서 Connection reset by peer 메시지 발생

잠시 정상 통신하다 특정 시점부터 연결 종료

VPN 연결 후 특정 서비스만 반복적으로 끊김

이런 상황에서는 단순히:

인터넷이 느리다

라고 판단하기보다 TCP 연결이 어떤 방식으로 끝났는지 확인해야 원인을 좁힐 수 있습니다.

Wireshark에서 RST 패킷이 발견됐다면 TCP 연결이 정상 종료 과정이 아니라 즉시 Reset된 상황인지 확인할 수 있습니다.

다만 먼저 기억할 원칙이 있습니다.

RST 패킷 하나를 발견했다고 해서 곧바로 서버 장애나 방화벽 차단이라고 결론 내리면 안 됩니다.

RST가 어디에서 왔는지, 직전에 어떤 패킷이 오갔는지, 정상적인 FIN 종료인지, 재전송이 반복되다 실패한 것인지까지 함께 봐야 합니다.

TCP 표준 RFC 9293도 정상 연결 종료는 FIN 기반으로, RST는 연결을 즉시 중단하는 Reset 동작으로 구분합니다. (RFC Editor)

먼저 RST·FIN·Retransmission을 구분한다

연결이 끊겼다고 해서 모두 같은 현상은 아닙니다.

실무에서 먼저 구분할 세 가지는 아래와 같습니다.

패킷 상태	의미	우선 확인할 방향
FIN	정상적인 연결 종료 과정	Application 종료·정상 세션 종료
RST	연결을 즉시 Reset	Client·Server·Proxy·Firewall 확인
Retransmission	이전 데이터 재전송	패킷 손실·지연·응답 부재 확인

FIN

FIN은 TCP 연결을 정상적으로 종료할 때 사용하는 Flag입니다.

단순화하면 아래 흐름이 나타날 수 있습니다.

Client                        Server

          데이터 통신
   ---------------------->

              <------------- FIN, ACK

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

   FIN, ACK ---------------->

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

세부 종료 순서는 어느 쪽에서 먼저 종료를 시작했는지에 따라 달라질 수 있습니다. 핵심은 FIN이 정상적인 종료 과정의 일부라는 점입니다.

RST

RST는 정상적인 FIN 절차 대신 현재 TCP 연결을 즉시 중단합니다.

예를 들어:

Client                        Server

SYN ----------------------->

    <---------------- SYN, ACK

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

DATA ---------------------->

    <---------------- RST, ACK

같은 흐름이 보일 수 있습니다.

이 경우 먼저 물어야 할 것은:

왜 RST가 발생했는가?

보다 먼저:

누가 RST를 보냈는가?

입니다.

Retransmission

Retransmission은 보낸 TCP Segment가 정상 확인되지 않아 다시 전송되는 상황을 분석할 때 중요합니다.

Wireshark는 Sequence Number 등 TCP 흐름을 분석해 특정 패킷을:

[TCP Retransmission]

으로 표시할 수 있습니다.

Wireshark 공식 문서에서 tcp.analysis.retransmission은 **의심되는 재전송(suspected retransmission)**을 나타내는 분석 필드입니다. 이 표시 하나만으로 실제 네트워크 패킷 손실을 확정해서는 안 됩니다. (Wireshark)

문제를 재현할 때는 짧은 구간만 캡처한다

연결 장애를 분석할 때 Wireshark를 몇 시간씩 계속 실행하면 오히려 분석이 어려워집니다.

가능하면:

Wireshark 시작
↓
문제 발생 직전에 Capture 시작
↓
웹·API·SSH 문제 재현
↓
문제가 발생하면 바로 Capture 중지
↓
pcapng 저장

처럼 짧은 구간을 확보하는 편이 좋습니다.

Wireshark가 설치되지 않았거나 Npcap·인터페이스 선택부터 확인해야 한다면 기존 글인 Windows에서 Wireshark 설치 후 패킷 캡처 확인하기 — Npcap·인터페이스·필터 점검에서 기본 캡처 환경을 먼저 확인합니다.

내부 링크:

https://dailyo.net/wireshark-install-guide/

Wireshark의 Display Filter는 캡처 파일을 삭제하거나 변경하지 않습니다. 이미 수집된 패킷 중 화면에 보여줄 패킷을 좁히는 기능입니다. (Wireshark)

TCP RST만 먼저 찾아보기

캡처가 끝났다면 먼저 아래 Display Filter를 적용합니다.

tcp.flags.reset == 1

그러면 RST Flag가 설정된 TCP 패킷만 표시됩니다.

특정 서버와의 연결만 보려면 IP 조건을 함께 사용합니다.

예를 들어 서버 IP가 203.0.113.20이라면:

ip.addr == 203.0.113.20 && tcp.flags.reset == 1

443 포트까지 제한하려면:

ip.addr == 203.0.113.20 && tcp.port == 443 && tcp.flags.reset == 1

처럼 범위를 좁힙니다.

여기서 바로 분석을 끝내면 안 됩니다.

RST 패킷만 필터링하면 RST 이전에 어떤 통신이 있었는지 보이지 않기 때문입니다.

RST가 발견되면 Source와 Destination을 확인한다

예를 들어 아래 패킷이 발견됐다고 가정해 보겠습니다.

Source          Destination       Info

203.0.113.20    192.0.2.10        443 → 53142 [RST, ACK]

현재 캡처 위치가 Client PC이고:

192.0.2.10

이 Client,

203.0.113.20

이 접속 대상 서버라면 화면상으로는 서버 방향에서 Client로 RST가 돌아온 것입니다.

반대라면:

192.0.2.10      203.0.113.20      53142 → 443 [RST, ACK]

Client 방향에서 Reset이 발생한 것입니다.

이 차이만으로 조사 범위를 상당히 줄일 수 있습니다.

다만 Source IP가 서버 주소라는 이유만으로 백엔드 애플리케이션이 직접 RST를 생성했다고 확정해서는 안 됩니다.

실제 통신 경로에 아래 장비가 있다면:

Load Balancer
Reverse Proxy
WAF
Firewall
VPN Gateway
TLS Inspection 장비

중간 장비가 TCP 연결의 Endpoint 역할을 하거나 세션을 종료할 수 있기 때문입니다.

패킷은 항상 어디에서 캡처했는지와 함께 해석해야 합니다.

RST 하나가 아니라 해당 TCP Stream 전체를 본다

RST 패킷을 선택한 뒤 해당 연결 전체를 확인하는 편이 좋습니다.

Wireshark에서는 패킷을 선택하고:

마우스 오른쪽 클릭
→ Follow
→ TCP Stream

또는:

Analyze
→ Follow
→ TCP Stream

을 사용합니다.

Wireshark 공식 가이드에 따르면 Follow TCP Stream은 선택한 연결의 패킷을 자동으로 필터링해 하나의 TCP Stream으로 확인하도록 합니다. (Wireshark)

Stream 번호를 확인했다면 Display Filter로 직접 지정할 수도 있습니다.

예를 들어:

tcp.stream eq 17

처럼 사용합니다.

이렇게 하면 아래처럼:

SYN
SYN, ACK
ACK
Application Data
ACK
Application Data
RST

실제 연결 전체 흐름을 한 번에 볼 수 있습니다.

RST 직전에 어떤 패킷이 있었는지가 중요하다

RST 원인을 추적할 때는 RST 패킷 자체보다 직전에 발생한 통신이 더 중요한 경우가 많습니다.

예를 들어 아래 흐름을 생각해 볼 수 있습니다.

Client → Server
TCP 연결 성공

Client → Server
Application 요청

Server → Client
ACK

Server → Client
RST

이 경우 서버 측 애플리케이션, Reverse Proxy, Load Balancer, 정책 장비 쪽으로 조사 범위를 좁혀볼 수 있습니다.

반대로:

Server → Client
Application Data

Client → Server
ACK

Client → Server
RST

라면 Client Application, 로컬 TCP Stack, Endpoint Security, VPN Client 영향도 함께 확인해야 합니다.

여기서도 RST 방향 하나만 보고 원인을 확정해서는 안 됩니다.

TCP 표준에는 존재하지 않는 연결로 패킷이 도착했을 때처럼 TCP 자체가 Reset을 발생시키는 조건도 있습니다. (RFC Editor)

FIN으로 종료됐다면 반드시 장애라고 볼 수는 없다

패킷을 확인했는데 RST가 없고 아래처럼 FIN이 보인다면:

Client              Server

        <--------- FIN, ACK
ACK -------------->

FIN, ACK ---------->

        <--------- ACK

이는 정상 TCP 연결 종료일 수 있습니다.

예를 들어:

HTTP 요청 완료
SSH 사용자가 로그아웃
API Client가 세션 종료
Application이 정상적으로 Socket Close

이런 경우에도 FIN이 나타날 수 있습니다.

사용자가:

연결이 끊어졌다

고 표현했더라도 패킷에서 반드시 장애가 발생한 것은 아닙니다.

애플리케이션이 정상적으로 세션을 종료한 것인지 확인해야 합니다.

Retransmission이 반복된다면 RST 분석과 방향이 달라진다

RST 대신 아래 표시가 반복된다면:

[TCP Retransmission]

분석 방향이 달라집니다.

Display Filter는:

tcp.analysis.retransmission

을 사용합니다.

RST와 FIN까지 한 번에 확인하려면:

tcp.flags.reset == 1 ||
tcp.flags.fin == 1 ||
tcp.analysis.retransmission

처럼 확인합니다.

Wireshark의 TCP 분석 기능은 Sequence Number와 이전 패킷 흐름을 기준으로 재전송 가능성을 판단합니다. Retransmission은 분석으로 판단되는 항목이므로 패킷 손실이 발생했다고 즉시 확정해서는 안 됩니다. (Wireshark)

예를 들어 아래 경우를 구분해야 합니다.

실제 Network Packet Loss

Server 응답 지연

Client 성능 문제

Wi-Fi 품질 문제

VPN 경로 문제

Capture 시작 시점 때문에 이전 패킷을 놓친 경우

Capture 환경 자체에서 일부 패킷이 누락된 경우

예를 들면:

TCP Retransmission 발견
=
네트워크 장비 장애 확정

은 아닙니다.

반복적인 재전송 뒤 RST가 나타나는지도 확인한다

아래 패턴은 단순 RST 한 개와 의미가 다릅니다.

Client → Server
DATA

Client → Server
TCP Retransmission

Client → Server
TCP Retransmission

Client → Server
TCP Retransmission

Client → Server
RST

이런 흐름이라면 먼저 아래를 확인합니다.

Server가 ACK를 보내지 못한 이유

중간 경로에서 패킷이 손실됐는지

Server Application이 응답하지 않았는지

Client Application Timeout이 발생했는지

반면:

Client → Server
Application Data

Server → Client
즉시 RST

라면 패킷 손실보다 애플리케이션이나 정책 기반 연결 종료 가능성을 먼저 확인합니다.

RST 직전 패킷 패턴이 원인 범위를 좁히는 핵심입니다.

Windows에서 실제 연결 상태도 함께 확인한다

Wireshark는 패킷에서 무슨 일이 있었는지 보여줍니다. 어떤 Windows 프로세스가 해당 연결을 만들었는지까지 함께 보면 훨씬 도움이 됩니다.

PowerShell에서:

Get-NetTCPConnection

을 실행하면 현재 TCP 연결을 확인합니다.

Microsoft 문서에 따르면 Get-NetTCPConnection은 Local/Remote IP와 Port, Connection State, Owning Process 정보를 조회합니다. (Microsoft Learn)

특정 서버를 확인하려면:

Get-NetTCPConnection |
Where-Object {
    $_.RemoteAddress -eq '203.0.113.20' -and
    $_.RemotePort -eq 443
} |
Select-Object LocalAddress,
              LocalPort,
              RemoteAddress,
              RemotePort,
              State,
              OwningProcess

처럼 범위를 좁힙니다.

결과에서 OwningProcess가:

이라면 아래 명령으로 프로세스를 확인합니다.

Get-Process -Id 7840

TCP Reset이 이미 발생해 Connection이 완전히 종료됐다면 Get-NetTCPConnection에서 해당 세션이 사라질 수 있습니다.

가능하면 문제를 재현하는 동안 함께 확인합니다.

netstat으로도 PID를 확인할 수 있다

명령 프롬프트에서는:

netstat -ano

를 사용합니다.

특정 포트를 확인하려면:

netstat -ano | findstr :443

처럼 사용합니다.

Microsoft 공식 문서에 따르면 netstat -o는 TCP 연결과 해당 연결의 PID를 함께 표시합니다. (Microsoft Learn)

예를 들어:

TCP    192.0.2.10:53142    203.0.113.20:443    ESTABLISHED    7840

가 보인다면:

PID 7840

이 해당 TCP Connection을 생성한 프로세스입니다.

작업 관리자 또는:

tasklist /FI "PID eq 7840"

으로 프로세스를 확인합니다.

패킷 시간과 애플리케이션 로그 시간을 맞춰 본다

Wireshark에서 RST가 아래 시간에 발생했다고 가정해 보겠습니다.

14:31:27.482

그렇다면 Windows Event Viewer나 해당 프로그램의 로그에서 14:31:27 전후를 확인하는 편이 좋습니다.

예를 들어:

14:31:27.470
Application Error

14:31:27.482
TCP RST

14:31:27.489
Application reconnect attempt

시간이 일치한다면 애플리케이션과 패킷 사이의 관계를 확인하는 데 도움이 됩니다.

이때 확인할 자료는 환경에 따라 아래와 같습니다.

Application Log

System Log

Web Server Log

Reverse Proxy Log

VPN Client Log

Endpoint Security Log

Firewall Log

Load Balancer Log

Wireshark는 원인을 자동으로 알려주는 프로그램이 아니라 원인 후보를 좁히는 도구로 사용하는 편이 좋습니다.

실제 분석에서는 이런 식으로 판단할 수 있다

다음은 특정 실제 장애를 재현한 사례가 아니라 패킷 분석 방법을 설명하는 예시입니다.

Client:

192.0.2.10

Server:

203.0.113.20:443

이라고 가정합니다.

Wireshark에서 아래 흐름을 확인했다고 가정합니다.

192.0.2.10     → 203.0.113.20    SYN

203.0.113.20   → 192.0.2.10      SYN, ACK

192.0.2.10     → 203.0.113.20    ACK

192.0.2.10     → 203.0.113.20    Application Data

203.0.113.20   → 192.0.2.10      ACK

203.0.113.20   → 192.0.2.10      RST, ACK

이 패턴에서는 아래 정도까지 판단할 수 있습니다.

TCP 3-Way Handshake 성공
↓
연결 자체는 성립
↓
Client가 데이터 전송
↓
Server 방향에서 ACK 수신
↓
그 뒤 RST 발생

이 경우:

DNS 조회 실패
TCP Port 자체 차단
SYN 단계에서 Connection Refused

같은 문제와는 성격이 다릅니다.

그다음에는 아래를 확인합니다.

Server Application Log

Reverse Proxy

Load Balancer

Firewall

TLS Inspection

Application 요청 형식

입니다.

패킷만 보고:

서버 프로그램이 문제다

라고 확정하지 않는 것입니다.

특정 사이트만 안 열린다면 앞 단계부터 확인해야 한다

RST 분석 전 DNS·Proxy·TLS에서 이미 실패하는 경우도 있습니다.

예를 들어:

DNS 자체가 실패

Proxy 설정 오류

TLS Handshake 실패

VPN 또는 HTTPS Inspection 문제

라면 TCP RST만 찾는 방식으로 전체 문제를 설명하기 어렵습니다.

이 경우 기존 글인:

Windows 11에서 인터넷은 되는데 특정 사이트만 안 열릴 때 — DNS·Proxy·TLS 점검

을 먼저 확인한 뒤 TCP Layer까지 내려오면 됩니다.

내부 링크:

https://dailyo.net/windows-11-specific-site-not-opening-dns-proxy-tls/

이렇게 연결하면 아래와 같은 흐름이 됩니다.

특정 사이트 접속 실패
↓
DNS 확인
↓
Proxy 확인
↓
TCP 확인
↓
TLS 확인
↓
필요하면 Wireshark RST 분석

TCP RST 분석에서 자주 하는 잘못된 판단

보이는 현상	바로 단정하면 안 되는 결론
RST 발견	서버 장애
서버 IP에서 RST	백엔드 Application이 직접 차단
Retransmission 발견	네트워크 장비 고장
FIN 발견	연결 장애
TCP 연결 성공	애플리케이션도 정상
Wireshark에 패킷 없음	상대 서버가 응답하지 않음

패킷 분석은 캡처 위치와 시점에 따라 보이는 결과가 달라질 수 있습니다.

Client와 Server에서 캡처한 결과를 비교할 수 있다면 원인을 훨씬 정확하게 좁힐 수 있습니다.

예를 들어:

Client Capture에는 패킷 존재
Server Capture에는 패킷 없음

이라면 중간 Network Path를 더 의심합니다.

반대로:

Server에서 요청 수신
Server에서 RST 전송 확인

까지 확보했다면 Server 영역으로 조사 범위를 더 좁힐 수 있습니다.

실무에서는 이 정도만 기록해도 충분히 도움이 된다

장애를 분석할 때 아래 정보를 기록해 두면 이후 비교하기 좋습니다.

발생 시간

Client IP / Port

Server IP / Port

사용 Application

TCP Stream 번호

RST 송신 방향

RST 직전 패킷

Retransmission 여부

FIN 존재 여부

Application Log

Firewall / VPN / Proxy 존재 여부

조치 내용

조치 후 재현 여부

예를 들어:

발생 시간:
2026-09-14 14:31:27

Client:
192.0.2.10:53142

Server:
203.0.113.20:443

증상:
API 요청 중 연결 종료

Wireshark:
Server → Client RST 확인

RST 이전:
Client Application Data 전송 후 Server ACK

Retransmission:
없음

조치:
Server Application Log 확인

검증:
동일 요청 재실행

이 정도로 기록하면 다음 장애가 발생했을 때 비교하기 쉬워집니다.

실제 사이트 게시글에 이런 예시를 넣을 때는 직접 확인한 환경과 설명용 예시를 명확하게 구분해야 합니다.

빠르게 확인할 Wireshark 필터

# TCP RST
tcp.flags.reset == 1

# TCP FIN
tcp.flags.fin == 1

# TCP Retransmission
tcp.analysis.retransmission

# 특정 서버
ip.addr == 203.0.113.20

# 특정 서버 + Port
ip.addr == 203.0.113.20 && tcp.port == 443

# 특정 TCP Stream
tcp.stream eq 17

실제 장애 분석에서는 필터 하나를 계속 유지하기보다 아래 순서로 확인합니다.

RST 확인
↓
Stream 특정
↓
필터 완화
↓
RST 이전 패킷까지 확인

정리

Windows에서 웹·API·SSH 등의 TCP 연결이 갑자기 끊긴다면 Wireshark에서 RST가 있는지 확인하는 것이 좋은 출발점이 될 수 있습니다.

하지만:

RST 발견
↓
원인 발견

은 아닙니다.

실제 분석은 아래 흐름으로 진행하면 됩니다.

문제 세션 확보
↓
RST / FIN / Retransmission 구분
↓
TCP Stream 전체 확인
↓
RST를 보낸 방향 확인
↓
RST 직전 통신 확인
↓
Windows Process와 연결
↓
Application·Firewall·VPN 로그와 시간 비교
↓
원인 범위 축소

특히 세 가지를 기억해야 합니다.

RST 하나만 보고 원인을 확정하지 않는 것, Retransmission을 곧바로 Packet Loss로 단정하지 않는 것, 그리고 Wireshark 결과를 애플리케이션 로그와 함께 해석하는 것입니다.

Wireshark가 장애를 자동으로 해결해 주지는 않습니다.

대신:

Client 문제인가?

Server 문제인가?

Network Path 문제인가?

Application 문제인가?

를 구분할 근거를 제공합니다.

이렇게 사용하면 단순 패킷 캡처 도구를 넘어 Windows 네트워크 장애의 원인 범위를 좁히는 실무 진단 도구로 활용할 수 있습니다.

참고 자료

Wireshark User’s Guide — Filtering Packets / Following Protocol Streams
Display Filter와 Follow TCP Stream의 공식 사용 방법입니다. Wireshark User’s Guide

Wireshark Display Filter Reference — TCP
tcp.flags.reset, tcp.flags.fin, tcp.analysis.retransmission, tcp.stream 등의 필드를 확인할 수 있습니다. Wireshark TCP Display Filter Reference

Wireshark User’s Guide — TCP Analysis
Wireshark의 Retransmission, Fast Retransmission, Out-of-Order 등의 판단 기준을 설명합니다. Wireshark TCP Analysis

RFC 9293 — Transmission Control Protocol (TCP)
TCP의 RST와 정상적인 FIN 기반 Connection Close 동작을 확인할 수 있는 표준 문서입니다. RFC 9293

Microsoft Learn — Get-NetTCPConnection
Windows에서 TCP Connection, Remote Address, Port, State, Owning Process를 확인하는 PowerShell 명령입니다. Get-NetTCPConnection 공식 문서

Microsoft Learn — netstat
Windows에서 TCP Connection과 PID를 확인하는 netstat 명령의 공식 문서입니다. netstat 공식 문서