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

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

WSL2에서 웹 서버나 개발 도구가 갑자기 Windows에서 보이지 않을 때, 애플리케이션 설정부터 다시 만지기보다 네트워크 모드와 서비스가 실제로 열려 있는 주소를 먼저 확인하는 편이 빠릅니다. WSL2의 기본 네트워크 방식은 NAT이고, 미러링 모드는 Windows와 Linux 사이의 연결 방식을 바꿔 localhost 사용 조건과 LAN 접근 경로에 영향을 줍니다.[1] 같은 명령을 실행해도 두 모드에서 보이는 주소와 필요한 방화벽 설정은 달라질 수 있어요.

내 환경에서 무엇이 달라지는가

미러링이 항상 더 빠르거나 모든 프로그램과 호환된다는 뜻은 아닙니다. Microsoft 문서도 기능과 환경에 따라 선택하도록 안내하므로, “모드 변경 후 문제가 사라질 것”이라고 단정하기보다 자신이 필요한 연결 방향을 기준으로 판단해야 해요. Windows에서 WSL 서비스에 접속하는지, WSL에서 Windows 서비스에 접속하는지, 같은 서비스를 집 안의 다른 기기에서 열어야 하는지를 따로 적어 보면 선택이 쉬워집니다.

먼저 버전과 설정 범위를 확인하세요

PowerShell에서 다음 명령으로 WSL 버전과 실행 상태를 확인합니다.

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

wsl -l -v는 배포판이 WSL 1인지 WSL 2인지 구분하는 데 쓰고, 실행 중인 배포판 목록은 설정을 바꾼 뒤 완전히 내려갔는지 확인하는 데 유용합니다.[2] Linux 안에서는 다음 정보를 기록해 두세요.

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

/etc/resolv.conf의 nameserver 주소는 NAT 환경에서 Windows 호스트 주소를 추정할 때 참고할 수 있지만, 모든 네트워크 문제를 해결하는 고정 주소는 아닙니다.[1] 주소를 메모할 때는 명령을 실행한 날짜와 사용한 모드도 함께 기록하세요.

설정 파일을 섞으면 원인을 찾기 어려워집니다. 배포판 단위 설정은 /etc/wsl.conf에서, WSL2 가상 머신 전체의 CPU·메모리·커널 같은 설정은 사용자 프로필의 .wslconfig에서 다룹니다.[2][3] 파일을 수정하기 전 원본을 복사하고, 한 번에 한 항목만 변경하세요. 설정 변경 후 실행 중인 창을 닫고 필요하면 wsl --shutdown으로 가상 머신을 명시적으로 종료한 다음 다시 시작합니다. 이 명령은 배포판 파일을 지우지는 않지만 실행 중인 서비스가 내려가므로 저장하지 않은 작업은 먼저 끝내야 합니다.

localhost 접속 실패를 좁히는 순서

1. Linux에서 ss -ltnp로 서비스가 실제로 listen 중인지 확인합니다.
2. 서비스가 127.0.0.1에만 묶였는지, 필요한 인터페이스에 열려 있는지 구분합니다.
3. Windows에서 접속할 때 사용한 주소와 포트가 서비스의 실제 listen 주소와 일치하는지 확인합니다.
4. Windows 방화벽과 VPN, 보안 소프트웨어가 해당 인터페이스나 포트를 차단하지 않는지 봅니다.
5. 한 포트만 골라 Windows→WSL, WSL→Windows 순서로 각각 테스트합니다.

개발용 서버를 무조건 0.0.0.0에 바인딩하는 것은 조심해야 해요. LAN에 서비스를 노출할 수 있으므로, Windows에서만 사용할 도구라면 가능한 범위에서 localhost 바인딩을 유지하는 편이 안전합니다. 반대로 집 안의 다른 기기에서 접근해야 한다면 서비스 바인딩만 바꿔서는 부족하고, 선택한 네트워크 모드의 외부 접근 경로와 방화벽을 함께 설정해야 합니다.

NAT에서 포트 전달을 사용할 때

NAT 환경에서 LAN 장치가 WSL 서비스에 접근해야 한다면 Windows 쪽 포트 전달 규칙과 WSL2 배포판의 가상 IP를 함께 관리해야 합니다. Microsoft 문서는 wsl.exe hostname -I로 배포판 주소를 조회하고 전달할 포트와 대상 주소를 지정하는 흐름을 설명합니다.[1] 이 가상 IP는 배포판을 다시 시작할 때 바뀔 수 있으므로, 한 번 만든 규칙을 영구적인 고정값처럼 취급하면 어느 날 접속이 끊길 수 있어요.

포트 전달을 추가했는데도 접속되지 않는다면 먼저 WSL 내부의 서비스가 열려 있는지 확인하고, 그다음 Windows가 해당 포트에서 실제로 기다리고 있는지, 마지막으로 방화벽 인바운드 규칙이 맞는지 순서대로 봅니다. 세 층을 한꺼번에 바꾸면 원인을 구분하기 어렵습니다.

미러링으로 바꿀지 결정하는 기준

localhost 중심의 로컬 개발이 많고 현재 WSL 버전이 요구 조건을 충족한다면 미러링을 검토할 수 있습니다.[1] 반대로 VPN이나 기업 보안 정책이 가상 인터페이스를 엄격히 통제하거나, 기존 NAT 포트 전달이 이미 문서화되어 안정적으로 동작한다면 모드를 유지하는 것이 관리하기 쉬울 수 있어요. 모드를 바꾼 뒤에는 기존 NAT 규칙을 무작정 남겨 두지 말고 실제로 어느 경로로 접속하는지 확인하세요.

미러링에서 특정 프로그램이 동작하지 않거나 정책과 충돌한다면 NAT로 되돌리는 것도 정상적인 선택입니다. 변경 전 .wslconfig와 배포판 설정을 백업하고, 변경 후 한 포트만 골라 연결 방향을 재확인하세요. systemd 서비스가 시작되지 않는 문제는 네트워크 모드와 별개일 수 있으므로 WSL systemd 서비스 점검 글의 절차로 따로 분리해 보는 편이 좋습니다.

자주 묻는 질문

WSL IP가 바뀌면 고장인가요?

NAT에서 가상 IP가 바뀌는 것은 가능한 동작입니다. 고정된 주소라고 가정한 전달 규칙이 있다면 현재 주소를 다시 확인하고 규칙을 갱신해야 합니다.[1]

미러링이면 방화벽을 보지 않아도 되나요?

아닙니다. 미러링에서도 Windows 방화벽과 Linux 서비스의 바인딩, VPN이나 보안 소프트웨어의 처리가 접속에 영향을 줍니다.

wsl --shutdown을 실행하면 파일이 지워지나요?

가상 머신과 실행 중인 서비스가 내려갈 뿐 배포판 파일을 지우는 명령은 아닙니다. 다만 실행 중인 작업은 종료될 수 있으니 저장 후 사용하세요.

진단 결과를 기록하면 재현이 쉬워져요

네트워크 문제는 같은 명령도 실행 시점에 따라 결과가 달라질 수 있습니다. 다음 네 가지를 한 줄씩 기록해 두면 모드를 바꾼 뒤 무엇이 달라졌는지 비교하기 쉽습니다.

Windows에서 localhost로 접속되는 것과 LAN의 다른 기기에서 접속되는 것은 다른 테스트입니다. 전자는 로컬 경로가 살아 있는지 보여 주지만, 후자는 서비스 바인딩·Windows 방화벽·포트 전달까지 통과해야 합니다. 반대로 WSL에서 Windows의 localhost 서비스에 접속하는 테스트도 별도 경로로 기록하세요. 한 방향이 성공했다고 반대 방향까지 정상이라고 결론 내리지 않는 것이 좋습니다.

설정을 되돌릴 때는 모드와 포트 전달을 동시에 바꾸지 마세요. 먼저 마지막으로 동작했던 설정 파일을 복원하고, WSL을 완전히 종료한 뒤 한 포트만 확인합니다. 그 다음 방화벽 규칙이나 서비스 바인딩을 하나씩 되돌리면 원인을 다시 좁힐 수 있습니다.

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