WSL 인터넷 안됨 DNS 오류 해결법: resolv.conf 고정 설정 가이드

이 글의 목적은 Windows 10/11 환경에서 WSL(Windows Subsystem for Linux) 사용 시 발생하는 인터넷 DNS 해석 오류를 진단하고, resolv.conf 설정을 통해 안정적으로 네임서버를 고정하여 접속 문제를 해결하는 실무 중심 방법을 정리하는 것이다.

1. WSL에서 인터넷·DNS 해석이 안 되는 전형적인 증상

1.1 증상 체크 리스트

WSL 터미널에서 다음과 같은 증상이 반복된다면 DNS 해석 문제일 가능성이 매우 높다.

  • ping google.com 은 실패하지만, ping 8.8.8.8 은 정상 응답이 오는 경우
  • apt update 또는 sudo apt-get update 실행 시 Temporary failure resolving ... 오류 발생
  • curl https://example.com 명령이 Could not resolve host 메시지를 출력하는 경우
  • nslookup, dig 명령으로 도메인 조회가 되지 않는 경우

이러한 상황에서 Windows 브라우저(Edge, Chrome)는 인터넷 접속이 정상이라면, 문제는 WSL 내부의 DNS 설정 또는 WSL 가상 네트워크 구성에 국한된 경우가 대부분이다.

1.2 왜 WSL에서 DNS 문제가 자주 발생하는가

WSL1, WSL2 모두 Windows 호스트의 네트워크를 기반으로 동작하지만, 구현 방식이 다르다.

  • WSL1: Windows 네트워크 스택을 공유하는 방식으로, 상대적으로 DNS 이슈가 적다.
  • WSL2: 가상 머신(VM) 기반으로 동작하며, 가상 NIC·가상 스위치를 사용한다. 이 과정에서 DNS 프록시, VPN, 보안 소프트웨어, 회사 전용 DNS 등과 충돌하면서 DNS 해석 문제가 자주 발생한다.

특히 다음과 같은 상황에서 문제가 빈번하게 보고된다.

  • 회사 VPN 연결 후 WSL에서만 도메인 해석이 안 되는 경우
  • 공유기 DNS 설정을 변경했는데 WSL이 이전 DNS 정보만 사용하는 경우
  • Windows에서 인터넷 제한, 방화벽, DNS 필터링 프로그램을 사용 중인 경우

2. 기본 점검: 네트워크 연결과 DNS 해석 구분

2.1 IP 연결 여부 확인

먼저 WSL 내부에서 IP 레벨 통신이 정상인지 확인한다.

# WSL 터미널에서 실행 ping 8.8.8.8 ping 1.1.1.1 
  • IP 주소로 ping이 정상 응답이면, 인터넷 경로 자체는 살아 있고 DNS 해석만 문제일 가능성이 높다.
  • IP 주소로도 ping이 되지 않는다면, WSL 가상 네트워크 어댑터 또는 Windows 방화벽·VPN·프록시 설정까지 포함해 더 넓게 확인해야 한다.

2.2 DNS 해석 테스트

다음으로 도메인 이름을 사용했을 때만 실패하는지 확인한다.

ping google.com ping www.microsoft.com 

IP는 되지만 도메인은 안 된다면, /etc/resolv.conf 에 설정된 네임서버가 잘못되었거나, 특정 DNS 서버가 차단·응답 지연 상태일 가능성이 있다.

3. /etc/resolv.conf 구조와 WSL의 자동 생성 메커니즘

3.1 resolv.conf란 무엇인가

/etc/resolv.conf 파일은 리눅스 시스템에서 어떤 DNS 서버를 사용해 도메인 이름을 IP로 해석할지 정의하는 설정 파일이다. 대표적인 항목은 다음과 같다.

nameserver 8.8.8.8 nameserver 1.1.1.1 search localdomain options timeout:2 attempts:3 

3.2 WSL에서 resolv.conf 동작 방식

WSL2에서는 기본적으로 WSL이 시작될 때마다 Windows 네트워크 설정을 읽어와 /etc/resolv.conf 를 자동 생성한다. 이때 다음과 같은 특징이 있다.

  • WSL 인스턴스를 다시 시작할 때마다 내용이 덮어쓰기 된다.
  • Windows 쪽에서 DNS가 동적으로 변경되면 WSL 내부 파일도 함께 변경된다.
  • VPN 연결·해제, 네트워크 전환 시 예기치 않은 DNS 주소가 들어오는 경우가 있다.

따라서 문제 해결을 위해 수동으로 DNS를 고정하려면, 자동 생성 기능을 끄고 resolv.conf 를 직접 관리해야 한다.

4. WSL DNS 문제 해결 전략 개요

실무적으로 다음과 같은 순서로 문제를 해결하는 것이 효율적이다.

  1. WSL 네트워크 기본 상태 점검 (ping, ipconfig, nslookup)
  2. Windows 호스트의 DNS 설정과 WSL 내부 DNS 설정 비교
  3. WSL의 자동 DNS 생성 비활성화 (wsl.conf 설정)
  4. /etc/resolv.conf 에 공용 DNS 또는 사내 DNS를 수동으로 설정
  5. WSL 인스턴스 재시작 및 재확인
주의 : 회사망·보안망에서는 사내에서 지정한 DNS 이외의 공용 DNS(8.8.8.8 등)를 사용하면 보안 정책 위반이 될 수 있다. 반드시 사내 네트워크 규정을 확인한 후 적용해야 한다.

5. resolv.conf 수동 설정을 위한 준비

5.1 현재 resolv.conf 내용 확인

먼저 WSL에서 현재 어떤 DNS 서버를 사용 중인지 확인한다.

cat /etc/resolv.conf 

예시로 다음과 같이 나올 수 있다.

# This file was automatically generated by WSL. To stop automatic generation, remove this line. nameserver 192.168.0.1 search lan 

첫 줄에 “automatically generated by WSL” 문구가 있다면, 현재는 자동 생성 모드임을 의미한다.

5.2 resolv.conf 백업

수동 설정을 적용하기 전에 기존 파일을 백업해 두는 것이 안전하다.

sudo cp /etc/resolv.conf /etc/resolv.conf.bak 

6. WSL에서 자동 DNS 생성 비활성화(wsl.conf 설정)

6.1 wsl.conf 파일 생성 또는 수정

/etc/wsl.conf 파일에서 WSL의 네트워크 관련 동작을 제어할 수 있다. 파일이 없을 수 있으므로, 에디터로 새로 생성한다.

sudo nano /etc/wsl.conf 

다음 내용을 추가하거나 기존 내용을 편집한다.

[network] generateResolvConf = false 
  • generateResolvConf = false 로 설정하면 WSL이 부팅될 때 /etc/resolv.conf 를 자동 생성하지 않는다.
주의 : 오타가 있으면 설정이 적용되지 않는다. 특히 대소문자(generateResolvConf)를 정확히 입력해야 한다.

6.2 기존 resolv.conf 삭제

자동 생성 기능을 끄고 나면, 기존에 자동 생성된 파일을 제거하고 수동으로 다시 만들어야 한다.

sudo rm /etc/resolv.conf 

삭제 후 바로 새 파일을 만들지 않더라도, WSL을 재시작하기 전까지는 기존 설정이 메모리에 남아 동작할 수 있다. 따라서 다음 단계에서 새 파일을 생성한다.

7. resolv.conf 수동 작성: 공용 DNS 예시

7.1 공용 DNS 서버 선택

개인 PC 환경에서 가장 많이 사용하는 공용 DNS 서버 예시는 다음과 같다.

DNS 제공자 IPv4 주소 특징
Google Public DNS 8.8.8.8, 8.8.4.4 전 세계적으로 많이 사용, 속도·안정성 우수
Cloudflare DNS 1.1.1.1, 1.0.0.1 개인정보 보호 강조, 지연시간이 짧은 편
OpenDNS 208.67.222.222, 208.67.220.220 필터링·보안 기능 제공(계정 설정 시)
KT·국내 ISP DNS(예시) 168.126.63.1, 168.126.63.2 국내 회선에서 응답이 빠른 편

여기서는 예시로 Google DNS와 Cloudflare DNS를 사용한다.

7.2 resolv.conf 새로 작성

다음과 같이 /etc/resolv.conf 파일을 새로 작성한다.

sudo nano /etc/resolv.conf 

편집기에서 아래 예시 내용을 입력한다.

nameserver 1.1.1.1 nameserver 8.8.8.8 options timeout:2 attempts:3 
  • nameserver: 우선 사용할 DNS 서버를 위에서부터 순서대로 나열한다.
  • options timeout:2: DNS 응답을 2초 동안 기다린다.
  • options attempts:3: 최대 3회까지 재시도한다.

7.3 resolv.conf 보호(선택)

일부 환경에서는 다른 스크립트·툴이 /etc/resolv.conf 를 다시 수정하는 경우가 있다. 이를 방지하려면 파일을 읽기 전용으로 설정할 수 있다.

sudo chmod 644 /etc/resolv.conf # 일반적인 권한 # 필요 시 # sudo chattr +i /etc/resolv.conf # 변경 불가 속성 부여(일반 Linux에서 가능, WSL에서는 동작이 다를 수 있다) 
주의 : 읽기 전용 또는 변경 불가 속성을 부여하면, 추후 DNS를 변경할 때 다시 권한을 조정해야 한다. 변경 계획이 잦다면 과도한 보호 설정은 피하는 것이 관리 측면에서 유리하다.

8. WSL 재시작 및 DNS 테스트

8.1 WSL 전체 종료

설정을 반영하려면 WSL 인스턴스를 완전히 종료했다 다시 시작해야 한다. Windows PowerShell 또는 CMD에서 다음을 실행한다.

wsl --shutdown 

8.2 WSL 재실행 후 확인

다시 WSL을 실행한 후, DNS 설정이 유지되는지 확인한다.

cat /etc/resolv.conf 

앞에서 작성한 내용이 그대로 보이면 설정이 적용된 것이다. 이후 다음과 같이 DNS 해석을 테스트한다.

ping google.com ping www.microsoft.com
패키지 업데이트 테스트 (Ubuntu 기준)
sudo apt update

curl 테스트
curl https://www.google.com -I

이 명령들이 정상 작동한다면, WSL 인터넷 DNS 해석 문제는 대부분 해결된 것이다.

9. 회사망·VPN 환경에서의 추가 고려 사항

9.1 사내 DNS 주소 사용

회사 VPN 또는 도메인 환경에서는 내부 도메인(예: internal.corp.local)을 해석하기 위해 사내 DNS 서버를 의무적으로 사용해야 하는 경우가 많다. 이때는 네트워크 관리자에게 다음 정보를 확인한다.

  • 사내 DNS 서버 IPv4 주소
  • 내부 도메인 검색 도메인(search domain) 값
  • DNS Split Tunneling 정책 존재 여부

확인한 후 /etc/resolv.conf 에 다음과 같이 설정한다.

nameserver 10.10.10.10 # 회사 DNS nameserver 1.1.1.1 # 보조용 공용 DNS (정책 허용 시) search corp.local options timeout:2 attempts:3 

9.2 VPN 재접속 시 DNS 재확인

일부 VPN은 연결 시 Windows의 DNS를 강제로 변경한다. WSL에서는 자동 생성 기능을 끈 상태이므로, VPN 연결·해제에 따라 직접 DNS를 조정해야 할 수 있다. VPN 연결 후 특정 도메인만 안 열린다면 다음을 점검한다.

  • VPN 클라이언트에서 Split DNS/Split Tunnel 설정이 있는지
  • 사내 DNS 서버에서 외부 도메인 조회가 제한되어 있는지
  • 사내 보안 정책에 따라 공용 DNS 사용이 차단되어 있지는 않은지

10. WSL 네트워크 초기화로도 해결되지 않을 때

10.1 WSL 네트워크 재설정

간혹 WSL 가상 스위치 자체가 꼬여서 DNS 문제가 반복되기도 한다. 이 경우 WSL 기능을 재설정하는 방법을 고려할 수 있다. 다만, 기존 배포본과 데이터에 영향을 줄 수 있으므로 신중하게 진행해야 한다.

  1. 중요 데이터는 WSL 내에서 백업 또는 외부 경로로 복사한다.
  2. Windows 기능에서 “Windows Subsystem for Linux”, “Virtual Machine Platform”을 껐다 다시 켠다.
  3. 필요 시 WSL 배포본을 재설치한다.
주의 : 이 단계는 최후의 수단에 가깝다. 단순 DNS 설정 문제라면 wsl.confresolv.conf 수동 설정만으로 충분히 해결되는 경우가 대부분이다.

10.2 방화벽·보안 프로그램 영향 확인

일부 엔드포인트 보안 솔루션은 WSL 프로세스(예: wslhost.exe, vmmem)가 DNS 요청을 보내는 것을 차단하거나 필터링한다. 다음 항목들을 점검한다.

  • 백신·보안 클라이언트 설정에서 WSL 관련 예외가 필요한지 확인
  • Windows Defender 방화벽 고급 설정에서 WSL 관련 규칙이 차단으로 되어 있지 않은지 확인
  • 회사에서 제공한 보안 정책 문서에 WSL 사용 관련 제한이 있는지 확인

11. 실무 적용 예: 대표적인 문제 상황과 resolv.conf 설정 예시

11.1 집(개인 인터넷)에서 WSL만 DNS 오류가 나는 경우

상황:

  • Windows 브라우저는 정상 인터넷 사용 가능
  • WSL에서 apt updateTemporary failure resolving 오류 발생

대응:

  1. wsl.conf 에서 generateResolvConf=false 설정
  2. /etc/resolv.conf 삭제 후, 다음과 같이 작성
nameserver 1.1.1.1 nameserver 8.8.8.8 options timeout:2 attempts:3 

11.2 회사 VPN 연결 시 WSL에서만 도메인 해석 안 되는 경우

상황:

  • Windows에서 회사 내부 시스템(intranet.corp.local) 접속 가능
  • WSL에서 같은 주소 ping 또는 curl 시 해석 실패

대응:

  1. 네트워크 관리자에게 사내 DNS 서버 주소와 검색 도메인 문의
  2. /etc/resolv.conf 에 사내 DNS 및 search 도메인 반영
nameserver 10.100.0.10 nameserver 10.100.0.11 search corp.local options timeout:2 attempts:3 

11.3 공유기 DNS를 수동으로 바꿨는데 WSL에만 반영이 안 되는 경우

상황:

  • 공유기에서 DNS를 Cloudflare(1.1.1.1)로 변경
  • Windows는 정상 동작하지만 WSL은 여전히 이전 DNS를 참조

대응:

  1. generateResolvConf=false 설정
  2. /etc/resolv.conf 를 공유기 DNS 또는 공용 DNS로 수동 설정
nameserver 1.1.1.1 nameserver 1.0.0.1 options timeout:2 attempts:3 

FAQ

Q1. resolv.conf를 수동으로 바꿨는데 자꾸 원래대로 돌아간다.

A1. /etc/wsl.conf 에서 [network] 섹션의 generateResolvConf 값을 false 로 설정했는지 확인해야 한다. 설정 후에는 반드시 wsl --shutdown 으로 WSL을 완전히 종료한 뒤 다시 실행해야 한다. 또한 다른 스크립트·툴이 resolv.conf 를 덮어쓰고 있을 가능성도 있으므로, 필요 시 chmodchattr 로 보호할 수 있다.

Q2. 8.8.8.8, 1.1.1.1 같은 공용 DNS를 써도 안전한가?

A2. 개인 PC 환경에서는 일반적으로 많이 사용하며 안정성도 높다. 다만 조직·회사·기관에서는 특정 DNS만 사용하도록 정책이 정해져 있을 수 있다. 이 경우 공용 DNS 사용은 보안 정책 위반이 될 수 있으므로 반드시 관리자 또는 보안 부서의 지침을 따라야 한다.

Q3. WSL1과 WSL2에서 DNS 설정 방법이 다른가?

A3. /etc/resolv.conf 를 사용하는 점은 동일하지만, WSL2는 가상 머신 방식이라 DNS 관련 문제가 더 자주 발생하는 경향이 있다. 다만 DNS를 수동으로 고정하는 절차(자동 생성 끄기, resolv.conf 작성)는 WSL1/WSL2 모두 유사하게 적용 가능하다. 다만 WSL1에서는 Windows 네트워크 설정을 더 직접적으로 공유하므로, 문제 원인이 DNS 이외에 다른 부분(방화벽, 호스트 네트워크 설정 등)일 가능성도 함께 고려해야 한다.

Q4. IPv6 DNS를 함께 설정해도 되는가?

A4. 네트워크 환경이 IPv6를 적극적으로 사용하는 경우라면 IPv6 형태의 nameserver 주소를 추가로 넣어도 된다. 하지만 IPv6가 제대로 구성되지 않은 환경에서 잘못된 IPv6 DNS를 우선 사용하면 오히려 응답 지연이나 실패가 늘어날 수 있으므로, 확실히 필요하지 않다면 IPv4 DNS만 사용하는 것이 문제 분석에 유리하다.

Q5. DNS 캐시를 지워야 할 때는 어떻게 하나?

A5. WSL 내부에서 systemd-resolved 또는 별도의 DNS 캐시 데몬을 사용하지 않는다면, 일반적으로 별도의 캐시 초기화는 필요하지 않다. 다만 Windows 쪽 DNS 캐시를 초기화하고 싶다면 관리자 권한 PowerShell에서 ipconfig /flushdns 명령을 실행해 DNS 캐시를 지울 수 있다.