Windows 포트 충돌과 WinNAT 예약 포트 범위 해결

Windows 환경에서 Node.js, Spring Boot, Docker 컨테이너 또는 Vite 개발 서버를 구동하다 보면 포트가 이미 사용 중이라며 바인딩에 실패하는 오류를 자주 마주합니다. 대표적으로 Node.js 환경의 listen EADDRINUSE: address already in use 0.0.0.0:3000이나 다른 런타임의 bind: An attempt was made to access a socket in a way forbidden by its access permissions (WSAEACCES 10013) 에러가 발생합니다. 이상한 점은 netstat이나 리소스 모니터로 아무리 조회해도 해당 포트를 사용 중인 프로세스 ID(PID)가 전혀 검색되지 않는다는 사실입니다.

이 현상은 애플리케이션 프로세스 간의 일반적인 포트 충돌이 아니라, Windows 커널의 가상화 네트워크 스택인 Hyper-V와 WinNAT 드라이버가 임의의 포트 구간을 시스템 예약 대역으로 선점해버렸기 때문에 일어납니다.

에러 증상과 숨겨진 포트 점유 분석

개발 서버가 특정 포트 번호에 바인딩하려 할 때 운영체제 레벨에서 접근이 차단되면 런타임마다 각기 다른 소켓 예외를 출력합니다. 공통적으로는 소켓 권한 거부 또는 포트 중복 에러 코드를 반환합니다:

Error: listen EADDRINUSE: address already in use :::3000
    at Server.setupListenHandle [as _listen2] (node:net:1872:16)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2008:7)

또는 Go, Python, Rust 등 Winsock API를 직접 호출하는 환경에서는 다음과 같은 소켓 바인딩 실패 로그가 기록됩니다:

bind: An attempt was made to access a socket in a way forbidden by its access permissions.
[WinError 10013] 액세스 권한에 의해 숨겨진 소켓에 액세스를 시도했습니다

이때 엔지니어가 가장 먼저 수행하는 조치는 해당 포트를 점유하고 있는 프로세스를 찾아 강제 종료하는 일입니다. PowerShell이나 명령 프롬프트(CMD)에서 netstat 명령을 실행합니다:

# 3000번 포트를 점유 중인 프로세스 검색
netstat -ano | findstr :3000

# PowerShell 네이티브 명령으로 TCP 연결 및 수신 포트 검색
Get-NetTCPConnection -LocalPort 3000 -ErrorAction SilentlyContinue

명령을 실행해도 아무런 출력 결과가 반환되지 않습니다. 즉, 유저 영역(User Space)에서 3000번 포트를 열어두고 있는 프로세스는 존재하지 않습니다. 프로세스가 없는데도 운영체제가 소켓 바인딩 요청을 거부하는 이유는 Windows TCP/IP 스택이 관리하는 제외 포트 범위(Excluded Port Range)에 해당 포트가 포함되었기 때문입니다.

현재 Windows 커널이 바인딩을 차단하고 있는 포트 대역 전체는 netsh 명령어로 즉시 확인할 수 있습니다:

# IPv4 프로토콜의 제외 포트 예약 범위 목록 조회
netsh interface ipv4 show excludedportrange protocol=tcp

출력 결과를 확인하면 수백 개에서 수천 개에 이르는 포트 블록들이 나열됩니다. 예를 들어 시작 포트: 2980, 끝 포트: 3079와 같이 개발용으로 흔히 쓰이는 3000번, 5000번, 8080번 포트가 시스템 관리 포트 대역에 그대로 묶여 있는 모습을 발견할 수 있습니다.

Hyper-V와 WinNAT 동적 포트 할당 메커니즘

이처럼 포트가 무작위로 예약 대역에 갇히는 근본 원인은 Windows의 가상화 기능인 Hyper-V, WSL2, Windows 샌드박스, 또는 Docker Desktop이 사용하는 WinNAT(Windows Network Address Translation) 커널 드라이버의 초기화 로직에 있습니다.

Windows는 부팅 시점이나 가상 스위치가 생성되는 단계에서 호스트와 가상 머신 간의 내부 네트워크 주소 변환을 처리하기 위해 Host Network Service(HNS)를 구동합니다. 이때 HNS와 WinNAT 드라이버는 가상 머신(WSL2 등)에서 외부로 나가는 아웃바운드 트래픽에 할당할 동적 포트 풀(Ephemeral Ports)을 호스트의 동적 포트 범위 내에서 블록 단위로 대량 예약합니다.

문제는 Windows의 기본 동적 포트 범위 설정입니다. Windows Vista 및 Windows Server 2008 이후의 공식 TCP/IP 동적 포트 시작 범위는 49152번이지만, 일부 Windows 빌드나 Hyper-V 서비스가 활성화된 특정 환경에서는 동적 포트 시작 번호가 1024번부터 할당되도록 레지스트리가 구성되어 있는 경우가 많습니다.

동적 포트의 시작점이 1024번으로 낮게 잡혀 있으면, WinNAT 드라이버가 부팅 시 임의의 포트 블록(예: 100개~200개 단위)을 무작위로 집어갈 때 3000(React/Node), 5000(Flask), 5173(Vite), 8080(Spring/Tomcat) 같은 개발용 포트들이 희생양이 됩니다. 심지어 컴퓨터를 재부팅할 때마다 WinNAT이 점유하는 포트 블록의 위치가 매번 바뀌기 때문에, 어제까지 잘 동작하던 프로젝트가 오늘 아침 출근 후 갑자기 포트 에러를 뿜어내는 기현상이 반복됩니다.

따라서 Windows의 TCP/IP 동적 포트 시작 범위를 IANA 표준 권고 규격인 49152번 이후로 완전히 격리 재배치하는 것이 문제의 근본적인 해결책입니다.

WinNAT 임시 복구와 동적 포트 범위 영구 재설정

문제를 해결하는 방법은 당장 개발을 진행하기 위한 임시 조치와, 재부팅 후에도 포트 충돌이 재발하지 않도록 운영체제 네트워크 스택을 교정하는 영구 조치로 나뉩니다.

WinNAT 서비스 재기동을 통한 임시 복구

지금 당장 실행해야 하는 개발 서버가 차단되어 급한 상황이라면, 관리자 권한 PowerShell에서 WinNAT 드라이버를 중지했다가 다시 시작하여 예약 포트 풀을 초기화할 수 있습니다:

# 관리자 권한 PowerShell 실행 필수
# WinNAT 드라이버 중지 (예약된 포트 블록 해제)
net stop winnat

# WinNAT 드라이버 재시작
net start winnat

이 명령을 실행하면 기존에 WinNAT이 물고 있던 제외 포트 블록들이 즉시 릴리즈되며, 원하는 포트에 정상적으로 개발 서버를 바인딩할 수 있게 됩니다. 그러나 이 방법은 임시방편에 불과하며, PC를 재부팅하거나 WSL2 환경을 재기동하면 다시 임의의 포트가 제외 대역으로 묶이게 됩니다.

동적 포트 범위 IANA 표준 재설정

재부팅 후에도 개발용 포트(1024~49151)가 WinNAT에 선점당하지 않도록 하려면, Windows의 TCP/IP 동적 포트 시작 위치를 49152번으로 영구 변경해야 합니다.

먼저 현재 시스템의 동적 포트 시작 번호와 할당 개수를 확인합니다:

# 현재 IPv4 동적 포트 설정 조회
netsh int ipv4 show dynamicport tcp

# 현재 IPv6 동적 포트 설정 조회
netsh int ipv6 show dynamicport tcp

조회 결과 시작 포트가 1024나 5000 등 낮은 숫자로 되어 있다면, 다음 명령어로 시작 포트를 49152로, 포트 수를 16384개(49152~65535)로 재설정합니다:

# IPv4 TCP 동적 포트 범위 재설정 (시작 49152, 포트수 16384)
netsh int ipv4 set dynamicport tcp start=49152 num=16384

# IPv6 TCP 동적 포트 범위 동일하게 동기화
netsh int ipv6 set dynamicport tcp start=49152 num=16384

# UDP 프로토콜 역시 동일한 규칙으로 대역 정립
netsh int ipv4 set dynamicport udp start=49152 num=16384
netsh int ipv6 set dynamicport udp start=49152 num=16384

이 설정을 적용하면 WinNAT 드라이버와 Hyper-V는 앞으로 49152번 이후의 고위 대역에서만 임시 포트를 할당받아 예약하게 되므로, 1024~49151 사이의 모든 개발 포트가 시스템 예약으로부터 안전하게 보호됩니다.

특정 포트 사전 예약 등록

만약 특정 프레임워크나 사내 고유 도구가 49152번 이상의 특정 포트를 반드시 리슨해야 한다면, Windows 레지스트리의 ReservedPorts 항목에 해당 포트를 등록하여 시스템이 임의로 건드리지 못하도록 방어할 수도 있습니다:

# 특정 포트(예: 50000~50010)를 영구 예약 포트로 등록하는 레지스트리 경로
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters"

# 현재 등록된 ReservedPorts 확인
Get-ItemProperty -Path $regPath -Name "ReservedPorts" -ErrorAction SilentlyContinue

이 설정은 시스템 레지스트리를 직접 조작하므로, 일반적인 개발 환경에서는 앞서 수행한 netsh 동적 포트 범위 재배치만으로도 충분합니다.

적용 결과 검증과 포트 바인딩 테스트

네트워크 스택 설정을 변경한 후에는 시스템을 한 번 재부팅한 뒤, 변경된 동적 포트 범위와 제외 포트 목록을 검증해야 합니다.

재부팅 완료 후 관리자 권한 PowerShell을 열고 변경 사항이 정상 유지되고 있는지 확인합니다:

# 동적 포트 범위 정상 적용 확인
netsh int ipv4 show dynamicport tcp

출력 화면의 시작 포트가 49152, 포트 수가 16384로 표시되어야 합니다. 이어서 현재 커널이 예약하고 있는 제외 포트 대역 전체를 스캔하여 개발용 포트가 포함되어 있는지 진단합니다:

# 특정 대상 포트가 제외 대역에 포함되어 있는지 검사하는 PowerShell 스크립트
$targetPort = 3000
$excludedRanges = netsh interface ipv4 show excludedportrange protocol=tcp

$isBlocked = $false
foreach ($line in ($excludedRanges -split "`r?`n")) {
    if ($line -match '^\s*(\d+)\s+(\d+)') {
        $start = [int]$matches[1]
        $end = [int]$matches[2]
        if ($targetPort -ge $start -and $targetPort -le $end) {
            Write-Host "경고: 포트 $targetPort 번이 제외 범위($start - $end)에 포함되어 있습니다." -ForegroundColor Red
            $isBlocked = $true
            break
        }
    }
}

if (-not $isBlocked) {
    Write-Host "정상: 포트 $targetPort 번은 시스템 예약 없이 사용 가능합니다." -ForegroundColor Green
}

스크립트 실행 결과 대상 포트가 제외 범위에 포함되지 않았다는 정상 메시지가 출력되면, 기존에 충돌을 겪었던 개발 서버(Node.js, Docker 컨테이너 등)를 구동하여 소켓 바인딩 에러 없이 애플리케이션이 정상적으로 리스닝 상태로 진입하는지 최종 확인합니다.

실무 환경 사이드 이펙트 방지 FAQ

Windows에서 네트워크 드라이버 및 포트 범위를 조정할 때 실무 엔지니어들이 자주 문의하는 예외 상황과 주의점을 정리했습니다.

winnat 서비스를 재기동하면 WSL2나 Docker 컨테이너 통신이 끊어지는지

net stop winnat을 실행하는 순간 Windows 호스트와 WSL2/Docker 가상 머신 간의 NAT 변환 테이블이 일시적으로 초기화됩니다. 따라서 컨테이너가 외부 인터넷과 통신 중이거나 호스트-컨테이너 간 활성 TCP 연결이 맺어져 있는 상태라면 즉시 연결이 끊어집니다. 따라서 실행 중인 데이터베이스 트랜잭션이나 파일 다운로드가 없는 상태에서 재기동을 수행해야 하며, 만약 재기동 후 WSL2 내부에서 인터넷 연결이 원활하지 않다면 WSL2 인스턴스를 재시작(wsl --shutdown)하는 것이 안전합니다. 가상화 인스턴스 전반의 디스크 및 네트워크 최적화는 WSL2 vhdx 디스크 용량 압축 및 회수 가이드에서도 다루었듯이 정기적인 관리가 병행되는 것이 좋습니다.

Windows 기능 업데이트 후 동적 포트 설정이 초기화되는 현상

Windows 11의 주요 누적 업데이트나 연간 기능 업데이트(예: 23H2에서 24H2로의 판올림)가 진행되면 TCP/IP 스택의 레지스트리 키가 기본값으로 롤백되는 경우가 종종 발생합니다. 대규모 업데이트 이후 다시 WSAEACCES 10013 에러가 발생한다면 가장 먼저 netsh int ipv4 show dynamicport tcp를 실행하여 시작 포트가 49152번에서 1024번으로 회귀하지 않았는지 확인해야 합니다. 팀 차원에서는 이 설정을 개발 환경 셋업 스크립트에 포함해 두는 것을 권장합니다.

WSL2의 미러 모드(mirrored networking)를 사용할 때도 동일한 문제가 발생하는지

WSL2의 최신 네트워크 모드인 미러 모드(networkingMode=mirrored)를 사용하는 경우, 리눅스 VM이 호스트의 네트워크 인터페이스를 직접 미러링하므로 전통적인 NAT 포트 매핑 구조에 비해 WinNAT 의존도가 크게 낮아집니다. 그러나 Windows 호스트 자체에서 실행되는 로컬 개발 서버나 Docker Desktop의 호스트 포트 바인딩에는 여전히 Windows 커널의 동적 포트 규칙이 동일하게 적용되므로, 미러 모드 사용 여부와 무관하게 동적 포트 범위를 49152번 이후로 설정해 두어야 안전합니다.

타사 보안 소프트웨어나 VPN 클라이언트와의 충돌 가능성

기업용 보안 에이전트(EDR, DLP)나 SSL-VPN 클라이언트는 자체적인 NDIS 가상 네트워크 필터 드라이버를 로드합니다. 이러한 소프트웨어가 특정 포트 대역을 보안 감사용으로 사전 점유하거나 로컬 루프백 트래픽을 가로채는 경우, netsh excludedportrange에는 나타나지 않으면서도 Winsock 레벨에서 바인딩이 차단될 수 있습니다. netsh 설정 후에도 특정 포트 접근이 계속 차단된다면 기업 보안 에이전트의 예외 규칙 및 VPN 클라이언트의 가상 어댑터 바인딩 상태를 점검해야 합니다. 소켓 생명주기와 관련한 포트 고갈 이슈는 TCP TIME_WAIT 소켓 누수 트러블슈팅을 함께 참고하면 네트워크 레이어 분석에 도움이 됩니다.