안녕하세요. 일본서버, 미국서버 호스팅 전문 지구 IDC 기술팀입니다.
Windows 10에서 평소보다 TCP 연결 수가 갑자기 많아졌다면 단순히 전체 연결 개수만 확인하기보다 어떤 TCP 상태가 증가했는지, 어느 프로세스(PID)가 연결을 만들고 있는지, 특정 원격 IP나 로컬 포트에 연결이 집중되는지를 순서대로 확인해야 합니다. ESTABLISHED, TIME_WAIT, CLOSE_WAIT, SYN_RECEIVED가 각각 증가하는 원인은 서로 다를 수 있습니다.
이 문서에서는 Windows 10의 기본 명령인 netstat과 PowerShell의 Get-NetTCPConnection을 사용하여 TCP 연결 수 증가 원인을 진단하는 방법을 설명합니다. 연결 상태별 분포, PID별 연결 수, 원격 IP 집중도, 동적 포트 범위와 포트 고갈 여부까지 확인하면 정상적인 트래픽 증가인지 애플리케이션의 소켓 처리 문제인지, 외부 스캔이나 비정상 연결 시도인지 범위를 좁힐 수 있습니다.
적용 환경과 점검 전 주의사항
| 항목 | 내용 |
|---|---|
| 운영체제 | Windows 10 |
| 주요 도구 | netstat, tasklist, PowerShell Get-NetTCPConnection, 이벤트 뷰어 |
| 권장 권한 | 관리자 권한 명령 프롬프트 또는 PowerShell |
참고: Microsoft의 일반 Windows 10 지원은 2025년 10월 14일 종료되었습니다. 기존 Windows 10 시스템에서도 아래 진단 명령은 사용할 수 있지만, 인터넷에 노출되는 시스템은 장기적으로 현재 지원되는 Windows 버전으로 이전하는 것을 권장합니다.
중요: TCP 연결 수가 많다는 사실만으로 장애나 DDoS 공격이라고 판단할 수는 없습니다. 웹 서버, 게임 서버, 프록시, 데이터베이스 클라이언트처럼 정상적으로 동시 접속이 많은 프로그램도 수백~수천 개의 연결을 가질 수 있습니다. 평소 기준치와 비교하면서 상태, PID, 원격 IP, 연결 증가 속도를 함께 확인해야 합니다.
TCP 연결 수가 증가할 때 먼저 구분할 항목
원인을 빠르게 찾으려면 먼저 어떤 TCP 상태가 증가했는지를 확인합니다. 상태에 따라 점검 방향이 크게 달라집니다.
| 상태 | 의미 | 비정상 증가 시 확인할 항목 |
|---|---|---|
ESTABLISHED |
TCP 연결이 정상적으로 성립되어 데이터를 주고받을 수 있는 상태 | 실제 사용자 증가, 장시간 유지되는 세션, 특정 프로세스의 연결 누수, 특정 원격 IP 집중 여부 |
TIME_WAIT |
종료된 TCP 연결의 지연 패킷을 처리하기 위해 일정 시간 대기하는 상태 | 짧은 TCP 연결을 지나치게 자주 생성하는 프로그램, 연결 재사용 부족, 동적 포트 고갈 가능성 |
CLOSE_WAIT |
원격 측이 종료를 요청했지만 로컬 애플리케이션이 소켓 종료를 완료하기를 기다리는 상태 | 특정 애플리케이션의 소켓 정리 지연 또는 연결 종료 처리 문제 |
SYN_RECEIVED |
연결 요청을 받고 응답한 뒤 최종 ACK를 기다리는 상태 | 클라이언트 응답 지연, 패킷 손실, 스캔, 다수의 불완전한 연결 시도 또는 SYN flood 가능성 |
SYN_SENT |
로컬 시스템이 원격 서버에 SYN을 보내고 응답을 기다리는 상태 | 원격 서버 장애, 방화벽 차단, 네트워크 손실, 애플리케이션의 반복 연결 시도 |
목차
- 현재 TCP 연결 수와 상태별 분포 확인
- 어느 프로세스가 연결을 많이 만드는지 확인
- 특정 원격 IP에 연결이 집중되는지 확인
- TIME_WAIT·CLOSE_WAIT·SYN_RECEIVED 원인 분석
- 동적 포트 고갈 여부 확인
- 연결 수가 계속 증가하는지 추적
- 외부 스캔·공격 가능성 확인
- 증상별 원인과 조치 방향
- 원인 조치 후 정상화 확인
- 관련 기술자료와 공식 참고자료
- 자주 묻는 질문
현재 TCP 연결 수와 상태별 분포 확인
netstat으로 전체 TCP 연결 확인
관리자 권한 명령 프롬프트에서 다음 명령을 실행하면 현재 TCP 연결과 수신 대기 포트, 로컬·원격 주소, 상태, PID를 확인할 수 있습니다.
netstat -ano -p tcp
-a는 활성 연결과 수신 대기 포트를 표시하고, -n은 주소와 포트 번호를 숫자로 표시하며, -o는 해당 연결의 PID를 함께 표시합니다. 연결 수가 많을 때는 결과를 파일로 저장해 비교하는 것도 좋습니다.
netstat -ano -p tcp > C:\tcp-connections.txt
PowerShell에서 상태별 연결 수 집계
PowerShell에서는 Get-NetTCPConnection 결과를 상태별로 묶어 어느 상태가 대부분을 차지하는지 빠르게 확인할 수 있습니다.
Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending | Select-Object Name, Count
전체 TCP 항목 수만 빠르게 확인하려면 다음 명령을 사용합니다.
(Get-NetTCPConnection).Count
평소 정상 상태의 연결 수를 알고 있다면 같은 시간대와 트래픽 조건에서 비교하는 것이 가장 좋습니다. 절대적인 연결 개수만으로 정상·비정상을 나누는 고정 기준은 없습니다.
어느 프로세스가 연결을 많이 만드는지 확인
연결 수 증가가 특정 프로그램 때문에 발생하는지 확인하려면 OwningProcess 기준으로 TCP 연결을 집계합니다.
Get-NetTCPConnection | Group-Object OwningProcess | Sort-Object Count -Descending | Select-Object -First 20 Name, Count
출력의 Name 값은 PID입니다. 예를 들어 PID가 1234라면 다음 명령으로 실제 프로세스를 확인합니다.
tasklist /FI "PID eq 1234"
svchost.exe처럼 하나의 프로세스 안에서 여러 Windows 서비스가 실행되는 경우에는 서비스 목록도 확인합니다.
tasklist /svc /FI "PID eq 1234"
Microsoft의 netstat 문서에서 제공하는 -b 옵션을 사용하면 각 연결을 만든 실행 파일도 확인할 수 있습니다. 다만 이 옵션은 관리자 권한이 필요할 수 있고 출력에 시간이 더 걸릴 수 있습니다.
netstat -anob -p tcp
주의: 연결 수가 많다는 이유만으로 PID를 바로 강제 종료하지 마십시오. 웹 서버, 데이터베이스, RDP, 게임 서버, 백업 프로그램 또는 Windows 핵심 서비스일 수 있습니다. 먼저 프로세스 이름과 역할, 해당 서비스의 로그를 확인한 뒤 정상적인 서비스 중지 절차를 사용해야 합니다.
특정 원격 IP에 연결이 집중되는지 확인
서버로 들어오는 연결이 급증했다면 ESTABLISHED 연결이 특정 원격 IP에 집중되는지 확인합니다. 다음 명령은 현재 연결된 원격 IP별 세션 수를 많은 순서대로 표시합니다.
Get-NetTCPConnection -State Established |
Group-Object RemoteAddress |
Sort-Object Count -Descending |
Select-Object -First 20 Name, Count
특정 서비스 포트만 확인하고 싶다면 예를 들어 로컬 TCP 3389번 포트의 연결만 다음과 같이 좁힐 수 있습니다.
Get-NetTCPConnection -LocalPort 3389 |
Group-Object RemoteAddress |
Sort-Object Count -Descending |
Select-Object -First 20 Name, Count
게임 서버나 웹 서버처럼 다른 포트를 사용하는 경우 3389를 실제 서비스 포트로 변경합니다. 특정 IP에서 연결이 많더라도 NAT, 프록시, 사내 게이트웨이 또는 CDN을 사용하는 환경에서는 여러 사용자가 하나의 공인 IP로 보일 수 있으므로 IP 개수만으로 차단 여부를 결정하지 않는 것이 좋습니다.
TIME_WAIT·CLOSE_WAIT·SYN_RECEIVED가 많을 때 원인 분석
TIME_WAIT가 많은 경우
Microsoft의 TCP/IP 포트 고갈 문서에 따르면 정상적으로 종료된 TCP 연결도 일정 시간 TIME_WAIT 상태에 머뭅니다. 따라서 TIME_WAIT가 많다는 사실만으로 포트 고갈을 확정할 수는 없습니다. 다만 특정 프로그램이 짧은 연결을 매우 빠르게 생성하고 종료한다면 TIME_WAIT가 누적되면서 동적 포트를 많이 사용할 수 있습니다.
현재 TIME_WAIT 수를 확인합니다.
(Get-NetTCPConnection -State TimeWait).Count
TIME_WAIT가 지속해서 증가한다면 애플리케이션이 HTTP·DB·API 연결을 매 요청마다 새로 생성하는지, 연결 풀이나 keep-alive를 적절히 재사용하는지 애플리케이션 설정과 로그를 함께 확인해야 합니다.
CLOSE_WAIT가 많은 경우
CLOSE_WAIT는 상대방이 연결 종료를 요청했지만 로컬 애플리케이션이 자신의 소켓 종료 처리를 끝내기를 기다리는 상태입니다. 특정 PID에서 CLOSE_WAIT가 계속 누적된다면 해당 애플리케이션의 연결 종료 처리와 소켓 관리 문제를 우선 확인합니다.
Get-NetTCPConnection -State CloseWait |
Group-Object OwningProcess |
Sort-Object Count -Descending |
Select-Object -First 20 Name, Count
상위 PID를 찾았다면 tasklist로 프로세스를 식별하고 애플리케이션 로그, 연결 풀, 예외 처리, 소켓 종료 코드를 확인합니다. 서비스 재시작으로 숫자가 일시적으로 줄더라도 원인이 애플리케이션에 있다면 다시 증가할 수 있습니다.
SYN_RECEIVED가 많은 경우
SYN_RECEIVED는 TCP 3-way handshake가 아직 완료되지 않은 상태입니다. 짧은 순간의 증가는 정상일 수 있지만 수가 비정상적으로 증가하고 오래 유지된다면 패킷 손실, 느린 클라이언트, 네트워크 장비 문제, 포트 스캔 또는 SYN flood와 같은 불완전 연결 시도를 의심할 수 있습니다.
netstat -ano -p tcp | findstr SYN_RECEIVED
특정 서비스 포트에 집중되는지 확인하려면 포트 번호도 함께 검색합니다. 예를 들어 TCP 3389번을 확인하려면 다음과 같이 사용할 수 있습니다.
netstat -ano -p tcp | findstr ":3389" | findstr SYN_RECEIVED
참고: SYN_RECEIVED가 많다는 사실만으로 DDoS 공격을 확정할 수 없습니다. 원격 IP 분포, 초당 연결 증가량, 네트워크 트래픽, 패킷 캡처, 방화벽 로그를 함께 확인해야 합니다.
동적 포트 고갈 여부 확인
Windows에서 외부로 TCP 연결을 생성할 때는 로컬 동적 포트가 사용됩니다. 애플리케이션이 매우 많은 아웃바운드 연결을 만들고 포트가 계속 소비되면 새 연결이 실패하는 포트 고갈(port exhaustion) 상태가 발생할 수 있습니다.
현재 IPv4 TCP 동적 포트 범위를 확인합니다.
netsh int ipv4 show dynamicport tcp
IPv6를 사용하는 환경이라면 다음 항목도 확인합니다.
netsh int ipv6 show dynamicport tcp
Microsoft 문서에서 설명하는 기본 동적 TCP 포트 범위는 일반적으로 49152부터 65535까지이지만, 시스템에서 범위가 변경되었을 수 있으므로 실제 값은 위 명령으로 확인해야 합니다.
이벤트 ID 4227과 4231 확인
Microsoft는 포트 고갈이 의심되는 경우 시스템 이벤트 로그에서 Event ID 4227과 4231을 확인하도록 안내합니다. PowerShell에서는 다음과 같이 최근 이벤트를 조회할 수 있습니다.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=4227,4231} -MaxEvents 20 |
Format-List TimeCreated, Id, ProviderName, Message
해당 이벤트와 함께 대량의 TIME_WAIT 또는 특정 프로세스의 과도한 연결 생성이 확인된다면 포트 고갈 가능성이 높아집니다.
주의: 동적 포트 범위를 무작정 변경하는 것은 근본적인 해결 방법이 아닙니다. Microsoft도 포트 범위를 늘리는 조치를 임시 대응으로 설명하며, 가장 많은 포트를 소비하는 프로세스를 찾아 원인을 해결하도록 권장합니다. 기존 방화벽이나 응용 프로그램이 특정 포트 범위를 전제로 구성되어 있다면 범위 변경으로 통신 장애가 발생할 수도 있습니다.
연결 수가 계속 증가하는지 추적
한 번의 netstat 결과만으로는 일시적인 트래픽 증가인지 연결 누적인지 구분하기 어렵습니다. PowerShell에서 일정 간격으로 상태별 연결 수를 반복 확인하면 증가 추세를 쉽게 볼 수 있습니다.
while ($true) {
Get-Date
Get-NetTCPConnection | Group-Object State | Sort-Object Name | Select-Object Name, Count
Start-Sleep -Seconds 10
}
중지하려면 Ctrl+C를 누릅니다. 특정 상태가 계속 증가한 뒤 줄어들지 않는다면 해당 상태를 만드는 PID와 원격 주소를 추가로 확인합니다.
TCP 프로토콜 누적 통계도 확인할 수 있습니다.
netstat -s -p tcp
이 통계는 누적값이므로 한 번의 숫자보다 일정 시간 간격으로 비교하여 연결 시도, 실패, 재전송 등이 빠르게 증가하는지 확인하는 용도로 사용하는 것이 좋습니다.
외부 스캔·공격 가능성 확인
인터넷에 직접 노출된 서버에서는 자동화된 포트 스캔이나 로그인 시도가 발생할 수 있습니다. TCP 연결 수가 증가할 때 다음 특징이 함께 보이면 외부 비정상 트래픽 가능성을 추가로 조사합니다.
- 특정 서비스 포트에
SYN_RECEIVED가 급격히 증가함 - 매우 많은 원격 IP에서 짧은 시간 동안 연결이 생성됨
- 특정 원격 IP가 비정상적으로 많은 세션을 반복 생성함
- 연결 수 증가와 동시에 CPU, 네트워크 또는 서비스 응답 시간이 급격히 악화됨
- RDP나 다른 인증 서비스에서 로그인 실패 이벤트가 동시에 급증함
다만 이런 현상도 정상적인 사용자 증가, NAT 환경, 프록시, 모니터링 시스템, 헬스 체크 때문에 나타날 수 있으므로 방화벽 로그와 애플리케이션 로그를 함께 확인합니다.
필요하면 네트워크 추적 수집
단순 소켓 목록만으로 원인을 판단하기 어렵다면 관리자 권한 명령 프롬프트에서 Windows 네트워크 추적을 수집할 수 있습니다. 먼저 저장할 폴더를 생성합니다.
mkdir C:\Temp
문제가 발생하는 동안 추적을 시작합니다.
netsh trace start scenario=netconnection capture=yes tracefile=C:\Temp\netconnection.etl
필요한 구간을 수집한 뒤 반드시 추적을 중지합니다.
netsh trace stop
주의: 네트워크 추적 파일에는 통신 대상 IP, 포트와 기타 네트워크 메타데이터가 포함될 수 있고 파일 크기가 커질 수 있습니다. 필요한 시간대만 수집하고 분석·전달 시 접근 권한을 제한하십시오.
증상별 원인과 조치 방향
| 증상 | 가능한 원인 | 확인 방법 | 조치 방향 |
|---|---|---|---|
ESTABLISHED가 급증 |
실사용자 증가, 세션 유지 시간이 김, 연결 누수 | PID별·원격 IP별 연결 수 집계 | 정상 트래픽인지 확인하고 특정 프로세스라면 애플리케이션 로그·연결 풀 점검 |
TIME_WAIT가 계속 증가 |
짧은 연결 과다 생성, 연결 재사용 부족 | Get-NetTCPConnection -State TimeWait, 동적 포트 범위, Event ID 4227/4231 |
HTTP keep-alive·연결 풀·DB 풀 등 애플리케이션 연결 재사용 구조 확인 |
CLOSE_WAIT가 특정 PID에 누적 |
애플리케이션이 원격 종료 후 소켓을 제대로 닫지 못함 | OwningProcess별 CLOSE_WAIT 수 집계 |
프로그램 로그와 소켓 종료 로직 확인, 필요 시 해당 애플리케이션 업데이트 |
SYN_RECEIVED가 급증 |
불완전 handshake, 패킷 손실, 스캔, SYN flood 가능성 | 서비스 포트, 원격 IP 분포, 트래픽·방화벽 로그, 네트워크 추적 | 네트워크 이상과 공격 가능성을 구분한 뒤 상위 방화벽 또는 DDoS 방어 장비 정책 검토 |
SYN_SENT가 많이 남음 |
원격 서버 미응답, 네트워크·방화벽 문제, 반복 재시도 | 원격 주소·포트와 PID 확인 | 대상 서비스 상태와 네트워크 경로를 확인하고 재시도 정책 점검 |
| 새 아웃바운드 연결이 실패함 | 동적 포트 고갈 가능성 | 동적 포트 범위, Event ID 4227/4231, netstat -anob |
가장 많은 포트를 사용하는 프로세스를 찾아 연결 생성 원인 해결 |
원인 조치 후 정상화 확인
애플리케이션 설정 변경, 서비스 정상 재시작, 방화벽 정책 수정 등 필요한 조치를 한 뒤에는 같은 방법으로 연결 분포가 정상화되었는지 다시 확인합니다.
Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending | Select-Object Name, Count
PID별 연결 수를 다시 확인하여 특정 프로세스의 연결이 계속 증가하는지도 비교합니다.
Get-NetTCPConnection | Group-Object OwningProcess | Sort-Object Count -Descending | Select-Object -First 20 Name, Count
정상화 여부는 단순히 연결 수가 낮아졌는지만 보지 말고 서비스 응답 상태, CPU·메모리·네트워크 사용률, 오류 로그, 사용자 접속 상태를 함께 확인해야 합니다.
관련 지구 IDC 기술자료
공식 참고자료
| 기관 | 문서 | 확인 내용 | 조회일 |
|---|---|---|---|
| Microsoft | netstat | -a, -b, -n, -o, -p, -s 옵션과 TCP 연결 조회 |
2026년 10월 25일 |
| Microsoft | Get-NetTCPConnection | 로컬·원격 주소와 포트, TCP 상태, OwningProcess 조회 | 2026년 10월 25일 |
| Microsoft | Troubleshoot port exhaustion issues | 동적 포트 범위, TIME_WAIT, Event ID 4227·4231, 포트 고갈 진단 | 2026년 10월 25일 |
| Microsoft | TCPSTATE enumeration | SYN_SENT, SYN_RECEIVED, ESTABLISHED, CLOSE_WAIT, TIME_WAIT 등 TCP 상태 정의 |
2026년 10월 25일 |
| Microsoft | TCP/IP connectivity issues troubleshooting | TCP handshake, TIME_WAIT, 패킷 손실과 네트워크 추적을 이용한 연결 문제 진단 | 2026년 10월 25일 |
| Microsoft Sysinternals | TCPView for Windows | GUI에서 TCP·UDP 엔드포인트와 연결 소유 프로세스를 실시간 확인하는 보조 도구 | 2026년 10월 25일 |
| Microsoft | Windows 10 지원 종료 | Windows 10 일반 지원 종료일 확인 | 2026년 10월 25일 |
자주 묻는 질문
TCP 연결은 몇 개부터 비정상이라고 판단하나요?
고정된 기준은 없습니다. 서버 역할, 애플리케이션 구조, 사용자 수와 트래픽에 따라 정상 연결 수가 크게 달라집니다. 평소 같은 시간대의 연결 수와 비교하고 상태별 분포, PID별 연결 수, 원격 IP와 시스템 부하를 함께 확인하는 것이 중요합니다.
TIME_WAIT가 수천 개면 바로 문제가 있는 것인가요?
반드시 그렇지는 않습니다. Microsoft도 많은 TIME_WAIT만으로 현재 포트가 고갈되었다고 판단할 수 없다고 설명합니다. 다만 빠르게 증가하면서 새 아웃바운드 연결이 실패하거나 Event ID 4227·4231이 함께 기록된다면 포트 고갈 가능성을 확인해야 합니다.
CLOSE_WAIT를 Windows 설정으로 강제로 줄여도 되나요?
일반적으로 먼저 해당 상태를 많이 보유한 애플리케이션의 원인을 확인해야 합니다. CLOSE_WAIT는 로컬 애플리케이션이 연결 종료 처리를 완료하기를 기다리는 상태이므로 숫자만 강제로 줄이는 방식보다 소켓 종료 로직, 연결 풀, 예외 처리와 프로그램 버전을 점검하는 것이 우선입니다.
SYN_RECEIVED가 많으면 SYN flood 공격인가요?
가능성 중 하나이지만 단정할 수는 없습니다. 네트워크 패킷 손실이나 느린 클라이언트에서도 불완전한 handshake가 발생할 수 있습니다. 특정 포트와 원격 IP 분포, 초당 증가량, 방화벽 로그, 패킷 추적을 함께 확인해야 합니다.
netstat 대신 실시간으로 보기 쉬운 Microsoft 도구가 있나요?
Microsoft Sysinternals의 TCPView를 사용할 수 있습니다. TCP와 UDP 엔드포인트, 로컬·원격 주소, TCP 상태, 소유 프로세스를 GUI에서 실시간으로 확인할 수 있어 연결 변화가 빠른 상황을 관찰할 때 유용합니다.
마무리
Windows 10에서 TCP 연결 수가 비정상적으로 증가한다면 먼저 상태별 연결 수를 확인하고, 이어서 연결을 많이 보유한 PID와 원격 IP를 찾는 순서로 진단하는 것이 효율적입니다. TIME_WAIT는 짧은 연결의 과다 생성, CLOSE_WAIT는 애플리케이션의 종료 처리 문제, SYN_RECEIVED는 불완전한 handshake 증가 여부를 중심으로 확인하면 원인을 빠르게 좁힐 수 있습니다.
특히 연결 수가 많다는 이유만으로 공격이라고 단정하거나 프로세스를 강제 종료하지 말고, 평소 기준치와 서비스 로그, 원격 IP 분포, 시스템 부하, 이벤트 로그를 함께 비교하시기 바랍니다.
지구 IDC는 일본서버와 미국서버를 포함한 다양한 서버 호스팅 환경에서 안정적인 운영에 도움이 되는 기술정보를 지속적으로 제공하겠습니다.