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

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

WSL2의 네트워크 문제를 “인터넷이 안 된다”로만 설명하면 점검 방향을 놓치기 쉽습니다. Windows 프로그램에서 WSL 서버로 가는지, WSL에서 Windows 서비스로 가는지, 다른 기기에서 들어오는지에 따라 경로와 방화벽 조건이 다릅니다. 이 글은 이미 배포판과 개발 서버를 사용 중인 분을 대상으로 합니다. 처음 설치하는 과정은 WSL2 기초 설치 글에서 확인할 수 있습니다.

NAT와 mirrored는 무엇이 다른가

WSL2의 기본 네트워크 모드는 NAT입니다. Linux 배포판이 Windows 호스트와 별도의 가상 네트워크 경로를 사용하므로, 어떤 상황에서는 WSL의 주소나 호스트 주소를 따로 확인해야 합니다. Microsoft는 Windows 11 22H2 이상에서 networkingMode=mirrored를 설정하면 Windows 네트워크 인터페이스를 Linux에 미러링하는 방식을 사용할 수 있다고 설명합니다.[1][2]

mirrored는 단순한 속도 향상 옵션이 아닙니다. Windows와 Linux 사이에서 주소·포트 처리를 더 직접적으로 할 수 있는 대신, VPN·보안 제품·DNS·포트 바인딩이 기존 NAT와 다르게 동작할 수 있습니다. 이미 안정적인 환경이라면 전환 전에 wsl --status, wsl -l -v, 현재 .wslconfig, 개발 서버 포트를 기록해 두세요.

localhost가 되는 방향부터 나눕니다

Windows 브라우저나 터미널에서 WSL 안의 서버로 접속할 때는 WSL2의 localhost 포워딩이 작동할 수 있습니다. 반대로 WSL 셸에서 Windows 호스트의 서비스로 접속할 때는 NAT 구성에서 호스트 주소를 따로 찾아야 하는 경우가 있습니다. Microsoft 문서에는 배포판의 주소를 확인하는 방법과 Windows 호스트에 연결하는 방향이 구분되어 있습니다.[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 문서에서 기본값은 NAT이며, mirrored는 지원되는 Windows 11 환경에서 사용할 수 있는 옵션으로 안내됩니다.[2]

[wsl2]
networkingMode=mirrored

1. 현재 설정과 실행 중인 개발 서버를 기록합니다.
2. .wslconfig를 수정합니다.
3. 작업 중인 프로세스가 없는지 확인한 뒤 wsl --shutdown으로 WSL 가상 머신을 완전히 종료합니다.
4. 배포판을 다시 열어 ip addr, cat /etc/resolv.conf, 개발 서버 포트를 확인합니다.
5. Windows → WSL, WSL → Windows, 다른 LAN 기기 → Windows 순서로 각각 접속 방향을 확인합니다.

설정 파일을 바꿨는데 동작이 그대로라면 WSL 인스턴스가 실제로 종료되지 않았을 수 있습니다. wsl --shutdown은 실행 중인 모든 WSL 배포판을 닫으므로 저장하지 않은 작업을 먼저 정리해야 합니다. 문제가 생기면 NAT로 되돌릴 수 있도록 원래 파일을 별도로 보관하세요.

VPN과 DNS를 분리해서 점검하세요

Microsoft 문서에는 dnsTunneling=true와 autoProxy=true 같은 WSL 설정이 소개되어 있습니다. dnsTunneling은 DNS 질의를 Windows 쪽 경로와 연동하는 데 쓰이고, autoProxy는 Windows의 HTTP 프록시 정보를 WSL에 전달하는 옵션입니다.[1][2] 회사 VPN이나 보안 클라이언트가 DNS와 라우팅을 강제로 관리하면 이 자동화와 충돌할 수 있습니다.

VPN을 사용 중이라면 설정을 여러 개 동시에 바꾸지 마세요. 먼저 VPN을 끈 상태에서 같은 주소가 해석되고 사설망에 접속되는지 확인한 뒤 Windows와 WSL의 결과를 비교합니다. WSL에서 getent hosts 도메인과 curl -Iv https://도메인을 실행하고, DNS만 실패하는지 HTTPS 연결까지 실패하는지 구분합니다. 여기서 https://도메인은 실제 회사 주소로 바꿔 쓰는 예시입니다.

1. VPN을 끈 상태에서 DNS와 개발 서비스 접속을 확인합니다.
2. Windows 명령 프롬프트에서 같은 도메인이 해석되는지 비교합니다.
3. DNS 실패라면 dnsTunneling과 VPN의 DNS 정책을 따로 봅니다.
4. HTTP·HTTPS만 실패라면 autoProxy와 HTTP_PROXY, HTTPS_PROXY 환경 변수를 확인합니다.
5. VPN에서만 실패하면 마지막으로 NAT와 mirrored 중 하나를 바꿔 재현 여부를 비교합니다.

Microsoft 문제 해결 문서에는 특정 보안 제품과 mirrored·DNS tunneling 조합에서 문제가 생길 때 dnsTunneling=false 또는 networkingMode=nat를 시도하는 사례가 제시됩니다.[3] 이는 모든 VPN에 적용되는 만능 처방이 아니며, 회사 보안 정책을 우회하라는 뜻도 아닙니다. 업무 장비라면 관리자에게 허용된 설정인지 먼저 확인하세요.

방화벽은 네트워크 모드와 별도 층입니다

WSL 안에서 서버가 실행되고 DNS도 정상이어도 Windows 방화벽이 인바운드 연결을 막을 수 있습니다. 방화벽을 무조건 끄기보다 현재 프로필과 허용 규칙을 읽는 편이 안전합니다. Microsoft는 PowerShell 명령으로 방화벽 규칙을 확인하고 관리하는 방법을 안내합니다.[4]

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

특정 개발 포트를 잠깐 열어야 한다면 출발지를 사설 네트워크로 제한하고, 작업 후 규칙이 남아 있는지 다시 확인하세요. 방화벽을 꺼서 문제가 사라졌다면 WSL 자체가 고장 난 것이 아니라 규칙·프로필·바인딩 중 한 층이 원인일 가능성이 큽니다. 원인을 확인한 뒤 방화벽을 다시 켜고 좁은 허용 규칙으로 되돌려야 합니다.

어느 모드를 선택할지와 되돌림 기준

mirrored가 필요한 기능보다 VPN 안정성이 더 중요하면 NAT가 맞을 수 있습니다. 반대로 주소·포트 처리가 빈번하고 회사 VPN이 mirrored를 지원한다면 단계적으로 시험할 수 있습니다. 네트워크 모드, DNS tunneling, autoProxy를 한꺼번에 바꾸지 말고 하나씩 변경한 뒤 접속 방향별 결과를 기록하세요.

자주 묻는 질문

mirrored가 NAT보다 항상 좋은가요?

아닙니다. 목적과 VPN·보안 제품의 호환성에 따라 다릅니다. 정상인 환경을 바꿀 이유가 없다면 현재 모드를 기록한 뒤 필요한 기능이 있을 때만 시험하세요.

localhost가 안 되면 곧바로 mirrored로 바꿔야 하나요?

먼저 접속 방향, 서버 바인딩, 포트, Windows 방화벽을 확인하세요. Windows → WSL과 WSL → Windows의 localhost 동작은 같은 문제가 아닙니다.[1]

방화벽을 끄면 되나요?

원인 확인을 위한 짧은 비교 외에는 권하지 않습니다. 프로필과 인바운드 규칙을 읽고 필요한 포트와 출발지만 좁게 허용하세요.[4]

증상별로 확인 순서를 고정하세요

이 표에서 명령 결과가 성공했다는 사실은 다음 층이 정상이라는 뜻일 뿐입니다. DNS가 풀려도 포트가 닫혀 있을 수 있고, 포트가 열려도 애플리케이션이 127.0.0.1에만 바인딩되어 있을 수 있습니다. 반대로 서버가 응답하지 않는다고 곧바로 DNS를 수정하면 원인과 무관한 설정을 바꾸게 됩니다.

변경 기록을 남기는 간단한 형식

회사 VPN이나 여러 개발 서버를 쓰는 환경에서는 다음 네 줄을 변경 전후에 기록해 두면 되돌리기 쉽습니다. 첫째, 네트워크 모드가 NAT인지 mirrored인지 적습니다. 둘째, VPN을 켠 상태와 끈 상태를 나눕니다. 셋째, Windows → WSL, WSL → Windows, LAN → 서버의 결과를 각각 적습니다. 넷째, DNS 실패·연결 거부·시간 초과처럼 증상을 구체적으로 씁니다.

• DNS 실패: 주소를 IP로 바꾸지 못하는 문제인지 확인합니다.
• 연결 거부: 대상 서비스가 실행 중인지와 포트 바인딩을 봅니다.
• 시간 초과: VPN 경로·방화벽·라우팅을 의심합니다.
• 인증 실패: 네트워크가 아니라 프록시나 서비스 자격 조건일 수 있습니다.

회사 장비에서는 보안 클라이언트가 설정 파일을 덮어쓰거나 특정 모드를 금지할 수 있습니다. 오류를 해결하려고 방화벽과 VPN을 동시에 끄는 대신, 허용된 진단 범위 안에서 한 요소만 바꾸고 관리자에게 로그와 시간, 접속 방향을 전달하세요.

Sources

1. [1] Microsoft Learn: Accessing network applications with WSL
2. [2] Microsoft Learn: WSL configuration settings
3. [3] Microsoft Learn: Troubleshooting Windows Subsystem for Linux
4. [4] Microsoft Learn: Configure Windows Firewall with command line