Chrome: 모든 사이트에서 DNS_PROBE_FINISHED_BAD_CONFIG

안녕하세요, BlueByte입니다. Chrome 화면이 This site can't be reached와 그 아래 DNS_PROBE_FINISHED_BAD_CONFIG로 가득 찹니다 — 그것도 한 사이트가 아니라 모든 사이트에서요. 문구만 보면 페이지가 고장 난 것 같지만 아닙니다. Chrome이 자체 DNS probe를 돌린 뒤, 문제는 웹사이트가 아니라 이 컴퓨터의 DNS 설정이라고 판단한 것입니다. 오늘은 이 문구가 뜻하는 것, 네트워크가 아니라 DNS 문제임을 증명하는 법, 원인별로 붙여넣어 쓸 수 있는 명령으로 고치는 법, 그리고 예방까지 하나씩 짚어보겠습니다.

DNS_PROBE_FINISHED_BAD_CONFIG가 실제로 알려주는 것

Chrome은 같은 페이지의 몇 가지 변형을 보여줍니다:

This site can't be reached
The webpage at https://example.com/ might be temporarily down or it may
have moved permanently to a new web address.
DNS_PROBE_FINISHED_BAD_CONFIG

앞서 DNS_PROBE_STARTED나 DNS_PROBE_FINISHED_NO_INTERNET가 잠깐 스칠 수도 있습니다. Chromium은 이 상태를 명확한 문장으로 정의합니다: "The DNS configuration is wrong, or the servers are down or broken." 이 한 줄이 진단의 전부입니다 — Chrome이 운영체제에 호스트명 해석을 요청했고, resolver가 실패로 응답했으며, Chrome의 후속 probe가 DNS 자체가 오작동하는 부분임을 확인한 것입니다. 사이트는 멀쩡하고, 이 컴퓨터(또는 앞단의 공유기)의 이름 해석이 정상이 아닙니다.

사이트가 아니라 DNS 설정이 문제인 이유

이 오류는 몇 가지 구체적 원인에서 나옵니다:

• 오래된 DNS resolver 캐시 — 낡고 잘못된 레코드가 캐시돼 계속 제공됩니다.
• 잘못된 DHCP 리스 — 어댑터가 더는 동작하지 않는 IP·게이트웨이·DNS 서버 조합을 받았습니다.
• 손상된 Winsock 카탈로그 — Windows 네트워크 스택이 나쁜 상태로, VPN이나 "네트워크 부스터" 도구를 지운 뒤 자주 생깁니다.
• 닿지 않거나 잘못된 DNS 서버 — 설정된 resolver(대개 공유기)가 죽었거나, 응답을 멈춘 서버를 수동으로 지정해 둔 경우입니다.
• DHCP로 잘못된 DNS를 나눠 주는 공유기 — 그 네트워크의 모든 기기가 같은 오류를 겪으며, 이것이 결정적 단서입니다.

먼저 네트워크가 아니라 DNS인지 확인하기

추측하지 말고, 연결과 이름 해석을 분리하세요:

ping 8.8.8.8
ping google.com

ping 8.8.8.8은 성공하는데 ping google.com이 could not find host로 실패하면, 네트워크는 살아 있지만 이름 해석이 안 되는 것입니다 — 오류가 주장하는 바로 그대로죠. 이제 resolver에 직접 물어봅니다:

nslookup google.com

망가진 resolver는 이렇게 보입니다:

Server:  UnKnown
Address:  192.168.0.1
 
*** UnKnown can't find google.com: Server failed

여기서 Server failed나 타임아웃이 나오면 설정된 DNS 서버를 정면으로 가리키는 것입니다. ipconfig /all로 어댑터가 실제로 쓰는 서버를 확인하세요.

잘못된 설정을 붙들고 있는 캐시부터 비우기

OS resolver 캐시부터 비웁니다 — 낡은 레코드가 원인이라면 이것만으로 해결됩니다. Windows에서는:

ipconfig /flushdns

Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

macOS에서는:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

systemd-resolved를 쓰는 Linux에서는:

resolvectl flush-caches

Chrome도 프로세스 안에 자체 host 캐시를 둡니다. chrome://net-internals/#dns를 열고 Clear host cache를 누른 뒤 페이지를 새로고침하세요.

리스를 갱신하고 네트워크 스택 초기화하기

캐시를 비워도 안 되면 DHCP 리스를 버리고 새로 받습니다:

ipconfig /release
ipconfig /renew

Microsoft 문서는 /release를 서버에 DHCPRELEASE를 보내는 것, /renew를 설정을 갱신하는 것으로 설명합니다 — 둘을 함께 쓰면 잘못된 리스가 교체됩니다. 스택 자체가 손상됐다면 Winsock과 IP 스택을 초기화한 뒤 재부팅합니다:

netsh winsock reset
netsh int ip reset

여기서 파일은 아무것도 건드리지 않습니다 — 디스크가 아니라 네트워크 상태를 되돌리는 것입니다. Winsock 초기화가 적용되려면 재부팅이 필요한데, 이는 정상이며 뭔가 잘못됐다는 신호가 아니니 겁먹지 않아도 됩니다.

실제로 응답하는 DNS resolver를 가리키기

ISP나 공유기의 resolver가 망가진 부분이라면, 어댑터에 공개 resolver를 지정하세요(Wi-Fi는 ipconfig /all에 나온 어댑터 이름으로 바꾸세요):

netsh interface ip set dns name="Wi-Fi" static 8.8.8.8
netsh interface ip add dns name="Wi-Fi" 1.1.1.1 index=2

페이지를 새로고침합니다. 이제 사이트가 열리면, 원래의 DNS 서버가 오류가 지목한 "bad config"였던 것입니다.

멈춘 노트북, 처음부터 끝까지 따라가기

Windows 노트북 한 대가 모든 사이트에서 DNS_PROBE_FINISHED_BAD_CONFIG를 보였고, 같은 Wi-Fi의 휴대폰은 멀쩡했으니 문제는 노트북에 있었습니다. ping 8.8.8.8은 되고 ping google.com은 실패 — DNS 확정입니다. ipconfig /flushdns도, release/renew도 변화가 없었습니다. nslookup google.com은 공유기 192.168.0.1에 대해 Server failed를 냈고, DNS를 8.8.8.8로 바꾸자 모든 사이트가 즉시 열렸습니다. 근본 원인은 공유기의 resolver가 죽은 것이었고, 클라이언트 DNS 변경이 즉효였으며 공유기 재시작이 영구적 해결이었습니다.

고쳐졌는지 확인하고 재발을 막기

nslookup google.com을 돌려 실제 주소가 돌아오는지 본 다음 Chrome에서 페이지를 열어 확인하세요. 재발을 막으려면: 공유기를 주기적으로 재부팅하거나 믿을 만한 resolver를 지정하고, 검증할 수 없는 DNS 서버를 손으로 넣지 말며, Winsock을 몰래 바꾸는 "네트워크 최적화" 도구를 제거하세요.

NXDOMAIN·ERR_NAME_NOT_RESOLVED와 어떻게 다른가

여기서 정확한 문구가 값을 합니다. Chromium은 DNS_PROBE_FINISHED_NXDOMAIN을 "The DNS servers are working fine, so the domain must not exist"로 정의합니다 — 오타나 죽은 도메인이며, 그 사이트 하나만 실패합니다. DNS_PROBE_FINISHED_BAD_CONFIG는 DNS 자체가 망가져 모든 사이트가 실패합니다. ERR_NAME_NOT_RESOLVED는 NXDOMAIN 경우의 더 낮은 계층 버전입니다. 간단한 규칙: 한 사이트만 실패하면 그 사이트나 오타를 의심하고, 모든 사이트가 실패하면 이 컴퓨터의 DNS 문제입니다.