Linux용 Windows 하위 시스템 문제 해결

2025-05-21

아래 WSL과 관련된 몇 가지 일반적인 문제 해결 시나리오를 다루었지만 GitHub의 WSL 제품 리포지토리에 제출된 문제도 검색하는 것이 좋습니다.

문제, 버그 보고서, 기능 요청 제출

WSL 제품 리포지토리 문제를 통해 다음을 수행할 수 있습니다.

기존 문제를 검색하여 당신이 겪고 있는 문제와 관련된 것이 있는지 확인하십시오. 검색 창에서 "is:open"을 제거하여 검색에서 이미 해결된 문제를 포함할 수 있습니다. 우선 순위로 앞으로 나아가는 데 관심을 나타내고 싶은 열린 문제에 대해 언급하거나 엄지손가락을 치켜세우십시오.
새 문제를 제출합니다. WSL에 문제가 있고 기존 문제가 없는 경우 녹색 새 문제 단추를 선택한 다음 WSL - 버그 보고서를 선택할 수 있습니다. 문제에 대한 제목, Windows 빌드 번호(현재 빌드 번호를 확인하려면 cmd.exe /c ver 실행), WSL 1 또는 2 중 실행 중인 WSL 버전, 현재 Linux 커널 버전(확인하려면 wsl.exe --status 또는 cat /proc/version 실행), 배포판 버전(확인하려면 lsb_release -r 실행), 관련된 다른 소프트웨어 버전, 재현 단계, 예상 동작, 실제 동작 및 진단 로그(사용 가능하고 적절한 경우)를 포함해야 합니다. 자세한 내용은 WSL에 대한 기여를 참조하세요.
녹색 새 문제 단추를 선택하여 기능 요청을 제출한 다음, 기능 요청을 선택합니다. 요청을 설명하는 몇 가지 질문을 해결해야 합니다.

또한 다음을 할 수 있습니다:

WSL 문서 리포지토리를 사용하여 설명서 문제를 제출합니다. WSL 문서에 기여하려면 Microsoft Docs 기여자 가이드를 참조하세요.
Windows 터미널, Windows 콘솔 또는 명령줄 UI와 관련된 문제가 있는 경우 Windows 터미널 제품 리포지토리 를 사용하여 Windows 터미널 문제를 제출합니다.

설치 문제

오류 0x80070003 설치 실패
- Linux용 Windows 하위 시스템은 시스템 드라이브에서만 실행됩니다(일반적으로 이는 C: 드라이브입니다). 배포가 시스템 드라이브에 저장되어 있는지 확인합니다.
- Windows 10에서 설정 ->시스템 ->스토리지 ->추가 스토리지 설정: 새 콘텐츠가 저장되는 위치 변경
- Windows 11에서 설정 ->System ->Storage ->Advanced Storage 설정 ->새 콘텐츠가 저장된 위치
오류 0x8007019e WslRegisterDistribution이 실패했습니다.
- Linux용 Windows 하위 시스템 옵션 구성 요소가 활성화되지 않았습니다.
- 제어판 열기 ->프로그램 및 기능 ->Windows 기능 켜기 또는 끄기 ->Linux용 Windows 하위 시스템을 확인하거나 이 문서의 시작 부분에 언급된 PowerShell cmdlet을 사용합니다.
오류 0x80070003 또는 오류 0x80370102 설치하지 못했습니다.
- 컴퓨터의 BIOS 내에서 가상화가 사용하도록 설정되어 있는지 확인하세요. 이 작업을 수행하는 방법에 대한 지침은 컴퓨터마다 다르며 CPU 관련 옵션에 따라 달라질 수 있습니다.
- WSL2를 사용하려면 CPU가 Intel Nehalem 프로세서(Intel Core 1세대) 및 AMD Opteron에 도입된 SLAT(두 번째 수준 주소 변환) 기능을 지원해야 합니다. Virtual Machine Platform이 성공적으로 설치되어 있더라도 이전 CPU(예: Intel Core 2 Duo)는 WSL2를 실행할 수 없습니다.
업그레이드를 시도할 때 오류가 발생했습니다. Invalid command line option: wsl --set-version Ubuntu 2
- Linux용 Windows 하위 시스템을 사용하도록 설정하고 Windows 빌드 버전 18362 이상을 사용하고 있는지 확인합니다. WSL을 사용하도록 설정하려면 관리자 권한으로 PowerShell 프롬프트에서 다음 명령을 실행합니다. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
가상 디스크 시스템 제한으로 인해 요청된 작업을 완료할 수 없습니다. 가상 하드 디스크 파일은 압축되지 않고 암호화되지 않아야 하며 스파스 파일이 아니어야 합니다.
- Linux 배포에 대한 프로필 폴더를 열어 "콘텐츠 압축"(선택한 경우 "콘텐츠 암호화")을 선택 취소합니다. 다음과 같이 Windows 파일 시스템의 폴더에 있어야 합니다. %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
- 이 Linux 배포판 프로필에는 LocalState 폴더가 있어야 합니다. 옵션 메뉴를 표시하려면 이 폴더를 마우스 오른쪽 단추로 클릭합니다. 고급 속성을 > 선택한 다음 "디스크 공간을 절약하기 위해 콘텐츠 압축" 및 "데이터를 보호하기 위해 콘텐츠 암호화" 확인란이 선택되지 않았는지 확인합니다(선택되지 않음). 현재 폴더 또는 모든 하위 폴더 및 파일에만 적용할지 묻는 메시지가 표시되면 압축 플래그만 지우기 때문에 "이 폴더만"을 선택합니다. 이 후에는 wsl --set-version 명령이 작동할 것입니다.

WSL 배포판 속성 설정 스크린샷

비고

내 경우 Ubuntu 18.04 배포판의 LocalState 폴더가 C:\Users<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

이 문제가 추적되고 있는 WSL Docs GitHub 스레드 #4103 에서 업데이트된 정보를 확인합니다.

'wsl'이라는 용어는 cmdlet, 함수, 스크립트 파일 또는 작동 가능한 프로그램의 이름으로 인식되지 않습니다.
- Linux용 Windows 하위 시스템 선택적 구성 요소가 설치되어 있는지 확인합니다. 또한 ARM64 디바이스를 사용하고 PowerShell에서 이 명령을 실행하는 경우 이 오류가 표시됩니다. 대신 wsl.exe 또는 명령 프롬프트에서 실행 합니다.
오류: Linux용 Windows 하위 시스템에 설치된 배포판이 없습니다.
- WSL 배포를 이미 설치한 후 이 오류가 표시되는 경우:
1. 명령줄에서 호출하기 전에 배포를 한 번 이상 실행합니다.
2. 별도의 사용자 계정을 실행하고 있는지 확인합니다. 관리자 모드에서 관리자 권한으로 기본 사용자 계정을 실행해도 이 오류가 발생하지는 않지만 Windows와 함께 제공되는 기본 제공 관리자 계정을 실수로 실행하지 않도록 해야 합니다. 이는 별도의 사용자 계정이며 설치된 WSL 배포판은 의도적으로 표시되지 않습니다. 자세한 내용은 기본 제공 관리자 계정 사용 및 사용 안 함을 참조하세요.
3. WSL 실행 파일은 네이티브 시스템 디렉터리에만 설치됩니다. 64비트 Windows(또는 ARM64의 모든 비 네이티브 조합)에서 32비트 프로세스를 실행하는 경우 호스팅되는 비 네이티브 프로세스는 실제로 다른 System32 폴더를 볼 수 있습니다. (x64 Windows에서 볼 수 있는 32비트 프로세스는 \Windows\SysWOW64의 디스크에 저장됩니다.) 가상 폴더 \Windows\sysnative를 확인하여 호스팅된 프로세스에서 "네이티브" system32에 액세스할 수 있습니다. 디스크에는 실제로 존재하지 않지만 파일 시스템 경로 확인자에서 찾을 수 있습니다.
오류: 이 업데이트는 Linux용 Windows 하위 시스템을 사용하는 컴퓨터에만 적용됩니다.
- Linux 커널 업데이트 MSI 패키지를 설치하려면 WSL이 필요하며 먼저 사용하도록 설정해야 합니다. 실패하면 다음과 같은 메시지가 This update only applies to machines with the Windows Subsystem for Linux표시됩니다.
- 이 메시지가 표시되는 세 가지 가능한 이유가 있습니다.
1. 여전히 WSL 2를 지원하지 않는 이전 버전의 Windows에 있습니다. 버전 요구 사항 및 업데이트 링크는 2단계를 참조하세요.
2. WSL을 사용할 수 없습니다. 1단계로 돌아가서 컴퓨터에서 선택적 WSL 기능을 사용하도록 설정해야 합니다.
3. WSL을 사용하도록 설정한 후에는 적용을 위해 컴퓨터를 다시 시작해야 합니다. 컴퓨터를 다시 시작한 후 다시 시도하십시오.
오류: WSL 2에는 커널 구성 요소에 대한 업데이트가 필요합니다. 자세한 정보를 보시려면 https://aka.ms/wsl2kernel을 방문하십시오.
- linux 커널 패키지가 %SystemRoot%\system32\lxss\tools 폴더에 없으면 이 오류가 발생합니다. 이러한 설치 지침의 4단계에서 Linux 커널 업데이트 MSI 패키지를 설치하여 해결합니다. '프로그램 추가 또는 제거'에서 MSI를 제거하고 다시 설치해야 할 수 있습니다.

일반적인 문제

Windows 10 버전 1903에 있으며 WSL 2에 대한 옵션이 표시되지 않습니다.

컴퓨터가 아직 WSL 2에 대한 백포트를 사용하지 않았기 때문일 수 있습니다. 이 문제를 해결하는 가장 간단한 방법은 Windows 설정으로 이동하고 '업데이트 확인'을 클릭하여 시스템에 최신 업데이트를 설치하는 것입니다. 백포트를 사용하는 방법에 대한 전체 지침을 참조하세요.

'업데이트 확인'을 누르고 업데이트가 아직 수신되지 않는 경우 KB KB4566116 수동으로 설치할 수 있습니다.

오류: 0x1bc가 발생할 때 `wsl --set-default-version 2`

이 문제는 '표시 언어' 또는 '시스템 로캘' 설정이 영어가 아닌 경우에 발생할 수 있습니다.

wsl --set-default-version 2
Error: 0x1bc
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

실제 오류 0x1bc 는 다음과 같습니다.

WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

자세한 내용은 문제 5749를 참조하세요.

Windows에서 WSL 파일에 액세스할 수 없음

9p 프로토콜 파일 서버는 Windows에서 Linux 파일 시스템에 액세스할 수 있도록 Linux 쪽에서 서비스를 제공합니다. Windows에서 사용하여 \\wsl$ WSL에 액세스할 수 없는 경우 9P가 올바르게 시작되지 않았기 때문일 수 있습니다.

이를 확인하려면 다음 dmesg |grep 9p을 사용하여 시작 로그를 확인할 수 있습니다. 그러면 오류가 표시됩니다. 성공적인 출력은 다음과 같습니다.

[    0.363323] 9p: Installing v9fs 9p2000 file system support
[    0.363336] FS-Cache: Netfs '9p' registered for caching
[    0.398989] 9pnet: Installing 9P2000 support

이 문제에 대한 자세한 내용은 이 GitHub 스레드 를 참조하세요.

WSL 2 배포를 시작할 수 없으며 출력에 'WSL 2'만 표시

표시 언어가 영어가 아닌 경우 잘린 버전의 오류 텍스트가 표시될 수 있습니다.

C:\Users\me>wsl
WSL 2

이 문제를 해결하려면 해당 문서 페이지의 지침에 따라 수동으로 커널을 방문하여 https://aka.ms/wsl2kernel 설치하세요.

`command not found` Linux에서 Windows .exe 실행할 때

사용자는 Linux에서 직접 notepad.exe 같은 Windows 실행 파일을 실행할 수 있습니다. 경우에 따라 아래와 같이 "명령을 찾을 수 없음"을 누를 수 있습니다.

$ notepad.exe
-bash: notepad.exe: command not found

$PATH Win32 경로가 없으면 interop에서 .exe찾을 수 없습니다. Linux에서 실행 echo $PATH 하여 확인할 수 있습니다. 출력에 Win32 경로(예: /mnt/c/Windows)가 표시됩니다. Windows 경로를 볼 수 없는 경우 Linux 셸에서 PATH를 덮어쓰는 것일 가능성이 큽니다.

다음은 Debian의 /etc/profile이 문제에 기여한 예입니다.

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi

Debian에서 올바른 방법은 위의 줄을 제거하는 것입니다. 아래와 같이 할당하는 동안 $PATH 추가할 수도 있지만, 이로 인해 WSL 및 VSCode 에 몇 가지 다른 문제가 발생합니다 .

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi

자세한 내용은 문제 5296 및 문제 5779를 참조하세요.

"오류: 0x80370102 필요한 기능이 설치되지 않아 가상 머신을 시작할 수 없습니다."

Virtual Machine Platform Windows 기능을 사용하도록 설정하고 BIOS에서 가상화를 사용하도록 설정했는지 확인하세요.

Hyper-V 시스템 요구 사항 확인
컴퓨터가 VM인 경우 중첩된 가상화를 수동으로 사용하도록 설정합니다. powershell을 관리자 권한으로 시작하고, 호스트 시스템에서 가상 머신의 이름으로 <VMName>을 교체하여 다음 명령을 실행합니다 (이름은 Hyper-V 관리자에서 찾을 수 있습니다).
```
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
```
가상화를 사용하도록 설정하는 방법에 대한 PC 제조업체의 지침을 따르세요. 일반적으로 시스템 BIOS를 사용하여 CPU에서 이러한 기능을 사용하도록 설정할 수 있습니다. 이 프로세스에 대한 지침은 컴퓨터마다 다를 수 있습니다. 예를 들어 Bleeping Computer의 이 문서를 참조하세요.
선택적 구성 요소를 사용하도록 설정한 Virtual Machine Platform 후 컴퓨터를 다시 시작합니다.
부팅 구성에서 하이퍼바이저 시작이 사용하도록 설정되어 있는지 확인합니다. (관리자 권한 powershell)을 실행하여 유효성을 검사할 수 있습니다.
```
 bcdedit /enum | findstr -i hypervisorlaunchtype
```
표시되는 hypervisorlaunchtype Off경우 하이퍼바이저가 비활성화됩니다. 실행 권한이 상승된 Powershell에서 실행되도록 설정하려면 다음을 수행합니다.
```
 bcdedit /set hypervisorlaunchtype Auto
```
또한 타사 하이퍼바이저(예: VMware 또는 VirtualBox)가 설치된 경우 HyperV(VMware 15.5.5 이상 및 VirtualBox 6 이상)를 지원할 수 있는 최신 버전에 해당 하이퍼바이저가 설치되어 있는지 확인하거나 꺼져 있는지 확인하세요.
Azure Virtual Machine에서 이 오류가 발생하는 경우 신뢰할 수 있는 시작을 사용하지 않도록 설정했는지 확인합니다. 중첩 가상화는 Trusted Launch가 설정된 Azure 가상 머신에서 지원되지 않습니다.

Virtual Machine에서 Hyper-V 실행할 때 중첩된 가상화를 구성하는 방법에 대해 자세히 알아봅니다.

WSL은 내 회사 컴퓨터 또는 엔터프라이즈 환경에서 네트워크 연결이 없습니다.

비즈니스 또는 엔터프라이즈 환경에는 권한 없는 네트워크 트래픽을 차단하도록 Windows Defender 방화벽 설정이 구성되어 있을 수 있습니다. 로컬 규칙 병합이 "아니요"로 설정된 경우 WSL 네트워킹은 기본적으로 작동하지 않으며 관리자는 이를 허용하기 위해 방화벽 규칙을 추가해야 합니다.

다음 단계에 따라 로컬 규칙 병합의 설정을 확인할 수 있습니다.

Windows 방화벽 설정 스크린샷

"고급 보안이 포함된 Windows Defender 방화벽"을 엽니다(제어판의 "Windows Defender 방화벽"과는 다름).
"로컬 컴퓨터의 고급 보안이 포함된 Windows Defender 방화벽" 탭을 마우스 오른쪽 단추로 클릭합니다.
"속성"을 선택합니다.
열리는 새 창에서 "공개 프로필" 탭을 선택합니다.
"설정" 섹션에서 "사용자 지정"을 선택합니다.
"규칙 병합"이 "아니요"로 설정되어 있는지 확인하려면 열리는 "공개 프로필에 대한 설정 사용자 지정" 창을 체크 인합니다. 그러면 WSL에 대한 액세스가 차단됩니다.

Hyper-V 방화벽 구성에서 이 방화벽 설정을 변경하는 방법에 대한 지침을 찾을 수 있습니다.

WSL은 VPN에 연결되면 네트워크 연결이 없습니다.

Windows에서 VPN에 연결한 후 bash가 네트워크 연결을 끊는 경우 bash 내에서 이 해결 방법을 시도해 보세요. 이 해결 방법을 사용하면 /etc/resolv.conf을 통해 DNS 확인을 수동으로 재정의할 수 있습니다.

VPN의 DNS 서버를 ipconfig.exe /all를 수행하여 기록해 두세요.
기존 resolv.conf의 복사본 만들기 sudo cp /etc/resolv.conf /etc/resolv.conf.new
현재 resolv.conf의 연결 해제 sudo unlink /etc/resolv.conf
sudo mv /etc/resolv.conf.new /etc/resolv.conf
이 콘텐츠를 편집 /etc/wsl.conf 하고 파일에 추가합니다. (이 설정에 대한 자세한 내용은 고급 설정 구성에서 찾을 수 있습니다.)

[network]
generateResolvConf=false

열기 /etc/resolv.conf 및
a. 자동 생성을 설명하는 주석이 있는 파일에서 첫 번째 줄을 삭제합니다.
b. 위의 (1)에서 DNS 항목을 DNS 서버 목록의 첫 번째 항목으로 추가합니다.
다. 파일을 닫습니다.

VPN의 연결이 끊어지면 변경 내용을 .로 되돌려야 합니다 /etc/resolv.conf. 이렇게 하려면 다음을 수행합니다.

cd /etc
sudo mv resolv.conf resolv.conf.new
sudo ln -s ../run/resolvconf/resolv.conf resolv.conf

WSL의 글로벌 보안 액세스 클라이언트 문제

전역 보안 액세스 클라이언트(/entra/global-secure-access/how-to-install-windows-client)는 이름을 확인할 때 임시 주소를 반환하는 기능이 있으므로 WSL 연결에 영향을 줄 수 있습니다. 그런 다음 네트워크 연결이 만들어지면 주소가 실제 주소로 교환됩니다. 이로 인해 WSL 트래픽이 GSA 클라이언트 후크 대부분 아래로 전달되면서 WSL이 중단될 수 있습니다.

DNS 터널링(dnsTunneling=false)을 사용하지 않도록 설정하거나 미러 모드(networkingMode=nat)를 사용하지 않도록 설정하는 것이 좋습니다.

NAT 모드에서 WSL과 관련된 Cisco Anyconnect VPN 문제

Cisco AnyConnect VPN은 NAT가 작동하지 않도록 경로를 수정합니다. WSL 2와 관련된 해결 방법이 있습니다. Cisco AnyConnect Secure Mobility Client 관리자 가이드, 릴리스 4.10 - AnyConnect 문제 해결을 참조하세요.

미러된 네트워킹 모드가 켜진 경우 VPN과 WSL 연결 문제

미러된 네트워킹 모드는 현재 WSL 구성에서 실험적 설정입니다. WSL의 기존 NAT 네트워킹 아키텍처는 "미러된 네트워킹 모드"라는 완전히 새로운 네트워킹 모드로 업데이트할 수 있습니다. 실험적 networkingMode가 mirrored로 설정될 때, Windows에 있는 네트워크 인터페이스가 Linux로 미러링되어 호환성을 향상시킵니다. 명령줄 블로그: WSL 2023년 9월 업데이트에서 자세히 알아보세요.

일부 VPN은 다음을 포함하여 WSL과 호환되지 않는 것으로 테스트되고 확인되었습니다.

"Bitdefender" 버전 26.0.2.1
"OpenVPN" 버전 2.6.501
"Mcafee Safe Connect" 버전 2.16.1.124

WSL에서 HttpProxy 미러링에 autoProxy를 사용할 때 고려 사항

autoProxy에 있는 설정을 사용하여 HTTP/S 프록시 미러링을 구성할 수 있습니다. 이 설정을 적용할 때 다음 사항을 고려합니다.

PAC 프록시: WSL은 "WSL_PAC_URL" 환경 변수를 설정하여 Linux에서 설정을 구성합니다. Linux는 기본적으로 PAC 프록시를 지원하지 않습니다.
WSLENV와의 상호 작용: 사용자 정의 환경 변수가 이 기능에서 지정한 변수보다 우선합니다.

사용하도록 설정하면 Linux 배포판의 프록시 설정에 다음이 적용됩니다.

Linux 환경 변수 HTTP_PROXY는 Windows HTTP 프록시 구성에 설치된 하나 이상의 HTTP 프록시로 설정됩니다.
Linux 환경 변수 HTTPS_PROXY는 Windows HTTP 프록시 구성에 설치된 하나 이상의 HTTPS 프록시로 설정됩니다.
Linux 환경 변수 NO_PROXY는 Windows 구성 대상에 있는 HTTP/S 프록시를 무시하도록 설정됩니다.
를 제외한 WSL_PAC_URL모든 환경 변수는 소문자 및 대문자로 설정됩니다. 예: HTTP_PROXY 및 http_proxy.

ZScaler 구성으로 인해 알려진 문제가 있습니다. 여기서 ZScaler는 Windows 프록시 구성을 반복적으로 사용하도록 설정하고 사용하지 않도록 설정하므로 WSL은 "호스트에서 Http 프록시 변경이 검색되었습니다." 알림을 반복적으로 표시합니다.

명령줄 블로그: WSL 2023년 9월 업데이트에서 자세히 알아보세요.

DNS 터널링을 사용하는 네트워킹 고려 사항

WSL이 인터넷에 연결할 수 없는 경우 Windows 호스트에 대한 DNS 호출이 차단되었기 때문일 수 있습니다. 이는 WSL VM에서 Windows 호스트로 보낸 DNS에 대한 네트워킹 패킷이 기존 네트워킹 구성에 의해 차단되기 때문입니다. DNS 터널링에서는 가상화 기능을 사용하여 Windows와 직접 통신하여 네트워킹 패킷을 보내지 않고 DNS 이름을 확인할 수 있도록 하여 이 문제를 해결합니다. 이 기능은 네트워크 호환성을 향상시키고 VPN, 특정 방화벽 설정 또는 기타 네트워킹 구성이 있는 경우에도 더 나은 인터넷 연결을 얻을 수 있도록 해야 합니다.

dnsTunneling의 실험적 섹션에 있는 설정을 사용하여 DNS 터널링을 구성할 수 있습니다. 이 설정을 적용할 때 다음 사항을 고려합니다.

WSL에서 VPN을 사용하는 경우 DNS 터널링을 켭니다. 대부분의 VPN은 NRPT 정책을 사용합니다. 이 정책은 DNS 터널링을 사용하는 경우에만 WSL DNS 쿼리에 적용됩니다.
Linux 배포의 파일에는 /etc/resolv.conf 최대 3개의 DNS 서버 제한이 있지만 Windows는 3개 이상의 DNS 서버를 사용할 수 있습니다. DNS 터널링을 사용하면 이러한 제한이 제거됩니다. 이제 Linux에서 모든 Windows DNS 서버를 사용할 수 있습니다.
WSL은 다음과 같은 순서로 Windows DNS 접미사를 사용합니다(Windows DNS 클라이언트에서 사용하는 순서와 유사).
1. 전역 DNS 접미사
2. 추가 DNS 접미사
3. 인터페이스별 DNS 접미사
4. Windows에서 DNS 암호화(DoH, DoT)를 사용하도록 설정하면 WSL의 DNS 쿼리에 암호화가 적용됩니다. 사용자가 Linux 내에서 DoH, DoT를 사용하도록 설정하려면 DNS 터널링을 사용하지 않도록 설정해야 합니다.
Docker Desktop에서 관리하는 Docker 컨테이너의 DNS 쿼리는 DNS 터널링을 무시합니다. Docker Desktop은 Docker 컨테이너의 DNS 쿼리에 호스트 DNS 설정 및 정책을 적용하는 고유한 방식(DNS 터널링과는 다른)을 가집니다.
DNS 터널링을 완벽하게 사용하도록 설정하려면 wsl.conf 파일의 generateResolvConf 옵션을 사용하지 않도록 설정하면 안 됩니다.
DNS 터널링을 사용하도록 설정하면 wsl.conf 파일의 generateHosts 옵션이 무시됩니다(Windows DNS 호스트 파일은 Linux /etc/hosts 파일에 복사되지 않음). Windows 호스트 파일의 정책은 Linux에서 파일을 복사할 필요 없이 Linux의 DNS 쿼리에 적용됩니다.

명령줄 블로그: WSL 2023년 9월 업데이트에서 자세히 알아보세요.

Windows 호스트가 WSL Virtual Machine으로 수신한 인바운드 트래픽을 조정하는 문제

미러된 네트워킹 모드(실험적 networkingMode 설정 mirrored)를 사용하는 경우 Windows 호스트에서 수신하는 일부 인바운드 트래픽은 Linux VM으로 조정되지 않습니다. 이 트래픽은 다음과 같습니다.

UDP 포트 68(DHCP)
TCP 포트 135(DCE 엔드포인트 확인)
TCP 포트 1900(UPnP)
TCP 포트 2869(SSDP)
TCP 포트 5004(RTP)
TCP 포트 3702(WSD)
TCP 포트 5357(WSD)
TCP 포트 5358(WSD)

WSL은 미러된 네트워킹 모드를 사용할 때 특정 Linux 네트워킹 설정을 자동으로 구성합니다. 미러된 네트워킹 모드를 사용하는 동안 이러한 설정의 사용자 구성은 지원되지 않습니다. WSL이 구성할 설정 목록은 다음과 같습니다.

설정 이름	가치
https://sysctl-explorer.net/net/ipv4/accept_local/	활성화됨(1)
https://sysctl-explorer.net/net/ipv4/route_localnet/	활성화됨(1)
https://sysctl-explorer.net/net/ipv4/rp_filter/	사용 안 함(0)
https://sysctl-explorer.net/net/ipv6/accept_ra/	사용 안 함(0)
https://sysctl-explorer.net/net/ipv6/autoconf/	사용 안 함(0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/	사용 안 함(0)
주소 생성 모드	사용 안 함(0)
disable_ipv6	사용 안 함(0)
https://sysctl-explorer.net/net/ipv4/arp_filter/	활성화됨(1)

기본 네트워킹 네임스페이스에서 실행할 때 미러된 네트워킹 모드가 활성화된 WSL2의 Docker 컨테이너 문제

게시된 포트가 있는 Docker Desktop 컨테이너(docker run –publish/-p)를 만들지 못하는 알려진 문제가 있습니다. WSL 팀은 이 문제를 해결하기 위해 Docker Desktop 팀과 협력하고 있습니다. 이 문제를 해결하려면 Docker 컨테이너에서 호스트의 네트워킹 네임스페이스를 사용합니다. "docker run" 명령에 사용되는 "--network host" 옵션을 통해 네트워크 유형을 설정합니다. 다른 해결 방법은 ignoredPorts 게시된 포트 번호를 나열하는 것입니다.

네트워크 관리자가 실행 중일 때 Docker 컨테이너 문제

네트워크 관리자 서비스가 실행되는 Docker 컨테이너에 알려진 문제가 있습니다. 증상으로는 호스트에 대한 루프백 연결을 시도할 때 오류가 발생합니다. WSL 네트워킹을 올바르게 구성하려면 네트워크 관리자 서비스를 중지하는 것이 좋습니다.

sudo systemctl disable network-manager.service

WSL에서 .local 이름 확인

기존 DNS 서버 없이 로컬 네트워크 내의 IP 주소로 호스트 이름을 확인하려면 .local 이름이 자주 사용됩니다. 이는 멀티캐스트 트래픽을 사용하여 작동하는 mDNS(멀티캐스트 DNS) 프로토콜을 통해 수행됩니다.

networkingMode를 NAT로 설정:

현재 이 기능은 DNS 터널링을 사용하는 경우 지원되지 않습니다. .local 이름을 확인할 수 있도록 다음 솔루션을 사용하는 것이 좋습니다.

DNS 터널링을 사용하지 않도록 설정합니다.
미러된 네트워킹 모드를 사용합니다.

networkingMode가 미러링됨으로 설정됨:

참고: 아래 기능을 얻으려면 WSL 빌드 2.3.17 이상에 있어야 합니다.

미러 모드는 멀티캐스트 트래픽을 지원하므로 mDNS(멀티캐스트 DNS) 프로토콜을 사용하여 .local 이름을 확인할 수 있습니다. Linux는 기본적으로 지원되지 않으므로 mDNS를 지원하도록 구성해야 합니다. 구성하는 한 가지 방법은 다음 두 단계를 사용하는 것입니다.

"libnss-mdns" 패키지 설치

sudo apt-get install libnss-mdns

*"libnss-mdns" 패키지는 mDNS(멀티캐스트 DNS)를 통해 호스트 이름 확인을 제공하는 GNU C 라이브러리(glibc)의 GNU NSS(이름 서비스 스위치) 기능에 대한 플러그 인입니다. 이 패키지를 사용하면 일반적인 Unix/Linux 프로그램이 임시 mDNS 도메인 .local에서 이름을 확인할 수 있습니다.

/etc/nsswitch.conf"호스트" 섹션에서 "mdns_minimal" 설정을 사용하도록 파일을 구성합니다. 파일의 콘텐츠 예제:

cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

WSL의 DNS 접미사

.wslconfig 파일의 구성에 따라 WSL은 DNS 접미사와 관련하여 다음과 같은 동작을 수행합니다.

networkingMode가 NAT로 설정된 경우:

사례 1) 기본적으로 Linux에서 DNS 접미사가 구성되지 않음

사례 2) DNS 터널링이 사용하도록 설정된 경우(.wslconfig에서 dnsTunneling이 true로 설정됨) 모든 Windows DNS 접미사는 /etc/resolv.conf의 "검색" 설정에서 Linux에서 구성됩니다.

접미사는 /etc/resolv.conf에서 다음과 같은 순서로 구성됩니다. 이는 Windows DNS 클라이언트가 이름을 확인할 때 접미사를 시도하는 순서와 유사합니다. 먼저 전역 DNS 접미사가 오고, 그 다음 보충 DNS 접미사, 그리고 인터페이스별 DNS 접미사가 설정됩니다.

Windows DNS 접미사가 변경되면 해당 변경 내용이 Linux에 자동으로 반영됩니다.

사례 3) DNS 터널링이 비활성화되고 SharedAccess DNS 프록시가 비활성화된 경우(dnsTunneling이 false로 설정되고 dnsProxy가 .wslconfig에서 false로 설정됨) 단일 DNS 접미사가 Linux에서 /etc/resolv.conf의 "도메인" 설정으로 구성됩니다.

Windows DNS 접미사가 변경되면 해당 변경 내용이 Linux에 반영되지 않습니다.

Linux에서 구성된 단일 DNS 접미사는 인터페이스별 DNS 접미사에서 선택됩니다(전역 및 추가 접미사는 무시됨).

Windows에 여러 인터페이스가 있는 경우 추론을 사용하여 Linux에서 구성할 단일 DNS 접미사를 선택합니다. 예를 들어 Windows에 VPN 인터페이스가 있는 경우 해당 인터페이스에서 접미사가 선택됩니다. VPN 인터페이스가 없으면 인터넷 연결을 제공할 가능성이 가장 큰 인터페이스에서 접미사가 선택됩니다.

networkingMode가 미러링됨으로 설정된 경우:

모든 Windows DNS 접미사는 /etc/resolv.conf의 "검색" 설정에서 Linux에서 구성됩니다.

접미사는 NAT 모드의 경우 2와 동일한 순서로 /etc/resolv.conf로 구성됩니다.

Windows DNS 접미사가 변경되면 해당 변경 내용이 Linux에 자동으로 반영됩니다.

참고: SetInterfaceDnsSettings - Win32 앱 | Microsoft Learn를 사용하여 Windows에서 추가 DNS 접미사를 구성할 수 있으며, 설정 매개 변수에 DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST 플래그가 설정되어야 합니다.

WSL에서 DNS 문제 해결

WSL이 NAT 모드에서 컨테이너를 시작할 때 기본 DNS 구성은 Windows 호스트의 NAT 디바이스가 WSL 컨테이너에 대한 DNS '서버'로 사용되도록 하는 것입니다. DNS 쿼리가 WSL 컨테이너에서 Windows 호스트의 해당 NAT 디바이스로 전송되면 DNS 패킷이 NAT 디바이스에서 호스트의 공유 액세스 서비스로 전달됩니다. 응답은 역방향으로 WSL 컨테이너로 다시 전송됩니다. 공유 액세스에 대한 이 패킷 전달 프로세스에는 WSL이 처음에 WSL 컨테이너에 대한 NAT 가상 네트워크를 만들도록 HNS에 요청할 때 HNS 서비스에서 만든 인바운드 DNS 패킷을 허용하는 방화벽 규칙이 필요합니다.

이 NAT - 공유 액세스 설계로 인해 WSL에서 이름 확인에 문제가 발생할 수 있는 몇 가지 알려진 설정이 있습니다.

1. 엔터프라이즈는 로컬로 정의된 방화벽 규칙을 허용하지 않고 엔터프라이즈 정책 정의 규칙만 허용하는 정책을 푸시할 수 있습니다.

엔터프라이즈에서 설정하면 로컬로 정의된 규칙이므로 HNS에서 만든 방화벽 규칙이 무시됩니다. 이 구성이 작동하려면 엔터프라이즈에서 UDP 포트 53을 공유 액세스 서비스에 허용하도록 방화벽 규칙을 만들어야 합니다. 그렇지 않으면 WSL이 DNS 터널링을 사용하도록 설정할 수 있습니다. 다음을 실행하여 로컬로 정의된 방화벽 규칙을 허용하지 않도록 구성되어 있는지 확인할 수 있습니다. 도메인, 프라이빗 및 퍼블릭의 3개 프로필 모두에 대한 설정이 표시됩니다. 모든 프로필에 설정된 경우 WSL vNIC에 해당 프로필이 할당되면 패킷이 차단됩니다(기본값은 공용). Powershell에서 반환되는 첫 번째 방화벽 프로필의 코드 조각일 뿐입니다.

PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                            : Domain
Enabled                         : True
DefaultInboundAction            : Block
DefaultOutboundAction           : Allow
AllowInboundRules               : True
AllowLocalFirewallRules         : False

AllowLocalFirewallRules:False means the locally defined firewall rules, like that by HNS, will not be applied or used.

2. 엔터프라이즈는 모든 인바운드 규칙을 차단하는 그룹 정책 및 MDM 정책 설정을 푸시다운할 수 있습니다.

이러한 설정은 모든 Allow-Inbound 방화벽 규칙을 재정의합니다. 따라서 이 설정은 HNS에서 만든 UDP 방화벽 규칙을 차단하므로 WSL에서 이름을 확인할 수 없습니다. 이 구성이 작동하려면 DNS 터널링을 사용하도록 WSL을 설정해야 합니다. 이 설정은 항상 NAT DNS 프록시를 차단합니다.

그룹 정책에서:

컴퓨터 구성 \ 관리 템플릿 \ 네트워크 \ 네트워크 연결 \ Windows Defender 방화벽 \ 도메인 프로필 | 표준 프로필

"Windows Defender 방화벽: 예외 허용 안 함" - 사용

MDM 정책에서:

./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Shielded

./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Shielded

./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Shielded

다음을 실행하여 인바운드 방화벽 규칙을 허용하지 않도록 구성되어 있는지 확인할 수 있습니다(방화벽 프로필에 대한 위의 주의 사항 참조). Powershell에서 반환되는 첫 번째 방화벽 프로필의 코드 조각일 뿐입니다.


PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                            : Domain
Enabled                         : True
DefaultInboundAction            : Block
DefaultOutboundAction           : Allow
AllowInboundRules               : False

AllowInboundRules: False means that no inbound Firewall rules will be applied.

3. 사용자가 Windows 보안 설정 앱을 살펴보고 컨트롤에서 "허용되는 앱 목록에 있는 연결을 포함하여 들어오는 모든 연결을 차단합니다."를 확인합니다.

Windows는 위의 #2에서 참조된 엔터프라이즈에서 적용할 수 있는 동일한 설정에 대한 사용자 옵트인을 지원합니다. 사용자는 "Windows 보안" 설정 페이지를 열고, "방화벽 및 네트워크 보호" 옵션을 선택하고, 구성하려는 방화벽 프로필(도메인, 개인 또는 공용)을 선택하고, "들어오는 연결"에서 "허용되는 앱 목록에 있는 연결을 포함하여 들어오는 모든 연결을 차단합니다"라는 레이블이 지정된 컨트롤을 확인합니다.

공용 프로필(WSL vNIC의 기본 프로필)에 대해 설정된 경우 UDP 패킷이 공유 액세스를 허용하도록 HNS에서 만든 방화벽 규칙이 차단됩니다.

WSL에서 작동하려면 NAT DNS 프록시 구성을 선택 취소해야 합니다 . 또는 DNS 터널링을 사용하도록 WSL을 설정할 수 있습니다.

4. DNS 패킷이 공유 액세스를 허용하도록 허용하는 HNS 방화벽 규칙은 이전 WSL 인터페이스 식별자를 참조하여 유효하지 않은 상태가 될 수 있습니다. 이는 최신 Windows 11 릴리스로 수정된 HNS 내의 결함입니다. 이전 릴리스에서는 이 문제가 발생하는 경우 쉽게 검색할 수 없지만 다음과 같은 간단한 작업을 수행할 수 있습니다.

WSL 중지

wsl.exe –shutdown
이전 HNS 방화벽 규칙을 삭제합니다. 이 Powershell 명령은 대부분의 경우 작동합니다.

Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule
모든 HNS 엔드포인트를 제거합니다. 참고: HNS를 사용하여 MDAG 또는 Windows 샌드박스와 같은 다른 컨테이너를 관리하는 경우 해당 컨테이너도 중지해야 합니다.

hnsdiag.exe delete all
HNS 서비스를 다시 부팅하거나 다시 시작합니다.

Restart-Service hns
WSL을 다시 시작하면 HNS는 WSL 인터페이스를 올바르게 대상으로 하는 새 방화벽 규칙을 만듭니다.

Windows에서 네트워크 액세스 문제 해결

네트워크에 액세스할 수 없는 경우 구성이 잘못되었을 수 있습니다. FSE 드라이버가 실행 중인지 확인하세요. 'sc queryex FSE'. FSE 실행이 표시되지 않는 경우 이 레지스트리 키 아래에 PortTrackerEnabledMode 레지스트리 값이 종료되는지 확인하세요. reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. FSE가 실행 중이거나 설치되어 있지 않고 PortTrackerEnabledMode가 있는 경우 해당 레지스트리 값을 삭제하고 다시 부팅하세요.

가상 어댑터를 삭제하는 수동 방법

고스트 어댑터 또는 PnP(가상 플러그 앤 플레이) 디바이스는 시스템에 표시되지만 물리적으로 연결되지 않은 하드웨어 구성 요소를 참조합니다. 이러한 "고스트" 디바이스는 시스템 설정에서 혼동과 혼란을 야기할 수 있습니다. VM(Virtual Machine)에서 WSL을 실행할 때 고스트 어댑터가 표시되는 경우 다음 수동 단계에 따라 이러한 가상 PnP 디바이스를 찾아 삭제합니다. Microsoft는 수동 개입이 필요하지 않은 자동화된 솔루션을 연구하고 있습니다. 자세한 내용은 곧 제공될 예정입니다.

디바이스 관리자를 엽니다.
숨겨진 디바이스 표시 보기 >

디바이스 관리자의 숨겨진 디바이스 메뉴 표시 스크린샷

네트워크 어댑터 열기

네트워크 어댑터 목록의 스크린샷

고스트 네트워크 어댑터를 마우스 오른쪽 단추로 클릭하고 디바이스 제거를 선택합니다.

네트워크 목록에서 가상 pnp를 마우스 오른쪽 단추로 클릭하고 디바이스 제거를 선택하는 스크린샷

WSL을 시작하거나 배포를 설치하면 오류 코드가 반환됩니다.

지침에 따라 GitHub의 WSL 리포지토리에서 WSL 로그를 수집 하여 자세한 로그를 수집하고 GitHub에 문제를 제출합니다.

WSL 업데이트

업데이트가 필요할 수 있는 Linux용 Windows 하위 시스템의 두 가지 구성 요소가 있습니다.

Linux용 Windows 하위 시스템을 업데이트하려면 PowerShell 또는 CMD에서 명령을 wsl --update 사용합니다.
특정 Linux 배포 사용자 이진 파일을 업데이트하려면 업데이트하려는 Linux 배포에서 다음 명령을 apt-get update | apt-get upgrade 사용합니다.

Apt-get 업그레이드 오류

일부 패키지는 아직 구현하지 않은 기능을 사용합니다. udev예를 들어 아직 지원되지 않으며 몇 가지 apt-get upgrade 오류가 발생합니다.

관련된 udev문제를 해결하려면 다음 단계를 수행합니다.

다음을 /usr/sbin/policy-rc.d에 입력하고 변경 내용을 저장합니다.
```
#!/bin/sh
exit 101
```
/usr/sbin/policy-rc.d에 실행 권한을 추가하십시오.
```
chmod +x /usr/sbin/policy-rc.d
```

다음 명령어를 실행하세요:

dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl

설치 시 "오류: 0x80040306"

이는 레거시 콘솔을 지원하지 않는다는 사실과 관련이 있습니다. 레거시 콘솔을 끄려면:

cmd.exe 열기
제목 표시줄을 마우스 오른쪽 단추로 클릭 -> 속성 -> 레거시 콘솔 사용 선택 취소
확인을 클릭합니다.

Windows 업데이트 후 "오류: 0x80040154"

Windows 업데이트 중에 Linux용 Windows 하위 시스템 기능을 사용하지 않도록 설정할 수 있습니다. 이 경우 Windows 기능을 다시 사용하도록 설정해야 합니다. Linux용 Windows 하위 시스템을 사용하도록 설정하기 위한 지침은 수동 설치 가이드에서 찾을 수 있습니다.

표시 언어 변경

WSL 설치는 Windows 설치의 로캘과 일치하도록 Ubuntu 로캘을 자동으로 변경하려고 합니다. 이 동작을 원하지 않는 경우 설치가 완료된 후 이 명령을 실행하여 Ubuntu 로캘을 변경할 수 있습니다. 이 변경 내용이 적용되려면 bash.exe 다시 시작해야 합니다.

아래 예제에서는 로캘이 다음과 같이 변경됩니다 en-US.

sudo update-locale LANG=en_US.UTF8

Windows 시스템 복원 후 설치 문제

%windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux 폴더를 삭제합니다.
참고: 선택적 기능이 완전히 설치되고 작동하는 경우에는 이 작업을 수행하지 마세요.
WSL 선택적 기능 사용(아직 없는 경우)
재부팅
lxrun /uninstall /full
bash 설치

WSL에서 인터넷 액세스 없음

일부 사용자는 WSL에서 인터넷 액세스를 차단하는 특정 방화벽 애플리케이션과 관련된 문제를 보고했습니다. 보고된 방화벽은 다음과 같습니다.

카스퍼 스키
평균
정지
Symantec Endpoint Protection

경우에 따라 방화벽을 해제하면 액세스할 수 있습니다. 경우에 따라 방화벽을 설치하기만 하면 액세스를 차단할 수 있습니다.

Microsoft Defender 방화벽을 사용하는 경우 "허용되는 앱 목록에 있는 연결을 포함하여 들어오는 모든 연결을 차단합니다."를 선택 취소하면 액세스할 수 있습니다.

ping을 사용할 때 사용 권한 거부 오류

Windows 1주년 업데이트 버전 1607의 경우 WSL에서 ping을 실행하려면 Windows의 관리자 권한이 필요합니다. ping을 실행하려면 Windows의 Ubuntu에서 관리자 권한으로 Bash를 실행하거나 관리자 권한으로 CMD/PowerShell 프롬프트에서 bash.exe 실행합니다.

이후 버전의 Windows 빌드 14926 이상에서는 관리자 권한이 더 이상 필요하지 않습니다.

Bash가 걸려 있습니다.

bash를 사용하는 동안 bash가 중단(또는 교착 상태)이고 입력에 응답하지 않는 경우 메모리 덤프를 수집하고 보고하여 문제를 진단하는 데 도움이 됩니다. 이러한 단계를 따르면 시스템이 멈출 수 있습니다. 이 작업에 익숙하지 않은 경우 이 작업을 수행하거나 이 작업을 수행하기 전에 작업을 저장하지 마세요.

메모리 덤프를 수집하려면

메모리 덤프 유형을 "메모리 덤프 완료"로 변경합니다. 덤프 형식을 변경하는 동안 현재 형식을 기록해 둡다.
단계를 사용하여 키보드 컨트롤로 크래시를 구성합니다.
응답 중단 또는 교착 상태를 재현하십시오.
(2)의 키 시퀀스를 사용하여 시스템을 크래시합니다.
시스템이 충돌하고 메모리 덤프를 수집합니다.
시스템이 다시 부팅되면 memory.dmp를 보고하십시오 secure@microsoft.com. 덤프 파일의 기본 위치는 %SystemRoot%\memory.dmp 또는 C:\Windows\memory.dmp이며, C:가 시스템 드라이브인 경우입니다. 이메일에서 덤프는 WSL 또는 Windows에서 Bash 팀을 위해 작성되었음을 명시하세요.
메모리 덤프 유형을 원래 설정으로 복원합니다.

빌드 번호 확인

PC의 아키텍처와 윈도우즈 빌드 번호를 찾으려면
설정>시스템>정보

OS 빌드 및 시스템 유형 필드를 찾습니다.
빌드 및 시스템 형식 필드의 스크린샷

Windows Server 빌드 번호를 찾으려면 PowerShell에서 다음을 실행합니다.

systeminfo | Select-String "^OS Name","^OS Version"

WSL이 사용하도록 설정되어 있는지 확인

관리자 권한 PowerShell 창에서 다음 명령을 실행하여 Linux용 Windows 하위 시스템이 활성화되어 있는지 확인할 수 있습니다.

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

OpenSSH-Server 연결 문제

"연결이 127.0.0.1 포트 22로 닫혔습니다."라는 오류와 함께 SSH 서버를 연결하지 못했습니다.

OpenSSH 서버가 실행 중인지 확인합니다.
```
sudo service ssh status
```
이 튜토리얼을 따라 했습니다: https://ubuntu.com/server/docs/service-openssh
sshd 서비스를 중지하고 디버그 모드에서 sshd를 시작합니다.
```
sudo service ssh stop
sudo /usr/sbin/sshd -d
```

시작 로그를 확인하고 HostKey를 사용할 수 있고 다음과 같은 로그 메시지가 표시되지 않는지 확인합니다.

debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: key_load_private: incorrect passphrase supplied to decrypt private key
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_rsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ed25519_key

이러한 메시지가 표시되고 /etc/ssh/ 아래에 키가 누락된 경우, 키를 다시 생성하거나 openssh-server를 정리 후에 설치해야 합니다.

sudo apt-get purge openssh-server
sudo apt-get install openssh-server

WSL 선택적 기능을 사용하도록 설정하는 경우 "참조된 어셈블리를 찾을 수 없습니다."

이 오류는 잘못된 설치 상태와 관련이 있습니다. 이 문제를 해결하려면 다음 단계를 완료하세요.

PowerShell에서 WSL 기능 사용 명령을 실행하는 경우 시작 메뉴를 열고 'Windows 기능 설정 또는 해제'를 검색한 다음 목록에서 선택적 구성 요소를 설치할 'Linux용 Windows 하위 시스템'을 선택하여 GUI를 사용하세요.
설정, 업데이트로 이동하고 '업데이트 확인'을 클릭하여 Windows 버전을 업데이트합니다.
둘 다 실패하고 WSL에 액세스해야 하는 경우 설치 미디어를 사용하여 Windows를 다시 설치하고 '모든 항목 유지'를 선택하여 앱과 파일이 유지되도록 하여 업그레이드를 고려하세요. Windows 10 다시 설치 페이지에서 이 작업을 수행하는 방법에 대한 지침을 찾을 수 있습니다.

이 오류가 표시되는 경우:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/private-key.pem' are too open.

이 문제를 해결하려면 파일 /etc/wsl.conf에 다음을 추가합니다.

[automount]
enabled = true
options = metadata,uid=1000,gid=1000,umask=0022

이 명령을 추가하면 메타데이터가 포함되고 WSL에서 볼 수 있는 Windows 파일에 대한 파일 사용 권한이 수정됩니다. 자세한 내용은 파일 시스템 사용 권한을 참조하세요.

Windows에서 OpenSSH를 사용하여 WSL을 원격으로 사용하지 못함

Windows에서 openssh-server를 사용하고 원격으로 WSL에 액세스하려는 경우 다음과 같은 오류가 표시됩니다.

The file cannot be accessed by the system.

WSL의 스토어 버전을 사용하는 경우 알려진 문제입니다. 현재 WSL 1을 사용하거나 Windows 내 버전의 WSL을 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 https://aka.ms/wslstoreinfo를 참조하세요.

배포 내에서 Windows 명령 실행 실패

Microsoft Store에서 사용할 수 있는 일부 배포판은 Windows 명령을 실행하기 위해 아직 완전히 호환되지 않습니다. -bash: powershell.exe: command not found 또는 다른 Windows 명령을 실행할 때 오류 powershell.exe /c start .가 발생하는 경우, 다음 단계에 따라 문제를 해결할 수 있습니다.

WSL 배포에서 .echo $PATH
포함되지 않는 경우: 무언가가 표준 PATH 변수를 재정의하고 있습니다.
cat /etc/profile을 사용하여 프로필 설정을 확인하십시오.
경로 변수 할당이 포함된 경우 해당 파일을 편집하여 경로 할당 블록을 #로 주석 처리합니다.
wsl.conf가 있는지 cat /etc/wsl.conf 확인하고 wsl.conf가 포함되어 appendWindowsPath=false있지 않은지 확인합니다. 그렇지 않으면 주석 처리합니다.
배포를 다시 시작하려면 배포 이름 뒤에 wsl -t 를 입력하거나 cmd 또는 PowerShell에서 wsl --shutdown을 실행합니다.

WSL 2를 설치한 후 부팅할 수 없음

WSL 2를 설치한 후 부팅할 수 없는 사용자에게 영향을 주는 문제를 알고 있습니다. 이러한 문제를 완전히 진단하는 동안 사용자는 버퍼 크기를 변경 하거나 올바른 드라이버를 설치하면 이 문제를 해결하는 데 도움이 될 수 있다고 보고했습니다. 이 문제에 대한 최신 업데이트를 보려면 이 GitHub 문제를 확인하세요.

ICS를 사용할 수 없는 경우 WSL 2 오류

ICS(인터넷 연결 공유)는 WSL 2의 필수 구성 요소입니다. ICS 서비스는 HNS(호스트 네트워크 서비스)에서 WSL 2가 NAT, DNS, DHCP 및 호스트 연결 공유에 의존하는 기본 가상 네트워크를 만드는 데 사용됩니다.

ICS 서비스(SharedAccess)를 사용하지 않도록 설정하거나 그룹 정책을 통해 ICS를 사용하지 않도록 설정하면 WSL HNS 네트워크가 생성되지 않습니다. 이렇게 하면 새 WSL 버전 2 이미지를 만들 때 오류가 발생하며 버전 1 이미지를 버전 2로 변환하려고 할 때 다음 오류가 발생합니다.

There are no more endpoints available from the endpoint mapper.

WSL 2가 필요한 시스템은 ICS 서비스(SharedAccess)를 기본 시작 상태인 수동(트리거 시작)으로 유지해야 하며, ICS를 사용하지 않도록 설정하는 정책은 덮어쓰거나 제거해야 합니다. ICS 서비스를 비활성화하면 WSL 2가 중단되며, ICS를 비활성화하는 것을 권장하지 않지만, 이러한 지침을 사용하여 ICS의 일부를 비활성화할 수 있습니다.

이전 버전의 Windows 및 WSL 사용

Windows 10 크리에이터스 업데이트(2017년 10월, 빌드 16299) 또는 1주년 업데이트(2016년 8월, 빌드 14393)와 같은 이전 버전의 Windows 및 WSL을 실행하는 경우 주의해야 할 몇 가지 차이점이 있습니다. 최신 Windows 버전으로 업데이트하는 것이 좋지만 가능하지 않은 경우 아래의 몇 가지 차이점을 간략하게 설명했습니다.

상호 운용성 명령 차이점:

bash.exe가 wsl.exe로 바뀌었습니다. Linux 명령은 Windows 명령 프롬프트나 PowerShell에서 실행할 수 있지만, 초기 Windows 버전을 사용하는 경우에는 bash 명령을 사용해야 할 수 있습니다. 예: C:\temp> bash -c "ls -la". WSL 명령어가 bash -c에 전달되면 수정 없이 WSL 프로세스로 넘겨집니다. 파일 경로는 WSL 형식으로 지정해야 하며 관련 문자를 이스케이프하는 데 주의해야 합니다. 예를 들어 C:\temp> bash -c "ls -la /proc/cpuinfo" 또는 C:\temp> bash -c "ls -la \"/mnt/c/Program Files\""입니다.
특정 배포에 사용할 수 있는 명령을 보려면 다음을 실행 [distro.exe] /?합니다. 예를 들어 Ubuntu: C:\> ubuntu.exe /?.
Windows 경로는 WSL $PATH에 포함됩니다.
이전 버전의 Windows 10에서 WSL 배포판에서 Windows 도구를 호출하는 경우 디렉터리 경로를 지정해야 합니다. 예를 들어 WSL 명령줄에서 Windows 메모장 앱을 호출하려면 다음을 입력합니다. /mnt/c/Windows/System32/notepad.exe
root로 기본 사용자를 변경하려면 PowerShell에서 이 명령을 사용하십시오: C:\> lxrun /setdefaultuser root 그런 다음 Bash.exe을 실행하여 로그인합니다: C:\> bash.exe. 배포 암호 명령을 $ passwd username 사용하여 암호를 재설정한 다음 Linux 명령줄 $ exit을 닫습니다. Windows 명령 프롬프트 또는 Powershell에서 기본 사용자를 일반 Linux 사용자 계정 C:\> lxrun.exe /setdefaultuser username으로 다시 설정합니다.

WSL의 레거시 버전 제거

원래 크리에이터스 업데이트(2017년 10월, 빌드 16299)전에 Windows 10 버전에 WSL을 설치한 경우 설치한 이전 Linux 배포판에서 Microsoft Store를 통해 설치된 최신 배포판으로 필요한 파일, 데이터 등을 마이그레이션하는 것이 좋습니다. 컴퓨터에서 레거시 배포를 제거하려면 명령줄 또는 PowerShell 인스턴스 wsl --unregister Legacy에서 다음을 실행합니다. Windows 파일 탐색기 또는 PowerShell%localappdata%\lxss\을 사용하여 폴더(및 모든 하위 콘텐츠)를 삭제하여 rm -Recurse $env:localappdata/lxss/ 이전 레거시 배포를 수동으로 제거할 수도 있습니다.