이 글의 목적은 브라우저에 “ERR_NAME_NOT_RESOLVED” 오류가 발생했을 때 현장에서 즉시 적용할 수 있는 DNS 캐시 플러시(ipconfig /flushdns)와 hosts 파일 재확인 절차를 체계적으로 제공하는 것이다.
1. 오류의 의미와 원인 구조 이해
ERR_NAME_NOT_RESOLVED는 브라우저가 입력한 도메인명을 IP 주소로 변환하지 못했음을 의미한다. 이는 DNS 질의가 실패했거나 잘못된 캐시·설정·로컬 매핑으로 인해 발생한다. 원인은 크게 네 가지로 분류한다.
- 로컬 문제: OS·브라우저 DNS 캐시 손상, 잘못된 hosts 파일 매핑, VPN/프록시 간섭, 보안 프로그램 차단 등이다.
- 네트워크 문제: 라우터·모뎀의 임시 오류, ISP DNS 장애, 사내 DNS 정책 충돌 등이다.
- 도메인 측 문제: 도메인 만료, 네임서버(NS) 설정 오류, A/AAAA/CNAME 레코드 누락 등이다.
- 일시적 전파/캐시 지연: 레코드 변경 직후 TTL 내 캐시가 갱신되지 않아 발생한다.
2. 가장 빠른 1차 조치 체크리스트
다음 순서대로 진행하면 시간 대비 해결 확률이 높다.
- 사내망·VPN·프록시를 잠시 해제하고 재시도한다.
- 브라우저 시크릿 창에서 재시도한다.
- DNS 캐시 플러시(운영체제)와 브라우저 캐시 초기화 후 재시도한다.
- 라우터 전원을 껐다가 30초 후 켠다.
- 공용 DNS(예: 8.8.8.8, 1.1.1.1)로 임시 전환하여 테스트한다.
- nslookup 또는 dig로 직접 질의하여 도메인 레코드 응답을 확인한다.
- hosts 파일에 잘못된 매핑이 있는지 확인한다.
3. DNS 캐시 플러시: 운영체제별 명령어
3.1 Windows
명령 프롬프트를 관리자 권한으로 실행한다.
ipconfig /flushdns
ipconfig /displaydns :: 캐시 확인 (선택)
ipconfig /registerdns :: 로컬 등록 갱신(선택)
netsh winsock reset :: 소켓 재설정(네트워크 이상 시 선택)실행 후 PC를 재부팅하거나 네트워크 어댑터를 비활성화 후 재활성화한다.
3.2 macOS
터미널에서 다음을 실행한다. macOS 버전에 따라 로그 메시지는 다를 수 있다.
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder필요 시 Wi-Fi를 껐다 켠다.
3.3 Linux
환경에 따라 다음 중 하나를 사용한다.
# systemd-resolved 사용 시
sudo resolvectl flush-caches
# nscd 사용 시
sudo service nscd restart
# 또는
sudo nscd -i hosts
# dnsmasq 사용 시
sudo service dnsmasq restart3.4 Android / iOS
- 비행기 모드를 10초간 켰다가 끈다.
- Wi-Fi 네트워크를 “삭제 후 재연결”한다.
- 모바일 브라우저 앱 캐시를 지운다. 필요 시 기기를 재부팅한다.
4. 브라우저 레벨 초기화
- 시크릿 모드에서 테스트하여 확장프로그램·쿠키 영향 여부를 분리한다.
- 브라우저 캐시·쿠키를 삭제한다.
- 필요 시 모든 확장프로그램을 일시 중지하고 테스트한다.
5. hosts 파일 재확인 절차
hosts 파일은 도메인→IP 매핑을 강제로 지정하는 로컬 설정이다. 잘못된 매핑이 있으면 DNS를 건너뛰고 오작동한다. 파일 위치는 다음과 같다.
| 운영체제 | 경로 | 권한/편집 방법 |
|---|---|---|
| Windows | C:\Windows\System32\drivers\etc\hosts | 메모장을 “관리자 권한으로 실행” 후 편집한다. |
| macOS/Linux | /etc/hosts | 터미널에서 관리자 권한으로 편집한다(예: sudo nano /etc/hosts). |
기본 예시는 다음과 같다.
127.0.0.1 localhost
::1 localhost테스트용으로 추가했던 줄이 남아있거나, 실제 IP가 변경되었는데 예전 IP가 남아 있는 경우를 제거·수정한다. 줄 앞에 #를 붙여 일시 비활성화할 수 있다.
6. DNS 서버 설정 점검 및 공용 DNS 전환 테스트
네트워크 어댑터의 DNS 서버 주소가 비어있거나 잘못 지정된 경우가 많다. 다음 방법으로 점검한다.
6.1 Windows
- 설정 > 네트워크 및 인터넷 > 어댑터 옵션에서 사용 중인 어댑터 속성을 연다.
- 인터넷 프로토콜 버전 4(TCP/IPv4) 속성에서 “다음 DNS 서버 주소 사용”을 선택한다.
- 우선 DNS: 1.1.1.1, 보조 DNS: 8.8.8.8 등으로 입력하고 확인한다.
6.2 macOS
- 시스템 설정 > 네트워크 > 사용 중인 인터페이스 > 상세 정보 > DNS를 연다.
- 1.1.1.1, 8.8.8.8을 추가한다.
6.3 라우터
라우터 관리 페이지에서 WAN DNS를 수동으로 1.1.1.1과 8.8.8.8로 지정하고 저장 후 재부팅한다. 사내 정책이 있는 경우 내부 DNS를 우선 사용한다.
7. nslookup과 dig로 근본 원인 분리
브라우저가 아닌 DNS 레벨에서 응답을 확인하면 원인 구분이 명확해진다.
7.1 Windows/macOS/Linux: nslookup
nslookup example.com
nslookup -type=A example.com
nslookup example.com 1.1.1.1 :: 특정 DNS로 질의정상 응답이면 도메인 측 레코드가 존재한다는 의미이다. 특정 DNS에서는 응답하고 기본 DNS에서는 실패한다면 DNS 서버 문제 가능성이 높다.
7.2 macOS/Linux: dig
dig example.com
dig A example.com @1.1.1.1
dig +trace example.com # 루트→TLD→권위(NS) 순 추적NOERROR와 함께 A/AAAA 레코드가 반환되면 레코드 자체는 정상이다. NXDOMAIN이면 레코드 미존재 또는 도메인 문제이다.
8. 브라우저만 실패할 때의 추가 점검
- 악성 확장프로그램 또는 잘못된 프록시 설정이 없는지 확인한다.
- 보안 프로그램의 웹 보호 기능이 도메인을 차단하는지 확인한다.
- 로컬 방화벽의 아웃바운드 규칙으로 DNS(UDP/TCP 53) 또는 DoH(HTTPS 443)가 차단되지 않았는지 확인한다.
9. 사내망·VPN 환경에서의 특수 이슈
- 스플릿 터널링이 꺼져 있을 때 외부 DNS 경로가 막힐 수 있다.
- 사내 DNS가 내부 전용 레코드를 반환하여 외부 접속이 실패하는 경우가 있다.
- 보안 게이트웨이에서 도메인을 분류 차단할 수 있다. 보안팀에 카테고리 해제 요청을 한다.
10. 도메인·레코드 측 문제를 빠르게 판별하는 방법
- 다른 네트워크(모바일 핫스팟)에서 접속해 본다. 여기서도 실패하면 도메인 측 문제 가능성이 높다.
nslookup -type=NS yourdomain.tld로 권한 네임서버(NS)를 확인하고 응답이 일관적인지 비교한다.- A/AAAA/CNAME 레코드가 누락되었거나 TTL이 과도하게 길지 확인한다.
- 도메인 만료 또는 네임서버 이전 중 전파 지연 여부를 확인한다.
11. 체계적 트러블슈팅 절차(현장용 표)
| 단계 | 점검 항목 | 명령/위치 | 판단 기준 | 조치 |
|---|---|---|---|---|
| 1 | 망 영향 분리 | 시크릿 창, VPN/프록시 해제 | 시크릿에서만 정상 | 브라우저 캐시 삭제, 확장 중지 |
| 2 | DNS 캐시 | Windows: ipconfig /flushdns | 캐시 초기화 후 개선 | 캐시·브라우저 초기화 유지 |
| 3 | DNS 서버 | 어댑터 DNS를 1.1.1.1로 변경 | 공용 DNS에서만 정상 | 기본 DNS 문제, 임시 우회 |
| 4 | hosts 파일 | Windows: C:\Windows\System32\drivers\etc\hosts | 의심 항목 존재 | 주석 처리 또는 삭제 |
| 5 | 도메인 응답 | nslookup/dig | NOERROR vs NXDOMAIN | 레코드 수정 또는 대기 |
| 6 | 장비 이슈 | 라우터 전원 재기동 | 재기동 후 정상 | 펌웨어 업데이트 검토 |
12. 현장에서 자주 발생하는 실수와 예방 팁
- 테스트용 hosts 매핑을 제거하지 않아 외부 IP 변경 뒤 계속 실패하는 경우가 많다.
- IPv6 환경에서 AAAA 레코드만 응답하거나, 방화벽이 IPv6를 차단해 절반만 연결되는 현상이 있다. 필요 시 IPv6 비활성화 후 재시험한다.
- 프록시 자동 설정(PAC) 파일이 오래되어 잘못된 경로로 트래픽이 전송되는 경우가 있다. PAC 최신화를 검토한다.
- 도메인 이전 직후 TTL을 길게 두면 전파 지연이 길어진다. 변경 작업 전 TTL을 낮추고 완료 후 원복한다.
13. 체크리스트: “ERR_NAME_NOT_RESOLVED” 10분 해결 루틴
- 시크릿 창 테스트, VPN/프록시 해제 후 재시도한다.
- Windows:
ipconfig /flushdns, macOS:dscacheutil -flushcache와killall -HUP mDNSResponder를 수행한다. - 브라우저 캐시·쿠키 삭제 후 재시도한다.
- DNS를 1.1.1.1/8.8.8.8로 임시 전환해 재시도한다.
nslookup example.com 1.1.1.1로 응답을 확인한다.- hosts 파일에서 도메인 관련 라인을 점검·정리한다.
- 라우터 재부팅 후 테스트한다.
- 도메인 레코드 변경 이력이 있으면 TTL 경과를 고려한다.
14. 문제 지속 시 심화 점검
- 방화벽 로그에서 DNS(53) 또는 DoH(443) 관련 차단 여부를 확인한다.
- 기업 환경에서는 내부 DNS 정책과 스플릿 DNS 사용 여부를 확인한다.
- 도메인 등록기관에서 도메인 상태와 네임서버 위임 상태를 점검한다.
- 네트워크 드라이버 및 라우터 펌웨어를 최신으로 유지한다.
FAQ
ipconfig /flushdns 후에도 효과가 없을 때는 무엇을 추가로 하나?
브라우저 캐시 삭제, netsh winsock reset 실행, 공용 DNS 전환, 라우터 재부팅 순으로 확대한다. 필요 시 보안 프로그램의 웹 보호 기능을 일시 중지하고 재시도한다.
hosts 파일을 비워도 되는가?
일반 사용 환경에서는 기본 localhost 항목만 있어도 된다. 테스트·내부망 목적의 매핑만 유지하고 불필요 항목은 주석 처리한다.
nslookup은 정상인데 브라우저만 실패한다. 원인은 무엇인가?
브라우저 확장, 프록시, DoH 설정, 쿠키·캐시 손상, 보안 프로그램 필터링이 주요 원인이다. 시크릿 모드·확장 중지·프록시 해제로 분리 진단한다.
도메인 레코드를 방금 수정했다. 언제 정상화되는가?
TTL에 따라 수분에서 수시간 소요된다. 글로벌 캐시 반영 지연이 있을 수 있으므로 공용 DNS로 교차 확인한다.
사내망에서만 접속이 안 된다. 어떻게 하나?
내부 DNS가 내부 IP로만 응답하거나 보안 게이트웨이가 차단할 수 있다. 네트워크 관리자에게 정책 확인과 예외 등록을 요청한다.