WSL2 네트워크 모드, NAT와 mirrored를 나눠야 하는 이유와 VPN 오류 점검법

글쓴이 Haechi

2026년 09월 06일

AI를 활용하여 생성한 이미지입니다.

컴퓨팅 · 중급 가이드

WSL2 네트워크 문제는 “인터넷이 안 된다” 한 문장으로 묶기 어려워요. Windows에서 WSL로 접속할 때와 WSL에서 Windows 서비스로 접속할 때 경로가 다르고, VPN이나 방화벽이 끼면 NAT에서만 실패하거나 mirrored에서만 꼬일 수 있어요. WSL을 처음 설치하는 방법은 기초 설치 글에서 다뤘으니, 여기서는 이미 배포판과 개발 서버를 쓰고 있는 경우에 초점을 맞출게요.

NAT와 mirrored는 무엇이 다른가

WSL2의 기본 네트워크는 NAT 기반이에요. Linux 쪽에 가상 네트워크 주소가 생기고 Windows 호스트와 별도의 경로를 거쳐요. Microsoft는 Windows 11 22H2 이상에서 networkingMode=mirrored를 설정하면 Windows 네트워크 인터페이스를 Linux에 미러링하는 새 구조를 사용할 수 있다고 설명해요.[1][2]

이 차이는 단순히 속도 설정이 아니에요. NAT에서는 WSL의 IP를 따로 확인해야 하는 상황이 많고, mirrored에서는 Windows와 Linux가 같은 인터페이스를 더 직접적으로 공유하는 대신 VPN·보안 제품·포트 바인딩 동작을 다시 확인해야 해요. 이미 정상인 개발환경이라면 모드를 바꾸기 전에 현재 구성을 기록하는 게 먼저예요.

localhost가 되는 방향부터 나눠요

Windows 프로그램에서 WSL 안의 서버로 접속하는 경우에는 WSL2의 localhost 포워딩이 작동할 수 있어요. 반대로 WSL에서 Windows 호스트의 서비스로 접속할 때는 NAT 구성에서 호스트 주소를 별도로 찾아야 하는 경우가 있습니다. Microsoft 문서도 Windows에서 wsl.exe --distribution <DistroName> hostname -I로 배포판의 주소를 확인하는 방법과, 호스트에 연결할 때의 방향을 따로 설명해요.[1]

아래처럼 실패 방향을 먼저 적어 두면 원인을 빨리 줄일 수 있어요.

Windows 브라우저 → WSL 서버: curl http://localhost:포트가 되는지 확인해요.
WSL 셸 → Windows 서비스: Windows 호스트 주소와 해당 서비스의 바인딩 주소를 확인해요.
다른 기기 → WSL 서버: localhost가 아니라 LAN 주소와 Windows 방화벽 인바운드 규칙을 확인해요.

서버가 127.0.0.1에만 바인딩되어 있으면 다른 기기에서 접근할 수 없어요. 반대로 0.0.0.0에 열어 두면 방화벽과 인증이 필수예요. 개발 서버를 외부 네트워크에 그대로 노출하는 설정은 피하는 게 좋아요.

mirrored 모드로 바꿀 때의 순서

사용자 프로필의 %UserProfile%\.wslconfig에 다음 설정을 넣을 수 있어요. Microsoft 문서에서 networkingMode의 기본값은 NAT이고, mirrored는 Windows 11 22H2 이상에서 사용할 수 있는 옵션으로 안내돼요.[2]

[wsl2]
networkingMode=mirrored

현재 설정을 백업하고 wsl --status, wsl -l -v 결과를 저장해요.
.wslconfig를 수정한 뒤 wsl --shutdown으로 WSL 가상 머신을 완전히 종료해요.
배포판을 다시 열어 ip addr, cat /etc/resolv.conf, 개발 서버 포트를 확인해요.
Windows → WSL, WSL → Windows, 다른 LAN 기기 → Windows 순서로 각각 접속을 시험해요.

설정 파일을 바꿨는데도 동작이 그대로라면 WSL 인스턴스가 종료되지 않았을 가능성이 있어요. wsl --shutdown은 실행 중인 모든 WSL 배포판을 닫으므로 작업 중인 프로세스가 없는지 먼저 확인하세요.

VPN과 DNS가 끼면 무엇을 볼까

Windows 11 22H2 이상에서는 dnsTunneling=true가 기본값이고, autoProxy=true를 사용하면 Windows의 HTTP 프록시 정보를 WSL에 전달할 수 있어요.[1][2] 회사 VPN이나 보안 클라이언트가 DNS와 라우팅을 강제로 관리하면 이 자동화가 오히려 충돌할 수 있어요.

Microsoft의 문제 해결 문서에는 특정 보안 제품과 mirrored·DNS tunneling 조합에서 문제가 생길 때 dnsTunneling=false 또는 networkingMode=nat를 시도하는 방법이 나와 있어요.[3] 이건 모든 VPN에 적용되는 만능 해법이 아니에요. 증상이 VPN 연결 직후에만 생긴다면 다음 순서로 범위를 좁혀 보세요.

VPN을 끈 상태에서 WSL의 DNS와 사설망 접속을 확인해요.
Windows 명령 프롬프트에서 같은 도메인이 해석되는지 비교해요.
WSL 안에서 getent hosts 도메인과 curl -Iv https://도메인을 실행해요.
DNS만 실패하면 dnsTunneling, HTTP만 실패하면 autoProxy와 프록시 환경 변수를 따로 봐요.
그래도 VPN에서만 막히면 NAT로 되돌려 재현 여부를 비교해요.

방화벽은 별도 층으로 점검해요

WSL 네트워크가 살아 있어도 Windows 방화벽에서 인바운드 연결을 막을 수 있어요. 방화벽 규칙을 무조건 끄기보다 현재 프로필과 허용 포트를 확인하는 편이 안전해요. Microsoft는 PowerShell의 New-NetFirewallRule 같은 명령으로 규칙을 만들고 관리하는 방법을 제공합니다.[4]

Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction
Get-NetFirewallRule -Enabled True -Direction Inbound | Select-Object DisplayName, Action, Profile

특정 개발 포트를 잠깐 열어야 한다면 출발지 범위를 사설 네트워크로 제한하고, 작업이 끝난 뒤 규칙을 다시 확인해요. 방화벽을 꺼서 문제가 사라졌다면 “WSL이 고장”난 게 아니라 규칙·프로필·바인딩 중 하나가 원인이라는 뜻이에요. 원인 확인 뒤에는 방화벽을 다시 켜고 좁은 규칙으로 되돌려야 해요.

되돌림 기준

mirrored 모드가 필요한 기능보다 VPN 안정성이 더 중요하다면 NAT가 맞을 수 있어요. 반대로 Windows와 Linux 사이의 주소·포트 처리가 자주 필요하고 현재 VPN이 mirrored를 지원한다면 전환을 시험할 수 있어요. 설정을 바꿀 때는 모드, DNS tunneling, autoProxy를 한꺼번에 바꾸지 말고 하나씩 바꿔야 어느 옵션이 영향을 줬는지 남아요.

핵심은 네트워크 모드를 “더 좋은 값”으로 고르는 게 아니에요. 접속 방향, DNS, 프록시, 방화벽을 서로 다른 층으로 나눠서 확인하고, 문제가 생겼을 때 마지막으로 바꾼 설정 하나만 되돌릴 수 있게 운영하는 게 안정적이에요.