DNS_PROBE_FINISHED_NXDOMAIN은 사이트가 느리다는 뜻이 아니라 브라우저가 도메인 이름의 DNS 답을 찾지 못했다는 뜻입니다. Cloudflare를 막 연결한 직후라면 DNS 레코드, 네임서버 위임, 내 PC의 오래된 DNS 캐시를 같은 순서로 보지 말고 먼저 범위를 나누어 확인해야 합니다.
- 다른 휴대폰과 다른 네트워크에서도 같은 도메인이 열리지 않는지 확인합니다.
- 루트 도메인과
www또는 서브도메인 중 어느 이름이 실패하는지 따로 적습니다. - Windows 캐시를 지우기 전에
nslookup으로 현재 DNS 서버가 무엇을 답하는지 확인합니다.
1. DNS_PROBE_FINISHED_NXDOMAIN 오류가 뜻하는 것
DNS_PROBE_FINISHED_NXDOMAIN은 DNS 조회 과정이 멈춘 오류가 아닙니다. DNS 서버가 요청한 이름이 존재하지 않는다고 응답한 상태입니다. 이름은 존재하지만 조회한 종류의 레코드만 없는 응답이나 서버 처리 실패와는 구분합니다. 주소가 존재하지 않거나 현재 사용 중인 DNS 서버가 그 이름을 찾지 못할 때 나타납니다.
이 오류가 보인다고 곧바로 Cloudflare 설정이 잘못됐다고 단정할 수는 없습니다. 특정 PC에만 남은 음수 캐시, 공유기나 통신사의 DNS 응답, 레지스트라의 네임서버 전환 미반영, Cloudflare DNS 레코드 누락도 같은 오류 문구로 보일 수 있습니다.
| 보이는 상황 | 우선 의심할 범위 | 처음 확인할 것 |
|---|---|---|
| 집 PC 한 대에서만 실패 | 브라우저·Windows·공유기 DNS 캐시 | 다른 기기와 다른 네트워크에서 같은 주소 확인 |
| 모든 기기와 모든 네트워크에서 실패 | DNS 레코드 또는 네임서버 위임 | Cloudflare Zone 상태와 레코드 이름 |
| 루트 도메인은 열리는데 www만 실패 | www 레코드 누락 또는 오타 | Cloudflare DNS의 www A·CNAME 레코드 |
| Cloudflare 연결 직후부터 전체 실패 | 레지스트라 네임서버 위임·레코드 상태부터 확인 | Cloudflare가 할당한 두 네임서버와 Zone 상태 |
2. 캐시 삭제 전에 오류 범위부터 나누기
가장 먼저 휴대폰의 모바일 데이터와 다른 PC에서 같은 주소를 열어 봅니다. 한 기기에서만 실패하면 도메인 설정을 바꾸기 전에 그 기기의 DNS 캐시와 설정을 확인하는 편이 안전합니다.
반대로 여러 네트워크에서 모두 실패하면 로컬 캐시보다 DNS 제공자 쪽을 우선 봐야 합니다. 이때 루트 도메인 example.com, www.example.com, 실제 서비스 서브도메인을 각각 확인합니다. 이름 하나만 빠져도 나머지 주소는 정상일 수 있습니다.
브라우저 오류 문구 하나만 보고 DNS 레코드를 지우거나 새 레코드를 덧붙이지 마십시오. 먼저 어떤 이름이 어느 네트워크에서 실패하는지를 기록해야 변경 전후를 비교할 수 있습니다.
3. 내 PC의 DNS 캐시와 DNS 서버 확인
1단계: nslookup으로 캐시 밖 응답 확인
명령 프롬프트에서 nslookup example.com을 실행합니다. 여기서 example.com은 실제 도메인으로 바꿉니다. Microsoft는 nslookup이 Windows DNS 클라이언트 캐시를 사용하지 않고 설정된 DNS 서버에 질의한다고 안내합니다.
출력에 표시되는 DNS 서버 이름과 주소를 먼저 기록합니다. 브라우저와 nslookup이 서로 다른 DNS 서버를 사용할 수 있으므로 응답 차이만으로 캐시 문제를 확정하지 않습니다. 브라우저의 보안 DNS·관리 정책·프록시도 함께 확인하세요. 브라우저만 오류가 나지만 nslookup이 정상 IP를 돌려주면 브라우저나 Windows 캐시 쪽일 가능성이 높습니다. 반대로 Non-existent domain 또는 NXDOMAIN이 보이면 그 DNS 서버가 해당 이름을 찾지 못한 상태입니다.
2단계: 음수 캐시를 비우고 같은 명령을 다시 실행
관리자 권한 명령 프롬프트에서 ipconfig /displaydns로 실패한 이름이 캐시에 남아 있는지 확인한 뒤 ipconfig /flushdns를 실행합니다. 이 명령은 Windows DNS 클라이언트 해석기 캐시를 비우고 초기화합니다.
캐시를 비운 뒤 같은 nslookup과 브라우저 접속을 다시 확인합니다. 이 단계는 내 PC의 오래된 응답을 지우는 작업일 뿐 Cloudflare의 레코드나 레지스트라 설정을 고치지는 않습니다.
4. Cloudflare DNS와 네임서버 확인
1단계: Cloudflare Zone 상태 확인
Cloudflare 대시보드에서 도메인을 열고 Zone 상태를 확인합니다. 전체 DNS 설정으로 Cloudflare를 쓰려면 레지스트라에 Cloudflare가 할당한 두 네임서버가 정확히 등록되어 있어야 합니다.
DNS 조회는 정상이지만 Cloudflare에서 원본 서버로 연결하는 단계에서 502가 난다면 별도 진단이 필요합니다. 그 경우에는 Cloudflare Tunnel은 Healthy인데 WordPress가 502일 때 확인할 것을 참고할 수 있습니다.
상태가 Pending Nameserver Update라면 레지스트라에 변경이 반영되지 않았거나 다른 네임서버를 넣었을 수 있습니다. DNSSEC의 기존 DS 레코드가 새 DNS 제공자의 키와 맞지 않으면 검증 실패로 SERVFAIL이 발생할 수 있습니다. 이는 NXDOMAIN과 다른 응답이므로 조회 결과를 기록한 뒤 별도로 확인합니다. DNSSEC를 해제·변경할 때는 레지스트라와 Cloudflare의 현재 상태를 함께 확인합니다.
2단계: 실제로 실패한 호스트 이름의 레코드 확인
Cloudflare의 DNS 화면에서 브라우저에 입력한 이름을 그대로 찾습니다. 루트 도메인과 www는 별도 이름입니다. www가 실패한다면 루트 도메인이 정상이어도 www용 A 또는 CNAME 레코드가 빠졌을 수 있습니다.
| 확인 대상 | 확인 방법 | 주의할 점 |
|---|---|---|
| 루트 도메인 | DNS 목록에서 @ 또는 도메인 자체의 A·AAAA·CNAME 확인 |
서비스가 IPv6를 쓰지 않는데 오래된 AAAA가 남아 있지 않은지 확인 |
| www | www 이름의 A 또는 CNAME 확인 |
루트 도메인 레코드가 자동으로 www를 만들지 않음 |
| 서브도메인 | blog, api 등 실제 이름으로 검색 |
와일드카드 레코드와 개별 레코드의 의도를 구분 |
| CNAME 대상 | 대상 이름과 해당 서비스의 공식 연결 안내를 대조 | 오타·삭제된 서비스 확인. Tunnel 등 특수 대상은 서비스 안내 우선 |
5. 결과에 따라 원인을 좁히는 진단 순서
이 오류는 같은 화면을 보여도 출발점이 다릅니다. 아래 순서에서는 설정을 고치기 전에 관찰 결과로 다음 확인 위치를 정합니다.
| 관찰 결과 | 판정 | 다음 확인 |
|---|---|---|
| 다른 네트워크에서는 열리고 내 PC에서만 실패 | 로컬 또는 공유기 DNS 캐시 가능성 | nslookup 결과와 ipconfig /flushdns 전후 비교 |
| 모든 네트워크에서 특정 서브도메인만 실패 | 해당 호스트 레코드 누락·오타 가능성 | Cloudflare DNS에서 그 이름의 A·AAAA·CNAME 확인 |
| 모든 네트워크에서 루트·www 모두 실패, Zone이 Pending | 네임서버 위임 문제 가능성 | 레지스트라 네임서버와 Cloudflare 지정값을 한 글자씩 비교 |
| 레코드는 있는데 nslookup이 다른 DNS 서버에서만 실패 | 전파 중이거나 상위 DNS 캐시 차이 가능성 | 변경 시각·TTL·확인한 DNS 서버를 기록하고 재확인 |
| nslookup은 정상이나 브라우저만 실패 | 브라우저 보안 DNS·캐시·프록시·확장 프로그램 차이 가능성 | 시크릿 창과 다른 브라우저에서 재현 여부 확인 |
DNS 변경 뒤에는 예전 응답이 TTL 동안 여러 DNS 캐시에 남을 수 있습니다. 변경 시각, 수정한 레코드 이름, nslookup을 실행한 네트워크를 함께 남겨야 단순 전파 대기와 잘못된 설정을 구분할 수 있습니다.
6. 문제별 원인과 해결 방법
| 문제 | 가능한 원인 | 해결 방법 |
|---|---|---|
| Cloudflare 연결 뒤 루트 도메인도 www도 안 열림 | 네임서버 위임 미완료·불일치·DNSSEC 문제 | 레지스트라의 네임서버를 Cloudflare 지정값과 비교하고 Zone 상태 확인 |
| www만 NXDOMAIN 오류가 남 | www 레코드 누락 또는 이름 오타 | Cloudflare DNS에 www용 A·CNAME을 추가하기 전 기존 레코드와 서비스 안내 확인 |
| 내 PC만 계속 오류가 남 | 음수 DNS 캐시 또는 로컬 DNS 설정 | nslookup으로 응답 확인 후 ipconfig /flushdns 실행 |
| 특정 서브도메인만 안 열림 | 서브도메인 레코드 누락·잘못된 CNAME 대상 | 입력한 호스트명과 DNS 레코드 이름·대상을 한 글자씩 비교 |
| 레코드를 수정했는데 바로 반영되지 않음 | TTL과 DNS 캐시의 잔존 | 수정 시각과 TTL을 기록하고 동일한 DNS 서버에서 재확인 |
7. 주의사항
Cloudflare DNS 화면에서 레코드를 삭제하거나 네임서버를 바꾸는 작업은 메일·서브도메인·외부 서비스 연결까지 끊을 수 있습니다. 현재 레코드 전체를 내보내거나 화면으로 기록한 뒤 한 항목씩 수정합니다.
특히 MX, TXT, DKIM, SPF, DMARC 레코드는 웹사이트 접속과 별개로 메일 수신·발신에 사용됩니다. 웹 레코드 문제를 고치려다 이 레코드를 함께 삭제하지 않습니다.
Cloudflare 파트너 호스팅이나 부분 CNAME 설정을 쓰는 도메인은 일반적인 네임서버 전환 절차를 그대로 적용하면 안 됩니다. 이 경우 호스팅 제공자의 DNS 관리 화면과 안내 문서를 우선합니다.
8. 마지막 정리
DNS_PROBE_FINISHED_NXDOMAIN은 도메인 이름에 대한 DNS 답을 찾지 못했을 때 나타납니다. 같은 오류라도 한 기기만 실패하는지, 특정 호스트 이름만 실패하는지, Cloudflare Zone이 활성화됐는지에 따라 확인 위치가 달라집니다.
먼저 다른 네트워크에서 범위를 나누고 nslookup으로 DNS 서버 응답을 확인합니다. 그다음 Windows 캐시, Cloudflare DNS 레코드, 레지스트라 네임서버 위임 순서로 좁혀 가면 불필요하게 레코드를 삭제하거나 다시 만드는 일을 줄일 수 있습니다.
9. 출처와 자료 확인일
DNS 응답 구분·DNSSEC 설명 보완 자료 확인일: 2026-10-23. 아래 기존 자료 확인일과 구분합니다.
자료 확인일: 2026-10-20
이 글이 도움이 되었나요?