BlueByte
DNS_PROBE_FINISHED_NXDOMAINWorkaround

Chrome: DNS_PROBE_FINISHED_NXDOMAIN

작성 Haneul Seo2026년 8월 18일 업데이트5 min

안녕하세요, BlueByte입니다. NXDOMAIN은 사이트가 죽은 것처럼 들리지만 거의 그렇지 않습니다 — 그저 이름이 확인되지 않은 것이고, 그건 조회의 당신 쪽 문제입니다. 오늘은 정말 DNS인지 확인하고, 한 기기 문제인지 전부인지 가려내고, 맞는 곳에서 고치는 순서로 가보겠습니다.

NXDOMAIN이 실제로 뜻하는 것

페이지가 이렇게 로드에 실패합니다:

This site can't be reached
DNS_PROBE_FINISHED_NXDOMAIN

NXDOMAIN은 DNS 조회가 "그런 도메인 없음"을 반환했다는 뜻입니다. 이름이 주소로 확인되지 않은 것 — 사이트 서버가 아니라 DNS 문제입니다. 이 구분이 중요합니다: 사이트에 뭘 해도 소용없고, 해결은 확인하는 쪽 — 당신의 기기, 리졸버, 라우터 — 에 있습니다.

이름이 확인되지 않는 이유

  • 도메인 오타 — NXDOMAIN은 철자 틀린 이름이 반환하는 바로 그것.
  • 실패한 조회를 쥔 오래되거나 오염된 DNS 캐시.
  • 제대로 답하지 않는 리졸버 — 문제 있는 ISP 리졸버, 또는 이름을 차단하는 필터링 DNS.
  • 이름을 엉뚱한 곳으로 가로채는 hosts 파일 항목.
  • 내부 이름만 확인하고 나머지엔 NXDOMAIN을 주는 VPN·기업 split-DNS.

먼저 어디서 실패하는지 확인

무언가 건드리기 전에 좁힙니다. 같은 네트워크의 다른 기기에서 같은 사이트를 시도:

  • 한 기기만 실패하면 원인이 그 기기에 국한 — 캐시·리졸버·hosts.
  • 모든 기기가 실패하면 라우터나 리졸버에서 고침.

그다음 이름을 공개 서버로 직접 확인해 정말 DNS인지 봅니다:

nslookup example.com 8.8.8.8

공개 리졸버는 답하는데 평소 것이 안 하면 리졸버가 문제입니다. 8.8.8.8마저 NXDOMAIN이면 도메인이 정말 없는 것 — 철자를 다시 확인하세요.

싼 것부터 해결

  1. 주소 오타를 확인 — 가장 싼 해결.

  2. DNS 캐시를 비웁니다.

Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  1. 공개 리졸버로 전환 — 네트워크 DNS를 8.8.8.8·1.1.1.1로 바꾸고 새로고침.

  2. hosts 파일(Windows C:\Windows\System32\drivers\etc\hosts, macOS/Linux /etc/hosts)에 도메인을 엉뚱한 곳으로 가리키는 오래된 항목이 있는지 보고 제거.

실제 사례: 한 노트북, 오래된 리졸버

한 노트북이 같은 Wi‑Fi의 휴대폰에선 잘 열리는 사이트를 못 엽니다. 노트북만 실패하므로 문제는 그 노트북에 국한됩니다. nslookup example.com 8.8.8.8이 주소로 답해 DNS 자체는 되니 — 노트북의 캐시나 리졸버가 오래된 것입니다. ipconfig /flushdns 후 새로고침해도 실패해 어댑터 DNS를 1.1.1.1로 설정합니다. 페이지가 열립니다. 옛 ISP 리졸버가 실패한 조회를 캐싱했고, 공개 리졸버를 가리켜 우회했습니다.

로드되는지 확인하고 무엇이 고쳤는지 기록

페이지를 새로고침합니다. 열리면 어느 단계가 고쳤는지 기록하세요. chrome://net-internals/#dns → Clear host cache로 Chrome 자체 캐시도 비워 브라우저 수준의 오래된 항목을 배제할 수 있습니다.

다시 겪지 않으려면

믿을 만한 리졸버(공개 또는 잘 운영되는 내부 서버)를 쓰고, hosts 파일에 남은 테스트 항목을 두지 말고, VPN·필터링 DNS가 특정 이름에 NXDOMAIN을 낼 수 있음을 기억해 한 이름만 실패할 때 잠시 꺼서 테스트하세요.

연결 오류와의 구분

DNS_PROBE_FINISHED_NXDOMAIN은 확인 실패입니다. ERR_CONNECTION_REFUSED·ERR_CONNECTION_TIMED_OUT은 이름이 확인된 뒤 — 서버는 찾았는데 연결을 안 받은 것 — 이라 DNS가 아니라 도달성 문제입니다. NXDOMAIN이 보이면 사이트가 아니라 리졸버를 보세요.

관련 질문

제 컴퓨터만 실패하고 휴대폰은 사이트가 열립니다. 왜죠?

그 컴퓨터에 국한된 문제입니다 — 오래된 DNS 캐시, 잘못된 리졸버 설정, 또는 hosts 파일 항목. 캐시를 비우고 공개 리졸버로 바꾸세요.

VPN이나 광고 차단기와 관련 있나요?

그럴 수 있습니다. VPN이나 필터링 DNS 서비스가 특정 이름을 확인하지 못할 수 있습니다. 잠시 꺼서 테스트한 뒤 설정을 조정하세요.

OS 수준 flush로 안 됐습니다.

chrome://net-internals/#dns → Clear host cache로 Chrome 자체 DNS 캐시를 비우세요. Chrome은 OS와 별도로 캐싱합니다.

네트워크의 모든 기기가 한 사이트에서 실패합니다.

라우터에서 고치세요: 라우터의 DNS 서버를 공개 리졸버로 바꾸거나, 네트워크 전역 필터가 이름을 차단하는지 확인하세요.

8.8.8.8마저 NXDOMAIN입니다. 이제 어떻게 하죠?

도메인이 정말 확인되지 않습니다 — 철자가 틀렸거나, 만료됐거나, 아직 전파 안 됐을 수 있습니다. 철자를 확인하고, 새 도메인이면 DNS 전파를 기다리세요.

참고 자료

Haneul Seo

Infrastructure engineer · 10+ years running Linux fleets

같은 카테고리 다른 글

Start request repeated too quicklyFixed

systemd: Start request repeated too quickly

systemd는 StartLimitIntervalSec(기본 10초) 안에 StartLimitBurst(기본 5회)보다 많이 시작된 유닛의 시작을 거부하며, Restart=도 이 제한에 포함됩니다. 기본 RestartSec 100ms로는 크래시하는 서비스가 1초도 안 되어 다섯 번을 소진합니다. 저널에서 진짜 크래시를 찾아 고치고, reset-failed를 실행한 뒤, RestartSec로 재시작에 여유를 주세요.

systemd
Too many authentication failuresFixed

SSH: Received disconnect ... Too many authentication failures

agent가 서버가 허용하는 것보다 많은 키를 내밀고 있습니다. sshd가 들여다보는 공개키 하나하나가 MaxAuthTries 시도를 한 번씩 소모하고 — 기본 6회, 하드닝된 호스트에서는 3회인 경우가 많습니다 — 정작 맞는 키는 차례가 오기 전에 연결이 끊깁니다. IdentitiesOnly=yes와 명시적 IdentityFile로 키 하나를 고정하면 시도 횟수가 1로 떨어집니다.

OpenSSH
1722Fixed

Active Directory: 복제가 error 1722(The RPC server is unavailable)로 실패

RPC는 하위 계층이 연결에 실패했을 때 1722(0x6ba, RPC_S_SERVER_UNAVAILABLE)를 보고합니다. 따라서 진짜 원인은 RPC 자신이 아니라 DNS, 차단된 포트, 두 도메인 컨트롤러 중 한쪽의 호스트 설정입니다. repadmin이 어느 파트너가 실패하는지 알려주고, dcdiag /test:dns가 이름 해석을 배제하며, Test-NetConnection과 동적 포트 범위가 방화벽 문제를 가릅니다. 가장 흔한 실수는 TCP 135만 허용하고 49152–65535는 막아 둔 규칙입니다.

Windows Server Active Directory
Windows Server RDSFixed

Windows Server RDS: The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license

120일 RD Licensing 유예 기간이 끝났는데 세션 호스트가 쓸 수 있는 라이선스 서버가 없어 세션을 거부하는 상황입니다. GetGracePeriodDays 의 DaysLeft 가 0 이고 SpecifiedLSList 가 비어 있으면 몇 초 만에 확인됩니다. 해결은 활성화된 라이선스 서버와, 호스트 버전을 감당할 만큼 새 CAL 입니다. 2019 CAL 은 2022 세션 호스트를 서비스하지 못합니다. 여기에 배포 또는 Licensing 정책 설정과 두 서버 사이의 RPC 포트 개방이 따라옵니다.

Windows Server RDS
0x80070035 / Event ID 31017Workaround

Windows 11: NAS 공유 폴더를 열 때 "조직의 보안 정책이 인증되지 않은 게스트 액세스를 차단" (0x80070035)

Windows 10 Enterprise/Education/Pro for Workstations, Windows 11 Pro, Windows Server 2019 이후의 SMB 클라이언트는 기본적으로 게스트 로그온을 거부하고, Windows 11 24H2 Enterprise/Pro/Education 은 게스트 세션이 할 수 없는 SMB 서명까지 요구합니다. 그래서 게스트 접근만 제공하는 NAS 공유는 'block unauthenticated guest access' 대화상자, Error code 0x80070035, 또는 System error 3227320323 으로 실패하고, SmbClient/Security 로그에 Event ID 31017 'Rejected an insecure guest logon' 이 남습니다. Microsoft 가 권하는 해결은 NAS 에 실제 계정을 만들고 펌웨어에서 서명을 지원하게 하는 것입니다. Set-SmbClientConfiguration -EnableInsecureGuestLogons $true(24H2 는 -RequireSecuritySignature $false 까지)는 비상구이며, 그 클라이언트의 서명과 암호화를 포기하는 대가가 있습니다.

Windows (SMB client)
E: Could not get lock /var/lib/dpkg/lock-frontendFixed

Ubuntu/Debian: E: Could not get lock /var/lib/dpkg/lock-frontend — 누가 쥐고 있고 어떻게 기다리는지

다른 패키지 관리자, 대개 부팅 때 persistent systemd 타이머로 발화한 Ubuntu 의 unattended-upgrades 가 여러분의 apt-get 이 도는 동안 dpkg 프런트엔드 락을 쥐고 있는 것입니다. Ubuntu 는 apt 바이너리에만 binary::apt::DPkg::Lock::Timeout "120" 을 실어 두어서 apt-get 은 즉시 포기하고 apt 는 기다립니다. 메시지의 PID 를 읽고, 실행이 끝나게 두거나 apt-get 에 -o DPkg::Lock::Timeout=<초> 를 주고, dpkg --configure -a 는 실제로 중단된 실행 뒤에만 쓰고, 락 파일은 절대 지우지 마세요. 보유자가 종료하면 커널이 푸는 fcntl 락입니다.

APT (Ubuntu/Debian)