Chrome이나 Edge에서 웹사이트를 열었는데 “사이트에 연결할 수 없음”, “서버 IP 주소를 찾을 수 없음”과 함께 DNS_PROBE_FINISHED_NXDOMAIN이 표시될 수 있습니다. 인터넷 연결 표시가 정상이고 다른 웹사이트는 열리는데 특정 도메인만 실패하는 경우도 있고, 같은 Wi-Fi에 연결된 모든 기기에서 여러 사이트가 동시에 안 열리는 경우도 있습니다.

검색 결과에는 DNS 캐시 삭제나 공용 DNS 변경이 반복해서 등장합니다. 그러나 NXDOMAIN은 단순히 인터넷 속도가 느리다는 뜻이 아닙니다. 사용 중인 DNS 해석 경로가 “그 이름에 해당하는 주소가 존재하지 않는다”는 부정 응답을 받았다는 뜻에 가깝습니다. 도메인 철자 오류, 만료되거나 잘못 위임된 도메인, 로컬 캐시, Hosts 파일, 공유기 DNS 프록시, VPN, 브라우저의 보안 DNS(DoH)가 모두 관여할 수 있습니다.

따라서 해결의 핵심은 DNS 서버 주소를 무작정 바꾸는 것이 아니라 어느 해석 경로에서 NXDOMAIN이 만들어졌는지 비교하는 것입니다. 이 글에서는 Windows 11과 Chromium 계열 브라우저를 기준으로 로컬 PC부터 권한 있는 DNS 서버까지 단계별로 원인을 좁히는 방법을 설명합니다.

핵심 결론: NXDOMAIN·SERVFAIL·시간 초과는 같은 오류가 아닙니다

DNS 문제를 진단할 때 가장 먼저 응답 종류를 구분해야 합니다.

DNS_PROBE_FINISHED_NXDOMAIN이라는 화면만으로 도메인이 실제로 존재하지 않는다고 확정할 수는 없습니다. 잘못된 DNS 서버, 오래 남은 부정 캐시, VPN의 사설 DNS, 브라우저 DoH가 다른 응답을 반환할 수 있기 때문입니다.

먼저 하지 말아야 할 행동

• 출처를 모르는 프로그램으로 DNS를 자동 최적화하지 않습니다.
• 회사 PC의 DNS·VPN·NRPT 정책을 임의로 변경하지 않습니다.
• Hosts 파일 내용을 확인하지 않고 통째로 삭제하지 않습니다.
• 공용 DNS로 바꾼 뒤 회사 내부 도메인이 안 열리는 상태를 방치하지 않습니다.
• 네트워크 초기화를 첫 단계로 실행하지 않습니다.
• 공유기 공장 초기화를 진단 전에 하지 않습니다.
• 도메인 운영자는 DNS 레코드를 여러 번 무작정 수정하지 않습니다.

네트워크 초기화는 어댑터와 일부 네트워크 구성을 다시 설치하며 VPN 클라이언트·가상 스위치·고정 IP 설정에 영향을 줄 수 있습니다. Microsoft도 네트워크 재설정을 연결 문제 해결의 마지막 단계로 안내합니다.

DNS 이름 해석은 어떤 순서로 진행될까요?

Microsoft의 Windows DNS 클라이언트 진단 문서에 따르면 이름 해석 과정에서는 먼저 캐시를 확인하고, Hosts 파일을 확인한 뒤, 필요한 경우 설정된 DNS 서버로 질의를 보냅니다.

일반적인 웹 접속에서는 다음 요소가 추가됩니다.

1. 사용자가 브라우저에 도메인을 입력합니다.
2. 브라우저 자체 캐시와 보안 DNS 설정이 관여할 수 있습니다.
3. Windows DNS 클라이언트 캐시를 확인합니다.
4. Hosts 파일의 정적 매핑을 확인합니다.
5. 네트워크 어댑터에 설정된 DNS 리졸버로 질의합니다.
6. 리졸버가 루트·TLD·권한 DNS 서버를 따라 답을 찾습니다.
7. 반환된 A·AAAA·CNAME 레코드로 웹서버에 접속합니다.

이 과정의 앞부분에서 잘못된 결과가 결정되면 뒤쪽 권한 DNS 서버로 패킷이 아예 나가지 않을 수 있습니다. Hosts 파일에 항목이 있으면 Windows DNS 클라이언트가 DNS 서버에 질의하지 않을 수 있다는 점이 대표적입니다.

1단계: 한 사이트만 실패하는지 모든 사이트가 실패하는지 구분합니다

다음 네 가지를 비교합니다.

• 같은 PC에서 다른 유명 사이트가 열리는가
• 같은 Wi-Fi의 스마트폰에서도 해당 도메인이 안 열리는가
• 스마트폰을 Wi-Fi에서 끄고 모바일 데이터로 접속하면 열리는가
• Chrome뿐 아니라 Edge 또는 다른 브라우저에서도 실패하는가

이 비교는 설정을 변경하지 않는 안전한 진단입니다. 모바일 데이터로 열렸다고 웹사이트가 완전히 정상이라고 확정할 수는 없지만, 적어도 서로 다른 네트워크 경로가 다른 DNS 결과를 받고 있다는 강한 단서가 됩니다.

2단계: Windows가 사용하는 DNS 서버부터 확인합니다

명령 프롬프트에서 다음을 실행합니다.

ipconfig /all

현재 사용 중인 Wi-Fi 또는 Ethernet 어댑터에서 다음 항목을 확인합니다.

• IPv4 주소
• 기본 게이트웨이
• DHCP 사용 여부
• DNS 서버 주소

가상 어댑터, 연결되지 않은 Ethernet, VPN 어댑터를 실제 인터넷 어댑터와 혼동하지 않습니다. 169.254.x.x 형태의 주소는 DHCP에서 정상 주소를 받지 못했을 가능성을 나타내므로 DNS보다 IP 할당 문제부터 해결해야 합니다.

PowerShell에서는 활성 어댑터별 DNS 서버를 다음처럼 확인할 수 있습니다.

Get-DnsClientServerAddress -AddressFamily IPv4 |
    Where-Object {$_.ServerAddresses.Count -gt 0} |
    Select-Object InterfaceAlias, ServerAddresses

결과 해석

• 공유기 주소가 DNS 서버로 표시됨: 공유기가 DNS 프록시 역할을 할 수 있습니다.
• 회사 내부 IP가 표시됨: 사내 도메인과 정책을 처리하는 DNS일 수 있으므로 임의 변경을 피합니다.
• VPN 어댑터 DNS가 우선됨: VPN 연결 상태에 따라 질의 경로가 달라질 수 있습니다.
• 예상하지 못한 DNS 주소: 보안 프로그램·VPN·수동 설정 여부를 확인합니다.

3단계: Resolve-DnsName으로 실제 응답을 확인합니다

PowerShell에서 문제가 발생한 정확한 호스트 이름을 질의합니다.

Resolve-DnsName www.example.com -Type A

example.com과 www.example.com은 서로 다른 이름이며 레코드도 다를 수 있습니다. 브라우저 주소창에 표시된 이름을 그대로 사용해야 합니다.

정상 응답

Name, Type, IPAddress가 출력되면 해당 경로에서 A 레코드 해석은 성공한 것입니다. 이후 브라우저 오류가 계속된다면 IPv6, HTTPS, 프록시, 브라우저 DoH 또는 웹서버 문제를 추가로 봅니다.

이름이 존재하지 않는다는 응답

현재 Windows 해석 경로가 NXDOMAIN을 받은 것입니다. 아직 도메인 자체가 사라졌다고 확정하지 말고 다른 DNS 서버와 비교합니다.

시간 초과

DNS 서버가 응답하지 않거나 패킷이 차단된 상황일 수 있습니다. NXDOMAIN과 달리 “이름이 없다”는 유효 응답조차 받지 못한 것입니다.

4단계: DNS 서버를 지정해 결과를 교차검증합니다

현재 설정된 DNS 서버와 다른 리졸버를 직접 지정하면 로컬 경로와 외부 관측 결과를 비교할 수 있습니다.

Resolve-DnsName www.example.com -Server 1.1.1.1 -Type A
Resolve-DnsName www.example.com -Server 8.8.8.8 -Type A

또는 다음처럼 nslookup을 사용할 수 있습니다.

nslookup www.example.com 1.1.1.1
nslookup www.example.com 8.8.8.8

비교표

공용 DNS 주소는 예시이며 모든 환경에서 최선이라는 뜻이 아닙니다. 자녀 보호, 기업 보안, 사내 전용 도메인, 지역 CDN 정책을 사용하는 환경에서는 기존 DNS가 필요합니다. 이 단계에서는 어댑터 설정을 바꾸지 않고 질의 대상만 지정해 비교합니다.

5단계: DNS 캐시를 확인한 뒤 필요한 경우에만 비웁니다

현재 캐시를 먼저 확인합니다.

Get-DnsClientCache | Where-Object {$_.Entry -like '*example.com*'}

또는 다음을 사용합니다.

ipconfig /displaydns

잘못되거나 오래된 레코드가 의심되면 캐시를 비웁니다.

ipconfig /flushdns

PowerShell에서는 다음 명령이 같은 목적을 가집니다.

Clear-DnsClientCache

이 명령이 하는 일

Windows DNS 클라이언트의 로컬 캐시를 비워 다음 질의에서 새 응답을 받게 합니다. 브라우저 기록·쿠키·암호·파일을 삭제하지 않습니다.

이 명령으로 해결되지 않는 경우

• 권한 DNS 서버의 레코드가 실제로 없음
• 공유기 또는 통신사 리졸버가 잘못된 응답을 캐시함
• Chrome이 별도의 보안 DNS 공급자를 사용함
• Hosts 파일이 이름을 가로챔
• VPN이 자체 DNS를 강제함

캐시를 반복해서 비우는 대신 한 번 비운 뒤 동일 질의를 다시 실행하고 결과가 어떻게 달라졌는지 기록합니다.

6단계: Hosts 파일이 질의를 가로채는지 확인합니다

Hosts 파일 기본 위치는 다음과 같습니다.

C:\Windows\System32\drivers\etc\hosts

관리자 권한으로 수정하기 전에 먼저 메모장으로 내용을 읽어봅니다. 문제가 되는 도메인, 0.0.0.0, 127.0.0.1, 오래된 서버 IP가 연결되어 있는지 확인합니다.

Hosts 항목을 무조건 모두 삭제해서는 안 됩니다. 개발 환경, 사내 시스템, 광고 차단, 보안 제품이 의도적으로 사용 중일 수 있습니다. 문제가 되는 줄을 확인하고 원래 용도를 파악한 뒤 변경하며, 수정 전 별도 위치에 백업본을 만듭니다.

Hosts 파일을 무시하고 DNS 서버만 질의해 비교하려면 PowerShell에서 다음 옵션을 활용할 수 있습니다.

Resolve-DnsName www.example.com -DnsOnly -NoHostsFile

이 명령의 결과는 DNS 서버 경로를 직접 비교하는 데 유용합니다. 일반 브라우저가 Hosts를 무시하도록 만드는 설정은 아닙니다.

7단계: Chrome·Edge의 보안 DNS(DoH)를 비교합니다

Chromium 계열 브라우저는 보안 DNS를 통해 DNS 질의를 HTTPS로 처리할 수 있습니다. 이 기능이 사용자 지정 공급자로 설정되어 있으면 Windows에 설정된 DNS와 다른 결과를 받을 수 있습니다.

Chrome에서는 일반적으로 다음 경로에서 확인합니다.

설정 → 개인정보 보호 및 보안 → 보안 → 보안 DNS 사용

Edge는 다음 경로에서 유사한 항목을 제공합니다.

설정 → 개인 정보, 검색 및 서비스 → 보안 → 보안 DNS

진단 방법

1. 현재 보안 DNS 사용 여부와 공급자를 기록합니다.
2. Windows Resolve-DnsName 결과와 브라우저 결과가 다른지 확인합니다.
3. 사용자 지정 공급자를 사용 중이라면 일시적으로 현재 서비스 공급자 사용 또는 관리 정책에 맞는 설정으로 비교합니다.
4. 변경 후 브라우저를 완전히 종료했다가 다시 실행합니다.

회사 관리 브라우저에는 정책이 적용될 수 있습니다. “관리 대상 브라우저” 표시가 있으면 로컬 설정을 우회하지 말고 관리자에게 문의합니다.

8단계: VPN·프록시·보안 프로그램의 DNS 경로를 확인합니다

VPN은 내부 DNS 서버, 분할 터널, NRPT 규칙을 사용해 특정 도메인만 다른 서버로 보낼 수 있습니다. VPN을 연결했을 때만 오류가 나거나, VPN을 끄면 사내 사이트만 안 열리는 경우가 대표적입니다.

확인할 항목은 다음과 같습니다.

• VPN 연결 전후 ipconfig /all의 DNS 서버 변화
• VPN 연결 전후 Resolve-DnsName 결과
• Windows 설정 → 네트워크 및 인터넷 → 프록시 상태
• 보안 프로그램의 웹 보호·DNS 필터링 기능
• 회사 환경의 NRPT 정책

NRPT 규칙을 읽기만 하려면 다음 명령을 사용할 수 있습니다.

Get-DnsClientNrptPolicy

결과가 있다고 무조건 삭제하지 않습니다. DirectAccess, VPN, 기업 보안 정책에 필요한 규칙일 수 있습니다.

9단계: 공유기 DNS 프록시와 네트워크 차이를 확인합니다

같은 공유기의 모든 기기에서 실패하지만 모바일 데이터에서는 정상이라면 공유기 또는 상위 DNS 경로를 의심할 수 있습니다.

다음 순서로 확인합니다.

1. 공유기 관리자 화면에서 WAN DNS와 DHCP DNS 배포 값을 기록합니다.
2. 공유기와 모뎀을 정상 종료 절차에 따라 재부팅합니다.
3. 펌웨어 업데이트와 보안 공지를 확인합니다.
4. 자녀 보호·유해 사이트 차단·보안 DNS 설정을 확인합니다.
5. 공용 리졸버 직접 질의 결과와 공유기 DNS 결과를 비교합니다.

공유기 공장 초기화는 SSID, Wi-Fi 암호, 포트포워딩, IPTV, 고정 할당 정보를 잃을 수 있으므로 마지막 단계입니다. 설정 백업과 통신사 구성 확인 없이 실행하지 않습니다.

10단계: 도메인 운영자라면 권한 DNS와 위임을 확인합니다

사이트 방문자가 아니라 도메인 소유자라면 클라이언트 설정만 바꿔서는 해결되지 않을 수 있습니다. 다음을 확인합니다.

• 도메인 등록이 만료되지 않았는지
• 등록기관의 네임서버 위임이 현재 DNS 공급자와 일치하는지
• apex 도메인과 www에 A·AAAA·CNAME 레코드가 존재하는지
• DNSSEC DS 레코드와 서명이 일치하는지
• 레코드 이름에 중복 도메인을 입력하지 않았는지
• TTL 변경 후 전파 시간을 고려했는지

권한 서버를 확인하려면 다음처럼 NS와 SOA 레코드를 조회합니다.

Resolve-DnsName example.com -Type NS
Resolve-DnsName example.com -Type SOA

NXDOMAIN은 캐시될 수 있습니다. 레코드를 새로 만든 직후에도 이전 부정 응답의 TTL 동안 일부 리졸버에서 실패가 계속될 수 있으므로, 여러 값을 반복 변경하면 진단이 더 어려워집니다. 변경 시각과 기존 값을 기록하고 한 번에 한 요소만 수정합니다.

11단계: TCP/IP 재설정과 네트워크 초기화는 마지막입니다

Microsoft가 안내하는 네트워크 명령에는 DNS 캐시 삭제, IP 갱신, Winsock 및 TCP/IP 재설정이 포함될 수 있습니다. 그러나 NXDOMAIN 원인이 권한 DNS나 브라우저 DoH라면 전체 스택 재설정은 불필요합니다.

다음 명령은 관리자 권한과 재부팅이 필요할 수 있으며 VPN·보안 프로그램에 영향을 줄 수 있습니다.

netsh winsock reset
netsh int ip reset

실행 전에는 다음 조건을 확인합니다.

• 여러 도메인이 모든 브라우저에서 실패함
• DNS·Hosts·DoH·VPN 비교로 원인을 찾지 못함
• 어댑터 설정 또는 Winsock 카탈로그 손상 정황이 있음
• 고정 IP·VPN·가상 어댑터 구성을 복원할 수 있음

Windows의 설정 → 네트워크 및 인터넷 → 고급 네트워크 설정 → 네트워크 초기화는 이보다 더 넓은 변경입니다. 가장 마지막에 사용합니다.

증거 조합별 최종 판단표

전문 점검이 필요한 경우

• 회사 도메인·Active Directory·VPN·NRPT 환경입니다.
• DNSSEC 검증 실패 또는 위임 불일치가 의심됩니다.
• 여러 지점에서 서로 다른 DNS 결과를 받습니다.
• 악성코드가 Hosts·프록시·DNS 설정을 변경한 정황이 있습니다.
• 공유기 DNS 하이재킹 또는 예상하지 못한 리졸버가 확인됩니다.
• 도메인 변경 후 메일·웹·인증 서비스가 동시에 장애를 겪습니다.
• 패킷 캡처로 UDP/TCP 53 또는 DoH 트래픽 분석이 필요합니다.

전문가에게 전달할 자료에는 발생 시각, 정확한 FQDN, 사용 DNS 서버, Resolve-DnsName 결과, 외부 DNS 비교, VPN·DoH 상태, NS·SOA 결과가 포함되어야 합니다. 내부 IP·사용자 이름·VPN 서버 주소는 공개 게시판에 그대로 올리지 않습니다.

NXDOMAIN 진단 체크리스트

• 도메인 철자와 www 포함 여부를 확인했다.
• 한 사이트와 전체 사이트 장애를 구분했다.
• 다른 기기와 모바일 데이터에서 비교했다.
• ipconfig /all로 실제 DNS 서버를 확인했다.
• Resolve-DnsName으로 기본 응답을 확인했다.
• 다른 리졸버를 지정해 결과를 비교했다.
• NXDOMAIN·SERVFAIL·timeout을 구분했다.
• 캐시를 확인한 뒤 한 번만 비웠다.
• Hosts 파일에서 해당 도메인을 확인했다.
• 브라우저 보안 DNS 공급자를 확인했다.
• VPN·프록시·NRPT 영향을 비교했다.
• 도메인 운영자는 NS·SOA·A/CNAME을 확인했다.
• 네트워크 초기화는 마지막으로 남겼다.

자주 묻는 질문

Q1. DNS_PROBE_FINISHED_NXDOMAIN은 인터넷이 끊겼다는 뜻인가요?

반드시 그렇지는 않습니다. 인터넷 연결은 정상이지만 특정 이름을 IP 주소로 해석하지 못할 때도 발생합니다.

Q2. DNS를 8.8.8.8로 바꾸면 무조건 해결되나요?

아닙니다. 비교 진단에는 유용하지만 Hosts·DoH·VPN·권한 DNS 문제는 해결되지 않을 수 있습니다. 사내 도메인은 공용 DNS에서 해석되지 않을 수 있습니다.

Q3. NXDOMAIN과 timeout은 무엇이 다른가요?

NXDOMAIN은 이름이 없다는 DNS 응답을 받은 것이고, timeout은 제한 시간 안에 응답을 받지 못한 것입니다.

Q4. DNS 캐시를 지우면 개인정보도 삭제되나요?

Windows DNS 캐시만 비우며 브라우저 암호·쿠키·파일은 삭제하지 않습니다.

Q5. IP 주소로 사이트가 열리면 DNS 문제인가요?

가능성은 커지지만 HTTPS 사이트는 인증서·가상 호스트 때문에 IP 직접 접속이 정상 동작하지 않을 수 있어 단독 판정 기준은 아닙니다.

Q6. Chrome에서만 오류가 납니다.

Chrome의 보안 DNS, 확장 프로그램, 브라우저 캐시를 Windows Resolve-DnsName 결과와 비교합니다.

Q7. Hosts 파일을 기본값으로 초기화해도 되나요?

개발·사내·보안 설정이 들어 있을 수 있으므로 먼저 백업하고 해당 항목의 목적을 확인해야 합니다.

Q8. VPN을 끄면 해결됩니다.

VPN이 자체 DNS나 NRPT 규칙을 적용하고 있을 가능성이 있습니다. 회사 VPN이라면 정책을 임의 변경하지 말고 관리자에게 결과를 전달합니다.

Q9. 스마트폰 모바일 데이터에서는 사이트가 열립니다.

Wi-Fi 공유기·통신사 DNS와 모바일 통신망이 서로 다른 응답을 받는 정황입니다. 각 리졸버 결과를 비교합니다.

Q10. 도메인 레코드를 만들었는데 바로 안 열립니다.

기존 NXDOMAIN 응답이 음수 캐시 TTL 동안 남을 수 있습니다. NS·SOA와 레코드가 정확하다면 변경을 반복하기보다 리졸버별 결과를 관찰합니다.

Q11. 네트워크 초기화를 바로 실행해도 되나요?

VPN·가상 어댑터·고정 IP 구성이 영향을 받을 수 있어 마지막 단계로 권장합니다.

Q12. DNS가 정상인데 사이트가 안 열립니다.

DNS 이후의 TCP 연결, HTTPS 인증서, 프록시, 웹 방화벽, 웹서버 상태를 확인해야 합니다.

마무리: DNS 서버를 바꾸기 전에 ‘누가 NXDOMAIN을 답했는지’ 찾습니다

DNS_PROBE_FINISHED_NXDOMAIN은 하나의 설정 오류 이름이 아닙니다. Windows 캐시, Hosts 파일, 네트워크 DNS, 브라우저 DoH, VPN, 권한 DNS 서버 중 어느 지점에서도 서로 다른 결과가 만들어질 수 있습니다.

가장 빠른 해결 순서는 범위를 나누고, 현재 DNS의 응답을 확인하고, 다른 리졸버와 비교한 뒤, 캐시·Hosts·DoH·VPN 순서로 좁혀가는 것입니다. 도메인 운영자라면 마지막으로 등록 상태와 NS·SOA·레코드 위임을 확인합니다. 이 과정을 거치면 효과 없는 네트워크 초기화와 반복적인 DNS 변경을 피할 수 있습니다.

현재 오류가 한 사이트에서만 발생하는지, 그리고 기본 DNS와 외부 DNS의 Resolve-DnsName 결과가 같은지 확인해 보셨나요? 도메인과 개인 네트워크 정보를 적절히 가린 뒤 두 결과를 비교하면 원인 계층을 훨씬 정확하게 좁힐 수 있습니다.

공식 참고 자료

• Microsoft Learn: Windows DNS 클라이언트 이름 해석 문제 해결
• Microsoft Learn: Windows DNSClient PowerShell 모듈
• Microsoft Learn: DNS 문제 해결 지침
• Microsoft 지원: Windows Hosts 파일 기본값 복원
• Microsoft 지원: Windows Wi-Fi 연결 문제 및 네트워크 초기화
• Microsoft 지원: Windows Ethernet 연결 문제 해결 명령
• Google Chrome 고객센터