WSL2 네트워크 모드 비교, NAT·미러링·포트 전달을 점검하는 방법

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

WSL2에서 네트워크 문제가 생기면 먼저 애플리케이션보다 네트워크 모드를 확인하는 편이 빨라요. 기본 모드는 NAT이고, 최근 WSL 문서는 최신 기능과 호환성이 필요할 때 미러링 모드를 먼저 시도하라고 안내해요.[1] 같은 WSL 명령을 써도 NAT에서는 Windows와 Linux가 서로 다른 가상 네트워크 주소를 가질 수 있고, 미러링에서는 양쪽이 localhost로 연결되는 조건이 달라져요.[1]

먼저 NAT와 미러링을 구분해요

모드부터 확인하려면 PowerShell에서 wsl --version과 wsl -l -v를 실행해요. 후자는 배포판이 WSL 1인지 WSL 2인지 보여줘요.[2] Linux 안에서는 hostname --all-ip-addresses로 현재 인스턴스 주소를 확인할 수 있고, NAT 환경에서 Windows 호스트 주소가 필요하면 /etc/resolv.conf에 표시된 nameserver 주소를 참고할 수 있어요.[1]

설정 파일을 섞지 않는 게 중요해요

wsl.conf는 특정 배포판에만 적용되고, 사용자 홈의 .wslconfig는 WSL2 가상 머신 전체에 적용돼요. 전자는 systemd, automount, 배포판 기본 사용자처럼 배포판 동작을 다루고, 후자는 RAM·CPU·커널과 같은 가상 머신 설정을 다뤄요.[2] 네트워크 문제를 고치겠다며 두 파일에 같은 옵션을 복사하면 어디의 설정이 영향을 줬는지 추적하기 어려워져요.

1. 배포판 안에서 /etc/wsl.conf를 읽어 배포판 단위 설정을 확인해요.
2. Windows 사용자 프로필의 .wslconfig가 있는지 확인해 전역 설정을 분리해요.
3. 설정 하나만 바꾼 뒤 모든 WSL 창을 닫고 wsl --list --running으로 실행 중인 배포판이 없는지 확인해요.
4. 완전히 멈춘 뒤 다시 실행해요. Microsoft 문서는 설정 변경이 반영되기까지 보통 약 8초가 걸릴 수 있다고 안내해요.[2]

설정이 계속 꼬이면 wsl --shutdown으로 WSL2 가상 머신을 명시적으로 종료한 뒤 다시 시작해요. 이것은 배포판 파일을 지우는 명령이 아니지만, 실행 중인 서비스는 모두 내려가므로 작업 내용을 저장한 다음 사용해야 해요.

localhost가 안 될 때의 점검 순서

Windows에서 localhost:포트로 WSL 서비스에 접속하는데 실패했다면 서비스가 실제로 어느 주소에 바인딩됐는지 먼저 확인해요. Linux에서 ss -ltnp 또는 서비스 자체의 listen 설정을 보고 127.0.0.1에만 묶였는지, 0.0.0.0 또는 필요한 인터페이스에 열려 있는지 구분해야 해요. 주소를 무조건 0.0.0.0으로 바꾸면 LAN에 노출될 수 있으니, 개발용이면 localhost에 남기는 편이 안전해요.

NAT에서 LAN 장치가 WSL 서비스에 접근해야 한다면 Windows 쪽 포트 전달과 방화벽 인바운드 규칙을 함께 확인해야 해요. Microsoft 문서는 전달할 포트와 WSL2 배포판의 가상 IP를 지정하는 방식, 그리고 wsl.exe hostname -I로 그 주소를 조회하는 흐름을 설명해요.[1] 배포판을 재시작하면 가상 IP가 바뀔 수 있으므로, 고정된 주소라고 가정한 규칙은 장애 원인이 될 수 있어요.

실패 원인을 좁히는 명령 묶음

# PowerShell
wsl --version
wsl -l -v
wsl --status
wsl --list --running

# WSL Linux
hostname --all-ip-addresses
ip addr
ip route
cat /etc/resolv.conf
ss -ltnp

이 출력에서 확인할 것은 네 가지예요. WSL 버전이 너무 오래되지 않았는지, 대상 배포판이 WSL2인지, 서비스가 실제로 listen 중인지, 그리고 Windows에서 사용한 주소와 Linux가 보고한 주소가 같은 네트워크 경로에 있는지예요. WSL 자체가 업데이트되지 않았다면 wsl --update를 실행하고, 업데이트 뒤에는 wsl --shutdown으로 인스턴스를 다시 올려요.[3]

미러링으로 바꿀 때의 트레이드오프

미러링은 NAT에서 반복하던 호스트 IP 조회를 줄이고 localhost 기반 개발 흐름을 단순하게 만들 수 있어요.[1] 그렇다고 모든 연결 문제가 자동으로 해결되는 것은 아니에요. Windows 방화벽, Linux 서비스의 바인딩 주소, VPN이나 보안 소프트웨어의 인터페이스 처리까지 여전히 영향을 줘요. 기존 NAT 포트 전달 규칙을 그대로 둔 채 모드만 바꾸면 어떤 경로로 접속하는지 혼란이 생길 수 있으니, 변경 후에는 한 포트만 골라 Windows→WSL, WSL→Windows, LAN→WSL 순서로 각각 확인하세요.

미러링에서 특정 프로그램이 오히려 동작하지 않거나 네트워크 정책과 충돌한다면 NAT로 되돌리는 것도 정상적인 선택이에요. 설정 파일을 백업하고 한 번에 한 항목만 바꾸면 원복은 어렵지 않아요. 반대로 NAT를 유지하면서 LAN 서비스를 운영할 때는 가상 IP 갱신을 전제로 전달 규칙을 관리해야 해요.

systemd 서비스 자체가 시작되지 않는 문제라면 네트워크 모드와 섞지 말고 별도로 진단하세요. WSL의 서비스 관리자 문제는 systemd 서비스 점검 글의 순서와 함께 보면 범위를 빠르게 나눌 수 있어요.

Sources

1. [1] Accessing network applications with WSL | Microsoft Learn
2. [2] Troubleshooting Windows Subsystem for Linux | Microsoft Learn
3. [3] Advanced settings configuration in WSL | Microsoft Learn