WSL2 미러링 모드에서 netvsc 커널 패닉을 구분하는 진단 절차

작성자:

WSL2에서 networkingMode=mirrored를 켠 뒤 통신이 끊겼다고 해서 모두 netvsc 커널 패닉은 아닙니다. WSL 셸이 계속 열리고 특정 포트만 실패한다면 애플리케이션 바인딩, Hyper-V 방화벽, VPN 경로를 먼저 봐야 합니다. 반대로 배포판이 통째로 종료되거나 VmmemWSL이 다시 시작되고, 같은 시각의 커널 로그에 panic, Oops, Call Trace가 남았다면 커널 경로를 조사할 근거가 생깁니다.

이 문서의 목적은 netvsc를 원인으로 단정하는 것이 아닙니다. 장애를 재현한 네트워크 모드, WSL·Windows·커널 버전, call trace, NAT 모드 비교 결과를 한 세트로 만들어 “일반 연결 장애”, “mirrored 모드 경로”, “Linux 커널 또는 워크로드” 중 어디를 더 조사할지 결정하는 데 초점을 둡니다. 아래 절차는 공식 문서와 공개된 드라이버 동작을 대조한 진단 가이드이며, 특정 커널 결함을 실제 장비에서 재현했다는 의미는 아닙니다.

먼저 패닉인지 연결 장애인지 구분합니다

관찰한 현상 우선 분류 다음 확인
WSL 셸은 살아 있고 한 서비스나 포트만 실패 일반 네트워크·바인딩 문제 리스닝 주소, Hyper-V 방화벽, VPN, 라우팅
배포판이 종료되거나 VmmemWSL이 재시작 WSL VM 또는 커널 장애 가능성 장애 시각, 이전 부팅 로그, WSL 진단 로그
로그에 netvsc 문자열만 있음 원인 확정 불가 panic/Oops와 call trace의 첫 실패 프레임
mirrored에서만 종료되고 NAT에서는 같은 부하가 통과 mirrored 경로로 범위 축소 WSL 버전 고정 후 반복 재현과 공식 로그 수집
NAT와 mirrored 모두 같은 call trace로 종료 모드 전용 문제가 아닐 가능성 배포판 커널, 모듈, 네트워크 워크로드

netvsc는 Hyper-V의 합성 네트워크 장치를 담당하는 Linux 드라이버입니다. 체크섬 오프로드, RSS, GRO/LRO 같은 기능을 제공하지만, 기능 목록 자체는 특정 패닉의 원인을 증명하지 않습니다. call trace에 드라이버 이름이 등장한 위치와 그 앞뒤 프레임을 함께 봐야 합니다.

설정을 바꾸기 전에 증거 다섯 가지를 저장합니다

장애 직후 Windows PowerShell에서 다음 정보를 한 파일에 남깁니다. .wslconfig는 사용자 프로필에 있는 전역 설정이므로 파일이 없다는 결과도 의미가 있습니다.

전체 설정과 로그에는 사용자 경로·식별자가 있을 수 있으므로 비공개로 수집합니다. 아래 읽기는 UTF-8 기준이며 기존 파일의 인코딩이 다르면 그 인코딩을 사용합니다. 원본 파일이 없었다면 원복 시 이번 시험에서 만든 파일만 제거하며, 다른 변경을 함께 지우지 않도록 먼저 차이를 확인합니다.

wsl --version
wsl --status
wsl -l -v
Get-Content -LiteralPath "$env:USERPROFILE\.wslconfig" -Encoding UTF8
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

기록에는 최소한 Windows 빌드, WSL 버전, WSL 커널 버전, 배포판 이름과 상태, networkingMode 값을 포함합니다. Microsoft 문서상 mirrored 모드는 Windows 11 22H2 이상에서 [wsl2] 아래 networkingMode=mirrored로 활성화합니다. 이 전제가 맞지 않으면 이 글의 mirrored 진단 경로를 적용하면 안 됩니다.

WSL 셸이 다시 열리는 상태라면 Linux 쪽에서도 인터페이스와 커널 단서를 수집합니다.

uname -a
ip -br link
ip -s link
dmesg -T | grep -iE 'panic|oops|call trace|netvsc|hv_netvsc'

검색 결과가 비어 있으면 화면의 “연결 끊김”만으로 커널 패닉을 주장할 수 없습니다. 배포판에서 systemd와 영구 저널을 사용하고 이전 부팅 로그가 보존된 경우에만 아래 명령이 의미가 있습니다.

journalctl -k -b -1 --no-pager | grep -iE 'panic|oops|call trace|netvsc|hv_netvsc'

No journal files were found 또는 이전 부팅 항목이 없으면 실패가 아니라 “이 방법으로는 이전 로그를 확인할 수 없음”으로 기록합니다. 로그 보존 설정을 바꾸기 전에 현재 상태부터 복사해 두는 편이 안전합니다.

mirrored와 NAT를 비교할 때 한 변수만 바꿉니다

네트워크 모드 비교는 원인 확정 실험이 아니라 범위 축소 실험입니다. VPN 연결 상태, 실행한 요청, 부하 시간, WSL·Windows 버전을 그대로 두고 networkingMode만 바꿉니다. 먼저 설정을 백업하고 모든 배포판에서 작업 중인 파일을 저장합니다.

$wslConfig = Join-Path $env:USERPROFILE '.wslconfig'
if (Test-Path -LiteralPath $wslConfig) {
    $wslBackup = $wslConfig + '.before-network-test.' + [guid]::NewGuid().ToString('N')
    Copy-Item -LiteralPath $wslConfig -Destination $wslBackup -ErrorAction Stop
} else {
    Write-Output 'Original .wslconfig was absent; record this before creating one.'
}

전체 .wslconfig를 아래 두 줄로 교체하지 않습니다. 원본 인코딩·주석·memory·processors·kernel·experimental 설정을 보존하고 기존 [wsl2] 섹션의 networkingMode 한 항목만 nat로 편집합니다. 키가 없으면 한 번만 추가하며 중복 섹션·키를 만들지 않습니다. 아래는 편집할 항목의 조각입니다. 파일과 모든 배포판의 작업을 저장한 뒤 wsl --shutdown을 실행하면 전체 WSL2 배포판과 VM이 종료됩니다.

[wsl2]
networkingMode=nat

변경 후 같은 요청을 같은 순서로 반복합니다. 한 번 성공한 결과보다 mirrored에서 여러 번 같은 종료가 나고 NAT에서는 같은 부하가 반복 통과하는지가 중요합니다. NAT에서도 같은 call trace가 나오면 mirrored 전용 가설을 버려야 합니다.

비교 결과는 이렇게 해석합니다

mirrored 결과 NAT 결과 해석
VM 종료와 동일 call trace 반복 정상 mirrored 경로 또는 그 경로에서만 드러나는 조합을 우선 조사
특정 포트만 실패, VM 유지 정상 Hyper-V 방화벽, VPN, 서비스 바인딩을 우선 조사
VM 종료와 call trace 반복 동일하게 종료 배포판 커널·모듈·워크로드까지 범위를 넓힘
두 모드 모두 정상 정상 일시 장애 가능성. 버전과 재현 조건을 보존하고 성급히 해결로 결론 내리지 않음

Microsoft의 WSL 네트워킹 문서는 mirrored 모드가 Windows 인터페이스를 Linux에 반영하는 별도 아키텍처이며, Hyper-V 방화벽이 적용될 수 있다고 설명합니다. 따라서 VM은 살아 있는데 인바운드 연결만 막힌 경우에는 커널 옵션을 바꾸기 전에 방화벽 정책과 서비스 리스닝 주소를 확인해야 합니다.

로그를 확보한 뒤 업데이트와 복구를 진행합니다

  1. 원본 자료를 보존합니다. 버전 출력, .wslconfig, call trace, 실패 시각을 먼저 저장합니다.
  2. WSL을 업데이트합니다. PowerShell에서 wsl --update를 실행한 뒤 성공 문구가 아니라 wsl --version의 실제 값이 달라졌는지 확인합니다.
  3. 원래 모드를 복원합니다. 백업한 설정을 되돌리고 wsl --shutdown 후 같은 트래픽을 다시 실행합니다.
  4. 실패가 계속되면 공식 로그를 수집합니다. Microsoft의 WSL 로그 수집 절차를 사용하고, 외부에 첨부하기 전에 계정명, 사용자 경로, 내부 IP와 도메인을 확인합니다.
  5. 멈춤과 패닉을 구분해 보고합니다. WSL 전체가 응답하지 않는 멈춤이라면 Microsoft가 안내하는 VmmemWSL 덤프 절차가 필요할 수 있습니다. 단순 연결 실패에는 메모리 덤프부터 만들 필요가 없습니다.

진단 중 피해야 할 조치

  • call trace 없이 netvsc 문자열만 보고 드라이버 결함으로 확정하지 않습니다.
  • 방화벽, VPN, 오프로드 기능, 네트워크 모드를 한 번에 바꾸지 않습니다. 어느 변경이 결과에 영향을 줬는지 알 수 없게 됩니다.
  • 공식 근거 없이 ethtool -K로 LRO/GRO를 무작정 끄지 않습니다. Linux 문서의 기능 예시는 일반적인 드라이버 기능 설명이지 이 패닉의 수정 명령이 아닙니다.
  • 진단을 위해 배포판 등록을 해제하거나 가상 디스크를 삭제하지 않습니다. 이 절차에는 데이터 삭제가 필요하지 않습니다.
  • NAT 우회를 영구 해결로 기록하지 않습니다. 원래 모드로 돌아갈 조건과 다시 확인할 버전을 함께 남깁니다.

공식 문서로 확인되는 범위

Microsoft의 WSL 문제 해결 가이드는 오류가 Linux 바이너리, 배포판, WSL 스택, 하드웨어 중 어느 계층에서 발생하는지 분리하고, WSL 고유 문제라면 공식 로그를 수집하도록 안내합니다. WSL 네트워킹 문서는 mirrored 모드의 요구 조건과 Hyper-V 방화벽의 영향을 설명합니다. Linux 커널 문서는 netvsc의 오프로드, RSS, 수신 버퍼 등 기능을 설명합니다.

반대로 이 세 문서는 “mirrored 모드의 모든 종료가 netvsc 결함”이라고 말하지 않습니다. 그래서 이 글도 특정 패치를 정답으로 제시하지 않고, call trace와 모드별 재현 결과가 모였을 때만 조사 범위를 좁히도록 구성했습니다.

공식 문서